* [PATCH v2] Documentation: gpu: Mention the requirements for new properties @ 2021-05-20 14:24 Maxime Ripard 2021-05-24 4:04 ` Laurent Pinchart 0 siblings, 1 reply; 5+ messages in thread From: Maxime Ripard @ 2021-05-20 14:24 UTC (permalink / raw) To: dri-devel, Daniel Vetter, David Airlie, Maarten Lankhorst, Thomas Zimmermann, Maxime Ripard Cc: linux-doc, Jonathan Corbet, Alexandre Belloni, Alexandre Torgue, Alex Deucher, Alison Wang, Alyssa Rosenzweig, Andrew Jeffery, Andrzej Hajda, Anitha Chrisanthus, Benjamin Gaignard, Ben Skeggs, Boris Brezillon, Brian Starkey, Chen Feng, Chen-Yu Tsai, Christian Gmeiner, Christian König, Chun-Kuang Hu, Edmund Dea, Eric Anholt, Fabio Estevam, Gerd Hoffmann, Haneen Mohammed, Hans de Goede, Heiko Stübner, Huang Rui, Hyun Kwon, Inki Dae, Jani Nikula, Jernej Skrabec, Jerome Brunet, Joel Stanley, John Stultz, Jonas Karlman, Jonathan Hunter, Joonas Lahtinen, Joonyoung Shim, Jyri Sarha, Kevin Hilman, Kieran Bingham, Krzysztof Kozlowski, Kyungmin Park, Laurent Pinchart, Linus Walleij, Liviu Dudau, Lucas Stach, Ludovic Desroches, Marek Vasut, Martin Blumenstingl, Matthias Brugger, Maxime Coquelin, Maxime Ripard, Melissa Wen, Neil Armstrong, Nicolas Ferre, Noralf Trønnes, NXP Linux Team, Oleksandr Andrushchenko, Patrik Jakobsson, Paul Cercueil, Pengutronix Kernel Team, Philippe Cornu, Philipp Zabel, Qiang Yu, Rob Clark, Robert Foss, Rob Herring, Rodrigo Siqueira, Rodrigo Vivi, Roland Scheidegger, Russell King, Sam Ravnborg, Sandy Huang, Sascha Hauer, Sean Paul, Seung-Woo Kim, Shawn Guo, Stefan Agner, Steven Price, Sumit Semwal, Thierry Reding, Tian Tao, Tomeu Vizoso, Tomi Valkeinen, VMware Graphics, Xinliang Liu, Xinwei Kong, Yannick Fertre, Zack Rusin, Daniel Vetter 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 <alexandre.belloni@bootlin.com> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Alison Wang <alison.wang@nxp.com> Cc: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Cc: Andrew Jeffery <andrew@aj.id.au> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Anitha Chrisanthus <anitha.chrisanthus@intel.com> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Boris Brezillon <bbrezillon@kernel.org> Cc: Brian Starkey <brian.starkey@arm.com> Cc: Chen Feng <puck.chen@hisilicon.com> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: Chun-Kuang Hu <chunkuang.hu@kernel.org> Cc: Edmund Dea <edmund.j.dea@intel.com> Cc: Eric Anholt <eric@anholt.net> Cc: Fabio Estevam <festevam@gmail.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Haneen Mohammed <hamohammed.sa@gmail.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: "Heiko Stübner" <heiko@sntech.de> Cc: Huang Rui <ray.huang@amd.com> Cc: Hyun Kwon <hyun.kwon@xilinx.com> Cc: Inki Dae <inki.dae@samsung.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Jernej Skrabec <jernej.skrabec@siol.net> Cc: Jerome Brunet <jbrunet@baylibre.com> Cc: Joel Stanley <joel@jms.id.au> Cc: John Stultz <john.stultz@linaro.org> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Joonyoung Shim <jy0922.shim@samsung.com> Cc: Jyri Sarha <jyri.sarha@iki.fi> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Cc: Marek Vasut <marex@denx.de> Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Melissa Wen <melissa.srw@gmail.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: "Noralf Trønnes" <noralf@tronnes.org> Cc: NXP Linux Team <linux-imx@nxp.com> Cc: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Cc: Paul Cercueil <paul@crapouillou.net> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: Philippe Cornu <philippe.cornu@foss.st.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Qiang Yu <yuq825@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Robert Foss <robert.foss@linaro.org> Cc: Rob Herring <robh@kernel.org> Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Roland Scheidegger <sroland@vmware.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Sandy Huang <hjc@rock-chips.com> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Sean Paul <sean@poorly.run> Cc: Seung-Woo Kim <sw0312.kim@samsung.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Stefan Agner <stefan@agner.ch> Cc: Steven Price <steven.price@arm.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Tian Tao <tiantao6@hisilicon.com> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Tomi Valkeinen <tomba@kernel.org> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Xinliang Liu <xinliang.liu@linaro.org> Cc: Xinwei Kong <kong.kongxinwei@hisilicon.com> Cc: Yannick Fertre <yannick.fertre@foss.st.com> Cc: Zack Rusin <zackr@vmware.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maxime Ripard <maxime@cerno.tech> --- 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 +requirements, in addition to the one mentioned 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. + +- An IGT test must be submitted where reasonable. + Property Types and Blob Property Support ---------------------------------------- -- 2.31.1 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH v2] Documentation: gpu: Mention the requirements for new properties 2021-05-20 14:24 [PATCH v2] Documentation: gpu: Mention the requirements for new properties Maxime Ripard @ 2021-05-24 4:04 ` Laurent Pinchart 2021-05-25 10:39 ` Maxime Ripard 0 siblings, 1 reply; 5+ messages in thread From: Laurent Pinchart @ 2021-05-24 4:04 UTC (permalink / raw) To: Maxime Ripard Cc: dri-devel, Daniel Vetter, David Airlie, Maarten Lankhorst, Thomas Zimmermann, linux-doc, Jonathan Corbet, Alexandre Belloni, Alexandre Torgue, Alex Deucher, Alison Wang, Alyssa Rosenzweig, Andrew Jeffery, Andrzej Hajda, Anitha Chrisanthus, Benjamin Gaignard, Ben Skeggs, Boris Brezillon, Brian Starkey, Chen Feng, Chen-Yu Tsai, Christian Gmeiner, Christian König, Chun-Kuang Hu, Edmund Dea, Eric Anholt, Fabio Estevam, Gerd Hoffmann, Haneen Mohammed, Hans de Goede, Heiko Stübner, Huang Rui, Hyun Kwon, Inki Dae, Jani Nikula, Jernej Skrabec, Jerome Brunet, Joel Stanley, John Stultz, Jonas Karlman, Jonathan Hunter, Joonas Lahtinen, Joonyoung Shim, Jyri Sarha, Kevin Hilman, Kieran Bingham, Krzysztof Kozlowski, Kyungmin Park, Linus Walleij, Liviu Dudau, Lucas Stach, Ludovic Desroches, Marek Vasut, Martin Blumenstingl, Matthias Brugger, Maxime Coquelin, Maxime Ripard, Melissa Wen, Neil Armstrong, Nicolas Ferre, Noralf Trønnes, NXP Linux Team, Oleksandr Andrushchenko, Patrik Jakobsson, Paul Cercueil, Pengutronix Kernel Team, Philippe Cornu, Philipp Zabel, Qiang Yu, Rob Clark, Robert Foss, Rob Herring, Rodrigo Siqueira, Rodrigo Vivi, Roland Scheidegger, Russell King, Sam Ravnborg, Sandy Huang, Sascha Hauer, Sean Paul, Seung-Woo Kim, Shawn Guo, Stefan Agner, Steven Price, Sumit Semwal, Thierry Reding, Tian Tao, Tomeu Vizoso, Tomi Valkeinen, VMware Graphics, Xinliang Liu, Xinwei Kong, Yannick Fertre, Zack Rusin, Daniel Vetter 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 <alexandre.belloni@bootlin.com> > Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> > Cc: Alex Deucher <alexander.deucher@amd.com> > Cc: Alison Wang <alison.wang@nxp.com> > Cc: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> > Cc: Andrew Jeffery <andrew@aj.id.au> > Cc: Andrzej Hajda <a.hajda@samsung.com> > Cc: Anitha Chrisanthus <anitha.chrisanthus@intel.com> > Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> > Cc: Ben Skeggs <bskeggs@redhat.com> > Cc: Boris Brezillon <bbrezillon@kernel.org> > Cc: Brian Starkey <brian.starkey@arm.com> > Cc: Chen Feng <puck.chen@hisilicon.com> > Cc: Chen-Yu Tsai <wens@csie.org> > Cc: Christian Gmeiner <christian.gmeiner@gmail.com> > Cc: "Christian König" <christian.koenig@amd.com> > Cc: Chun-Kuang Hu <chunkuang.hu@kernel.org> > Cc: Edmund Dea <edmund.j.dea@intel.com> > Cc: Eric Anholt <eric@anholt.net> > Cc: Fabio Estevam <festevam@gmail.com> > Cc: Gerd Hoffmann <kraxel@redhat.com> > Cc: Haneen Mohammed <hamohammed.sa@gmail.com> > Cc: Hans de Goede <hdegoede@redhat.com> > Cc: "Heiko Stübner" <heiko@sntech.de> > Cc: Huang Rui <ray.huang@amd.com> > Cc: Hyun Kwon <hyun.kwon@xilinx.com> > Cc: Inki Dae <inki.dae@samsung.com> > Cc: Jani Nikula <jani.nikula@linux.intel.com> > Cc: Jernej Skrabec <jernej.skrabec@siol.net> > Cc: Jerome Brunet <jbrunet@baylibre.com> > Cc: Joel Stanley <joel@jms.id.au> > Cc: John Stultz <john.stultz@linaro.org> > Cc: Jonas Karlman <jonas@kwiboo.se> > Cc: Jonathan Hunter <jonathanh@nvidia.com> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> > Cc: Joonyoung Shim <jy0922.shim@samsung.com> > Cc: Jyri Sarha <jyri.sarha@iki.fi> > Cc: Kevin Hilman <khilman@baylibre.com> > Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> > Cc: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> > Cc: Kyungmin Park <kyungmin.park@samsung.com> > Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> > Cc: Linus Walleij <linus.walleij@linaro.org> > Cc: Liviu Dudau <liviu.dudau@arm.com> > Cc: Lucas Stach <l.stach@pengutronix.de> > Cc: Ludovic Desroches <ludovic.desroches@microchip.com> > Cc: Marek Vasut <marex@denx.de> > Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com> > Cc: Matthias Brugger <matthias.bgg@gmail.com> > Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> > Cc: Maxime Ripard <mripard@kernel.org> > Cc: Melissa Wen <melissa.srw@gmail.com> > Cc: Neil Armstrong <narmstrong@baylibre.com> > Cc: Nicolas Ferre <nicolas.ferre@microchip.com> > Cc: "Noralf Trønnes" <noralf@tronnes.org> > Cc: NXP Linux Team <linux-imx@nxp.com> > Cc: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> > Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> > Cc: Paul Cercueil <paul@crapouillou.net> > Cc: Pengutronix Kernel Team <kernel@pengutronix.de> > Cc: Philippe Cornu <philippe.cornu@foss.st.com> > Cc: Philipp Zabel <p.zabel@pengutronix.de> > Cc: Qiang Yu <yuq825@gmail.com> > Cc: Rob Clark <robdclark@gmail.com> > Cc: Robert Foss <robert.foss@linaro.org> > Cc: Rob Herring <robh@kernel.org> > Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> > Cc: Roland Scheidegger <sroland@vmware.com> > Cc: Russell King <linux@armlinux.org.uk> > Cc: Sam Ravnborg <sam@ravnborg.org> > Cc: Sandy Huang <hjc@rock-chips.com> > Cc: Sascha Hauer <s.hauer@pengutronix.de> > Cc: Sean Paul <sean@poorly.run> > Cc: Seung-Woo Kim <sw0312.kim@samsung.com> > Cc: Shawn Guo <shawnguo@kernel.org> > Cc: Stefan Agner <stefan@agner.ch> > Cc: Steven Price <steven.price@arm.com> > Cc: Sumit Semwal <sumit.semwal@linaro.org> > Cc: Thierry Reding <thierry.reding@gmail.com> > Cc: Tian Tao <tiantao6@hisilicon.com> > Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> > Cc: Tomi Valkeinen <tomba@kernel.org> > Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> > Cc: Xinliang Liu <xinliang.liu@linaro.org> > Cc: Xinwei Kong <kong.kongxinwei@hisilicon.com> > Cc: Yannick Fertre <yannick.fertre@foss.st.com> > Cc: Zack Rusin <zackr@vmware.com> > Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> > Signed-off-by: Maxime Ripard <maxime@cerno.tech> > > --- > > 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. 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. > +- An IGT test must be submitted where reasonable. > + > Property Types and Blob Property Support > ---------------------------------------- > -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2] Documentation: gpu: Mention the requirements for new properties 2021-05-24 4:04 ` Laurent Pinchart @ 2021-05-25 10:39 ` Maxime Ripard 2021-05-27 15:14 ` Liviu Dudau 2021-05-27 15:53 ` Laurent Pinchart 0 siblings, 2 replies; 5+ messages in thread From: Maxime Ripard @ 2021-05-25 10:39 UTC (permalink / raw) To: Laurent Pinchart Cc: dri-devel, Daniel Vetter, David Airlie, Maarten Lankhorst, Thomas Zimmermann, linux-doc, Jonathan Corbet, Alexandre Belloni, Alexandre Torgue, Alex Deucher, Alison Wang, Alyssa Rosenzweig, Andrew Jeffery, Andrzej Hajda, Anitha Chrisanthus, Benjamin Gaignard, Ben Skeggs, Boris Brezillon, Brian Starkey, Chen Feng, Chen-Yu Tsai, Christian Gmeiner, Christian König, Chun-Kuang Hu, Edmund Dea, Eric Anholt, Fabio Estevam, Gerd Hoffmann, Haneen Mohammed, Hans de Goede, Heiko Stübner, Huang Rui, Hyun Kwon, Inki Dae, Jani Nikula, Jernej Skrabec, Jerome Brunet, Joel Stanley, John Stultz, Jonas Karlman, Jonathan Hunter, Joonas Lahtinen, Joonyoung Shim, Jyri Sarha, Kevin Hilman, Kieran Bingham, Krzysztof Kozlowski, Kyungmin Park, Linus Walleij, Liviu Dudau, Lucas Stach, Ludovic Desroches, Marek Vasut, Martin Blumenstingl, Matthias Brugger, Maxime Coquelin, Melissa Wen, Neil Armstrong, Nicolas Ferre, Noralf Trønnes, NXP Linux Team, Oleksandr Andrushchenko, Patrik Jakobsson, Paul Cercueil, Pengutronix Kernel Team, Philippe Cornu, Philipp Zabel, Qiang Yu, Rob Clark, Robert Foss, Rob Herring, Rodrigo Siqueira, Rodrigo Vivi, Roland Scheidegger, Russell King, Sam Ravnborg, Sandy Huang, Sascha Hauer, Sean Paul, Seung-Woo Kim, Shawn Guo, Stefan Agner, Steven Price, Sumit Semwal, Thierry Reding, Tian Tao, Tomeu Vizoso, Tomi Valkeinen, VMware Graphics, Xinliang Liu, Xinwei Kong, Yannick Fertre, Zack Rusin, Daniel Vetter [-- Attachment #1: Type: text/plain, Size: 8131 bytes --] 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 <alexandre.belloni@bootlin.com> > > Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> > > Cc: Alex Deucher <alexander.deucher@amd.com> > > Cc: Alison Wang <alison.wang@nxp.com> > > Cc: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> > > Cc: Andrew Jeffery <andrew@aj.id.au> > > Cc: Andrzej Hajda <a.hajda@samsung.com> > > Cc: Anitha Chrisanthus <anitha.chrisanthus@intel.com> > > Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> > > Cc: Ben Skeggs <bskeggs@redhat.com> > > Cc: Boris Brezillon <bbrezillon@kernel.org> > > Cc: Brian Starkey <brian.starkey@arm.com> > > Cc: Chen Feng <puck.chen@hisilicon.com> > > Cc: Chen-Yu Tsai <wens@csie.org> > > Cc: Christian Gmeiner <christian.gmeiner@gmail.com> > > Cc: "Christian König" <christian.koenig@amd.com> > > Cc: Chun-Kuang Hu <chunkuang.hu@kernel.org> > > Cc: Edmund Dea <edmund.j.dea@intel.com> > > Cc: Eric Anholt <eric@anholt.net> > > Cc: Fabio Estevam <festevam@gmail.com> > > Cc: Gerd Hoffmann <kraxel@redhat.com> > > Cc: Haneen Mohammed <hamohammed.sa@gmail.com> > > Cc: Hans de Goede <hdegoede@redhat.com> > > Cc: "Heiko Stübner" <heiko@sntech.de> > > Cc: Huang Rui <ray.huang@amd.com> > > Cc: Hyun Kwon <hyun.kwon@xilinx.com> > > Cc: Inki Dae <inki.dae@samsung.com> > > Cc: Jani Nikula <jani.nikula@linux.intel.com> > > Cc: Jernej Skrabec <jernej.skrabec@siol.net> > > Cc: Jerome Brunet <jbrunet@baylibre.com> > > Cc: Joel Stanley <joel@jms.id.au> > > Cc: John Stultz <john.stultz@linaro.org> > > Cc: Jonas Karlman <jonas@kwiboo.se> > > Cc: Jonathan Hunter <jonathanh@nvidia.com> > > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> > > Cc: Joonyoung Shim <jy0922.shim@samsung.com> > > Cc: Jyri Sarha <jyri.sarha@iki.fi> > > Cc: Kevin Hilman <khilman@baylibre.com> > > Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> > > Cc: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> > > Cc: Kyungmin Park <kyungmin.park@samsung.com> > > Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> > > Cc: Linus Walleij <linus.walleij@linaro.org> > > Cc: Liviu Dudau <liviu.dudau@arm.com> > > Cc: Lucas Stach <l.stach@pengutronix.de> > > Cc: Ludovic Desroches <ludovic.desroches@microchip.com> > > Cc: Marek Vasut <marex@denx.de> > > Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com> > > Cc: Matthias Brugger <matthias.bgg@gmail.com> > > Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> > > Cc: Maxime Ripard <mripard@kernel.org> > > Cc: Melissa Wen <melissa.srw@gmail.com> > > Cc: Neil Armstrong <narmstrong@baylibre.com> > > Cc: Nicolas Ferre <nicolas.ferre@microchip.com> > > Cc: "Noralf Trønnes" <noralf@tronnes.org> > > Cc: NXP Linux Team <linux-imx@nxp.com> > > Cc: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> > > Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> > > Cc: Paul Cercueil <paul@crapouillou.net> > > Cc: Pengutronix Kernel Team <kernel@pengutronix.de> > > Cc: Philippe Cornu <philippe.cornu@foss.st.com> > > Cc: Philipp Zabel <p.zabel@pengutronix.de> > > Cc: Qiang Yu <yuq825@gmail.com> > > Cc: Rob Clark <robdclark@gmail.com> > > Cc: Robert Foss <robert.foss@linaro.org> > > Cc: Rob Herring <robh@kernel.org> > > Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> > > Cc: Roland Scheidegger <sroland@vmware.com> > > Cc: Russell King <linux@armlinux.org.uk> > > Cc: Sam Ravnborg <sam@ravnborg.org> > > Cc: Sandy Huang <hjc@rock-chips.com> > > Cc: Sascha Hauer <s.hauer@pengutronix.de> > > Cc: Sean Paul <sean@poorly.run> > > Cc: Seung-Woo Kim <sw0312.kim@samsung.com> > > Cc: Shawn Guo <shawnguo@kernel.org> > > Cc: Stefan Agner <stefan@agner.ch> > > Cc: Steven Price <steven.price@arm.com> > > Cc: Sumit Semwal <sumit.semwal@linaro.org> > > Cc: Thierry Reding <thierry.reding@gmail.com> > > Cc: Tian Tao <tiantao6@hisilicon.com> > > Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> > > Cc: Tomi Valkeinen <tomba@kernel.org> > > Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> > > Cc: Xinliang Liu <xinliang.liu@linaro.org> > > Cc: Xinwei Kong <kong.kongxinwei@hisilicon.com> > > Cc: Yannick Fertre <yannick.fertre@foss.st.com> > > Cc: Zack Rusin <zackr@vmware.com> > > Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> > > Signed-off-by: Maxime Ripard <maxime@cerno.tech> > > > > --- > > > > 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. Maxime [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2] Documentation: gpu: Mention the requirements for new properties 2021-05-25 10:39 ` Maxime Ripard @ 2021-05-27 15:14 ` Liviu Dudau 2021-05-27 15:53 ` Laurent Pinchart 1 sibling, 0 replies; 5+ messages in thread From: Liviu Dudau @ 2021-05-27 15:14 UTC (permalink / raw) To: Maxime Ripard Cc: Laurent Pinchart, dri-devel, Daniel Vetter, David Airlie, Maarten Lankhorst, Thomas Zimmermann, linux-doc, Jonathan Corbet, Alexandre Belloni, Alexandre Torgue, Alex Deucher, Alison Wang, Alyssa Rosenzweig, Andrew Jeffery, Andrzej Hajda, Anitha Chrisanthus, Benjamin Gaignard, Ben Skeggs, Boris Brezillon, Brian Starkey, Chen Feng, Chen-Yu Tsai, Christian Gmeiner, Christian König, Chun-Kuang Hu, Edmund Dea, Eric Anholt, Fabio Estevam, Gerd Hoffmann, Haneen Mohammed, Hans de Goede, Heiko Stübner, Huang Rui, Hyun Kwon, Inki Dae, Jani Nikula, Jernej Skrabec, Jerome Brunet, Joel Stanley, John Stultz, Jonas Karlman, Jonathan Hunter, Joonas Lahtinen, Joonyoung Shim, Jyri Sarha, Kevin Hilman, Kieran Bingham, Krzysztof Kozlowski, Kyungmin Park, Linus Walleij, Lucas Stach, Ludovic Desroches, Marek Vasut, Martin Blumenstingl, Matthias Brugger, Maxime Coquelin, Melissa Wen, Neil Armstrong, Nicolas Ferre, Noralf Trønnes, NXP Linux Team, Oleksandr Andrushchenko, Patrik Jakobsson, Paul Cercueil, Pengutronix Kernel Team, Philippe Cornu, Philipp Zabel, Qiang Yu, Rob Clark, Robert Foss, Rob Herring, Rodrigo Siqueira, Rodrigo Vivi, Roland Scheidegger, Russell King, Sam Ravnborg, Sandy Huang, Sascha Hauer, Sean Paul, Seung-Woo Kim, Shawn Guo, Stefan Agner, Steven Price, Sumit Semwal, Thierry Reding, Tian Tao, Tomeu Vizoso, Tomi Valkeinen, VMware Graphics, Xinliang Liu, Xinwei Kong, Yannick Fertre, Zack Rusin, Daniel Vetter 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 <alexandre.belloni@bootlin.com> > > > Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> > > > Cc: Alex Deucher <alexander.deucher@amd.com> > > > Cc: Alison Wang <alison.wang@nxp.com> > > > Cc: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> > > > Cc: Andrew Jeffery <andrew@aj.id.au> > > > Cc: Andrzej Hajda <a.hajda@samsung.com> > > > Cc: Anitha Chrisanthus <anitha.chrisanthus@intel.com> > > > Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> > > > Cc: Ben Skeggs <bskeggs@redhat.com> > > > Cc: Boris Brezillon <bbrezillon@kernel.org> > > > Cc: Brian Starkey <brian.starkey@arm.com> > > > Cc: Chen Feng <puck.chen@hisilicon.com> > > > Cc: Chen-Yu Tsai <wens@csie.org> > > > Cc: Christian Gmeiner <christian.gmeiner@gmail.com> > > > Cc: "Christian König" <christian.koenig@amd.com> > > > Cc: Chun-Kuang Hu <chunkuang.hu@kernel.org> > > > Cc: Edmund Dea <edmund.j.dea@intel.com> > > > Cc: Eric Anholt <eric@anholt.net> > > > Cc: Fabio Estevam <festevam@gmail.com> > > > Cc: Gerd Hoffmann <kraxel@redhat.com> > > > Cc: Haneen Mohammed <hamohammed.sa@gmail.com> > > > Cc: Hans de Goede <hdegoede@redhat.com> > > > Cc: "Heiko Stübner" <heiko@sntech.de> > > > Cc: Huang Rui <ray.huang@amd.com> > > > Cc: Hyun Kwon <hyun.kwon@xilinx.com> > > > Cc: Inki Dae <inki.dae@samsung.com> > > > Cc: Jani Nikula <jani.nikula@linux.intel.com> > > > Cc: Jernej Skrabec <jernej.skrabec@siol.net> > > > Cc: Jerome Brunet <jbrunet@baylibre.com> > > > Cc: Joel Stanley <joel@jms.id.au> > > > Cc: John Stultz <john.stultz@linaro.org> > > > Cc: Jonas Karlman <jonas@kwiboo.se> > > > Cc: Jonathan Hunter <jonathanh@nvidia.com> > > > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> > > > Cc: Joonyoung Shim <jy0922.shim@samsung.com> > > > Cc: Jyri Sarha <jyri.sarha@iki.fi> > > > Cc: Kevin Hilman <khilman@baylibre.com> > > > Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> > > > Cc: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> > > > Cc: Kyungmin Park <kyungmin.park@samsung.com> > > > Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> > > > Cc: Linus Walleij <linus.walleij@linaro.org> > > > Cc: Liviu Dudau <liviu.dudau@arm.com> > > > Cc: Lucas Stach <l.stach@pengutronix.de> > > > Cc: Ludovic Desroches <ludovic.desroches@microchip.com> > > > Cc: Marek Vasut <marex@denx.de> > > > Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com> > > > Cc: Matthias Brugger <matthias.bgg@gmail.com> > > > Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> > > > Cc: Maxime Ripard <mripard@kernel.org> > > > Cc: Melissa Wen <melissa.srw@gmail.com> > > > Cc: Neil Armstrong <narmstrong@baylibre.com> > > > Cc: Nicolas Ferre <nicolas.ferre@microchip.com> > > > Cc: "Noralf Trønnes" <noralf@tronnes.org> > > > Cc: NXP Linux Team <linux-imx@nxp.com> > > > Cc: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> > > > Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> > > > Cc: Paul Cercueil <paul@crapouillou.net> > > > Cc: Pengutronix Kernel Team <kernel@pengutronix.de> > > > Cc: Philippe Cornu <philippe.cornu@foss.st.com> > > > Cc: Philipp Zabel <p.zabel@pengutronix.de> > > > Cc: Qiang Yu <yuq825@gmail.com> > > > Cc: Rob Clark <robdclark@gmail.com> > > > Cc: Robert Foss <robert.foss@linaro.org> > > > Cc: Rob Herring <robh@kernel.org> > > > Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> > > > Cc: Roland Scheidegger <sroland@vmware.com> > > > Cc: Russell King <linux@armlinux.org.uk> > > > Cc: Sam Ravnborg <sam@ravnborg.org> > > > Cc: Sandy Huang <hjc@rock-chips.com> > > > Cc: Sascha Hauer <s.hauer@pengutronix.de> > > > Cc: Sean Paul <sean@poorly.run> > > > Cc: Seung-Woo Kim <sw0312.kim@samsung.com> > > > Cc: Shawn Guo <shawnguo@kernel.org> > > > Cc: Stefan Agner <stefan@agner.ch> > > > Cc: Steven Price <steven.price@arm.com> > > > Cc: Sumit Semwal <sumit.semwal@linaro.org> > > > Cc: Thierry Reding <thierry.reding@gmail.com> > > > Cc: Tian Tao <tiantao6@hisilicon.com> > > > Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> > > > Cc: Tomi Valkeinen <tomba@kernel.org> > > > Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> > > > Cc: Xinliang Liu <xinliang.liu@linaro.org> > > > Cc: Xinwei Kong <kong.kongxinwei@hisilicon.com> > > > Cc: Yannick Fertre <yannick.fertre@foss.st.com> > > > Cc: Zack Rusin <zackr@vmware.com> > > > Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> > > > Signed-off-by: Maxime Ripard <maxime@cerno.tech> > > > > > > --- > > > > > > 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! / --------------- ¯\_(ツ)_/¯ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2] Documentation: gpu: Mention the requirements for new properties 2021-05-25 10:39 ` Maxime Ripard 2021-05-27 15:14 ` Liviu Dudau @ 2021-05-27 15:53 ` Laurent Pinchart 1 sibling, 0 replies; 5+ messages in thread From: Laurent Pinchart @ 2021-05-27 15:53 UTC (permalink / raw) To: Maxime Ripard Cc: dri-devel, Daniel Vetter, David Airlie, Maarten Lankhorst, Thomas Zimmermann, linux-doc, Jonathan Corbet, Alexandre Belloni, Alexandre Torgue, Alex Deucher, Alison Wang, Alyssa Rosenzweig, Andrew Jeffery, Andrzej Hajda, Anitha Chrisanthus, Benjamin Gaignard, Ben Skeggs, Boris Brezillon, Brian Starkey, Chen Feng, Chen-Yu Tsai, Christian Gmeiner, Christian König, Chun-Kuang Hu, Edmund Dea, Eric Anholt, Fabio Estevam, Gerd Hoffmann, Haneen Mohammed, Hans de Goede, Heiko Stübner, Huang Rui, Hyun Kwon, Inki Dae, Jani Nikula, Jernej Skrabec, Jerome Brunet, Joel Stanley, John Stultz, Jonas Karlman, Jonathan Hunter, Joonas Lahtinen, Joonyoung Shim, Jyri Sarha, Kevin Hilman, Kieran Bingham, Krzysztof Kozlowski, Kyungmin Park, Linus Walleij, Liviu Dudau, Lucas Stach, Ludovic Desroches, Marek Vasut, Martin Blumenstingl, Matthias Brugger, Maxime Coquelin, Melissa Wen, Neil Armstrong, Nicolas Ferre, Noralf Trønnes, NXP Linux Team, Oleksandr Andrushchenko, Patrik Jakobsson, Paul Cercueil, Pengutronix Kernel Team, Philippe Cornu, Philipp Zabel, Qiang Yu, Rob Clark, Robert Foss, Rob Herring, Rodrigo Siqueira, Rodrigo Vivi, Roland Scheidegger, Russell King, Sam Ravnborg, Sandy Huang, Sascha Hauer, Sean Paul, Seung-Woo Kim, Shawn Guo, Stefan Agner, Steven Price, Sumit Semwal, Thierry Reding, Tian Tao, Tomeu Vizoso, Tomi Valkeinen, VMware Graphics, Xinliang Liu, Xinwei Kong, Yannick Fertre, Zack Rusin, Daniel Vetter Hi Maxime, On Tue, May 25, 2021 at 12:39:40PM +0200, Maxime Ripard wrote: > On Mon, May 24, 2021 at 07:04:43AM +0300, Laurent Pinchart wrote: > > 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 <alexandre.belloni@bootlin.com> > > > Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> > > > Cc: Alex Deucher <alexander.deucher@amd.com> > > > Cc: Alison Wang <alison.wang@nxp.com> > > > Cc: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> > > > Cc: Andrew Jeffery <andrew@aj.id.au> > > > Cc: Andrzej Hajda <a.hajda@samsung.com> > > > Cc: Anitha Chrisanthus <anitha.chrisanthus@intel.com> > > > Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> > > > Cc: Ben Skeggs <bskeggs@redhat.com> > > > Cc: Boris Brezillon <bbrezillon@kernel.org> > > > Cc: Brian Starkey <brian.starkey@arm.com> > > > Cc: Chen Feng <puck.chen@hisilicon.com> > > > Cc: Chen-Yu Tsai <wens@csie.org> > > > Cc: Christian Gmeiner <christian.gmeiner@gmail.com> > > > Cc: "Christian König" <christian.koenig@amd.com> > > > Cc: Chun-Kuang Hu <chunkuang.hu@kernel.org> > > > Cc: Edmund Dea <edmund.j.dea@intel.com> > > > Cc: Eric Anholt <eric@anholt.net> > > > Cc: Fabio Estevam <festevam@gmail.com> > > > Cc: Gerd Hoffmann <kraxel@redhat.com> > > > Cc: Haneen Mohammed <hamohammed.sa@gmail.com> > > > Cc: Hans de Goede <hdegoede@redhat.com> > > > Cc: "Heiko Stübner" <heiko@sntech.de> > > > Cc: Huang Rui <ray.huang@amd.com> > > > Cc: Hyun Kwon <hyun.kwon@xilinx.com> > > > Cc: Inki Dae <inki.dae@samsung.com> > > > Cc: Jani Nikula <jani.nikula@linux.intel.com> > > > Cc: Jernej Skrabec <jernej.skrabec@siol.net> > > > Cc: Jerome Brunet <jbrunet@baylibre.com> > > > Cc: Joel Stanley <joel@jms.id.au> > > > Cc: John Stultz <john.stultz@linaro.org> > > > Cc: Jonas Karlman <jonas@kwiboo.se> > > > Cc: Jonathan Hunter <jonathanh@nvidia.com> > > > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> > > > Cc: Joonyoung Shim <jy0922.shim@samsung.com> > > > Cc: Jyri Sarha <jyri.sarha@iki.fi> > > > Cc: Kevin Hilman <khilman@baylibre.com> > > > Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> > > > Cc: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> > > > Cc: Kyungmin Park <kyungmin.park@samsung.com> > > > Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> > > > Cc: Linus Walleij <linus.walleij@linaro.org> > > > Cc: Liviu Dudau <liviu.dudau@arm.com> > > > Cc: Lucas Stach <l.stach@pengutronix.de> > > > Cc: Ludovic Desroches <ludovic.desroches@microchip.com> > > > Cc: Marek Vasut <marex@denx.de> > > > Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com> > > > Cc: Matthias Brugger <matthias.bgg@gmail.com> > > > Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> > > > Cc: Maxime Ripard <mripard@kernel.org> > > > Cc: Melissa Wen <melissa.srw@gmail.com> > > > Cc: Neil Armstrong <narmstrong@baylibre.com> > > > Cc: Nicolas Ferre <nicolas.ferre@microchip.com> > > > Cc: "Noralf Trønnes" <noralf@tronnes.org> > > > Cc: NXP Linux Team <linux-imx@nxp.com> > > > Cc: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> > > > Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> > > > Cc: Paul Cercueil <paul@crapouillou.net> > > > Cc: Pengutronix Kernel Team <kernel@pengutronix.de> > > > Cc: Philippe Cornu <philippe.cornu@foss.st.com> > > > Cc: Philipp Zabel <p.zabel@pengutronix.de> > > > Cc: Qiang Yu <yuq825@gmail.com> > > > Cc: Rob Clark <robdclark@gmail.com> > > > Cc: Robert Foss <robert.foss@linaro.org> > > > Cc: Rob Herring <robh@kernel.org> > > > Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> > > > Cc: Roland Scheidegger <sroland@vmware.com> > > > Cc: Russell King <linux@armlinux.org.uk> > > > Cc: Sam Ravnborg <sam@ravnborg.org> > > > Cc: Sandy Huang <hjc@rock-chips.com> > > > Cc: Sascha Hauer <s.hauer@pengutronix.de> > > > Cc: Sean Paul <sean@poorly.run> > > > Cc: Seung-Woo Kim <sw0312.kim@samsung.com> > > > Cc: Shawn Guo <shawnguo@kernel.org> > > > Cc: Stefan Agner <stefan@agner.ch> > > > Cc: Steven Price <steven.price@arm.com> > > > Cc: Sumit Semwal <sumit.semwal@linaro.org> > > > Cc: Thierry Reding <thierry.reding@gmail.com> > > > Cc: Tian Tao <tiantao6@hisilicon.com> > > > Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> > > > Cc: Tomi Valkeinen <tomba@kernel.org> > > > Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> > > > Cc: Xinliang Liu <xinliang.liu@linaro.org> > > > Cc: Xinwei Kong <kong.kongxinwei@hisilicon.com> > > > Cc: Yannick Fertre <yannick.fertre@foss.st.com> > > > Cc: Zack Rusin <zackr@vmware.com> > > > Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> > > > Signed-off-by: Maxime Ripard <maxime@cerno.tech> > > > > > > --- > > > > > > 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? It is, no disagreement about that. Pushing driver authors to explore standardization of properties is a good idea. As long as we have a pragmatic approach and allow vendor-specific properties when it makes sense, I'll have no concern. > 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. I like the idea of a vendor prefix. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-05-27 15:53 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-05-20 14:24 [PATCH v2] Documentation: gpu: Mention the requirements for new properties Maxime Ripard 2021-05-24 4:04 ` Laurent Pinchart 2021-05-25 10:39 ` Maxime Ripard 2021-05-27 15:14 ` Liviu Dudau 2021-05-27 15:53 ` Laurent Pinchart
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).