drm/connector: hdmi: Add Broadcast RGB property

The i915 driver has a property to force the RGB range of an HDMI output.
The vc4 driver then implemented the same property with the same
semantics. KW

drm/connector: hdmi: Add Broadcast RGB property

The i915 driver has a property to force the RGB range of an HDMI output.
The vc4 driver then implemented the same property with the same
semantics. KWin has support for it, and a PR for mutter is also there to
support it.

Both drivers implementing the same property with the same semantics,
plus the userspace having support for it, is proof enough that it's
pretty much a de-facto standard now and we can provide helpers for it.

Let's plumb it into the newly created HDMI connector.

Reviewed-by: Dave Stevenson <[email protected]>
Acked-by: Pekka Paalanen <[email protected]>
Reviewed-by: Sebastian Wick <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Maxime Ripard <[email protected]>

show more ...

drm/doc: Remove unused Broadcast RGB Property

The Broadcast RGB property has been documented as three separate entries
so far, each with a different set of values.

The first one is pretty much the

drm/doc: Remove unused Broadcast RGB Property

The Broadcast RGB property has been documented as three separate entries
so far, each with a different set of values.

The first one is pretty much the generic one: it's used by i915 and vc4,
and is the one used by all the compositors.

The second one is used by the gma500 driver, and is a subset of the
first one: it can have the values "Full" or "Limited 16:235", but lack
the "Automatic" value.

The third one however isn't used by any driver and documents the values
"off", "auto" and "on".

It's unclear where the last one comes from. It was first documented in
commit 6c6a3996f2c5 ("Documentation: drm: describing drm properties
exposed by various drivers") which adds a number of properties used by
drivers, but without mentioning which driver was using what property.

Grepping at the 6c6a3996f2c5 commit however, it looks like no driver is
actually using it, and a quick look at the entire kernel history doesn't
show any match either.

At the time though, gma500 had an "audio" property used right next to
Broadcast RGB that did have the "off", "auto" and "on" values in the
same order.

As such, it was probably a copy/paste or scripting error back then, and
there's never been such property used in the kernel.

Either way, it certainly hasn't been used in a decade or two so we can
just get rid of it.

Suggested-by: Dmitry Baryshkov <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Maxime Ripard <[email protected]>

show more ...

Documentation: Fix typos

Fix typos in Documentation.

Signed-off-by: Bjorn Helgaas <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jon

Documentation: Fix typos

Fix typos in Documentation.

Signed-off-by: Bjorn Helgaas <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

drm/doc: Drop "content type" from the legacy kms property table

We want new stuff documented in more verbose form, this table is
deprecated. "content type" is already documented properly.

Reviewed-

drm/doc: Drop "content type" from the legacy kms property table

We want new stuff documented in more verbose form, this table is
deprecated. "content type" is already documented properly.

Reviewed-by: Ville Syrjälä <[email protected]>
Fixes: 50525c332b55 ("drm: content-type property for HDMI connector")
Cc: Hans Verkuil <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Stanislav Lisovskiy <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm: content-type property for HDMI connector

Added content_type property to drm_connector_state
in order to properly handle external HDMI TV content-type setting.

v2:
* Moved helper function whic

drm: content-type property for HDMI connector

Added content_type property to drm_connector_state
in order to properly handle external HDMI TV content-type setting.

v2:
* Moved helper function which attaches content type property
to the drm core, as was suggested.
Removed redundant connector state initialization.

v3:
* Removed caps in drm_content_type_enum_list.
After some discussion it turned out that HDMI Spec 1.4
was wrongly assuming that IT Content(itc) bit doesn't affect
Content type states, however itc bit needs to be manupulated
as well. In order to not expose additional property for itc,
for sake of simplicity it was decided to bind those together
in same "content type" property.

v4:
* Added it_content checking in intel_digital_connector_atomic_check.
Fixed documentation for new content type enum.

v5:
* Moved patch revision's description to commit messages.

v6:
* Minor naming fix for the content type enumeration string.

v7:
* Fix parameter name for documentation and parameter alignment
in order not to get warning. Added Content Type description to
new HDMI connector properties section.

v8:
* Thrown away unneeded numbers from HDMI content-type property
description. Switch to strings desription instead of plain
definitions.

v9:
* Moved away hdmi specific content-type enum from
drm_connector_state. Content type property should probably not
be bound to any specific connector interface in
drm_connector_state.
Same probably should be done to hdmi_picture_aspect_ration enum
which is also contained in drm_connector_state. Added special
helper function to get derive hdmi specific relevant infoframe
fields.

v10:
* Added usage description to HDMI properties kernel doc.

v11:
* Created centralized function for filling HDMI AVI infoframe, based
on correspondent DRM property value.

Acked-by: Hans Verkuil <[email protected]>
Acked-by: Daniel Vetter <[email protected]>
Signed-off-by: Stanislav Lisovskiy <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
[vsyrjala: clean up checkpatch multiple blank lines warnings]
Signed-off-by: Ville Syrjälä <[email protected]>

show more ...

drm/docs: Remove the rcar alpha from the csv file

Now that we moved the rcar-du DRM driver has been switched to the generic
alpha property, remove the former property documentation from the
deprecat

drm/docs: Remove the rcar alpha from the csv file

Now that we moved the rcar-du DRM driver has been switched to the generic
alpha property, remove the former property documentation from the
deprecated CSV file.

Acked-by: Maarten Lankhorst <[email protected]>
Acked-by: Sean Paul <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/04be5e2256aa8d33d9521a68a10f0b73a24f8040.1523432341.git-series.maxime.ripard@bootlin.com

show more ...

drm/docs: Document "scaling mode" property better

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 ho

drm/docs: Document "scaling mode" property better

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 <[email protected]>
Cc: Hans de Goede <[email protected]>
Reviewed-by: Thierry Reding <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm/doc: remove standard connector props from the csv file

They're properly documented in drm_connector.c now, and this
csv file is a horrible mess. Better to remove it.

Reviewed-by: Alex Deucher <

drm/doc: remove standard connector props from the csv file

They're properly documented in drm_connector.c now, and this
csv file is a horrible mess. Better to remove it.

Reviewed-by: Alex Deucher <[email protected]>
Reviewed-by: Harry Wentland <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm: Remove dirty property from docs

We removed it in

commit 6ab10b76ff6252bd9be0849c40f5865e39a29961
Author: Daniel Vetter <[email protected]>
Date: Fri Aug 12 22:48:45 2016 +0200

drm/

drm: Remove dirty property from docs

We removed it in

commit 6ab10b76ff6252bd9be0849c40f5865e39a29961
Author: Daniel Vetter <[email protected]>
Date: Fri Aug 12 22:48:45 2016 +0200

drm/kms: Nuke dirty_info property

Reviewed-by: Sean Paul <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Sean Paul <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm/doc: Document color space handling

Again move it from the unmaintainable csv into DOC free-form overview
sections.

v2: Types Lionel&Sean spotted.

Cc: Lionel Landwerlin <lionel.g.landwerlin@int

drm/doc: Document color space handling

Again move it from the unmaintainable csv into DOC free-form overview
sections.

v2: Types Lionel&Sean spotted.

Cc: Lionel Landwerlin <[email protected]>
Reviewed-by: Sean Paul <[email protected]>
Reviewed-by: Lionel Landwerlin <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Sean Paul <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm/doc: Polish plane composition property docs

Try to spec a bit more precisely how they all fit together, now that
at least the code is for all the additional properties is in one
place.

Also rem

drm/doc: Polish plane composition property docs

Try to spec a bit more precisely how they all fit together, now that
at least the code is for all the additional properties is in one
place.

Also remove the entries for the standardized properties from the
table, because that thing is supremely unmaintaineable.

v2: Fix typos Sean spotted.

Cc: Ville Syrjälä <[email protected]>
Cc: Sean Paul <[email protected]>
Cc: Benjamin Gaignard <[email protected]>
Reviewed-by: Sean Paul <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Sean Paul <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm: add generic zpos property

version 8:
- move drm_blend.o from drm-y to drm_kms_helper-y to avoid
EXPORT_SYMBOL(drm_atomic_helper_normalize_zpos)
- remove dead function declarations in drm_crtc

drm: add generic zpos property

version 8:
- move drm_blend.o from drm-y to drm_kms_helper-y to avoid
EXPORT_SYMBOL(drm_atomic_helper_normalize_zpos)
- remove dead function declarations in drm_crtc.h

version 7:
- remove useless EXPORT_SYMBOL()
- better z-order wording in Documentation

version 6:
- add zpos in gpu documentation file
- merge Ville patch about zpos initial value and API improvement.
I have split Ville patch between zpos core and drivers

version 5:
- remove zpos range check and comeback to 0 to N-1
normalization algorithm

version 4:
- make sure that normalized zpos value is stay
in the defined property range and warn user if not

This patch adds support for generic plane's zpos property property with
well-defined semantics:
- added zpos properties to plane and plane state structures
- added helpers for normalizing zpos properties of given set of planes
- well defined semantics: planes are sorted by zpos values and then plane
id value if zpos equals

Normalized zpos values are calculated automatically when generic
muttable zpos property has been initialized. Drivers can simply use
plane_state->normalized_zpos in their atomic_check and/or plane_update
callbacks without any additional calls to DRM core.

Signed-off-by: Marek Szyprowski <[email protected]>

Compare to Marek's original patch zpos property is now specific to each
plane and no more to the core.
Normalize function take care of the range of per plane defined range
before set normalized_zpos.

Signed-off-by: Benjamin Gaignard <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Acked-by: Laurent Pinchart <[email protected]>
Tested-by: Laurent Pinchart <[email protected]>

Cc: Inki Dae <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Ville Syrjala <[email protected]>
Cc: Joonyoung Shim <[email protected]>
Cc: Seung-Woo Kim <[email protected]>
Cc: Andrzej Hajda <[email protected]>
Cc: Krzysztof Kozlowski <[email protected]>
Cc: Bartlomiej Zolnierkiewicz <[email protected]>
Cc: Tobias Jakobi <[email protected]>
Cc: Gustavo Padovan <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: Laurent Pinchart <[email protected]>

show more ...

Documentation/gpu: convert the KMS properties table to CSV

Pandoc really did a bad job of converting the big KMS properties table
to RST. Instead, put the properties into a separate plain text CSV f

Documentation/gpu: convert the KMS properties table to CSV

Pandoc really did a bad job of converting the big KMS properties table
to RST. Instead, put the properties into a separate plain text CSV file,
and include it in the RST file. The generated output isn't very pretty,
but at least the information is there, and it's stored in a format
that's easier to process and improve upon at a later time.

The CSV file was generated by copy-pasting the table from the HTML
generated by the DocBook toolchain into LibreOffice Calc, and then saved
as CSV, unmodified.

Signed-off-by: Jani Nikula <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/17053ff08caf5cfac4f478437ef796f83a31d772.1466506505.git.jani.nikula@intel.com

show more ...