linux-stable.git/drivers/gpu/drm, branch v3.18.35

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

2016-06-06T23:11:10+00:00

[ Upstream commit 7045c3689f148a0c95f42bae8ef3eb2829ac7de9 ]

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()")
Cc: stable@vger.kernel.org
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: Sasha Levin

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

2016-06-06T23:11:06+00:00

[ Upstream commit 255f0e7c418ad95a4baeda017ae6182ba9b3c423 ]

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.

Cc: stable@vger.kernel.org
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: Sasha Levin

drm/gma500: Fix possible out of bounds read

2016-06-01T20:26:03+00:00

[ Upstream commit 7ccca1d5bf69fdd1d3c5fcf84faf1659a6e0ad11 ]

Fix possible out of bounds read, by adding missing comma.
The code may read pass the end of the dsi_errors array
when the most significant bit (bit #31) in the intr_stat register
is set.
This bug has been detected using CppCheck (static analysis tool).

Cc: stable@vger.kernel.org
Signed-off-by: Itai Handler 
Signed-off-by: Patrik Jakobsson 
Signed-off-by: Sasha Levin

drm/i915: Bail out of pipe config compute loop on LPT

2016-05-18T01:56:40+00:00

[ Upstream commit 2700818ac9f935d8590715eecd7e8cadbca552b6 ]

LPT is pch, so might run into the fdi bandwidth constraint (especially
since it has only 2 lanes). But right now we just force pipe_bpp back
to 24, resulting in a nice loop (which we bail out with a loud
WARN_ON). Fix this.

Cc: Chris Wilson 
Cc: Maarten Lankhorst 
References: https://bugs.freedesktop.org/show_bug.cgi?id=93477
Signed-off-by: Daniel Vetter 
Tested-by: Chris Wilson 
Signed-off-by: Maarten Lankhorst 
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1462264381-7573-1-git-send-email-daniel.vetter@ffwll.ch
(cherry picked from commit f58a1acc7e4a1f37d26124ce4c875c647fbcc61f)
Signed-off-by: Jani Nikula 
Signed-off-by: Sasha Levin

drm/radeon: make sure vertical front porch is at least 1

2016-05-17T21:30:03+00:00

[ Upstream commit 3104b8128d4d646a574ed9d5b17c7d10752cd70b ]

hw doesn't like a 0 value.

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

drm/i915/ddi: Fix eDP VDD handling during booting and suspend/resume

2016-05-17T18:49:16+00:00

[ Upstream commit 5eaa60c7109b40f17ac81090bc8b90482da76cd1 ]

The driver's VDD on/off logic assumes that whenever the VDD is on we
also hold an AUX power domain reference. Since BIOS can leave the VDD on
during booting and resuming and on DDI platforms we won't take a
corresponding power reference, the above assumption won't hold on those
platforms and an eventual delayed VDD off work will do an extraneous AUX
power domain put resulting in a refcount underflow. Fix this the same
way we did this for non-DDI DP encoders:

commit 6d93c0c41760c0 ("drm/i915: fix VDD state tracking after system
resume")

At the same time call the DP encoder suspend handler the same way as the
non-DDI DP encoders do to flush any pending VDD off work. Leaving the
work running may cause a HW access where we don't expect this (at a point
where power domains are suspended already).

While at it remove an unnecessary function call indirection.

This fixed for me AUX refcount underflow problems on BXT during
suspend/resume.

CC: Ville Syrjälä 
CC: stable@vger.kernel.org
Signed-off-by: Imre Deak 
Reviewed-by: Ville Syrjälä 
Link: http://patchwork.freedesktop.org/patch/msgid/1460963062-13211-4-git-send-email-imre.deak@intel.com
(cherry picked from commit bf93ba67e9c05882f05b7ca2d773cfc8bf462c2a)
Signed-off-by: Jani Nikula 
Signed-off-by: Sasha Levin

drm/i915: Read out the power sequencer port assignment on resume on vlv/chv

2016-05-17T18:49:04+00:00

[ Upstream commit 49e6bc51bc9e22c8a433ba32a4e45a5818de3850 ]

When we suspend we turn everything off so the pps should be idle, and we
also (or at least should) disable all power wells which will reset the
power sequencer port assignment. So when we resume all power sequencers
should be in their reset state. However it's at least theoretically
possible that the BIOS would touch the power seuqencer(s), so to be safe
we ought to read out the current port assignment like we do at driver
init time.

To do that we can simply call vlv_initial_power_sequencer_setup() from
the encoder ->reset() hook before calling intel_edp_panel_vdd_sanitize().
There's no danger or clobbering the pps delays since we now have those
stored within intel_dp and we don't change them once initialized.

This will make sure that the vdd state gets correctly tracked post-resume
in case the BIOS enabled it.

We need to shuffle things around a bit to get the locking right, and
while at it, make intel_edp_panel_vdd_sanitize() static and move it
around a bit to avoid a forward declaration.

Cc: Imre Deak 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Imre Deak 
Signed-off-by: Daniel Vetter 
Signed-off-by: Sasha Levin

drm/dp/mst: Restore primary hub guid on resume

2016-05-17T18:32:34+00:00

[ Upstream commit 9dc0487d96a0396367a1451b31873482080b527f ]

Some hubs are forgetful, and end up forgetting whatever GUID we set
previously after we do a suspend/resume cycle. This can lead to
hotplugging breaking (along with probably other things) since the hub
will start sending connection notifications with the wrong GUID. As
such, we need to check on resume whether or not the GUID the hub is
giving us is valid.

Signed-off-by: Lyude 
Reviewed-by: Harry Wentland 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1460580618-7421-1-git-send-email-cpaul@redhat.com
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie 
Signed-off-by: Sasha Levin

drm/dp/mst: Get validated port ref in drm_dp_update_payload_part1()

2016-05-17T18:32:23+00:00

[ Upstream commit 263efde31f97c498e1ebad30e4d2906609d7ad6b ]

We can thank KASAN for finding this, otherwise I probably would have spent
hours on it. This fixes a somewhat harder to trigger kernel panic, occuring
while enabling MST where the port we were currently updating the payload on
would have all of it's refs dropped before we finished what we were doing:

==================================================================
BUG: KASAN: use-after-free in drm_dp_update_payload_part1+0xb3f/0xdb0 [drm_kms_helper] at addr ffff8800d29de018
Read of size 4 by task Xorg/973
=============================================================================
BUG kmalloc-2048 (Tainted: G    B   W      ): kasan: bad access detected
-----------------------------------------------------------------------------

INFO: Allocated in drm_dp_add_port+0x1aa/0x1ed0 [drm_kms_helper] age=16477 cpu=0 pid=2175
	___slab_alloc+0x472/0x490
	__slab_alloc+0x20/0x40
	kmem_cache_alloc_trace+0x151/0x190
	drm_dp_add_port+0x1aa/0x1ed0 [drm_kms_helper]
	drm_dp_send_link_address+0x526/0x960 [drm_kms_helper]
	drm_dp_check_and_send_link_address+0x1ac/0x210 [drm_kms_helper]
	drm_dp_mst_link_probe_work+0x77/0xd0 [drm_kms_helper]
	process_one_work+0x562/0x1350
	worker_thread+0xd9/0x1390
	kthread+0x1c5/0x260
	ret_from_fork+0x22/0x40
INFO: Freed in drm_dp_free_mst_port+0x50/0x60 [drm_kms_helper] age=7521 cpu=0 pid=2175
	__slab_free+0x17f/0x2d0
	kfree+0x169/0x180
	drm_dp_free_mst_port+0x50/0x60 [drm_kms_helper]
	drm_dp_destroy_connector_work+0x2b8/0x490 [drm_kms_helper]
	process_one_work+0x562/0x1350
	worker_thread+0xd9/0x1390
	kthread+0x1c5/0x260
	ret_from_fork+0x22/0x40

which on this T460s, would eventually lead to kernel panics in somewhat
random places later in intel_mst_enable_dp() if we got lucky enough.

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

drm/radeon: forbid mapping of userptr bo through radeon device file

2016-05-10T16:20:18+00:00

[ Upstream commit b5dcec693f87cb8475f2291c0075b2422addd3d6 ]

Allowing userptr bo which are basicly a list of page from some vma
(so either anonymous page or file backed page) would lead to serious
corruption of kernel structures and counters (because we overwrite
the page->mapping field when mapping buffer).

This will already block if the buffer was populated before anyone does
try to mmap it because then TTM_PAGE_FLAG_SG would be set in in the
ttm_tt flags. But that flag is check before ttm_tt_populate in the ttm
vm fault handler.

So to be safe just add a check to verify_access() callback.

Reviewed-by: Christian König 
Signed-off-by: Jérôme Glisse 
Cc: 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin