linux-stable.git/drivers/gpu, branch v4.1.18

drm/i915: Take all modeset locks for DP MST hotplug

2016-02-15T20:45:36+00:00

[ Upstream commit 8bb4da1df54a20d68c34427356e34315ba122c0f ]

While auditing various users of the connector/encoder lists I realized
that the atomic code is a very prolific user of them. And it only ever
grabs the mode_config->connection_mutex, but not the
mode_config->mutex like all the other code walking encoder/connector
lists.

The problem is that we can't grab the mode_config.mutex late in atomic
code since that would lead to locking inversions. And we don't want to
grab it unconditionally like the legacy set_config modeset path since
that would render all the fine-grained locking moot.

Instead just grab more locks in the dp mst hotplug code. Note that
drm_connector_init (which is the one adding the connector to these
lists) already uses drm_modeset_lock_all.

The other reason for grabbing all locks is that the dpms off in the
unplug function amounts to a modeset, so better to take all required
locks for that.

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

drm/radeon: Take all modeset locks for DP MST hotplug

2016-02-15T20:45:36+00:00

[ Upstream commit 2ee6bcdcfa4d8b56b20bc6308cd5f9bced5b5324 ]

Similar with the i915 take all modeset locks for mst hotplug. This is
needed to make sure radeon holds both mode_config.mutex and
mode_config.connection_mutex when updating the connector_list, which
is the new (interim) locking regime we want for that.

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

drm/dp/mst: fixup handling hotplug on port removal.

2016-02-15T20:45:36+00:00

[ Upstream commit df4839fdc9b3c922586b945f062f38cbbda022bb ]

output ports should always have a connector, unless
in the rare case connector allocation fails in the
driver.

In this case we only need to teardown the pdt,
and free the struct, and there is no need to
send a hotplug msg.

In the case were we add the port to the destroy
list we need to send a hotplug if we destroy
any connectors, so userspace knows to reprobe
stuff.

this patch also handles port->connector allocation
failing which should be a rare event, but makes
the code consistent.

Reviewed-by: Daniel Vetter 
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie 
Signed-off-by: Sasha Levin

drm/dp/mst: Remove port after removing connector.

2016-02-15T20:45:35+00:00

[ Upstream commit 4772ff03df8094fd99d28de5fcf5df3a3e9c68bb ]

The port is removed synchronously, but the connector delayed.
This causes a use after free which can cause a kernel BUG with
slug_debug=FPZU. This is fixed by freeing the port after the
connector.

This fixes a regression introduced with
6b8eeca65b18ae77e175cc2b6571731f0ee413bf
"drm/dp/mst: close deadlock in connector destruction."

Cc: stable@vger.kernel.org
Cc: Dave Airlie 
Signed-off-by: Maarten Lankhorst 
Reviewed-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
Signed-off-by: Sasha Levin

drm/dp/mst: Calculate MST PBN with 31.32 fixed point

2016-02-15T20:45:35+00:00

[ Upstream commit a9ebb3e46c7ef6112c0da466ef0954673ad36832 ]

Our PBN value overflows the 20 bits integer part of the 20.12
fixed point. We need to use 31.32 fixed point to avoid this.

This happens with display clocks larger than 293122 (at 24 bpp),
which we see with the Sharp (and similar) 4k tiled displays.

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

drm: fix missing reference counting decrease

2016-02-15T20:45:35+00:00

[ Upstream commit dabe19540af9e563d526113bb102e1b9b9fa73f9 ]

In drm_dp_mst_allocate_vcpi, it returns true in two paths,
but in one path, there is no reference couting decrease.

Signed-off-by: Insu Yun 
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie 
Signed-off-by: Sasha Levin

drm/radeon: mask out WC from BO on unsupported arches

2016-02-15T20:45:31+00:00

[ Upstream commit c5244987394648913ae1a03879c58058a2fc2cee ]

Reviewed-by: Christian König 
Reviewed-by: Michel Dänzer 
Signed-off-by: Oded Gabbay 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

drm/radeon: Always disable RADEON_GEM_GTT_UC along with RADEON_GEM_GTT_WC

2016-02-15T20:45:31+00:00

[ Upstream commit a28bbd5824d4a2af98de45b300ab8d8fb39739fc ]

Write-combining is a CPU feature. From the GPU POV, these both simply
mean no GPU<->CPU cache coherency.

Reviewed-by: Christian König 
Signed-off-by: Michel Dänzer 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/i915/dp: fall back to 18 bpp when sink capability is unknown

2016-02-15T20:45:29+00:00

[ Upstream commit 5efd407674068dede403551bea3b0b134c32513a ]

Per DP spec, the source device should fall back to 18 bpp, VESA range
RGB when the sink capability is unknown. Fix the color depth
clamping. 18 bpp color depth should ensure full color range in automatic
mode.

The clamping has been HDMI specific since its introduction in

commit 996a2239f93b03c5972923f04b097f65565c5bed
Author: Daniel Vetter 
Date:   Fri Apr 19 11:24:34 2013 +0200

    drm/i915: Disable high-bpc on pre-1.4 EDID screens

Cc: stable@vger.kernel.org
Reported-and-tested-by: Dihan Wickremasuriya 
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105331
Reviewed-by: Ville Syrjälä 
Signed-off-by: Jani Nikula 
Link: http://patchwork.freedesktop.org/patch/msgid/1452695720-7076-1-git-send-email-jani.nikula@intel.com
(cherry picked from commit 013dd9e038723bbd2aa67be51847384b75be8253)
Signed-off-by: Sasha Levin

drm/vmwgfx: respect 'nomodeset'

2016-02-15T20:45:26+00:00

[ Upstream commit 96c5d076f0a5e2023ecdb44d8261f87641ee71e0 ]

Signed-off-by: Rob Clark 
Reviewed-by: Thomas Hellstrom .
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie 
Signed-off-by: Sasha Levin