<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/gpu, branch v4.0-rc4</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>[PATCH] drm/mm: Fix support 4 GiB and larger ranges</title>
<updated>2015-03-15T20:28:50+00:00</updated>
<author>
<name>Krzysztof Kolasa</name>
<email>kkolasa@winsoft.pl</email>
</author>
<published>2015-03-15T19:22:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=046d669c62f37323ef0329c41d83a03c06b2087d'/>
<id>046d669c62f37323ef0329c41d83a03c06b2087d</id>
<content type='text'>
bad argument if(tmp)... in check_free_hole

fix oops: kernel BUG at drivers/gpu/drm/drm_mm.c:305!

[airlied: excellent, this was my task for today].

Signed-off-by: Krzysztof Kolasa &lt;kkolasa@winsoft.pl&gt;
Reviewed-by: Chris wilson &lt;chris@chris-wilson.co.uk&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
bad argument if(tmp)... in check_free_hole

fix oops: kernel BUG at drivers/gpu/drm/drm_mm.c:305!

[airlied: excellent, this was my task for today].

Signed-off-by: Krzysztof Kolasa &lt;kkolasa@winsoft.pl&gt;
Reviewed-by: Chris wilson &lt;chris@chris-wilson.co.uk&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux into drm-fixes</title>
<updated>2015-03-12T23:21:24+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2015-03-12T23:21:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=e2cdcafa8a53228cb996b3c3a0a48efe91c57b8e'/>
<id>e2cdcafa8a53228cb996b3c3a0a48efe91c57b8e</id>
<content type='text'>
Some additional radeon fixes for 4.0

* 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux:
  drm/radeon: drop setting UPLL to sleep mode
  drm/radeon: fix wait to actually occur after the signaling callback
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Some additional radeon fixes for 4.0

* 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux:
  drm/radeon: drop setting UPLL to sleep mode
  drm/radeon: fix wait to actually occur after the signaling callback
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'vmwgfx-fixes-4.0' of git://people.freedesktop.org/~thomash/linux into drm-fixes</title>
<updated>2015-03-12T23:15:56+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2015-03-12T23:15:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=552d6643412980044dfb9b38fcfe0179dbd77b28'/>
<id>552d6643412980044dfb9b38fcfe0179dbd77b28</id>
<content type='text'>
A couple of fixes for vmwgfx.

* 'vmwgfx-fixes-4.0' of git://people.freedesktop.org/~thomash/linux:
  drm/vmwgfx: Fix an issue with the device losing its irq line on module unload
  drm/vmwgfx: Correctly NULLify dma buffer pointer on failure
  drm/vmwgfx: Reorder device takedown somewhat
  drm/vmwgfx: Fix a couple of lock dependency violations
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A couple of fixes for vmwgfx.

* 'vmwgfx-fixes-4.0' of git://people.freedesktop.org/~thomash/linux:
  drm/vmwgfx: Fix an issue with the device losing its irq line on module unload
  drm/vmwgfx: Correctly NULLify dma buffer pointer on failure
  drm/vmwgfx: Reorder device takedown somewhat
  drm/vmwgfx: Fix a couple of lock dependency violations
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'drm-intel-fixes-2015-03-12' of git://anongit.freedesktop.org/drm-intel into drm-fixes</title>
<updated>2015-03-12T23:15:01+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2015-03-12T23:15:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=17b263f6ea4692b031775df1028e367cfcaad950'/>
<id>17b263f6ea4692b031775df1028e367cfcaad950</id>
<content type='text'>
More i915 fixes, three out of four are fixes to old bugs, cc: stable.

* tag 'drm-intel-fixes-2015-03-12' of git://anongit.freedesktop.org/drm-intel:
  drm/i915: Prevent TLB error on first execution on SNB
  drm/i915: Do both mt and gen6 style forcewake reset on ivb probe
  drm/i915: Make WAIT_IOCTL negative timeouts be indefinite again
  drm/i915: use in_interrupt() not in_irq() to check context
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
More i915 fixes, three out of four are fixes to old bugs, cc: stable.

* tag 'drm-intel-fixes-2015-03-12' of git://anongit.freedesktop.org/drm-intel:
  drm/i915: Prevent TLB error on first execution on SNB
  drm/i915: Do both mt and gen6 style forcewake reset on ivb probe
  drm/i915: Make WAIT_IOCTL negative timeouts be indefinite again
  drm/i915: use in_interrupt() not in_irq() to check context
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/vmwgfx: Fix an issue with the device losing its irq line on module unload</title>
<updated>2015-03-11T18:47:41+00:00</updated>
<author>
<name>Thomas Hellstrom</name>
<email>thellstrom@vmware.com</email>
</author>
<published>2015-03-10T18:07:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=fd3e4d6e26288d12b566912f692e278e8db15b82'/>
<id>fd3e4d6e26288d12b566912f692e278e8db15b82</id>
<content type='text'>
Starting with commit b4b55cda5874
("x86/PCI: Refine the way to release PCI IRQ resources")

the device lost its irq resource on module unload. While that's ok and
apparently intentional, the driver never got the resource back on module load

The code apparently wants drivers to disable the pci device at pci device
driver removal, so lets do that. That fixes the issue.

Signed-off-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Reviewed-by: Brian Paul &lt;brianp@vmware.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Starting with commit b4b55cda5874
("x86/PCI: Refine the way to release PCI IRQ resources")

the device lost its irq resource on module unload. While that's ok and
apparently intentional, the driver never got the resource back on module load

The code apparently wants drivers to disable the pci device at pci device
driver removal, so lets do that. That fixes the issue.

Signed-off-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Reviewed-by: Brian Paul &lt;brianp@vmware.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/vmwgfx: Correctly NULLify dma buffer pointer on failure</title>
<updated>2015-03-11T18:47:41+00:00</updated>
<author>
<name>Colin Ian King</name>
<email>colin.king@canonical.com</email>
</author>
<published>2015-01-22T15:17:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=da5efffc42222d09079a3427b60374a68200d798'/>
<id>da5efffc42222d09079a3427b60374a68200d798</id>
<content type='text'>
cppcheck on lines 917 and 977 show an ineffective assignment
to the dma buffer pointer:

[drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:917]:
[drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:977]:
  (warning) Assignment of function parameter has no effect
  outside the function. Did you forget dereferencing it?

On a successful DMA buffer lookup, the dma buffer pointer is
assigned, however, on failure it currently is left in an
undefined state.

The original intention in the error exit path was to nullify
the pointer on an error (which the original code failed to
do properly). This patch fixes this also ensures all failure
paths nullify the buffer pointer on the error return.

Fortunately the callers to vmw_translate_mob_ptr and
vmw_translate_guest_ptr are checking on a return status and not
on the dma buffer pointer, so the original code worked.

Reviewed-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Signed-off-by: Colin Ian King &lt;colin.king@canonical.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
cppcheck on lines 917 and 977 show an ineffective assignment
to the dma buffer pointer:

[drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:917]:
[drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:977]:
  (warning) Assignment of function parameter has no effect
  outside the function. Did you forget dereferencing it?

On a successful DMA buffer lookup, the dma buffer pointer is
assigned, however, on failure it currently is left in an
undefined state.

The original intention in the error exit path was to nullify
the pointer on an error (which the original code failed to
do properly). This patch fixes this also ensures all failure
paths nullify the buffer pointer on the error return.

Fortunately the callers to vmw_translate_mob_ptr and
vmw_translate_guest_ptr are checking on a return status and not
on the dma buffer pointer, so the original code worked.

Reviewed-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Signed-off-by: Colin Ian King &lt;colin.king@canonical.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/vmwgfx: Reorder device takedown somewhat</title>
<updated>2015-03-11T18:47:40+00:00</updated>
<author>
<name>Thomas Hellstrom</name>
<email>thellstrom@vmware.com</email>
</author>
<published>2015-03-05T10:33:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=3458390b9f0ba784481d23134798faee27b5f16f'/>
<id>3458390b9f0ba784481d23134798faee27b5f16f</id>
<content type='text'>
To take down the MOB and GMR memory types, the driver may have to issue
fence objects and thus make sure that the fence manager is taken down
after those memory types.
Reorder device init accordingly.

Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Reviewed-by: Sinclair Yeh &lt;syeh@vmware.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
To take down the MOB and GMR memory types, the driver may have to issue
fence objects and thus make sure that the fence manager is taken down
after those memory types.
Reorder device init accordingly.

Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Reviewed-by: Sinclair Yeh &lt;syeh@vmware.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/vmwgfx: Fix a couple of lock dependency violations</title>
<updated>2015-03-11T18:47:40+00:00</updated>
<author>
<name>Thomas Hellstrom</name>
<email>thellstrom@vmware.com</email>
</author>
<published>2015-03-09T08:56:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=5151adb37a5918957f4c33a8d8e7629c0fb00563'/>
<id>5151adb37a5918957f4c33a8d8e7629c0fb00563</id>
<content type='text'>
Experimental lockdep annotation added to the TTM lock has unveiled a
couple of lock dependency violations in the vmwgfx driver. In both
cases it turns out that the device_private::reservation_sem is not
needed so the offending code is moved out of that lock.

Cc: &lt;stable@vger.kernel.org&gt;
Acked-by: Sinclair Yeh &lt;syeh@vmware.com&gt;
Signed-off-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Experimental lockdep annotation added to the TTM lock has unveiled a
couple of lock dependency violations in the vmwgfx driver. In both
cases it turns out that the device_private::reservation_sem is not
needed so the offending code is moved out of that lock.

Cc: &lt;stable@vger.kernel.org&gt;
Acked-by: Sinclair Yeh &lt;syeh@vmware.com&gt;
Signed-off-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/radeon: drop setting UPLL to sleep mode</title>
<updated>2015-03-11T12:31:56+00:00</updated>
<author>
<name>Christian König</name>
<email>christian.koenig@amd.com</email>
</author>
<published>2015-02-19T08:40:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=a17d4996e051e78d164989b894608cf37cd5110b'/>
<id>a17d4996e051e78d164989b894608cf37cd5110b</id>
<content type='text'>
Just keep it working, seems to fix some PLL problems.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=73378

Signed-off-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Just keep it working, seems to fix some PLL problems.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=73378

Signed-off-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/radeon: fix wait to actually occur after the signaling callback</title>
<updated>2015-03-11T12:30:35+00:00</updated>
<author>
<name>Maarten Lankhorst</name>
<email>maarten.lankhorst@ubuntu.com</email>
</author>
<published>2015-03-03T08:56:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b6610101718d4ab90d793c482625e98eb1262cad'/>
<id>b6610101718d4ab90d793c482625e98eb1262cad</id>
<content type='text'>
A normal wait adds to the front of the tail. By doing something
similar to fence_default_wait the fence code can run without racing.

This is a complete fix for "panic on suspend from KDE with radeon",
and a partial fix for "Radeon: System pauses on TAHITI". On tahiti
si_irq_set needs to be fixed too, to completely flush the writes
before radeon_fence_activity is called in radeon_fence_enable_signaling.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90741
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90861
Signed-off-by: Maarten Lankhorst &lt;maarten.lankhorst@ubuntu.com&gt;
Reported-by: Jon Arne Jørgensen &lt;jonjon.arnearne@gmail.com&gt;
Reported-and-tested-by: Gustaw Smolarczyk &lt;wielkiegie@gmail.com&gt;
Cc: stable@vger.kernel.org (v3.18+)
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A normal wait adds to the front of the tail. By doing something
similar to fence_default_wait the fence code can run without racing.

This is a complete fix for "panic on suspend from KDE with radeon",
and a partial fix for "Radeon: System pauses on TAHITI". On tahiti
si_irq_set needs to be fixed too, to completely flush the writes
before radeon_fence_activity is called in radeon_fence_enable_signaling.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90741
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90861
Signed-off-by: Maarten Lankhorst &lt;maarten.lankhorst@ubuntu.com&gt;
Reported-by: Jon Arne Jørgensen &lt;jonjon.arnearne@gmail.com&gt;
Reported-and-tested-by: Gustaw Smolarczyk &lt;wielkiegie@gmail.com&gt;
Cc: stable@vger.kernel.org (v3.18+)
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
