<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu, branch v4.4.99</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.4.99</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.4.99'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2017-11-15T16:13:13+00:00</updated>
<entry>
<title>drm/vmwgfx: Fix Ubuntu 17.10 Wayland black screen issue</title>
<updated>2017-11-15T16:13:13+00:00</updated>
<author>
<name>Sinclair Yeh</name>
<email>syeh@vmware.com</email>
</author>
<published>2017-11-01T17:47:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ba4828af60e227fffb6ccca2e17c64938e7a5d0d'/>
<id>urn:sha1:ba4828af60e227fffb6ccca2e17c64938e7a5d0d</id>
<content type='text'>
commit cef75036c40408ba3bc308bcb00a3d440da713fc upstream.

This is an extension of Commit 7c20d213dd3c ("drm/vmwgfx: Work
around mode set failure in 2D VMs")

With Wayland desktop and atomic mode set, during the mode setting
process there is a moment when two framebuffer sized surfaces
are being pinned.  This was not an issue with Xorg.

Since this only happens during a mode change, there should be no
performance impact by increasing allowable mem_size.

Signed-off-by: Sinclair Yeh &lt;syeh@vmware.com&gt;
Reviewed-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm: drm_minor_register(): Clean up debugfs on failure</title>
<updated>2017-11-15T16:13:09+00:00</updated>
<author>
<name>Noralf Trønnes</name>
<email>noralf@tronnes.org</email>
</author>
<published>2017-01-26T22:56:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2393241b7a223a87761ab47fea43dbe466198629'/>
<id>urn:sha1:2393241b7a223a87761ab47fea43dbe466198629</id>
<content type='text'>
[ Upstream commit a67834f8bfa1e2f48bb27d07b9a552ba7c3af82a ]

Call drm_debugfs_cleanup() in case drm_debugfs_init() fails to
cover for failure in the drm_driver.debugfs_init callback.

Signed-off-by: Noralf Trønnes &lt;noralf@tronnes.org&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/20170126225621.12314-3-noralf@tronnes.org
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/amdgpu: when dpm disabled, also need to stop/start vce.</title>
<updated>2017-11-08T09:06:29+00:00</updated>
<author>
<name>Rex Zhu</name>
<email>Rex.Zhu@amd.com</email>
</author>
<published>2017-10-07T22:37:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3b7d9a95ccd38436295ab6598c526dac83504556'/>
<id>urn:sha1:3b7d9a95ccd38436295ab6598c526dac83504556</id>
<content type='text'>
[ Upstream commit 28ed5504ab4b211a4e589e648e5ebd1e0caa7a6a ]

Signed-off-by: Rex Zhu &lt;Rex.Zhu@amd.com&gt;
Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Acked-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/msm: fix an integer overflow test</title>
<updated>2017-11-08T09:06:28+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2017-06-30T07:59:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ded34f972348b0f252256bee161839c1aa5d8ae4'/>
<id>urn:sha1:ded34f972348b0f252256bee161839c1aa5d8ae4</id>
<content type='text'>
commit 65e93108891e571f177c202add9288eda9ac4100 upstream.

We recently added an integer overflow check but it needs an additional
tweak to work properly on 32 bit systems.

The problem is that we're doing the right hand side of the assignment as
type unsigned long so the max it will have an integer overflow instead
of being larger than SIZE_MAX.  That means the "sz &gt; SIZE_MAX" condition
is never true even on 32 bit systems.  We need to first cast it to u64
and then do the math.

Fixes: 4a630fadbb29 ("drm/msm: Fix potential buffer overflow issue")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Acked-by: Jordan Crouse &lt;jcrouse@codeaurora.org&gt;
Signed-off-by: Rob Clark &lt;robdclark@gmail.com&gt;
Cc: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/msm: Fix potential buffer overflow issue</title>
<updated>2017-11-08T09:06:28+00:00</updated>
<author>
<name>Kasin Li</name>
<email>donglil@codeaurora.org</email>
</author>
<published>2017-06-19T21:36:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=031b02bc16aeeb34c8038026cbbca1e6430c9d75'/>
<id>urn:sha1:031b02bc16aeeb34c8038026cbbca1e6430c9d75</id>
<content type='text'>
commit 4a630fadbb29d9efaedb525f1a8f7449ad107641 upstream.

In function submit_create, if nr_cmds or nr_bos is assigned with
negative value, the allocated buffer may be small than intended.
Using this buffer will lead to buffer overflow issue.

Signed-off-by: Kasin Li &lt;donglil@codeaurora.org&gt;
Signed-off-by: Jordan Crouse &lt;jcrouse@codeaurora.org&gt;
Signed-off-by: Rob Clark &lt;robdclark@gmail.com&gt;
Cc: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/nouveau/mmu: flush tlbs before deleting page tables</title>
<updated>2017-10-27T08:23:16+00:00</updated>
<author>
<name>Ben Skeggs</name>
<email>bskeggs@redhat.com</email>
</author>
<published>2017-09-25T05:05:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4516069f1b05d3e84f5e11a8490ee0ca09997731'/>
<id>urn:sha1:4516069f1b05d3e84f5e11a8490ee0ca09997731</id>
<content type='text'>
commit 77913bbcb43ac9a07a6fe849c2fd3bf85fc8bdd8 upstream.

Even though we've zeroed the PDE, the GPU may have cached the PD, so we
need to flush when deleting them.

Noticed while working on replacement MMU code, but a backport might be a
good idea, so let's fix it in the current code too.

Signed-off-by: Ben Skeggs &lt;bskeggs@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/nouveau/bsp/g92: disable by default</title>
<updated>2017-10-27T08:23:16+00:00</updated>
<author>
<name>Ilia Mirkin</name>
<email>imirkin@alum.mit.edu</email>
</author>
<published>2017-10-01T17:52:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=195674adee572b97761501f3906e4cc0e290891f'/>
<id>urn:sha1:195674adee572b97761501f3906e4cc0e290891f</id>
<content type='text'>
commit 194d68dd051c2dd5ac2b522ae16100e774e8d869 upstream.

G92's seem to require some additional bit of initialization before the
BSP engine can work. It feels like clocks are not set up for the
underlying VLD engine, which means that all commands submitted to the
xtensa chip end up hanging. VP seems to work fine though.

This still allows people to force-enable the bsp engine if they want to
play around with it, but makes it harder for the card to hang by
default.

Signed-off-by: Ilia Mirkin &lt;imirkin@alum.mit.edu&gt;
Signed-off-by: Ben Skeggs &lt;bskeggs@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/dp/mst: save vcpi with payloads</title>
<updated>2017-10-21T15:09:01+00:00</updated>
<author>
<name>Harry Wentland</name>
<email>harry.wentland@amd.com</email>
</author>
<published>2015-12-07T18:55:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c088f7bc3310bb57e0aaea297c7e2f467015d215'/>
<id>urn:sha1:c088f7bc3310bb57e0aaea297c7e2f467015d215</id>
<content type='text'>
commit 6cecdf7a161d2b909dc7c8979176bbc4f0669968 upstream.

This makes it possibly for drivers to find the associated
mst_port by looking at the payload allocation table.

Signed-off-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/1449514552-10236-3-git-send-email-harry.wentland@amd.com
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Cc: Kai Heng Feng &lt;kai.heng.feng@canonical.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915/bios: ignore HDMI on port A</title>
<updated>2017-10-12T09:27:35+00:00</updated>
<author>
<name>Jani Nikula</name>
<email>jani.nikula@intel.com</email>
</author>
<published>2017-09-21T14:19:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=33d1fa43aad4ca11f5d01ede363c1dbdd2010540'/>
<id>urn:sha1:33d1fa43aad4ca11f5d01ede363c1dbdd2010540</id>
<content type='text'>
commit 2ba7d7e0437127314864238f8bfcb8369d81075c upstream.

The hardware state readout oopses after several warnings when trying to
use HDMI on port A, if such a combination is configured in VBT. Filter
the combo out already at the VBT parsing phase.

v2: also ignore DVI (Ville)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102889
Cc: Imre Deak &lt;imre.deak@intel.com&gt;
Reviewed-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Tested-by: Daniel Drake &lt;dan@reactivated.net&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20170921141920.18172-1-jani.nikula@intel.com
(cherry picked from commit d27ffc1d00327c29b3aa97f941b42f0949f9e99f)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/amdkfd: fix improper return value on error</title>
<updated>2017-10-08T08:14:17+00:00</updated>
<author>
<name>Pan Bian</name>
<email>bianpan2016@163.com</email>
</author>
<published>2016-12-01T08:10:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8b2522eb44aed2b81d0958000a18f2ba8fb59ac3'/>
<id>urn:sha1:8b2522eb44aed2b81d0958000a18f2ba8fb59ac3</id>
<content type='text'>
[ Upstream commit 8bf793883da213864efc50c274d2b38ec0ca58b2 ]

In function kfd_wait_on_events(), when the call to copy_from_user()
fails, the value of return variable ret is 0. 0 indicates success, which
is inconsistent with the execution status. This patch fixes the bug by
assigning "-EFAULT" to ret when copy_from_user() returns an unexpected
value.

Signed-off-by: Pan Bian &lt;bianpan2016@163.com&gt;
Signed-off-by: Oded Gabbay &lt;oded.gabbay@gmail.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
