linux-stable.git/drivers/gpu, branch linux-4.5.y

drm/imx: Match imx-ipuv3-crtc components using device node in platform data

2016-06-08T01:18:52+00:00

commit 310944d148e3600dcff8b346bee7fa01d34903b1 upstream.

The component master driver imx-drm-core matches component devices using
their of_node. Since commit 950b410dd1ab ("gpu: ipu-v3: Fix imx-ipuv3-crtc
module autoloading"), the imx-ipuv3-crtc dev->of_node is not set during
probing. Before that, of_node was set and caused an of: modalias to be
used instead of the platform: modalias, which broke module autoloading.

On the other hand, if dev->of_node is not set yet when the imx-ipuv3-crtc
probe function calls component_add, component matching in imx-drm-core
fails. While dev->of_node will be set once the next component tries to
bring up the component master, imx-drm-core component binding will never
succeed if one of the crtc devices is probed last.

Add of_node to the component platform data and match against the
pdata->of_node instead of dev->of_node in imx-drm-core to work around
this problem.

Fixes: 950b410dd1ab ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading")
Signed-off-by: Philipp Zabel 
Tested-by: Fabio Estevam 
Tested-by: Lothar Waßmann 
Tested-by: Heiko Schocher 
Tested-by: Chris Ruehl 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Fix watermarks for VLV/CHV

2016-06-08T01:18:52+00:00

commit caed361d83b204b7766924b80463bf7502ee7986 upstream.

commit 92826fcdfc14 ("drm/i915: Calculate watermark related members in the crtc_state, v4.")
broke thigns by removing the pre vs. post wm update distinction. We also
lost the pre plane wm update entirely for VLV/CHV from the crtc enable
path.

This caused underruns on modeset and plane enable/disable on CHV,
and often those can lead to a dead pipe.

So let's bring back the pre vs. post thing, and let's toss in an
explicit wm update to valleyview_crtc_enable() to avoid having to
put it into the common code.

This is more or less a partial revert of the offending commit.

Cc: Maarten Lankhorst 
Cc: drm-intel-fixes@lists.freedesktop.org
Fixes: 92826fcdfc14 ("drm/i915: Calculate watermark related members in the crtc_state, v4.")
Signed-off-by: Ville Syrjälä 
Link: http://patchwork.freedesktop.org/patch/msgid/1457543247-13987-4-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Don't leave old junk in ilk active watermarks on readout

2016-06-08T01:18:52+00:00

commit 7045c3689f148a0c95f42bae8ef3eb2829ac7de9 upstream.

When we read out the watermark state from the hardware we're supposed to
transfer that into the active watermarks, but currently we fail to any
part of the active watermarks that isn't explicitly written. Let's clear
it all upfront.

Looks like this has been like this since the beginning, when I added the
readout. No idea why I didn't clear it up.

Cc: Matt Roper 
Fixes: 243e6a44b9ca ("drm/i915: Init HSW watermark tracking in intel_modeset_setup_hw_state()")
Signed-off-by: Ville Syrjälä 
Reviewed-by: Matt Roper 
Signed-off-by: Matt Roper 
Link: http://patchwork.freedesktop.org/patch/msgid/1463151318-14719-2-git-send-email-ville.syrjala@linux.intel.com
(cherry picked from commit 15606534bf0a65d8a74a90fd57b8712d147dbca6)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915/psr: Try to program link training times correctly

2016-06-08T01:18:52+00:00

commit 03b7b5f983091bca17e9c163832fcde56971d7d1 upstream.

The default of 0 is 500us of link training, but that's not enough for
some platforms. Decoding this correctly means we're using 2.5ms of
link training on these platforms, which fixes flickering issues
associated with enabling PSR.

v2: Unbotch the math a bit.

v3: Drop debug hunk.

v4: Improve commit message.

Tested-by: Lyude 
Cc: Lyude 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95176
Cc: Rodrigo Vivi 
Cc: Sonika Jindal 
Cc: Durgadoss R 
Cc: "Pandiyan, Dhinakaran" 
Tested-by: Ville Syrjälä 
Reviewed-by: Ville Syrjälä 
Tested-by: fritsch@kodi.tv
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1463590036-17824-2-git-send-email-daniel.vetter@ffwll.ch
(cherry picked from commit 50db139018f9c94376d5f4db94a3bae65fdfac14)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/atomic: Verify connector->funcs != NULL when clearing states

2016-06-08T01:18:52+00:00

Unfortunately since we don't have Dave's connector refcounting patch
here yet, it's very possible that drm_atomic_state_default_clear() could
get called by intel_display_resume() when
intel_dp_mst_destroy_connector() isn't completely finished destroying an
mst connector, but has already finished setting connector->funcs to
NULL. As such, we need to treat the connector like it's already been
destroyed and just skip it, otherwise we'll end up dereferencing a NULL
pointer.

This fix is only required for 4.6 and below. David Airlie's patchseries
for 4.7 to add connector reference counting provides a more proper fix
for this.

Changes since v1:
 - Fix leftover whitespace

Upstream fix: 0552f7651bc2 ("drm/i915/mst: use reference counted
connectors. (v3)")
Reviewed-by: Daniel Vetter 
Signed-off-by: Lyude

drm/fb_helper: Fix references to dev->mode_config.num_connector

2016-06-08T01:18:52+00:00

commit 255f0e7c418ad95a4baeda017ae6182ba9b3c423 upstream.

During boot, MST hotplugs are generally expected (even if no physical
hotplugging occurs) and result in DRM's connector topology changing.
This means that using num_connector from the current mode configuration
can lead to the number of connectors changing under us. This can lead to
some nasty scenarios in fbcon:

- We allocate an array to the size of dev->mode_config.num_connectors.
- MST hotplug occurs, dev->mode_config.num_connectors gets incremented.
- We try to loop through each element in the array using the new value
  of dev->mode_config.num_connectors, and end up going out of bounds
  since dev->mode_config.num_connectors is now larger then the array we
  allocated.

fb_helper->connector_count however, will always remain consistent while
we do a modeset in fb_helper.

Note: This is just polish for 4.7, Dave Airlie's drm_connector
refcounting fixed these bugs for real. But it's good enough duct-tape
for stable kernel backporting, since backporting the refcounting
changes is way too invasive.

Signed-off-by: Lyude 
[danvet: Clarify why we need this. Also remove the now unused "dev"
local variable to appease gcc.]
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1463065021-18280-3-git-send-email-cpaul@redhat.com
Signed-off-by: Greg Kroah-Hartman

drm/i915/fbdev: Fix num_connector references in intel_fb_initial_config()

2016-06-08T01:18:52+00:00

commit 14a3842a1d5945067d1dd0788f314e14d5b18e5b upstream.

During boot time, MST devices usually send a ton of hotplug events
irregardless of whether or not any physical hotplugs actually occurred.
Hotplugs mean connectors being created/destroyed, and the number of DRM
connectors changing under us. This isn't a problem if we use
fb_helper->connector_count since we only set it once in the code,
however if we use num_connector from struct drm_mode_config we risk it's
value changing under us. On top of that, there's even a chance that
dev->mode_config.num_connector != fb_helper->connector_count. If the
number of connectors happens to increase under us, we'll end up using
the wrong array size for memcpy and start writing beyond the actual
length of the array, occasionally resulting in kernel panics.

Note: This is just polish for 4.7, Dave Airlie's drm_connector
refcounting fixed these bugs for real. But it's good enough duct-tape
for stable kernel backporting, since backporting the refcounting
changes is way too invasive.

Signed-off-by: Lyude 
[danvet: Clarify why we need this.]
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1463065021-18280-2-git-send-email-cpaul@redhat.com
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: Fix hdmi deep color support.

2016-06-08T01:18:52+00:00

commit 9d746ab68163d642dae13756b2b3145b2e38cb65 upstream.

When porting the hdmi deep color detection code from
radeon-kms to amdgpu-kms apparently some kind of
copy and paste error happened, attaching an else
branch to the wrong if statement.

The result is that hdmi deep color mode is always
disabled, regardless of gpu and display capabilities and
user wishes, as the code mistakenly thinks that the display
doesn't provide the required max_tmds_clock limit and falls
back to 8 bpc.

This patch fixes deep color support, as tested on a
R9 380 Tonga Pro + suitable display, and should be
backported to all kernels with amdgpu-kms support.

Signed-off-by: Mario Kleiner 
Cc: Alex Deucher 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: use drm_mode_vrefresh() rather than mode->vrefresh

2016-06-08T01:18:51+00:00

commit 6b8812eb004ee2b24aac8b1a711a0e8e797df3ce upstream.

This is a port of radeon commit:
3d2d98ee1af0cf6eebfbd6bff4c17d3601ac1284
drm/radeon: use drm_mode_vrefresh() rather than mode->vrefresh
to amdgpu.

Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: Fix order of operation

2016-06-08T01:18:51+00:00

commit 7851496a32319237456919575e5f4ba62f74cc7d upstream.

mode->hdisplay * (var->bits_per_pixel + 7) gets evaluated before
the division, potentially making the pitch larger than it should
be.

Since the original intention is to do a div-round-up, just use
the macro instead.

Signed-off-by: Sinclair Yeh 
Reviewed-by: Thomas Hellstrom 
Signed-off-by: Greg Kroah-Hartman