kernel/linux.git/drivers/gpu/drm/drm_atomic.c, branch v4.17.18

drm/atomic: Handling the case when setting old crtc for plane

2018-08-03T05:47:56+00:00

[ Upstream commit fc2a69f3903dfd97cd47f593e642b47918c949df ] In the func drm_atomic_set_crtc_for_plane, with the current code, if crtc of the plane_state and crtc passed as argument to the func are same, entire func will executed in vein. It will get state of crtc and clear and set the bits in plane_mask. All these steps are not required for same old crtc. Ideally, we should do nothing in this case, this patch handles the same, and causes the program to return without doing anything in such scenario. Signed-off-by: Satendra Singh Thakur Cc: Madhur Verma Cc: Hemanshu Srivastava Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/1525326572-25854-1-git-send-email-satendra.t@samsung.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drm/atomic: Clean private obj old_state/new_state in drm_atomic_state_default_clear()

2018-05-07T14:19:11+00:00

Clear the old_state and new_state pointers for private objects in drm_atomic_state_default_clear(). We don't actually have functions to get the new/old state for private objects so getting access to the potentially stale pointers requires a bit more manual labour than for other object types. But let's clear the pointers for private objects as well, if only to avoid future surprises when someone decides to add the functions to get at them. v2: Split private objs to a separate patch (Daniel) Cc: # v4.14+ Cc: Maarten Lankhorst Cc: Laurent Pinchart Cc: Abhay Kumar Fixes: a4370c777406 (drm/atomic: Make private objs proper objects) Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20180502183247.5746-1-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst Reviewed-by: Daniel Vetter Signed-off-by: Sean Paul

drm/atomic: Clean old_state/new_state in drm_atomic_state_default_clear()

2018-05-07T14:19:11+00:00

Clear the old_state and new_state pointers for every object in drm_atomic_state_default_clear(). Otherwise drm_atomic_get_{new,old}_*_state() will hand out stale pointers to anyone who hasn't first confirmed that the object is in fact part of the current atomic transcation, if they are called after we've done the ww backoff dance while hanging on to the same drm_atomic_state. For example, handle_conflicting_encoders() looks like it could hit this since it iterates the full connector list and just calls drm_atomic_get_new_connector_state() for each. And I believe we have now witnessed this happening at least once in i915 check_digital_port_conflicts(). Commit 8b69449d2663 ("drm/i915: Remove last references to drm_atomic_get_existing* macros") changed the safe drm_atomic_get_existing_connector_state() to the unsafe drm_atomic_get_new_connector_state(), which opened the doors for this particular bug there as well. v2: Split private objs out to a separate patch (Daniel) Cc: stable@vger.kernel.org Cc: Maarten Lankhorst Cc: Laurent Pinchart Cc: Abhay Kumar Fixes: 581e49fe6b41 ("drm/atomic: Add new iterators over all state, v3.") Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20180502183247.5746-1-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst Reviewed-by: Daniel Vetter Signed-off-by: Sean Paul

drm: Verify gamma/degamma LUT size

2018-03-16T13:44:01+00:00

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: Remove now pointelss blob->data casts

2018-03-16T13:44:01+00:00

Now that blob->data is void* again we don't need the casts anymore. Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20180223192506.29992-2-ville.syrjala@linux.intel.com Reviewed-by: Shashank Sharma Reviewed-by: Daniel Vetter

drm/atomic: Include color encoding/range in plane state dump

2018-03-02T12:41:21+00:00

Include color_enconding and color_range in the plane state dump. v2: Add kerneldoc (danvet) Cc: Harry Wentland Cc: Daniel Vetter Cc: Daniel Stone Cc: Russell King - ARM Linux Cc: Ilia Mirkin Cc: Hans Verkuil Cc: Uma Shankar Cc: Shashank Sharma Cc: Jyri Sarha Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20180219202846.10628-1-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter Acked-by: Harry Wentland

drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane

2018-03-02T12:23:26+00:00

Add a standard optional properties to support different non RGB color encodings in DRM planes. COLOR_ENCODING select the supported non RGB color encoding, for instance ITU-R BT.709 YCbCr. COLOR_RANGE selects the value ranges within the selected color encoding. The properties are stored to drm_plane object to allow different set of supported encoding for different planes on the device. v2: Add/fix kerneldocs, verify bitmasks (danvet) Cc: Harry Wentland Cc: Daniel Vetter Cc: Daniel Stone Cc: Russell King - ARM Linux Cc: Ilia Mirkin Cc: Hans Verkuil Cc: Uma Shankar Cc: Shashank Sharma Reviewed-by: Ville Syrjälä Signed-off-by: Jyri Sarha [vsyrjala v2: Add/fix kerneldocs, verify bitmasks] Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20180219202823.10508-1-ville.syrjala@linux.intel.com Acked-by: Harry Wentland Reviewed-by: Daniel Vetter

drm: Check that the plane supports the request format+modifier combo

2018-02-26T14:29:47+00:00

Currently we only check that the plane supports the pixel format of the fb we're about to feed to it. Extend it to check also the modifier, and more specifically that the combination of the format and modifier is supported. Cc: dri-devel@lists.freedesktop.org Cc: Ben Widawsky Cc: Jason Ekstrand Cc: Daniel Stone Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20171222192231.17981-8-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter

Merge tag 'topic/hdcp-2018-02-13' of git://anongit.freedesktop.org/drm/drm-misc into drm-next

2018-02-15T23:36:04+00:00

Add HDCP support to i915 drm driver. * tag 'topic/hdcp-2018-02-13' of git://anongit.freedesktop.org/drm/drm-misc: (26 commits) drm/i915: fix misalignment in HDCP register def drm/i915: Reauthenticate HDCP on failure drm/i915: Detect panel's hdcp capability drm/i915: Optimize HDCP key load drm/i915: Retry HDCP bksv read drm/i915: Connector info in HDCP debug msgs drm/i915: Stop encryption for repeater with no sink drm/i915: Handle failure from 2nd stage HDCP auth drm/i915: Downgrade hdcp logs from INFO to DEBUG_KMS drm/i915: Restore HDCP DRM_INFO when with no downstream drm/i915: Check for downstream topology errors drm/i915: Start repeater auth on READY/CP_IRQ drm/i915: II stage HDCP auth for repeater only drm/i915: Extending HDCP for HSW, BDW and BXT+ drm/i915/dp: Fix compilation of intel_dp_hdcp_check_link drm/i915: Only disable HDCP when it's active drm/i915: Don't allow HDCP on PORT E/F drm/i915: Implement HDCP for DisplayPort drm/i915: Implement HDCP for HDMI drm/i915: Add function to output Aksv over GMBUS ...

drm/atomic: Remove WARN_ON for invalid plane configuration.

2018-01-30T15:42:21+00:00

Userspace can set a FB_ID on a plane without setting CRTC_ID, which will fail with -EINVAL, but the kernel shouldn't warn about that. Same for !FB_ID and CRTC_ID being set. Signed-off-by: Maarten Lankhorst Acked-by: Daniel Vetter Cc: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20180130102704.28016-1-maarten.lankhorst@linux.intel.com Reviewed-by: Harry Wentland