linux-kernel - Re: [PATCH 01/21] dt-bindings: gpu: img: More explicit compatible strings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241106-flagstone-mandarin-8caf9da78f19@spud>
Date: Wed, 6 Nov 2024 16:57:41 +0000
From: Conor Dooley <conor@...nel.org>
To: Matt Coster <Matt.Coster@...tec.com>
Cc: Frank Binns <Frank.Binns@...tec.com>, David Airlie <airlied@...il.com>,
	Simona Vetter <simona@...ll.ch>,
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
	Maxime Ripard <mripard@...nel.org>,
	Thomas Zimmermann <tzimmermann@...e.de>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, Nishanth Menon <nm@...com>,
	Vignesh Raghavendra <vigneshr@...com>,
	Tero Kristo <kristo@...nel.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	Randolph Sapp <rs@...com>, Darren Etheridge <detheridge@...com>
Subject: Re: [PATCH 01/21] dt-bindings: gpu: img: More explicit compatible
 strings

On Wed, Nov 06, 2024 at 10:17:47AM +0000, Matt Coster wrote:
> On 05/11/2024 18:13, Conor Dooley wrote:
> > On Tue, Nov 05, 2024 at 03:58:07PM +0000, Matt Coster wrote:
> >> The current compatible strings are not specific enough to constrain the
> >> hardware in devicetree. For example, the current "img,img-axe" string
> >> refers to the entire family of Series AXE GPUs. The more specific
> >> "img,img-axe-1-16m" string refers to the AXE-1-16M GPU which, unlike the
> >> rest of its family, only uses a single power domain.
> > 
> > That's not true, you could apply the rules using the ti,am62-gpu
> > compatible, no?
> 
> The intent here is to draw a line between properties inherent to the IP
> core and choices made by the silicon vendor at integration time. The
> number of power domains is a property of the IP core, whereas the
> decision to use one or three clocks (next patch) is a vendor choice.

That's a different argument than the one in your commit message, but I
will accept it.

> >> Work is currently underway to add support for volcanic-based Imagination
> >> GPUs; also add a generic top-level "img,img-rogue" compatible string to
> >> allow for simpler differentiation in devicetrees.
> > 
> > This makes no sense, how does adding another fallback compatible make
> > it simpler? I have to assume that this means there will be geothermally
> > powered axes in the future and you want to tell the difference between
> > them and those pesky rogue axes that chop the heads off of naughty
> > children?
> 
> The intent is to add Volcanic bindings in img,powervr-volcanic.yaml, but
> the split between Rogue and Volcanic is... a bit weird. The BXS-4-64
> we're adding support for here is Rogue but, for example, the BXS-32-1024
> is Volcanic. I figured it would be nice to be able to grok from the
> devicetree which architecture a core is using without having to refer
> back to the bindings.

So not geothermally powered axes, but it was the rationale.

> The primary differentiator from a dt perspective is power topology. In
> Rogue, there are few (poorly named) power domains. Volcanic has (a)
> better domain names and (b) typically more granularity in domains,
> leading to actual dependency trees we need to care about besides the
> trivial A->B->... in Rogue.

Please add that detail to the commit message. Not all of it, but the
bits in the first paragraph.

Cheers,
Conor.

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)