Message-ID: <3dggaesvunebogkqvclz4imruhynrftkhsvmndm75vfccqwpa6@3zp3dgzpzta6>
Date: Thu, 21 Dec 2023 10:02:54 +0100
From: Maxime Ripard <mripard@...nel.org>
To: Andrew Davis <afd@...com>
Cc: "H. Nikolaus Schaller" <hns@...delico.com>, 
	Frank Binns <frank.binns@...tec.com>, Donald Robson <donald.robson@...tec.com>, 
	Matt Coster <matt.coster@...tec.com>, Adam Ford <aford173@...il.com>, 
	Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, 
	Thomas Zimmermann <tzimmermann@...e.de>, Rob Herring <robh+dt@...nel.org>, 
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>, Chen-Yu Tsai <wens@...e.org>, 
	Jernej Skrabec <jernej.skrabec@...il.com>, Samuel Holland <samuel@...lland.org>, 
	Benoît Cousson <bcousson@...libre.com>, Tony Lindgren <tony@...mide.com>, Nishanth Menon <nm@...com>, 
	Vignesh Raghavendra <vigneshr@...com>, Tero Kristo <kristo@...nel.org>, 
	Paul Cercueil <paul@...pouillou.net>, dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, 
	linux-sunxi@...ts.linux.dev, linux-omap@...r.kernel.org, linux-mips@...r.kernel.org
Subject: Re: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs

On Tue, Dec 19, 2023 at 11:19:49AM -0600, Andrew Davis wrote:
> On 12/18/23 4:54 AM, H. Nikolaus Schaller wrote:
> > 
> > 
> > > Am 18.12.2023 um 11:14 schrieb Maxime Ripard <mripard@...nel.org>:
> > > 
> > > On Mon, Dec 18, 2023 at 10:28:09AM +0100, H. Nikolaus Schaller wrote:
> > > > Hi Maxime,
> > > > 
> > > > > Am 15.12.2023 um 14:33 schrieb Maxime Ripard <mripard@...nel.org>:
> > > > > 
> > > > > > > 
> > > > > > > It's for a separate architecture, with a separate driver, maintained out
> > > > > > > of tree by a separate community, with a separate set of requirements as
> > > > > > > evidenced by the other thread. And that's all fine in itself, but
> > > > > > > there's very little reason to put these two bindings in the same file.
> > > > > > > 
> > > > > > > We could also turn this around, why is it important that it's in the
> > > > > > > same file?
> > > > > > 
> > > > > > Same vendor. And enough similarity in architectures, even a logical sequence
> > > > > > of development of versions (SGX = Version 5, Rogue = Version 6+) behind.
> > > > > > (SGX and Rogue seem to be just trade names for their architecture development).
> > > > > 
> > > > > Again, none of that matters for *where* the binding is stored.
> > > > 
> > > > So what then speaks against extending the existing bindings file as proposed
> > > > here?
> > > 
> > > I mean, apart from everything you quoted, then sure, nothing speaks
> > > against it.
> > > 
> > > > > > AFAIK bindings should describe hardware and not communities or drivers
> > > > > > or who is currently maintaining it. The latter can change, the first not.
> > > > > 
> > > > > Bindings are supposed to describe hardware indeed. Nothing was ever said
> > > > > about where those bindings are supposed to be located.
> > > > > 
> > > > > There's hundreds of other YAML bindings describing devices of the same
> > > > > vendors and different devices from the same generation.
> > > > 
> > > > Usually SoC seem to be split over multiple files by subsystem. Not by versions
> > > > or generations. If the subsystems are similar enough they share the same bindings
> > > > doc instead of having one for each generation duplicating a lot of code.
> > > > 
> > > > Here is a comparable example that combines multiple vendors and generations:
> > > > 
> > > > Documentation/devicetree/bindings/usb/generic-ehci.yaml
> > > 
> > > EHCI is a single interface for USB2.0 controllers. It's a standard API,
> > > and is made of a single driver that requires minor modifications to deal
> > > with multiple devices.
> > > 
> > > We're very far from the same situation here.
> > 
> > How far are we really? And, it is the purpose of the driver to handle different cases.
> > 
> > That there are currently two drivers is just a matter of history and not a necessity.
> > 
> > > 
> > > > > If anything it'll make it easier for you. I'm really not sure why it is
> > > > > controversial and you're fighting this so hard.
> > > > 
> > > > Well, you made it controversial by proposing to split what IMHO belongs together.
> > > 
> > > No, reviews aren't controversial.
> > > The controversy started when you chose
> > > to oppose it while you could have just rolled with it.
> > 
> > Well, you asked
> > 
> > "I think it would be best to have a separate file for this, img,sgx.yaml
> > maybe?"
> > 
> > and
> > 
> > "Because it's more convenient?"
> > 
> > I understood that as an invitation for discussing the pros and cons and working out the
> > most convenient solution. And that involves playing the devil's advocate which of course
> > is controversial by principle.
> > 
> > Now, IMHO all the pros and cons are on the table and the question is who makes a decision
> > how to go.
> > 
> 
> As much as I would land on the side of same file for both, the answer to this question
> is simple: the maintainer makes the decision :) So I'll respin with separate binding files.
>
> The hidden unaddressed issue here is that by making these bindings separate it implies
> they are not on equal footing (i.e. pre-series6 GPUs are not true "powervr" and so do not
> belong in img,powervr.yaml).

No, not really. As far as I'm concerned, the only unequal footing here
is that one driver is in-tree and the other isn't, but this situation
was handled nicely for Mali GPUs and lima that used to be in the same
situation for example.

The situation is simple, really: bindings are supposed to be backward
compatible, period. If we ever make a change to that binding that isn't,
you will be well within your right to complain because your driver is
now broken.

> So if no one objects I'd also like to do the rename of that
> file as suggested before and have:
> 
> img,powervr-sgx.yaml
> img,powervr-rogue.yaml

Sounds good to me.

Maxime

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

Powered by blists - more mailing lists