<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm, branch v4.1.25</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.1.25</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.1.25'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2016-05-17T17:43:12+00:00</updated>
<entry>
<title>drm/radeon: fix DP mode validation</title>
<updated>2016-05-17T17:43:12+00:00</updated>
<author>
<name>Alex Deucher</name>
<email>alexander.deucher@amd.com</email>
</author>
<published>2016-05-11T20:16:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6bdf63fe8999171e65f6b65bf837d3c5f8571da1'/>
<id>urn:sha1:6bdf63fe8999171e65f6b65bf837d3c5f8571da1</id>
<content type='text'>
[ Upstream commit ff0bd441bdfbfa09d05fdba9829a0401a46635c1 ]

Switch the order of the loops to walk the rates on the top
so we exhaust all DP 1.1 rate/lane combinations before trying
DP 1.2 rate/lane combos.

This avoids selecting rates that are supported by the monitor,
but not the connector leading to valid modes getting rejected.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=95206

Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>drm/i915: Bail out of pipe config compute loop on LPT</title>
<updated>2016-05-17T17:43:06+00:00</updated>
<author>
<name>Daniel Vetter</name>
<email>daniel.vetter@ffwll.ch</email>
</author>
<published>2016-05-03T08:33:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4a4c1df1af598459b550861f6bff17bfd8792295'/>
<id>urn:sha1:4a4c1df1af598459b550861f6bff17bfd8792295</id>
<content type='text'>
[ 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 &lt;chris@chris-wilson.co.uk&gt;
Cc: Maarten Lankhorst &lt;maarten.lankhorst@linux.intel.com&gt;
References: https://bugs.freedesktop.org/show_bug.cgi?id=93477
Signed-off-by: Daniel Vetter &lt;daniel.vetter@intel.com&gt;
Tested-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Signed-off-by: Maarten Lankhorst &lt;maarten.lankhorst@linux.intel.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
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 &lt;jani.nikula@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>drm/radeon: fix DP link training issue with second 4K monitor</title>
<updated>2016-05-17T17:43:01+00:00</updated>
<author>
<name>Arindam Nath</name>
<email>arindam.nath@amd.com</email>
</author>
<published>2016-05-04T18:09:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c42d74f018b072b30570856dd43ff582c4e5117e'/>
<id>urn:sha1:c42d74f018b072b30570856dd43ff582c4e5117e</id>
<content type='text'>
[ Upstream commit 1a738347df2ee4977459a8776fe2c62196bdcb1b ]

There is an issue observed when we hotplug a second DP
4K monitor to the system. Sometimes, the link training
fails for the second monitor after HPD interrupt
generation.

The issue happens when some queued or deferred transactions
are already present on the AUX channel when we initiate
a new transcation to (say) get DPCD or during link training.

We set AUX_IGNORE_HPD_DISCON bit in the AUX_CONTROL
register so that we can ignore any such deferred
transactions when a new AUX transaction is initiated.

Signed-off-by: Arindam Nath &lt;arindam.nath@amd.com&gt;
Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>drm/radeon: make sure vertical front porch is at least 1</title>
<updated>2016-05-17T17:42:57+00:00</updated>
<author>
<name>Alex Deucher</name>
<email>alexander.deucher@amd.com</email>
</author>
<published>2016-05-02T22:53:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d102342c3a8e0e791ba934cc3a43b0ed80b28938'/>
<id>urn:sha1:d102342c3a8e0e791ba934cc3a43b0ed80b28938</id>
<content type='text'>
[ Upstream commit 3104b8128d4d646a574ed9d5b17c7d10752cd70b ]

hw doesn't like a 0 value.

Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>drm/radeon: fix vertical bars appear on monitor (v2)</title>
<updated>2016-05-17T17:42:46+00:00</updated>
<author>
<name>Vitaly Prosyak</name>
<email>vitaly.prosyak@amd.com</email>
</author>
<published>2016-04-14T17:34:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3b54e5f0a5415a9a8b8618fa61d1303e2ba8add6'/>
<id>urn:sha1:3b54e5f0a5415a9a8b8618fa61d1303e2ba8add6</id>
<content type='text'>
[ Upstream commit 5d5b7803c49bbb01bdf4c6e95e8314d0515b9484 ]

When crtc/timing is disabled on boot the dig block
should be stopped in order ignore timing from crtc,
reset the steering fifo otherwise we get display
corruption or hung in dp sst mode.

v2: agd: fix coding style

Signed-off-by: Vitaly Prosyak &lt;vitaly.prosyak@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>drm/i915: Make RPS EI/thresholds multiple of 25 on SNB-BDW</title>
<updated>2016-05-17T17:42:46+00:00</updated>
<author>
<name>Ville Syrjälä</name>
<email>ville.syrjala@linux.intel.com</email>
</author>
<published>2016-04-20T13:43:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=344a144c6f7310bf40dd4a40daa4c0abb994d3c5'/>
<id>urn:sha1:344a144c6f7310bf40dd4a40daa4c0abb994d3c5</id>
<content type='text'>
[ Upstream commit 4ea3959018d09edfa36a9e7b5ccdbd4ec4b99e49 ]

Somehow my SNB GT1 (Dell XPS 8300) gets very unhappy around
GPU hangs if the RPS EI/thresholds aren't suitably aligned.
It seems like scheduling/timer interupts stop working somehow
and things get stuck eg. in usleep_range().

I bisected the problem down to
commit 8a5864377b12 ("drm/i915/skl: Restructured the gen6_set_rps_thresholds function")
I observed that before all the values were at least multiples of 25,
but afterwards they are not. And rounding things up to the next multiple
of 25 does seem to help, so lets' do that. I also tried roundup(..., 5)
but that wasn't sufficient. Also I have no idea if we might need this sort of
thing on gen9+ as well.

These are the original EI/thresholds:
 LOW_POWER
  GEN6_RP_UP_EI          12500
  GEN6_RP_UP_THRESHOLD   11800
  GEN6_RP_DOWN_EI        25000
  GEN6_RP_DOWN_THRESHOLD 21250
 BETWEEN
  GEN6_RP_UP_EI          10250
  GEN6_RP_UP_THRESHOLD    9225
  GEN6_RP_DOWN_EI        25000
  GEN6_RP_DOWN_THRESHOLD 18750
 HIGH_POWER
  GEN6_RP_UP_EI           8000
  GEN6_RP_UP_THRESHOLD    6800
  GEN6_RP_DOWN_EI        25000
  GEN6_RP_DOWN_THRESHOLD 15000

These are after 8a5864377b12:
 LOW_POWER
  GEN6_RP_UP_EI          12500
  GEN6_RP_UP_THRESHOLD   11875
  GEN6_RP_DOWN_EI        25000
  GEN6_RP_DOWN_THRESHOLD 21250
 BETWEEN
  GEN6_RP_UP_EI          10156
  GEN6_RP_UP_THRESHOLD    9140
  GEN6_RP_DOWN_EI        25000
  GEN6_RP_DOWN_THRESHOLD 18750
 HIGH_POWER
  GEN6_RP_UP_EI           7812
  GEN6_RP_UP_THRESHOLD    6640
  GEN6_RP_DOWN_EI        25000
  GEN6_RP_DOWN_THRESHOLD 15000

And these are what we have after this patch:
 LOW_POWER
  GEN6_RP_UP_EI          12500
  GEN6_RP_UP_THRESHOLD   11875
  GEN6_RP_DOWN_EI        25000
  GEN6_RP_DOWN_THRESHOLD 21250
 BETWEEN
  GEN6_RP_UP_EI          10175
  GEN6_RP_UP_THRESHOLD    9150
  GEN6_RP_DOWN_EI        25000
  GEN6_RP_DOWN_THRESHOLD 18750
 HIGH_POWER
  GEN6_RP_UP_EI           7825
  GEN6_RP_UP_THRESHOLD    6650
  GEN6_RP_DOWN_EI        25000
  GEN6_RP_DOWN_THRESHOLD 15000

Cc: stable@vger.kernel.org
Cc: Akash Goel &lt;akash.goel@intel.com&gt;
Cc: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Testcase: igt/kms_pipe_crc_basic/hang-read-crc-pipe-B
Fixes: 8a5864377b12 ("drm/i915/skl: Restructured the gen6_set_rps_thresholds function")
Signed-off-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/1461159836-9108-1-git-send-email-ville.syrjala@linux.intel.com
Acked-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Reviewed-by: Patrik Jakobsson &lt;patrik.jakobsson@linux.intel.com&gt;
(cherry picked from commit 8a292d016d1cc4938ff14b4df25328230b08a408)
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>drm/i915/ddi: Fix eDP VDD handling during booting and suspend/resume</title>
<updated>2016-05-17T17:42:45+00:00</updated>
<author>
<name>Imre Deak</name>
<email>imre.deak@intel.com</email>
</author>
<published>2016-04-18T07:04:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=39161f8ab357bc5e13eca3a04828cb7aecab0f9d'/>
<id>urn:sha1:39161f8ab357bc5e13eca3a04828cb7aecab0f9d</id>
<content type='text'>
[ 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ä &lt;ville.syrjala@linux.intel.com&gt;
CC: stable@vger.kernel.org
Signed-off-by: Imre Deak &lt;imre.deak@intel.com&gt;
Reviewed-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
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 &lt;jani.nikula@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>drm/dp/mst: Restore primary hub guid on resume</title>
<updated>2016-05-17T17:42:44+00:00</updated>
<author>
<name>Lyude</name>
<email>cpaul@redhat.com</email>
</author>
<published>2016-04-13T20:50:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b61a5d5456479618426d25bec4175c011bcc9726'/>
<id>urn:sha1:b61a5d5456479618426d25bec4175c011bcc9726</id>
<content type='text'>
[ 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 &lt;cpaul@redhat.com&gt;
Reviewed-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
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 &lt;airlied@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>drm/dp/mst: Get validated port ref in drm_dp_update_payload_part1()</title>
<updated>2016-05-17T17:42:43+00:00</updated>
<author>
<name>cpaul@redhat.com</name>
<email>cpaul@redhat.com</email>
</author>
<published>2016-04-22T20:08:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=85489830a875eee4c5357b2ffa217f06676c1211'/>
<id>urn:sha1:85489830a875eee4c5357b2ffa217f06676c1211</id>
<content type='text'>
[ 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 &lt;cpaul@redhat.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>drm/radeon: forbid mapping of userptr bo through radeon device file</title>
<updated>2016-05-10T16:17:32+00:00</updated>
<author>
<name>Jérôme Glisse</name>
<email>jglisse@redhat.com</email>
</author>
<published>2016-04-19T13:07:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2719d3c05d4c93054e7c5838cc5b1906f72b465e'/>
<id>urn:sha1:2719d3c05d4c93054e7c5838cc5b1906f72b465e</id>
<content type='text'>
[ 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-&gt;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 &lt;christian.koenig@amd.com&gt;
Signed-off-by: Jérôme Glisse &lt;jglisse@redhat.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
</feed>
