Hi Maxime,
On Tue, May 25, 2021 at 12:39:40PM +0200, Maxime Ripard wrote:
>
> Hi Laurent,
>
> On Mon, May 24, 2021 at 07:04:43AM +0300, Laurent Pinchart wrote:
> > Hi Maxime,
> >
> > Thank you for the patch.
> >
> > On Thu, May 20, 2021 at 04:24:35PM +0200, Maxime Ripard wrote:
> > > New KMS properties come with a bunch of requirements to avoid each
> > > driver from running their own, inconsistent, set of properties,
> > > eventually leading to issues like property conflicts, inconsistencies
> > > between drivers and semantics, etc.
> > >
> > > Let's document what we expect.
> > >
> > > Cc: Alexandre Belloni <[email protected]>
> > > Cc: Alexandre Torgue <[email protected]>
> > > Cc: Alex Deucher <[email protected]>
> > > Cc: Alison Wang <[email protected]>
> > > Cc: Alyssa Rosenzweig <[email protected]>
> > > Cc: Andrew Jeffery <[email protected]>
> > > Cc: Andrzej Hajda <[email protected]>
> > > Cc: Anitha Chrisanthus <[email protected]>
> > > Cc: Benjamin Gaignard <[email protected]>
> > > Cc: Ben Skeggs <[email protected]>
> > > Cc: Boris Brezillon <[email protected]>
> > > Cc: Brian Starkey <[email protected]>
> > > Cc: Chen Feng <[email protected]>
> > > Cc: Chen-Yu Tsai <[email protected]>
> > > Cc: Christian Gmeiner <[email protected]>
> > > Cc: "Christian König" <[email protected]>
> > > Cc: Chun-Kuang Hu <[email protected]>
> > > Cc: Edmund Dea <[email protected]>
> > > Cc: Eric Anholt <[email protected]>
> > > Cc: Fabio Estevam <[email protected]>
> > > Cc: Gerd Hoffmann <[email protected]>
> > > Cc: Haneen Mohammed <[email protected]>
> > > Cc: Hans de Goede <[email protected]>
> > > Cc: "Heiko Stübner" <[email protected]>
> > > Cc: Huang Rui <[email protected]>
> > > Cc: Hyun Kwon <[email protected]>
> > > Cc: Inki Dae <[email protected]>
> > > Cc: Jani Nikula <[email protected]>
> > > Cc: Jernej Skrabec <[email protected]>
> > > Cc: Jerome Brunet <[email protected]>
> > > Cc: Joel Stanley <[email protected]>
> > > Cc: John Stultz <[email protected]>
> > > Cc: Jonas Karlman <[email protected]>
> > > Cc: Jonathan Hunter <[email protected]>
> > > Cc: Joonas Lahtinen <[email protected]>
> > > Cc: Joonyoung Shim <[email protected]>
> > > Cc: Jyri Sarha <[email protected]>
> > > Cc: Kevin Hilman <[email protected]>
> > > Cc: Kieran Bingham <[email protected]>
> > > Cc: Krzysztof Kozlowski <[email protected]>
> > > Cc: Kyungmin Park <[email protected]>
> > > Cc: Laurent Pinchart <[email protected]>
> > > Cc: Linus Walleij <[email protected]>
> > > Cc: Liviu Dudau <[email protected]>
> > > Cc: Lucas Stach <[email protected]>
> > > Cc: Ludovic Desroches <[email protected]>
> > > Cc: Marek Vasut <[email protected]>
> > > Cc: Martin Blumenstingl <[email protected]>
> > > Cc: Matthias Brugger <[email protected]>
> > > Cc: Maxime Coquelin <[email protected]>
> > > Cc: Maxime Ripard <[email protected]>
> > > Cc: Melissa Wen <[email protected]>
> > > Cc: Neil Armstrong <[email protected]>
> > > Cc: Nicolas Ferre <[email protected]>
> > > Cc: "Noralf Trønnes" <[email protected]>
> > > Cc: NXP Linux Team <[email protected]>
> > > Cc: Oleksandr Andrushchenko <[email protected]>
> > > Cc: Patrik Jakobsson <[email protected]>
> > > Cc: Paul Cercueil <[email protected]>
> > > Cc: Pengutronix Kernel Team <[email protected]>
> > > Cc: Philippe Cornu <[email protected]>
> > > Cc: Philipp Zabel <[email protected]>
> > > Cc: Qiang Yu <[email protected]>
> > > Cc: Rob Clark <[email protected]>
> > > Cc: Robert Foss <[email protected]>
> > > Cc: Rob Herring <[email protected]>
> > > Cc: Rodrigo Siqueira <[email protected]>
> > > Cc: Rodrigo Vivi <[email protected]>
> > > Cc: Roland Scheidegger <[email protected]>
> > > Cc: Russell King <[email protected]>
> > > Cc: Sam Ravnborg <[email protected]>
> > > Cc: Sandy Huang <[email protected]>
> > > Cc: Sascha Hauer <[email protected]>
> > > Cc: Sean Paul <[email protected]>
> > > Cc: Seung-Woo Kim <[email protected]>
> > > Cc: Shawn Guo <[email protected]>
> > > Cc: Stefan Agner <[email protected]>
> > > Cc: Steven Price <[email protected]>
> > > Cc: Sumit Semwal <[email protected]>
> > > Cc: Thierry Reding <[email protected]>
> > > Cc: Tian Tao <[email protected]>
> > > Cc: Tomeu Vizoso <[email protected]>
> > > Cc: Tomi Valkeinen <[email protected]>
> > > Cc: VMware Graphics <[email protected]>
> > > Cc: Xinliang Liu <[email protected]>
> > > Cc: Xinwei Kong <[email protected]>
> > > Cc: Yannick Fertre <[email protected]>
> > > Cc: Zack Rusin <[email protected]>
> > > Reviewed-by: Daniel Vetter <[email protected]>
> > > Signed-off-by: Maxime Ripard <[email protected]>
> > >
> > > ---
> > >
> > > Changes from v2:
> > > - Typos and wording reported by Daniel and Alex
> > > ---
> > > Documentation/gpu/drm-kms.rst | 19 +++++++++++++++++++
> > > 1 file changed, 19 insertions(+)
> > >
> > > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> > > index 87e5023e3f55..c28b464dd397 100644
> > > --- a/Documentation/gpu/drm-kms.rst
> > > +++ b/Documentation/gpu/drm-kms.rst
> > > @@ -463,6 +463,25 @@ KMS Properties
> > > This section of the documentation is primarily aimed at user-space
> > > developers.
> > > For the driver APIs, see the other sections.
> > >
> > > +Requirements
> > > +------------
> > > +
> > > +KMS drivers might need to add extra properties to support new features.
> > > +Each new property introduced in a driver need to meet a few
> >
> > s/need/needs/
> >
> > > +requirements, in addition to the one mentioned above.:
> >
> > s/above./above/
> >
> > > +
> > > +- It must be standardized, with some documentation to describe how the
> > > + property can be used.
> > > +
> > > +- It must provide a generic helper in the core code to register that
> > > + property on the object it attaches to.
> > > +
> > > +- Its content must be decoded by the core and provided in the object's
> > > + associated state structure. That includes anything drivers might want
> > > to
> > > + precompute, like :c:type:`struct drm_clip_rect <drm_clip_rect>` for
> > > planes.
> >
> > Does this effectively mean that we completely forbid driver-specific
> > properties ? While I agree that we should strive for standardization,
> > there are two issues that worry me. The first one is simple, we may need
> > to control features that would be very device-specific, and
> > standardizing properties doesn't seem to make much sense in that case.
>
> I'd say that we should make it clear in that case that it's
> driver-specific.
>
> > The second issue relates to properties that could be applicable to
> > multiple devices, but for which we have a single driver. Designing a
> > standard with a single data point usually leads to a bad design. I'm not
> > sure how to handle this correctly though, as we certainly don't want
> > this to be taken as an excuse to create driver-specific properties when
> > generic properties would make sense.
>
> The discussion that made us create that patch was about this property:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/sti/sti_hdmi.c#n170
>
> It's all kind of bad:
> - It kind of conflicts with the generic Colorspace property
> - It's not really a colorspace (Not that "Colorspace" is either)
> - It could have been made generic from the start
> - We don't have any knowledge on who uses it and why, so it's
> difficult to rework
>
> This was introduced before we had any kind of rule or documentation on
> the UAPI though, so there's no-one to blame really but we don't really
> want to have something like that happen again.
>
> I agree that doing something generic from the beginning can be
> difficult, but this is some userspace API that we will have to carry
> around forever, so it's worth it I guess?
>
> You have a point on the vendor properties though. Maybe we can require a
> vendor prefix for those? It would reduce the risk of a conflict.
My suggestion is to reword the documentation patch to suggest that driver
properties
should be first checked against generic properties and only if there is no
conflict
then they can be added to the driver.
TBH, mandating that new properties should go straight into the core on the first
implementation (which is likely to be applicable to only one, maybe two
drivers) is
increasing the maintainance burden. If userspace starts using those properties
and
later on we figure out we need a change in syntax, we will have to maintain
backwards
compatiblity with the old, broken properties. Adding a driver specific property
first
and then working it into a more generic one is simpler, as the UAPI surface is
smaller.
Best regards,
Liviu
>
> Maxime
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
