kernel.git/Documentation/gpu/drm-kms.rst, branch linux-4.19.y

drm: switch drm_plane to inline comments

2018-07-13T16:40:28Z

And use that opportunity to polish the kernel doc all around: - Beef up some of the documentation. - Intro text for drm_plane and better links - Fix all the hyperlinks! v2: Fix linebreaks. Reviewed-by: Sean Paul Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20180709084016.23750-10-daniel.vetter@ffwll.ch

drm: drop _mode_ from drm_mode_connector_attach_encoder

2018-07-13T16:40:27Z

Again to align with the usual prefix of just drm_connector_. Again done with sed + manual fixup for indent issues. Reviewed-by: Sean Paul Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20180709084016.23750-7-daniel.vetter@ffwll.ch

drm: Fix hdmi connector content type property docs

2018-07-03T06:58:57Z

Apparently didn't get carefully checked. Fixes: 50525c332b55 ("drm: content-type property for HDMI connector") Cc: Hans Verkuil Cc: Daniel Vetter Cc: Stanislav Lisovskiy Cc: Ville Syrjälä Reviewed-by: Stanislav Lisovskiy Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20180702091023.695-1-daniel.vetter@ffwll.ch

drm: Add writeback connector type

2018-06-20T14:27:49Z

Writeback connectors represent writeback engines which can write the CRTC output to a memory framebuffer. Add a writeback connector type and related support functions. Drivers should initialize a writeback connector with drm_writeback_connector_init() which takes care of setting up all the writeback-specific details on top of the normal functionality of drm_connector_init(). Writeback connectors have a WRITEBACK_FB_ID property, used to set the output framebuffer, and a WRITEBACK_PIXEL_FORMATS blob used to expose the supported writeback formats to userspace. When a framebuffer is attached to a writeback connector with the WRITEBACK_FB_ID property, it is used only once (for the commit in which it was included), and userspace can never read back the value of WRITEBACK_FB_ID. WRITEBACK_FB_ID can only be set if the connector is attached to a CRTC. Changes since v1: - Added drm_writeback.c + documentation - Added helper to initialize writeback connector in one go - Added core checks - Squashed into a single commit - Dropped the client cap - Writeback framebuffers are no longer persistent Changes since v2: Daniel Vetter: - Subclass drm_connector to drm_writeback_connector - Relax check to allow CRTC to be set without an FB - Add some writeback_ prefixes - Drop PIXEL_FORMATS_SIZE property, as it was unnecessary Gustavo Padovan: - Add drm_writeback_job to handle writeback signalling centrally Changes since v3: - Rebased - Rename PIXEL_FORMATS -> WRITEBACK_PIXEL_FORMATS Chances since v4: - Embed a drm_encoder inside the drm_writeback_connector to reduce the amount of boilerplate code required from the drivers that are using it. Changes since v5: - Added Rob Clark's atomic_commit() vfunc to connector helper funcs, so that writeback jobs are committed from atomic helpers - Updated create_writeback_properties() signature to return an error code rather than a boolean false for failure. - Free writeback job with the connector state rather than when doing the cleanup_work() Changes since v7: - fix extraneous use of out_fence that is only introduced in a subsequent patch. Changes since v8: - whitespace changes pull from subsequent patch Changes since v9: - Revert the v6 changes that free the writeback job in the connector state cleanup and return to doing it in the cleanup_work() function Signed-off-by: Brian Starkey [rebased and fixed conflicts] Signed-off-by: Mihail Atanassov [rebased and added atomic_commit() vfunc for writeback jobs] Signed-off-by: Rob Clark Signed-off-by: Liviu Dudau Reviewed-by: Eric Anholt Link: https://patchwork.freedesktop.org/patch/229037/

drm: content-type property for HDMI connector

2018-05-17T15:58:35Z

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 Acked-by: Daniel Vetter Signed-off-by: Stanislav Lisovskiy Link: https://patchwork.freedesktop.org/patch/msgid/20180515135928.31092-2-stanislav.lisovskiy@intel.com [vsyrjala: clean up checkpatch multiple blank lines warnings] Signed-off-by: Ville Syrjälä

drm: Verify gamma/degamma LUT size

2018-03-16T13:44:01Z

While we want to potentially support multiple different gamma/degamma LUT sizes we can (and should) at least check that the blob length is a multiple of the LUT entry size. v2: s/expected_size_mod/expected_elem_size/ (Daniel) Add kernel doc (Daniel) v3: s/we/were/ typo in the docs Cc: Daniel Vetter Signed-off-by: Ville Syrjälä Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20180315152241.7113-1-ville.syrjala@linux.intel.com

drm/docs: Discourage adding more to kms-properties.csv

2018-02-20T11:10:46Z

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 Cc: Laurent Pinchart Reviewed-by: Thierry Reding Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20180219225356.24996-1-daniel.vetter@ffwll.ch

drm/doc: Move legacy kms helpers to the very end

2017-12-15T10:26:54Z

We don't want people to accidentally stumble over there. Also rename the plane helpers to legacy plane helpers. After Ville's patch to make the clipping helper atomic and move it to drm_atomic_helper.c there's nothing left in there that should be useful for modern drivers. v2: Laurent had a few questions around how state is added to drm_atomic_state, tried to clarify that. And spotted another sentence where the docs suggested subclassing. v3: Small polish (Alex). Reviewed-by: Alex Deucher Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20171214203054.20141-6-daniel.vetter@ffwll.ch

drm/atomic: document how to handle driver private objects

2017-12-15T10:26:54Z

DK put some nice docs into the commit introducing driver private state, but in the git history alone it'll be lost. Also, since Ville remove the void* usage it's a good opportunity to give the driver private stuff some tlc on the doc front. Finally try to explain why the "let's just subclass drm_atomic_state" approach wasn't the greatest, and annotate all those functions as deprecated in favour of more standardized driver private states. Also note where we could/should extend driver private states going forward (atm neither locking nor synchronization is handled in core/helpers, which isn't really all that great). v2: Spelling and phrasing improvements (Alex, DK). Cc: Harry Wentland Cc: Dhinakaran Pandiyan Cc: Maarten Lankhorst Cc: Ville Syrjälä Cc: Laurent Pinchart Cc: Rob Clark Cc: Alex Deucher Cc: Ben Skeggs Reviewed-by: Dhinakaran Pandiyan Reviewed-by: Alex Deucher Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20171214203054.20141-5-daniel.vetter@ffwll.ch

drm/doc: vblank cleanup

2017-06-20T08:26:01Z

Unify and review everything, plus make sure it's all correct markup. Drop the kernel-doc for internal functions. Also rework the overview section, it's become rather outdated. Unfortuantely the kernel-doc in drm_driver isn't rendered yet, but that will change as soon as drm_driver is kernel-docified properly. Also document properly that drm_vblank_cleanup is optional, the core calls this already. v2: Make it clear that cleanup happens in drm_dev_fini for drivers with their own ->release callback (Thierry). Acked-by: Thierry Reding Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170524145212.27837-11-daniel.vetter@ffwll.ch