[PATCH 1/5] drm/docs: Discourage adding more to kms-properties.csv

[PATCH 1/5] drm/docs: Discourage adding more to kms-properties.csv

[Daniel Vetter]

Motivated by patch review.

The table is really hard to read in source form, hard to edit, and
we've moved away to more focused sections about specific features and
how they're exposed in properties.

Those sections can then more easily enumerate options, link to helper
functions and other parts of the docs. All things that get ugly real
fast in the docs.

Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 Documentation/gpu/drm-kms.rst | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 2dcf5b42015d..56a3780e39b8 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -547,8 +547,9 @@ Explicit Fencing Properties
 Existing KMS Properties
 -----------------------
 
-The following table gives description of drm properties exposed by
-various modules/drivers.
+The following table gives description of drm properties exposed by various
+modules/drivers. Because this table is very unwieldy, do not add any new
+properties here. Instead document them in a section above.
 
 .. csv-table::
    :header-rows: 1
-- 
2.15.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/5] drm/docs: Align layout of optional plane blending properties

[Daniel Vetter]

Just a bit of drive-by OCD. All the other property docs use enumerations,
for some nice visual consistency. It also neatly highlights the property
name.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 drivers/gpu/drm/drm_blend.c | 18 ++++++++++--------
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index 4c62dff14893..5a81e1b4c076 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -88,15 +88,17 @@
  * On top of this basic transformation additional properties can be exposed by
  * the driver:
  *
- * - Rotation is set up with drm_plane_create_rotation_property(). It adds a
- *   rotation and reflection step between the source and destination rectangles.
- *   Without this property the rectangle is only scaled, but not rotated or
- *   reflected.
+ * rotation:
+ *	Rotation is set up with drm_plane_create_rotation_property(). It adds a
+ *	rotation and reflection step between the source and destination rectangles.
+ *	Without this property the rectangle is only scaled, but not rotated or
+ *	reflected.
  *
- * - Z position is set up with drm_plane_create_zpos_immutable_property() and
- *   drm_plane_create_zpos_property(). It controls the visibility of overlapping
- *   planes. Without this property the primary plane is always below the cursor
- *   plane, and ordering between all other planes is undefined.
+ * zpos:
+ *	Z position is set up with drm_plane_create_zpos_immutable_property() and
+ *	drm_plane_create_zpos_property(). It controls the visibility of overlapping
+ *	planes. Without this property the primary plane is always below the cursor
+ *	plane, and ordering between all other planes is undefined.
  *
  * Note that all the property extensions described here apply either to the
  * plane or the CRTC (e.g. for the background color, which currently is not
-- 
2.15.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/5] drm/docs: Document "scaling mode" property better

[Daniel Vetter]

Move it out of the csv dungeon.

While at it add the missing link to the helper functions for setting
up the "panel rotation" property.

Also OCD how we list enum property values and their corresponding docs.
Going for a nest definition list seams cleanest, no need for also making
it an uordered list.

Cc: Sean Paul <seanpaul@chromium.org>
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 Documentation/gpu/kms-properties.csv |  1 -
 drivers/gpu/drm/drm_connector.c      | 32 ++++++++++++++++++++++++++++----
 2 files changed, 28 insertions(+), 5 deletions(-)

diff --git a/Documentation/gpu/kms-properties.csv b/Documentation/gpu/kms-properties.csv
index 927b65e14219..6b28b014cb7d 100644
--- a/Documentation/gpu/kms-properties.csv
+++ b/Documentation/gpu/kms-properties.csv
@@ -1,5 +1,4 @@
 Owner Module/Drivers,Group,Property Name,Type,Property Values,Object attached,Description/Restrictions
-,,“scaling mode”,ENUM,"{ ""None"", ""Full"", ""Center"", ""Full aspect"" }",Connector,"Supported by: amdgpu, gma500, i915, nouveau and radeon."
 ,DVI-I,“subconnector”,ENUM,"{ “Unknown”, “DVI-D”, “DVI-A” }",Connector,TBD
 ,,“select subconnector”,ENUM,"{ “Automatic”, “DVI-D”, “DVI-A” }",Connector,TBD
 ,TV,“subconnector”,ENUM,"{ ""Unknown"", ""Composite"", ""SVIDEO"", ""Component"", ""SCART"" }",Connector,TBD
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 16b9c3810af2..b3cde897cd80 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -849,13 +849,13 @@ DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
  *
  *	The value of this property can be one of the following:
  *
- *	- DRM_MODE_CONTENT_PROTECTION_UNDESIRED = 0
+ *	DRM_MODE_CONTENT_PROTECTION_UNDESIRED = 0
  *		The link is not protected, content is transmitted in the clear.
- *	- DRM_MODE_CONTENT_PROTECTION_DESIRED = 1
+ *	DRM_MODE_CONTENT_PROTECTION_DESIRED = 1
  *		Userspace has requested content protection, but the link is not
  *		currently protected. When in this state, kernel should enable
  *		Content Protection as soon as possible.
- *	- DRM_MODE_CONTENT_PROTECTION_ENABLED = 2
+ *	DRM_MODE_CONTENT_PROTECTION_ENABLED = 2
  *		Userspace has requested content protection, and the link is
  *		protected. Only the driver can set the property to this value.
  *		If userspace attempts to set to ENABLED, kernel will return
@@ -889,7 +889,31 @@ DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
  *	INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
  *	coordinates, so if userspace rotates the picture to adjust for
  *	the orientation it must also apply the same transformation to the
- *	touchscreen input coordinates.
+ *	touchscreen input coordinates. This property is initialized by calling
+ *	drm_connector_init_panel_orientation_property().
+ *
+ * scaling mode:
+ *	This property defines how a non-native mode is upscaled to the native
+ *	mode of an LCD panel:
+ *
+ *	None:
+ *		No upscaling happens, scaling is left to the panel. Not all
+ *		drivers expose this mode.
+ *	Full:
+ *		The output is upscaled to the full resolution of the panel,
+ *		ignoring the aspect ratio.
+ *	Center:
+ *		No upscaling happens, the output is centered within the native
+ *		resolution the panel.
+ *	Full aspect:
+ *		The output is upscaled to maximize either the width or height
+ *		while retaining the aspect ratio.
+ *
+ *	This property should be set up by calling
+ *	drm_connector_attach_scaling_mode_property(). Note that drivers
+ *	can also expose this property to external outputs, in which case they
+ *	must support "None", which should be the default (since external screens
+ *	have a built-in scaler).
  */
 
 int drm_connector_create_standard_properties(struct drm_device *dev)
-- 
2.15.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/5] drm/doc: Polish for drm_mode_parse_command_line_for_connector

[Daniel Vetter]

Quoting the module option format looks soo much nice, and avoids
sphinx spewing errors about markup issues.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/gpu/drm/drm_modes.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index c397b523c945..5a8033fda4e3 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1346,9 +1346,9 @@ EXPORT_SYMBOL(drm_mode_connector_list_update);
  * modeline in fb_mode_option will be parsed instead.
  *
  * This uses the same parameters as the fb modedb.c, except for an extra
- * force-enable, force-enable-digital and force-disable bit at the end:
+ * force-enable, force-enable-digital and force-disable bit at the end::
  *
- * <xres>x<yres>[M][R][-<bpp>][@<refresh>][i][m][eDd]
+ *	<xres>x<yres>[M][R][-<bpp>][@<refresh>][i][m][eDd]
  *
  * The intermediate drm_cmdline_mode structure is required to store additional
  * options from the command line modline like the force-enable/disable flag.
-- 
2.15.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/5] drm/doc: Use new substruct support

[Daniel Vetter]

Note: This is untested because the new stuff hasn't landed in upstream
yet. But it should work.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 include/drm/drm_vblank.h | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
index 16d46e2a6854..d25a9603ab57 100644
--- a/include/drm/drm_vblank.h
+++ b/include/drm/drm_vblank.h
@@ -55,8 +55,24 @@ struct drm_pending_vblank_event {
 	 * @event: Actual event which will be sent to userspace.
 	 */
 	union {
+		/**
+		 * @event.base: DRM event base class.
+		 */
 		struct drm_event base;
+
+		/**
+		 * @event.vbl:
+		 *
+		 * Event payload for vblank events, requested through
+		 * either the MODE_PAGE_FLIP or MODE_ATOMIC IOCTL. Also
+		 * generated by the legacy WAIT_VBLANK IOCTL, but new userspace
+		 * should use MODE_QUEUE_SEQUENCE and &event.seq instead.
+		 */
 		struct drm_event_vblank vbl;
+
+		/**
+		 * @event.seq: Event payload for the MODE_QUEUEU_SEQUENCE IOCTL.
+		 */
 		struct drm_event_crtc_sequence seq;
 	} event;
 };
-- 
2.15.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/5] drm/docs: Discourage adding more to kms-properties.csv

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 775 bytes --]

On Mon, Feb 19, 2018 at 11:53:52PM +0100, Daniel Vetter wrote:
> Motivated by patch review.
> 
> The table is really hard to read in source form, hard to edit, and
> we've moved away to more focused sections about specific features and
> how they're exposed in properties.
> 
> Those sections can then more easily enumerate options, link to helper
> functions and other parts of the docs. All things that get ugly real
> fast in the docs.
> 
> Cc: Maxime Ripard <maxime.ripard@bootlin.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  Documentation/gpu/drm-kms.rst | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)

Reviewed-by: Thierry Reding <treding@nvidia.com>

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/5] drm/docs: Align layout of optional plane blending properties

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 455 bytes --]

On Mon, Feb 19, 2018 at 11:53:53PM +0100, Daniel Vetter wrote:
> Just a bit of drive-by OCD. All the other property docs use enumerations,
> for some nice visual consistency. It also neatly highlights the property
> name.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
>  drivers/gpu/drm/drm_blend.c | 18 ++++++++++--------
>  1 file changed, 10 insertions(+), 8 deletions(-)

Reviewed-by: Thierry Reding <treding@nvidia.com>

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/5] drm/docs: Document "scaling mode" property better

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 777 bytes --]

On Mon, Feb 19, 2018 at 11:53:54PM +0100, Daniel Vetter wrote:
> Move it out of the csv dungeon.
> 
> While at it add the missing link to the helper functions for setting
> up the "panel rotation" property.
> 
> Also OCD how we list enum property values and their corresponding docs.
> Going for a nest definition list seams cleanest, no need for also making
> it an uordered list.
> 
> Cc: Sean Paul <seanpaul@chromium.org>
> Cc: Hans de Goede <hdegoede@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  Documentation/gpu/kms-properties.csv |  1 -
>  drivers/gpu/drm/drm_connector.c      | 32 ++++++++++++++++++++++++++++----
>  2 files changed, 28 insertions(+), 5 deletions(-)

Reviewed-by: Thierry Reding <treding@nvidia.com>

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/5] drm/doc: Polish for drm_mode_parse_command_line_for_connector

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 207 bytes --]

On Mon, Feb 19, 2018 at 11:53:55PM +0100, Daniel Vetter wrote:
> Quoting the module option format looks soo much nice, and avoids

"nicer"? Other than that:

Reviewed-by: Thierry Reding <treding@nvidia.com>

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/5] drm/doc: Use new substruct support

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 549 bytes --]

On Mon, Feb 19, 2018 at 11:53:56PM +0100, Daniel Vetter wrote:
> Note: This is untested because the new stuff hasn't landed in upstream
> yet. But it should work.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  include/drm/drm_vblank.h | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)

I couldn't find a reference to the new stuff, so maybe this was already
discussed, but wouldn't it be possible for the parser to figure out the
substruct by itself? That way the event. prefix could be avoided.

Thierry

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/5] drm/doc: Use new substruct support

[Daniel Vetter]

On Tue, Feb 20, 2018 at 10:49:52AM +0100, Thierry Reding wrote:
> On Mon, Feb 19, 2018 at 11:53:56PM +0100, Daniel Vetter wrote:
> > Note: This is untested because the new stuff hasn't landed in upstream
> > yet. But it should work.

Ok Jani put the patch into topic/core-for-CI temporarily, so I could test.
It works.

> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> >  include/drm/drm_vblank.h | 16 ++++++++++++++++
> >  1 file changed, 16 insertions(+)
> 
> I couldn't find a reference to the new stuff, so maybe this was already
> discussed, but wouldn't it be possible for the parser to figure out the
> substruct by itself? That way the event. prefix could be avoided.

https://lkml.org/lkml/2018/2/16/339

Jon said he pulled it all in already, I guess this way was simplest, the
actual fix is a one-liner:

https://lkml.org/lkml/2018/2/16/344

The reason for this is likely that you'll end up with name clashes
everywhere if you don't insist on the fully qualified name.

I merged the other patches meanwhile, thanks a lot for your review.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/5] drm/doc: Use new substruct support

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 1458 bytes --]

On Tue, Feb 20, 2018 at 12:10:35PM +0100, Daniel Vetter wrote:
> On Tue, Feb 20, 2018 at 10:49:52AM +0100, Thierry Reding wrote:
> > On Mon, Feb 19, 2018 at 11:53:56PM +0100, Daniel Vetter wrote:
> > > Note: This is untested because the new stuff hasn't landed in upstream
> > > yet. But it should work.
> 
> Ok Jani put the patch into topic/core-for-CI temporarily, so I could test.
> It works.
> 
> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > ---
> > >  include/drm/drm_vblank.h | 16 ++++++++++++++++
> > >  1 file changed, 16 insertions(+)
> > 
> > I couldn't find a reference to the new stuff, so maybe this was already
> > discussed, but wouldn't it be possible for the parser to figure out the
> > substruct by itself? That way the event. prefix could be avoided.
> 
> https://lkml.org/lkml/2018/2/16/339
> 
> Jon said he pulled it all in already, I guess this way was simplest, the
> actual fix is a one-liner:
> 
> https://lkml.org/lkml/2018/2/16/344
> 
> The reason for this is likely that you'll end up with name clashes
> everywhere if you don't insist on the fully qualified name.

Thanks for the pointers. I would've thought that the parser could simply
stick the prefix onto the name itself to make it fully qualified and
thereby avoid any name clashes.

But looking at the patches and the parser a little, this will have to do
for now:

Reviewed-by: Thierry Reding <treding@nvidia.com>

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/5] drm/doc: Use new substruct support

[Jani Nikula]

On Tue, 20 Feb 2018, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Mon, Feb 19, 2018 at 11:53:56PM +0100, Daniel Vetter wrote:
>> Note: This is untested because the new stuff hasn't landed in upstream
>> yet. But it should work.
>> 
>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>> ---
>>  include/drm/drm_vblank.h | 16 ++++++++++++++++
>>  1 file changed, 16 insertions(+)
>
> I couldn't find a reference to the new stuff, so maybe this was already
> discussed, but wouldn't it be possible for the parser to figure out the
> substruct by itself? That way the event. prefix could be avoided.

The short answer, supporting this format is a one-line change, while I'm
told anything else is harder.

Also, the format then is the same at all nesting levels, and you can do
any one of the three options below:

/**
 * struct foo - foo
 * @bar.baz: baz description, option 1 (support upstream)
 */
struct foo {
	/**
         * @bar.baz: baz description, option 2 (support in docs-next)
         */
	struct bar {
        	/**
	         * @bar.baz: baz description, option 3 (support in docs-next)
                 */
        	int baz;
        };
}

I don't deny it would be nice to be able to leave out the prefix when it
can be figured out from the context, but I'm not prepared to do the
work, and Mauro helpfully provided the patch for this approach, so it
seemed like the rational choice. See also [1] and [2].

BR,
Jani.


[1] http://mid.mail-archive.com/874lmjlfmg.fsf@intel.com
[2] http://mid.mail-archive.com/cover.1518788761.git.mchehab@s-opensource.com


-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/5] drm/doc: Use new substruct support

[Daniel Vetter]

On Tue, Feb 20, 2018 at 12:22:18PM +0100, Thierry Reding wrote:
> On Tue, Feb 20, 2018 at 12:10:35PM +0100, Daniel Vetter wrote:
> > On Tue, Feb 20, 2018 at 10:49:52AM +0100, Thierry Reding wrote:
> > > On Mon, Feb 19, 2018 at 11:53:56PM +0100, Daniel Vetter wrote:
> > > > Note: This is untested because the new stuff hasn't landed in upstream
> > > > yet. But it should work.
> > 
> > Ok Jani put the patch into topic/core-for-CI temporarily, so I could test.
> > It works.
> > 
> > > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > > ---
> > > >  include/drm/drm_vblank.h | 16 ++++++++++++++++
> > > >  1 file changed, 16 insertions(+)
> > > 
> > > I couldn't find a reference to the new stuff, so maybe this was already
> > > discussed, but wouldn't it be possible for the parser to figure out the
> > > substruct by itself? That way the event. prefix could be avoided.
> > 
> > https://lkml.org/lkml/2018/2/16/339
> > 
> > Jon said he pulled it all in already, I guess this way was simplest, the
> > actual fix is a one-liner:
> > 
> > https://lkml.org/lkml/2018/2/16/344
> > 
> > The reason for this is likely that you'll end up with name clashes
> > everywhere if you don't insist on the fully qualified name.
> 
> Thanks for the pointers. I would've thought that the parser could simply
> stick the prefix onto the name itself to make it fully qualified and
> thereby avoid any name clashes.
> 
> But looking at the patches and the parser a little, this will have to do
> for now:
> 
> Reviewed-by: Thierry Reding <treding@nvidia.com>

Thanks for your review, patch applied.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/5] drm/docs: Discourage adding more to kms-properties.csv

[Laurent Pinchart]

Hi Daniel,

Thank you for the patch.

On Tuesday, 20 February 2018 00:53:52 EET Daniel Vetter wrote:
> Motivated by patch review.
> 
> The table is really hard to read in source form, hard to edit, and
> we've moved away to more focused sections about specific features and
> how they're exposed in properties.
> 
> Those sections can then more easily enumerate options, link to helper
> functions and other parts of the docs. All things that get ugly real
> fast in the docs.
> 
> Cc: Maxime Ripard <maxime.ripard@bootlin.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

> ---
>  Documentation/gpu/drm-kms.rst | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 2dcf5b42015d..56a3780e39b8 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -547,8 +547,9 @@ Explicit Fencing Properties
>  Existing KMS Properties
>  -----------------------
> 
> -The following table gives description of drm properties exposed by
> -various modules/drivers.
> +The following table gives description of drm properties exposed by various
> +modules/drivers. Because this table is very unwieldy, do not add any new
> +properties here. Instead document them in a section above.
> 
>  .. csv-table::
>     :header-rows: 1

-- 
Regards,

Laurent Pinchart

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel