Message ID | 20240108183302.255055-5-afd@ti.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-19966-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:37c1:b0:101:2151:f287 with SMTP id y1csp1203192dyq; Mon, 8 Jan 2024 10:36:13 -0800 (PST) X-Google-Smtp-Source: AGHT+IHrLe5g/SQCSSQKzCEO+a/mZiMtkTfJB9987Xbx4W4cFAy5kt+DQQB4nzYQxExOr2bgeuGg X-Received: by 2002:a05:6512:1290:b0:50e:a789:dd3b with SMTP id u16-20020a056512129000b0050ea789dd3bmr2047376lfs.1.1704738973664; Mon, 08 Jan 2024 10:36:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704738973; cv=none; d=google.com; s=arc-20160816; b=c4qGHB6ZxcM/nKlAgyw4TkxwXzF+F/9OAOKExkvN8SR8Dq4Wzxu3nr53gkS0qOhBTf RRjEyAg8+Tv9aAdp686rgrXNsfiiJapWyDr4XHBJp6k/bhFGNk9p7OP7bO/Ku9gLLe/Q 03En54QgrmW1mCT0k55RrnybocAqh03nHHcTb4+99VGaQ5un2RGx2pw7Q0c5VA+1hrDI HSTIb8WY1bLlwzo7JeOurBp9WMyd8F+HpFo51cmaUFeeb75q7UfPNsRKqvHvuI0N/PXt bgTSgIrQDt7Rr5D/oWrlrsPyrg73KtYMRMg8/85XsKLVmgSvYrpNGmQO5zCuU/XcvrE2 uH/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=IvOnC4lLIEjNUz1mnrO+cPAxILKA9wZcK1lUrScpP9Q=; fh=KxsLCgRx1W60WvlrtjrMBLJnN6MITNW0a37pWS2ejYg=; b=XuRKFE/8pHw9Tlq2J3fVUCew39T8lNm+fQFFgCp6uOm51L5N3jsiI7I/BvEugNWYGJ BOfKEG/4Sq08Nc8w/fcugLlhkTXF1vcfmz1nUPAdfZFceKn2VSFszgQSeLqV/v7hXBcF VUOyTQ5kEjp6XfXxy0ZLyqdjNOiTnCF8DuBZ5CiSr4jKSo3gCuSjzyVw7W5VGTPPNcin 4Gp7WdFyPQce89Jiixk9pDBcb8Uj91Tp3cS6Y6+8eOJOTY1WqfGsR9QEO0pBmEJ/shcD JNKXcyc3fTgUvSYBMUGa5HIGGM6n3Mx5IzM2Y+dWpVByMYsMXcKTzJ18e3zRyGklhWQT g/yg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=MRE+pV3S; spf=pass (google.com: domain of linux-kernel+bounces-19966-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-19966-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id jo19-20020a170906f6d300b00a2a13930388si118772ejb.624.2024.01.08.10.36.13 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jan 2024 10:36:13 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-19966-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=MRE+pV3S; spf=pass (google.com: domain of linux-kernel+bounces-19966-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-19966-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 437851F224BB for <ouuuleilei@gmail.com>; Mon, 8 Jan 2024 18:36:13 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D246955C33; Mon, 8 Jan 2024 18:33:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ti.com header.i=@ti.com header.b="MRE+pV3S" X-Original-To: linux-kernel@vger.kernel.org Received: from lelv0143.ext.ti.com (lelv0143.ext.ti.com [198.47.23.248]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B8F4355786; Mon, 8 Jan 2024 18:33:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=ti.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ti.com Received: from fllv0035.itg.ti.com ([10.64.41.0]) by lelv0143.ext.ti.com (8.15.2/8.15.2) with ESMTP id 408IX8A9009981; Mon, 8 Jan 2024 12:33:08 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1704738788; bh=IvOnC4lLIEjNUz1mnrO+cPAxILKA9wZcK1lUrScpP9Q=; h=From:To:CC:Subject:Date:In-Reply-To:References; b=MRE+pV3SgTB/edyNUqBzfYck8AeafJwgJVY+aAOHf1SzZ1P2CP7RbJXp3MyGsb4Ez ssQSICwiAFsY/R9m9zx+O5n/1Lcf7isVTX3yXODL6/ShF4dbFm/Z4eBQwiWmvXzAqd STyI67BJFboosy6L4XI40FgkK5RAVdCJfUZM3zL4= Received: from DFLE115.ent.ti.com (dfle115.ent.ti.com [10.64.6.36]) by fllv0035.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 408IX88X061373 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 8 Jan 2024 12:33:08 -0600 Received: from DFLE105.ent.ti.com (10.64.6.26) by DFLE115.ent.ti.com (10.64.6.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Mon, 8 Jan 2024 12:33:08 -0600 Received: from lelvsmtp5.itg.ti.com (10.180.75.250) by DFLE105.ent.ti.com (10.64.6.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23 via Frontend Transport; Mon, 8 Jan 2024 12:33:08 -0600 Received: from lelvsmtp5.itg.ti.com ([10.249.40.136]) by lelvsmtp5.itg.ti.com (8.15.2/8.15.2) with ESMTP id 408IX3hD051691; Mon, 8 Jan 2024 12:33:07 -0600 From: Andrew Davis <afd@ti.com> To: Frank Binns <frank.binns@imgtec.com>, Donald Robson <donald.robson@imgtec.com>, Matt Coster <matt.coster@imgtec.com>, "H . Nikolaus Schaller" <hns@goldelico.com>, Adam Ford <aford173@gmail.com>, Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>, Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Maxime Ripard <mripard@kernel.org>, Thomas Zimmermann <tzimmermann@suse.de>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Chen-Yu Tsai <wens@csie.org>, Jernej Skrabec <jernej.skrabec@gmail.com>, Samuel Holland <samuel@sholland.org>, =?utf-8?q?Beno=C3=AEt_Cousson?= <bcousson@baylibre.com>, Tony Lindgren <tony@atomide.com>, Nishanth Menon <nm@ti.com>, Vignesh Raghavendra <vigneshr@ti.com>, Tero Kristo <kristo@kernel.org>, Paul Cercueil <paul@crapouillou.net> CC: <dri-devel@lists.freedesktop.org>, <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, <linux-sunxi@lists.linux.dev>, <linux-omap@vger.kernel.org>, <linux-mips@vger.kernel.org>, Andrew Davis <afd@ti.com> Subject: [PATCH RFC v2 04/11] ARM: dts: omap4: Add device tree entry for SGX GPU Date: Mon, 8 Jan 2024 12:32:55 -0600 Message-ID: <20240108183302.255055-5-afd@ti.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240108183302.255055-1-afd@ti.com> References: <20240108183302.255055-1-afd@ti.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1787548373617683806 X-GMAIL-MSGID: 1787548373617683806 |
Series |
Device tree support for Imagination Series5 GPU
|
|
Commit Message
Andrew Davis
Jan. 8, 2024, 6:32 p.m. UTC
Add SGX GPU device entry to base OMAP4 dtsi file.
Signed-off-by: Andrew Davis <afd@ti.com>
---
arch/arm/boot/dts/ti/omap/omap4.dtsi | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
Comments
Andrew Davis <afd@ti.com> writes: > Add SGX GPU device entry to base OMAP4 dtsi file. > > Signed-off-by: Andrew Davis <afd@ti.com> > --- Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Hi, I just comment on this example, but it applies almost the same for all other .dtsi changes. > Am 08.01.2024 um 19:32 schrieb Andrew Davis <afd@ti.com>: > > Add SGX GPU device entry to base OMAP4 dtsi file. > > Signed-off-by: Andrew Davis <afd@ti.com> > --- > arch/arm/boot/dts/ti/omap/omap4.dtsi | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/arch/arm/boot/dts/ti/omap/omap4.dtsi b/arch/arm/boot/dts/ti/omap/omap4.dtsi > index 2bbff9032be3e..559b2bfe4ca7c 100644 > --- a/arch/arm/boot/dts/ti/omap/omap4.dtsi > +++ b/arch/arm/boot/dts/ti/omap/omap4.dtsi > @@ -501,10 +501,11 @@ sgx_module: target-module@56000000 { > #size-cells = <1>; > ranges = <0 0x56000000 0x2000000>; > > - /* > - * Closed source PowerVR driver, no child device > - * binding or driver in mainline > - */ > + gpu@0 { I wonder why we don't add a "gpu:" label here. Almost all other subsystem nodes have one (e.g. emif:, aes:, dss:, dsi:, hdmi:, etc.), obviously for convenience when using a .dtsi file. It would allow a board-specific DTS to easily add status = "disabled" to avoid driver probing or disabling the GPU (e.g. if there is no display). > + compatible = "ti,omap4430-gpu", "img,powervr-sgx540"; It still appears to me that the "img,powervr-sgx540" (or similar) entry is redundant information. I have experimentally updated our openpvrsgx driver and we do not have any use for this information (at least in the kernel driver): https://github.com/goldelico/letux-kernel/commit/f2f7cb3b858ef255f52f2b82a8bb34c047337afe It shows how easy it is to derive the sgx version and revision number if we ever need it inside the driver. So if you want to keep a reference to powervr, it would suffice to have > + compatible = "ti,omap4430-gpu", "img,powervr-sgx"; Otherwise your device tree entries compile fine and seem to work (at least in a cursory test on PandaBoard ES). > + reg = <0x0 0x2000000>; /* 32MB */ > + interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>; > + }; > }; BR and thanks, Nikolaus
Hi, On Fri, Jan 12, 2024 at 06:33:58PM +0100, H. Nikolaus Schaller wrote: > > Am 08.01.2024 um 19:32 schrieb Andrew Davis <afd@ti.com>: > > > > Add SGX GPU device entry to base OMAP4 dtsi file. > > > > Signed-off-by: Andrew Davis <afd@ti.com> > > --- > > arch/arm/boot/dts/ti/omap/omap4.dtsi | 9 +++++---- > > 1 file changed, 5 insertions(+), 4 deletions(-) > > > > diff --git a/arch/arm/boot/dts/ti/omap/omap4.dtsi b/arch/arm/boot/dts/ti/omap/omap4.dtsi > > index 2bbff9032be3e..559b2bfe4ca7c 100644 > > --- a/arch/arm/boot/dts/ti/omap/omap4.dtsi > > +++ b/arch/arm/boot/dts/ti/omap/omap4.dtsi > > @@ -501,10 +501,11 @@ sgx_module: target-module@56000000 { > > #size-cells = <1>; > > ranges = <0 0x56000000 0x2000000>; > > > > - /* > > - * Closed source PowerVR driver, no child device > > - * binding or driver in mainline > > - */ > > + gpu@0 { > > I wonder why we don't add a "gpu:" label here. > > Almost all other subsystem nodes have one (e.g. emif:, aes:, dss:, dsi:, hdmi:, etc.), > obviously for convenience when using a .dtsi file. > > It would allow a board-specific DTS to easily add status = "disabled" to avoid driver > probing or disabling the GPU (e.g. if there is no display). There's no reason to disable it in the DT: the hardware block would still be there and it's rendering to memory so it still could be useful. If there's no display on the board and you really don't want the GPU driver, then you can disable the driver or block the module loading, but it should be a distro / package / user decision, not a DT / kernel one still. Maxime
Hi, > Am 15.01.2024 um 09:25 schrieb Maxime Ripard <mripard@kernel.org>: > > Hi, > > On Fri, Jan 12, 2024 at 06:33:58PM +0100, H. Nikolaus Schaller wrote: >>> Am 08.01.2024 um 19:32 schrieb Andrew Davis <afd@ti.com>: >>> >>> Add SGX GPU device entry to base OMAP4 dtsi file. >>> >>> Signed-off-by: Andrew Davis <afd@ti.com> >>> --- >>> arch/arm/boot/dts/ti/omap/omap4.dtsi | 9 +++++---- >>> 1 file changed, 5 insertions(+), 4 deletions(-) >>> >>> diff --git a/arch/arm/boot/dts/ti/omap/omap4.dtsi b/arch/arm/boot/dts/ti/omap/omap4.dtsi >>> index 2bbff9032be3e..559b2bfe4ca7c 100644 >>> --- a/arch/arm/boot/dts/ti/omap/omap4.dtsi >>> +++ b/arch/arm/boot/dts/ti/omap/omap4.dtsi >>> @@ -501,10 +501,11 @@ sgx_module: target-module@56000000 { >>> #size-cells = <1>; >>> ranges = <0 0x56000000 0x2000000>; >>> >>> - /* >>> - * Closed source PowerVR driver, no child device >>> - * binding or driver in mainline >>> - */ >>> + gpu@0 { >> >> I wonder why we don't add a "gpu:" label here. >> >> Almost all other subsystem nodes have one (e.g. emif:, aes:, dss:, dsi:, hdmi:, etc.), >> obviously for convenience when using a .dtsi file. >> >> It would allow a board-specific DTS to easily add status = "disabled" to avoid driver >> probing or disabling the GPU (e.g. if there is no display). > > There's no reason to disable it in the DT: the hardware block would > still be there and it's rendering to memory so it still could be useful. Well, if you know that the board does not have a dm3730 but a dm3725 without GPU it is better to disable the GPU completely instead of loading the driver and make it detect by some internal bits that it has no GPU on the SoC. > If there's no display on the board and you really don't want the GPU > driver, then you can disable the driver or block the module loading, but > it should be a distro / package / user decision, not a DT / kernel one > still. The same holds for aes: dss: dsi: hdmi: etc. If they are not used by some board file, they don't change a single bit of the DTB [1] which IMHO would be of reasonable concern to question additional labels. BR and thanks, Nikolaus [1] https://devicetree-specification.readthedocs.io/en/stable/source-language.html "Labels are only used in the devicetree source format and are not encoded into the DTB binary."
Hi, On Mon, 15 Jan 2024 09:55:00 +0100 "H. Nikolaus Schaller" <hns@goldelico.com> wrote: > > There's no reason to disable it in the DT: the hardware block would > > still be there and it's rendering to memory so it still could be useful. > > Well, if you know that the board does not have a dm3730 but a dm3725 without > GPU it is better to disable the GPU completely instead of loading the driver > and make it detect by some internal bits that it has no GPU on the SoC. > That is at least some valid reason. > > If there's no display on the board and you really don't want the GPU > > driver, then you can disable the driver or block the module loading, but > > it should be a distro / package / user decision, not a DT / kernel one > > still. > > The same holds for aes: dss: dsi: hdmi: etc. If they are not used by some > board file, they don't change a single bit of the DTB [1] which IMHO would > be of reasonable concern to question additional labels. There is some difference here, some hardware can just not be used without wired external pins, the gpu can be used even if no display is connected either to accelerate some remote access or you could use the gpu for something completely else... Maybe mining bitcoins if temperate gets too low to warm you pocket ;-) But as these labels do not harm, I have no strong opinion against it. Regards, Andreas
On Mon, Jan 15, 2024 at 09:55:00AM +0100, H. Nikolaus Schaller wrote: > Hi, > > > Am 15.01.2024 um 09:25 schrieb Maxime Ripard <mripard@kernel.org>: > > > > Hi, > > > > On Fri, Jan 12, 2024 at 06:33:58PM +0100, H. Nikolaus Schaller wrote: > >>> Am 08.01.2024 um 19:32 schrieb Andrew Davis <afd@ti.com>: > >>> > >>> Add SGX GPU device entry to base OMAP4 dtsi file. > >>> > >>> Signed-off-by: Andrew Davis <afd@ti.com> > >>> --- > >>> arch/arm/boot/dts/ti/omap/omap4.dtsi | 9 +++++---- > >>> 1 file changed, 5 insertions(+), 4 deletions(-) > >>> > >>> diff --git a/arch/arm/boot/dts/ti/omap/omap4.dtsi b/arch/arm/boot/dts/ti/omap/omap4.dtsi > >>> index 2bbff9032be3e..559b2bfe4ca7c 100644 > >>> --- a/arch/arm/boot/dts/ti/omap/omap4.dtsi > >>> +++ b/arch/arm/boot/dts/ti/omap/omap4.dtsi > >>> @@ -501,10 +501,11 @@ sgx_module: target-module@56000000 { > >>> #size-cells = <1>; > >>> ranges = <0 0x56000000 0x2000000>; > >>> > >>> - /* > >>> - * Closed source PowerVR driver, no child device > >>> - * binding or driver in mainline > >>> - */ > >>> + gpu@0 { > >> > >> I wonder why we don't add a "gpu:" label here. > >> > >> Almost all other subsystem nodes have one (e.g. emif:, aes:, dss:, dsi:, hdmi:, etc.), > >> obviously for convenience when using a .dtsi file. > >> > >> It would allow a board-specific DTS to easily add status = "disabled" to avoid driver > >> probing or disabling the GPU (e.g. if there is no display). > > > > There's no reason to disable it in the DT: the hardware block would > > still be there and it's rendering to memory so it still could be useful. > > Well, if you know that the board does not have a dm3730 but a dm3725 without > GPU it is better to disable the GPU completely instead of loading the driver > and make it detect by some internal bits that it has no GPU on the SoC. It shouldn't even be in the DTSI if it's not in the SoC. > > If there's no display on the board and you really don't want the GPU > > driver, then you can disable the driver or block the module loading, but > > it should be a distro / package / user decision, not a DT / kernel one > > still. > > The same holds for aes: dss: dsi: hdmi: etc. If they are not used by some > board file, they don't change a single bit of the DTB [1] which IMHO would > be of reasonable concern to question additional labels. Not really, no. If there's no HDMI connector, the HDMI controller is useless. A GPU without a display can still be useful, depending on the workload. Maxime
diff --git a/arch/arm/boot/dts/ti/omap/omap4.dtsi b/arch/arm/boot/dts/ti/omap/omap4.dtsi index 2bbff9032be3e..559b2bfe4ca7c 100644 --- a/arch/arm/boot/dts/ti/omap/omap4.dtsi +++ b/arch/arm/boot/dts/ti/omap/omap4.dtsi @@ -501,10 +501,11 @@ sgx_module: target-module@56000000 { #size-cells = <1>; ranges = <0 0x56000000 0x2000000>; - /* - * Closed source PowerVR driver, no child device - * binding or driver in mainline - */ + gpu@0 { + compatible = "ti,omap4430-gpu", "img,powervr-sgx540"; + reg = <0x0 0x2000000>; /* 32MB */ + interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>; + }; }; /*