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

drm: Allow determining if current task is output poll worker

2018-03-18T10:18:48+00:00

commit 25c058ccaf2ebbc3e250ec1e199e161f91fe27d4 upstream.

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
Signed-off-by: Greg Kroah-Hartman

drm: Schedule the output_poll_work with 1s delay if we have delayed event

2017-02-01T07:33:02+00:00

commit 68f458eec7069d618a6c884ca007426e0cea411b upstream.

Instead of scheduling the work to handle the initial delayed event, use 1s
delay.

This delay should not be needed, but Optimus/nouveau will fail in a
mysterious way if the delayed event is handled as soon as possible like it
is done in drm_helper_probe_single_connector_modes() in case the poll
was enabled before.

Reverting 339fd36238dd would give back the 10 sec (!) delay to handle the
delayed event. Adding 1sec delay to the poll_work is enough to work around
the issue in Optimus setups and gives shorter response on handling the
initial delayed event.

Fixes: 339fd36238dd ("drm: drm_probe_helper: Fix output_poll_work scheduling")
Signed-off-by: Peter Ujfalusi 
[danvet: Add FIXME to the comment to make it stick out more.]
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/20170109143158.21917-1-peter.ujfalusi@ti.com
Signed-off-by: Greg Kroah-Hartman

drm: drm_probe_helper: Fix output_poll_work scheduling

2016-08-31T11:23:30+00:00

drm_kms_helper_poll_enable_locked() should check if we have delayed event
pending and if we have, schedule the work to run without delay.

Currently the output_poll_work is only scheduled if any of the connectors
have DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT with
DRM_OUTPUT_POLL_PERIOD delay. It does not matter if we have delayed event
already registered to be handled. The detection will be delayd by
DRM_OUTPUT_POLL_PERIOD in any case.
Furthermore if none of the connectors are marked as POLL_CONNECT or
POLL_DISCONNECT because all connectors are either POLL_HPD or they are
always connected: the output_poll_work will not run at all even if we
have delayed event marked.

When none of the connectors require polling, their initial status change
from unknown to connected/disconnected is not going to be handled until
the first kms application starts or if we have fb console enabled.

Note that in general the output poll work should be enabled already
when this happens, but at driver load usually the first probe happens
before the output polling is enabled. This patch fixes this case.

Signed-off-by: Peter Ujfalusi 
[danvet: Note when exactly this is an issue, since the probe code
schedules the poll work itself already.]
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/20160831110905.31289-1-peter.ujfalusi@ti.com

drm: Only create a cmdline mode if no probed modes match

2016-06-02T13:10:22+00:00

The intention of using video=: is primarily to select
the user's preferred resolution at startup. Currently we always create a
new mode irrespective of whether the monitor has a native mode at the
desired resolution. This has the issue that we may then select the fake
mode rather the native mode during fb_helper->inital_config() and so
if the fake mode is invalid we then end up with a loss of signal. Oops.
This invalid fake mode would also be exported to userspace, who
potentially may make the same mistake.

To avoid this issue, we filter out the added command line mode if we
detect the desired resolution (and clock if specified) amongst the
probed modes. This fixes the immediate problem of adding a duplicate
mode, but perhaps more generically we should avoid adding a GTF mode if
the monitor has an EDID that is not GTF-compatible, or similarly for
CVT.

Was meant to fix a regression from

commit eaf99c749d43ae74ac7ffece5512f3c73f01dfd2
Author: Chris Wilson 
Date:   Wed Aug 6 10:08:32 2014 +0200

    drm: Perform cmdline mode parsing during connector initialisation

but Radek explained that the original bug is no longer reproducible on
latest kernels.

v2: Explicitly delete our earlier cmdline mode
v3: Mode pruning should now be sufficient to delete stale cmdline modes
v4: Compute the vrefresh for the probed mode

Reported-by: Radek Dostál 
Signed-off-by: Chris Wilson 
Cc: Radek Dostál 
Cc: Jesse Barnes 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc: Julia Lemire 
Cc: Dave Airlie 
Reviewed-by: Alex Deucher 
Reviewed-by: Ville Syrjälä 
[danvet: Drop cc: stable since no longer a pressing bugfix, just
nice-to-have.]
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1464774651-20376-1-git-send-email-chris@chris-wilson.co.uk

drm: probe_helper: Hide ugly ifdef

2016-04-20T11:35:14+00:00

Push the ifdef to the drm_edid.h and create a stub, for the
DRM_LOAD_EDID_FIRMWARE=n case. This removes some clutter in
the code, making it more readable.

Signed-off-by: Ezequiel Garcia 
Reviewed-by: Jani Nikula 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1461087638-16959-1-git-send-email-ezequiel@vanguardiasur.com.ar

drm: Expand the drm_helper_probe_single_connector_modes() docs

2015-12-11T08:35:16+00:00

Describe the procedure that drm_helper_probe_single_connector_modes()
uses to do it's work in the kernel-doc comment.

Caveat: Looks like crap and trying to reverse engineer the documentation
tools is not something I want to do.

Suggested-by: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1449782037-19722-3-git-send-email-ville.syrjala@linux.intel.com

drm: Allow override_edid to override the firmware EDID

2015-12-11T08:35:12+00:00

IMO the override_edid should override any default EDID for the
connector, whether that came in via the connector helper ->get_modes()
vfunc or via the firmware EDID mechanism.

Cc: Thomas Wood 
Signed-off-by: Ville Syrjälä 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1449782037-19722-2-git-send-email-ville.syrjala@linux.intel.com

drm: Drop drm_helper_probe_single_connector_modes_nomerge()

2015-12-11T08:32:53+00:00

Now that the mode type bit merge logic is fixed to only merge
between new probed modes, hopefully we can eliminat the special
case for qxl and virtio. That is make the merge the mode type
bits from all matching new probed modes, just like every other
driver.

qxl and virtio got excluded from the merging in
commit 3fbd6439e463 ("drm: copy mode type in drm_mode_connector_list_update()")
commit abce1ec9b08a ("Revert "drm: copy mode type in drm_mode_connector_list_update()"")
commit b87577b7c768 ("drm: try harder to avoid regression when merging mode bits")

Cc: Marc-André Lureau 
Cc: Dave Airlie 
Cc: Daniel Vetter 
Cc: Adam Jackson 
Signed-off-by: Ville Syrjälä 
[danvet: Resolve conflicts with doc updates.]
Signed-off-by: Daniel Vetter

drm: Rename MODE_UNVERIFIED to MODE_STALE

2015-12-11T08:26:47+00:00

MODE_UNVERIFIED actually means that the mode came from a previous probe,
and if the new probe doesn't produce a matching mode it will get pruned
from the list. Rename the flag to MODE_STALE to better convey the
meaning.

v2: Rebased due to conflicts with Daniel's doc stuff

Cc: Adam Jackson 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Daniel Vetter 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1449779948-10906-1-git-send-email-ville.syrjala@linux.intel.com

drm: Don't overwrite UNVERFIED mode status to OK

2015-12-11T08:21:02+00:00

The way the mode probing works is this:
1. All modes currently on the mode list are marked as UNVERIFIED
2. New modes are on the probed_modes list (they start with
   status OK)
3. Modes are moved from the probed_modes list to the actual
   mode list. If a mode already on the mode list is deemed
   to match one of the probed modes, the duplicate is dropped
   and the mode status updated to OK. After this the
   probed_modes list will be empty.
4. All modes on the mode list are verified to not violate any
   constraints. Any that do are marked as such.
5. Any mode left with a non-OK status is pruned from the list,
   with an appropriate debug message.

What all this means is that any mode on the original list that
didn't have a duplicate on the probed_modes list, should be left
with status UNVERFIED (or previously could have been left with
some other status, but never OK).

I broke that in
commit 05acaec334fc ("drm: Reorganize probed mode validation")
by always assigning something to the mode->status during the validation
step. So any mode from the old list that still passed the validation
would be left on the list with status OK in the end.

Fix this by not doing the basic mode validation unless the mode
already has status OK (meaning it came from the probed_modes list,
or at least a duplicate of it was on that list). This way we will
correctly prune away any mode from the old mode list that didn't
appear on the probed_modes list.

Cc: stable@vger.kernel.org
Cc: Adam Jackson 
Fixes: 05acaec334fc ("drm: Reorganize probed mode validation")
Signed-off-by: Ville Syrjälä 
Link: http://patchwork.freedesktop.org/patch/msgid/1449177255-9515-2-git-send-email-ville.syrjala@linux.intel.com
Testcase: igt/kms_force_connector_basic/prune-stale-modes
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93332
[danvet: Also applying to drm-misc to avoid too much conflict hell -
there's a big pile of patches from Ville on top of this one.]
Signed-off-by: Daniel Vetter