linux-stable.git/drivers/gpu/drm, branch v4.1.23

drm/i915: Fix race condition in intel_dp_destroy_mst_connector()

2016-04-20T05:03:45+00:00

[ Upstream commit 9e60290dbafdf577766e5fc5f2fdb3be450cf9a6 ]

After unplugging a DP MST display from the system, we have to go through
and destroy all of the DRM connectors associated with it since none of
them are valid anymore. Unfortunately, intel_dp_destroy_mst_connector()
doesn't do a good enough job of ensuring that throughout the destruction
process that no modesettings can be done with the connectors. As it is
right now, intel_dp_destroy_mst_connector() works like this:

* Take all modeset locks
* Clear the configuration of the crtc on the connector, if there is one
* Drop all modeset locks, this is required because of circular
  dependency issues that arise with trying to remove the connector from
  sysfs with modeset locks held
* Unregister the connector
* Take all modeset locks, again
* Do the rest of the required cleaning for destroying the connector
* Finally drop all modeset locks for good

This only works sometimes. During the destruction process, it's very
possible that a userspace application will attempt to do a modesetting
using the connector. When we drop the modeset locks, an ioctl handler
such as drm_mode_setcrtc has the oppurtunity to take all of the modeset
locks from us. When this happens, one thing leads to another and
eventually we end up committing a mode with the non-existent connector:

	[drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* failed to enable link training
	[drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
	[drm:intel_dp_start_link_train [i915]] *ERROR* failed to start channel equalization
	[drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
	[drm:intel_mst_pre_enable_dp [i915]] *ERROR* failed to allocate vcpi

And in some cases, such as with the T460s using an MST dock, this
results in breaking modesetting and/or panicking the system.

To work around this, we now unregister the connector at the very
beginning of intel_dp_destroy_mst_connector(), grab all the modesetting
locks, and then hold them until we finish the rest of the function.

CC: stable@vger.kernel.org
Signed-off-by: Lyude 
Signed-off-by: Rob Clark 
Reviewed-by: Ville Syrjälä 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1458155884-13877-1-git-send-email-cpaul@redhat.com
(cherry picked from commit 1f7717552ef1306be3b7ed28c66c6eff550e3a23)
Signed-off-by: Jani Nikula 
Signed-off-by: Sasha Levin

drm/i915: Update atomic state when removing mst connector, v3.

2016-04-20T05:03:45+00:00

[ Upstream commit 20fae983c6667d038e810c618e3340946b8dc506 ]

Fully remove the MST connector from the atomic state, and remove the
early returns in check_*_state for MST connectors.

With atomic the state can be made consistent all the time.

Thanks to Sivakumar Thulasimani for the idea of using
drm_atomic_helper_set_config.

Changes since v1:
- Remove the MST check in intel_connector_check_state too.
Changes since v2:
- Use drm_atomic_helper_set_config.

Signed-off-by: Maarten Lankhorst 
Cc: Sivakumar Thulasimani 
Reviewed-by: Sivakumar Thulasimani 
Signed-off-by: Daniel Vetter 
Signed-off-by: Sasha Levin

drm/qxl: fix cursor position with non-zero hotspot

2016-04-20T05:03:42+00:00

[ Upstream commit d59a1f71ff1aeda4b4630df92d3ad4e3b1dfc885 ]

The SPICE protocol considers the position of a cursor to be the location
of its active pixel on the display, so the cursor is drawn with its
top-left corner at "(x - hot_spot_x, y - hot_spot_y)" but the DRM cursor
position gives the location where the top-left corner should be drawn,
with the hotspot being a hint for drivers that need it.

This fixes the location of the window resize cursors when using Fluxbox
with the QXL DRM driver and both the QXL and modesetting X drivers.

Signed-off-by: John Keeping 
Reviewed-by: Daniel Vetter 
Cc: stable@vger.kernel.org
Link: http://patchwork.freedesktop.org/patch/msgid/1447845445-2116-1-git-send-email-john@metanate.com
Signed-off-by: Jani Nikula 
Signed-off-by: Sasha Levin

drm/radeon: rework fbdev handling on chips with no connectors

2016-04-18T12:50:57+00:00

[ Upstream commit e5f243bd2edd95c6cc1d90c1878f821068e83fba ]

Move all the logic to radeon_fb.c and add checks to functions
called frome elsewhere.

bug:
https://bugzilla.kernel.org/show_bug.cgi?id=112781

Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

drm/radeon: Don't drop DP 2.7 Ghz link setup on some cards.

2016-04-18T12:50:51+00:00

[ Upstream commit 459ee1c3fd097ab56ababd8ff4bb7ef6a792de33 ]

As observed on Apple iMac10,1, DCE-3.2, RV-730,
link rate of 2.7 Ghz is not selected, because
the args.v1.ucConfig flag setting for 2.7 Ghz
gets overwritten by a following assignment of
the transmitter to use.

Move link rate setup a few lines down to fix this.
In practice this didn't have any positive or
negative effect on display setup on the tested
iMac10,1 so i don't know if backporting to stable
makes sense or not.

Signed-off-by: Mario Kleiner 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

drm/radeon: disable runtime pm on PX laptops without dGPU power control

2016-04-18T12:50:51+00:00

[ Upstream commit e64c952efb8e0c15ae82cec8e455ab4910690ef1 ]

Some PX laptops don't provide an ACPI method to control dGPU power.  On
those systems, the driver is responsible for handling the dGPU power
state.  Disable runtime PM on them until support for this is implemented.

Reviewed-by: Michel Dänzer 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

Revert "drm/radeon: call hpd_irq_event on resume"

2016-04-13T21:14:28+00:00

[ Upstream commit 256faedcfd646161477d47a1a78c32a562d2e845 ]

This reverts commit dbb17a21c131eca94eb31136eee9a7fe5aff00d9.

It turns out that commit can cause problems for systems with multiple
GPUs, and causes X to hang on at least a HP Pavilion dv7 with hybrid
graphics.

This got noticed originally in 4.4.4, where this patch had already
gotten back-ported, but 4.5-rc7 was verified to have the same problem.

Alexander Deucher says:
 "It looks like you have a muxed system so I suspect what's happening is
  that one of the display is being reported as connected for both the
  IGP and the dGPU and then the desktop environment gets confused or
  there some sort problem in the detect functions since the mux is not
  switched to the dGPU.  I don't see an easy fix unless Dave has any
  ideas.  I'd say just revert for now"

Reported-by: Jörg-Volker Peetz 
Acked-by: Alexander Deucher 
Cc: Dave Airlie 
Cc: stable@kernel.org  # wherever dbb17a21c131 got back-ported
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

drm/dp/mst: deallocate payload on port destruction

2016-04-13T21:14:25+00:00

[ Upstream commit 91a25e463130c8e19bdb42f2d827836c7937992e ]

This is needed to properly deallocate port payload
after downstream branch get unplugged.

In order to do this unplugged MST topology should
be preserved, to find first alive port on path to
unplugged MST topology, and send payload deallocation
request to branch device of found port.

For this mstb and port kref's are used in reversed
order to track when port and branch memory could be
freed.

Added additional functions to find appropriate mstb
as described above.

Signed-off-by: Mykola Lysenko 
Reviewed-by: Harry Wentland 
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie 
Signed-off-by: Sasha Levin

drm/dp/mst: Reverse order of MST enable and clearing VC payload table.

2016-04-13T21:14:24+00:00

[ Upstream commit c175cd16df272119534058f28cbd5eeac6ff2d24 ]

On DELL U3014 if you clear the table before enabling MST it sometimes
hangs the receiver.

Signed-off-by: Andrey Grodzovsky 
Reviewed-by: Harry Wentland 
Cc: stable@vger.kernel.org
Acked-by: Alex Deucher 
Signed-off-by: Dave Airlie 
Signed-off-by: Sasha Levin

drm/dp/mst: move GUID storage from mgr, port to only mst branch

2016-04-13T21:14:24+00:00

[ Upstream commit 5e93b8208d3c419b515fb75e2601931c027e12ab ]

Previous implementation does not handle case below: boot up one MST branch
to DP connector of ASIC. After boot up, hot plug 2nd MST branch to DP output
of 1st MST, GUID is not created for 2nd MST branch. When downstream port of
2nd MST branch send upstream request, it fails because 2nd MST branch GUID
is not available.

New Implementation: only create GUID for MST branch and save it within Branch.

Signed-off-by: Hersen Wu 
Reviewed-by: Harry Wentland 
Cc: stable@vger.kernel.org
Acked-by: Alex Deucher 
Signed-off-by: Dave Airlie 
Signed-off-by: Sasha Levin