linux-toradex.git/drivers/gpu/drm/drm_probe_helper.c, branch v4.16-rc4

Merge tag 'drm-misc-fixes-2018-02-21' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes

2018-02-21T22:39:26+00:00

Fixes for 4.16. I contains fixes for deadlock on runtime suspend on few
drivers, a memory leak on non-blocking commits, a crash on color-eviction.
The is also meson and edid fixes, plus a fix for a doc warning.

* tag 'drm-misc-fixes-2018-02-21' of git://anongit.freedesktop.org/drm/drm-misc:
  drm/tve200: fix kernel-doc documentation comment include
  drm/meson: fix vsync buffer update
  drm: Handle unexpected holes in color-eviction
  drm/edid: Add 6 bpc quirk for CPT panel in Asus UX303LA
  drm/amdgpu: Fix deadlock on runtime suspend
  drm/radeon: Fix deadlock on runtime suspend
  drm/nouveau: Fix deadlock on runtime suspend
  drm: Allow determining if current task is output poll worker
  workqueue: Allow retrieval of current task's work struct
  drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits

drm: Allow determining if current task is output poll worker

2018-02-16T21:30:06+00:00

Introduce a helper to determine if the current task is an output poll
worker.

This allows us to fix a long-standing deadlock in several DRM drivers
wherein the ->runtime_suspend callback waits for the output poll worker
to finish and the worker in turn calls a ->detect callback which waits
for runtime suspend to finish.  The ->detect callback is invoked from
multiple call sites and waiting for runtime suspend to finish is the
correct thing to do except if it's executing in the context of the
worker.

v2: Expand kerneldoc to specifically mention deadlock between
    output poll worker and autosuspend worker as use case. (Lyude)

Cc: Dave Airlie 
Cc: Ben Skeggs 
Cc: Alex Deucher 
Reviewed-by: Lyude Paul 
Signed-off-by: Lukas Wunner 
Link: https://patchwork.freedesktop.org/patch/msgid/3549ce32e7f1467102e70d3e9cbf70c46bfe108e.1518593424.git.lukas@wunner.de

drm/probe-helper: Fix drm_kms_helper_poll_enable() docs

2017-11-30T17:17:37+00:00

Fix docs to reflect code and drm_kms_helper_poll_disable() docs by saying
that calling drm_kms_helper_poll_enable() is fine even if output polling
is not enabled.

Signed-off-by: Noralf Trønnes 
Reviewed-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20171106191812.38927-2-noralf@tronnes.org

drm: Pass struct drm_file * to __drm_mode_object_find [v2]

2017-10-12T00:03:04+00:00

This will allow __drm_mode_object_file to be extended to perform
access control checks based on the file in use.

v2: Also fix up vboxvideo driver in staging

[airlied: merging early as this is an API change]

Suggested-by: Daniel Vetter 
Signed-off-by: Keith Packard 
Signed-off-by: Dave Airlie

drm: handle override and firmware EDID at drm_do_get_edid() level

2017-09-19T14:49:25+00:00

Handle debugfs override edid and firmware edid at the low level to
transparently and completely replace the real edid. Previously, we
practically only used the modes from the override EDID, and none of the
other data, such as audio parameters.

This change also prevents actual EDID reads when the EDID is to be
overridden, but retains the DDC probe. This is useful if the reason for
preferring override EDID are problems with reading the data, or
corruption of the data.

Move firmware EDID loading from helper to core, as the functionality
moves to lower level as well. This will result in a change of module
parameter from drm_kms_helper.edid_firmware to drm.edid_firmware, which
arguably makes more sense anyway.

Some future work remains related to override and firmware EDID
validation. Like before, no validation is done for override EDID. The
firmware EDID is validated separately in the loader. Some unification
and deduplication would be in order, to validate all of them at the
drm_do_get_edid() level, like "real" EDIDs.

v2: move firmware loading to core

v3: rebase, commit message refresh

Cc: Abdiel Janulgue 
Cc: Daniel Vetter 
Cc: Ville Syrjälä 
Tested-by: Abdiel Janulgue 
Reviewed-by: Ville Syrjälä 
Acked-by: Dave Airlie 
Signed-off-by: Jani Nikula 
Link: https://patchwork.freedesktop.org/patch/msgid/1e8a710bcac46e5136c1a7b430074893c81f364a.1505203831.git.jani.nikula@intel.com

drm: add helper to validate YCBCR420 modes

2017-07-14T18:23:54+00:00

YCBCR420 modes are supported only on HDMI 2.0 capable sources.
This patch adds:
- A drm helper to validate YCBCR420-only mode on a particular
  connector. This function will help pruning the YCBCR420-only
  modes from the connector's modelist.
- A bool variable (ycbcr_420_allowed) in the drm connector structure.
  While handling the EDID from HDMI 2.0 sinks, its important to know
  if the source is capable of handling YCBCR420 output, so that no
  YCBCR 420 modes will be listed for sources which can't handle it.
  A driver should set this variable if it wants to see YCBCR420 modes
  in the modedb.

V5: Introduced the patch in series.
V6: Squashed two patches (validate YCBCR420 and add YCBCR420
	   identifier)
V7: Addressed review comments from Vile:
    - Move this patch before we add 420 modes from EDID.
    - No need for drm_valid_cea_vic() check, function back to non-static.
    - Update MODE_STATUS with NO_420 condition.
    - Introduce y420_vdb_modes variable in this patch

Cc: Ville Syrjala 
Signed-off-by: Shashank Sharma 
Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-6-git-send-email-shashank.sharma@intel.com
[vsyrjala: Drop the now bogus EXPORT_SYMBOL(drm_valid_cea_vic)]
Signed-off-by: Ville Syrjälä

drm: Use new mode_valid() helpers in connector probe helper

2017-05-30T06:37:50+00:00

This changes the connector probe helper function to use the new
encoder->mode_valid(), bridge->mode_valid() and crtc->mode_valid()
helper callbacks to validate the modes.

The new callbacks are optional so the behaviour remains the same
if they are not implemented. If they are, then the code loops
through all the connector's encodersXbridgesXcrtcs and calls the
callback.

If at least a valid encoderXbridgeXcrtc combination is found which
accepts the mode then the function returns MODE_OK.

Signed-off-by: Jose Abreu 
Reviewed-by: Daniel Vetter 
Cc: Carlos Palminha 
Cc: Dave Airlie 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 

Changes v3->v4:
	- Change function name (Laurent)
Changes v2->v3:
	- Call also bridge->mode_valid (Daniel)
Changes v1->v2:
	- Use new helpers suggested by Ville
	- Change documentation (Daniel)
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/d4e3ba87d822fa92f1b8773e441b9a02af3bde71.1495720737.git.joabreu@synopsys.com

drm: Add drm_{crtc/encoder/connector}_mode_valid()

2017-05-30T06:37:24+00:00

Add a new helper to call crtc->mode_valid, connector->mode_valid
and encoder->mode_valid callbacks.

Suggested-by: Ville Syrjälä 
Signed-off-by: Jose Abreu 
Reviewed-by: Daniel Vetter 
Reviewed-by: Andrzej Hajda 
Cc: Carlos Palminha 
Cc: Dave Airlie 

Changes v2->v3:
	- Move helpers to drm_probe_helper.c (Daniel)
	- Squeeze patches that introduce helpers into a single
	one (Daniel)

Signed-off-by: Jose Abreu 
[danvet: Make it compile when CONFIG_DRM_DP_AUX_CHARDEV is selected.]
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/b55c8bd029da219ff04e39086025c115731a49b1.1495720737.git.joabreu@synopsys.com

drm/atomic: Acquire connection_mutex lock in drm_helper_probe_single_connector_modes, v4.

2017-04-06T19:29:23+00:00

mode_valid() called from drm_helper_probe_single_connector_modes()
may need to look at connector->state because what a valid mode is may
depend on connector properties being set. For example some HDMI modes
might be rejected when a connector property forces the connector
into DVI mode.

Some implementations of detect() already lock all state,
so we have to pass an acquire_ctx to them to prevent a deadlock.

This means changing the function signature of detect() slightly,
and passing the acquire_ctx for locking multiple crtc's.
For the callbacks, it will always be non-zero. To allow callers
not to worry about this, drm_helper_probe_detect_ctx is added
which might handle -EDEADLK for you.

Changes since v1:
- Always set ctx parameter.
Changes since v2:
- Always take connection_mutex when probing.
Changes since v3:
- Remove the ctx from intel_dp_long_pulse, and add
  WARN_ON(!connection_mutex) (danvet)
- Update docs to clarify the locking situation. (danvet)

Signed-off-by: Maarten Lankhorst 
Cc: Boris Brezillon 
Reviewed-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1491504920-4017-1-git-send-email-maarten.lankhorst@linux.intel.com

drm/doc: Small markup fixup

2017-04-04T18:47:54+00:00

Drive-by cleanup.

Reviewed-by: Neil Armstrong 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/20170404095304.17599-11-daniel.vetter@ffwll.ch