<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/gpu/drm/i810, branch v3.6.2</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>drm: use drm_compat_ioctl for 32-bit apps</title>
<updated>2012-09-05T20:55:02+00:00</updated>
<author>
<name>Keith Packard</name>
<email>keithp@keithp.com</email>
</author>
<published>2012-07-09T22:40:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=804d74abe2e3f361ead5c5c6850d5b1ab0203862'/>
<id>804d74abe2e3f361ead5c5c6850d5b1ab0203862</id>
<content type='text'>
Most of the DRM drivers appear to be missing the .compat_ioctl file
operation entry necessary for 32-bit application compatibility.

This patch  uses drm_compat_ioctl for all drivers which don't have
their own, and which are using drm_ioctl for .unlocked_ioctl.

This leaves drivers/gpu/drm/psb/psb_drv.c unchanged; it has a custom
.unlocked_ioctl and will presumably need a custom .compat_ioctl as
well.

Signed-off-by: Keith Packard &lt;keithp@keithp.com&gt;
Signed-off-by: Dave Airlie &lt;airlied@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Most of the DRM drivers appear to be missing the .compat_ioctl file
operation entry necessary for 32-bit application compatibility.

This patch  uses drm_compat_ioctl for all drivers which don't have
their own, and which are using drm_ioctl for .unlocked_ioctl.

This leaves drivers/gpu/drm/psb/psb_drv.c unchanged; it has a custom
.unlocked_ioctl and will presumably need a custom .compat_ioctl as
well.

Signed-off-by: Keith Packard &lt;keithp@keithp.com&gt;
Signed-off-by: Dave Airlie &lt;airlied@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm: kill dma queue support</title>
<updated>2012-07-20T02:50:55+00:00</updated>
<author>
<name>Daniel Vetter</name>
<email>daniel.vetter@ffwll.ch</email>
</author>
<published>2011-10-25T22:54:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a344a7e7c27776950a70ce4b829a9ac15a212e65'/>
<id>a344a7e7c27776950a70ce4b829a9ac15a212e65</id>
<content type='text'>
Absolutely unused. All the values are only ever initialized and
then used at most in some debug printout functions.

Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Absolutely unused. All the values are only ever initialized and
then used at most in some debug printout functions.

Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "Revert "drm/i810: cleanup reclaim_buffers""</title>
<updated>2012-07-20T02:49:49+00:00</updated>
<author>
<name>Daniel Vetter</name>
<email>daniel.vetter@ffwll.ch</email>
</author>
<published>2012-06-11T19:50:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d5346b3727bad3a033cb0a5b45a4a2da45119ec3'/>
<id>d5346b3727bad3a033cb0a5b45a4a2da45119ec3</id>
<content type='text'>
This reverts commit 6e877b576ddf7cde5db2e9a6dcb56fef0ea77e64,
reinstating the original commit:

commit 87499ffdcb1c70f66988cd8febc4ead0ba2f9118
Author: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Date:   Tue Oct 25 23:51:24 2011 +0200

    drm/i810: cleanup reclaim_buffers

    My dear old i815 always hits the deadlocked on reclaim_buffers
    warning. Switch over to the idlelock duct-tape on hope that
    works better. I've fired up my i815 and now closing glxgears doesn't
    take 5 seconds anymore. \o/

The original problem with that was that I've moved it ahead in the
series so that it could be included despite some patches not being
ready quite yet. The little problem is that this patch required some
of the previous rework to work correctly.

Now that everything is in the right order again, this actually works
on my i810 and does speed up closing gl apps as the original commit
claimed. Without hanging the machine, as the revert says.

Signed-Off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit 6e877b576ddf7cde5db2e9a6dcb56fef0ea77e64,
reinstating the original commit:

commit 87499ffdcb1c70f66988cd8febc4ead0ba2f9118
Author: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Date:   Tue Oct 25 23:51:24 2011 +0200

    drm/i810: cleanup reclaim_buffers

    My dear old i815 always hits the deadlocked on reclaim_buffers
    warning. Switch over to the idlelock duct-tape on hope that
    works better. I've fired up my i815 and now closing glxgears doesn't
    take 5 seconds anymore. \o/

The original problem with that was that I've moved it ahead in the
series so that it could be included despite some patches not being
ready quite yet. The little problem is that this patch required some
of the previous rework to work correctly.

Now that everything is in the right order again, this actually works
on my i810 and does speed up closing gl apps as the original commit
claimed. Without hanging the machine, as the revert says.

Signed-Off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>i810: switch to vm_mmap()</title>
<updated>2012-05-31T01:04:54+00:00</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2012-05-30T01:24:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=244ca2b4d0b5e500681e52ad9e6d7f3f2b9362a1'/>
<id>244ca2b4d0b5e500681e52ad9e6d7f3f2b9362a1</id>
<content type='text'>
Weirdness around do_mmap() in there does not rely on -&gt;mmap_sem for
exclusion, so no need to keep it under that.  As the result, we can
turn that do_mmap() into vm_mmap().

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Weirdness around do_mmap() in there does not rely on -&gt;mmap_sem for
exclusion, so no need to keep it under that.  As the result, we can
turn that do_mmap() into vm_mmap().

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>kill mm argument of vm_munmap()</title>
<updated>2012-04-21T05:58:20+00:00</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2012-04-21T01:57:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bfce281c287a427d0841fadf5d59242757b4e620'/>
<id>bfce281c287a427d0841fadf5d59242757b4e620</id>
<content type='text'>
it's always current-&gt;mm

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
it's always current-&gt;mm

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>VM: add "vm_mmap()" helper function</title>
<updated>2012-04-21T00:29:13+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2012-04-21T00:13:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6be5ceb02e98eaf6cfc4f8b12a896d04023f340d'/>
<id>6be5ceb02e98eaf6cfc4f8b12a896d04023f340d</id>
<content type='text'>
This continues the theme started with vm_brk() and vm_munmap():
vm_mmap() does the same thing as do_mmap(), but additionally does the
required VM locking.

This uninlines (and rewrites it to be clearer) do_mmap(), which sadly
duplicates it in mm/mmap.c and mm/nommu.c.  But that way we don't have
to export our internal do_mmap_pgoff() function.

Some day we hopefully don't have to export do_mmap() either, if all
modular users can become the simpler vm_mmap() instead.  We're actually
very close to that already, with the notable exception of the (broken)
use in i810, and a couple of stragglers in binfmt_elf.

Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This continues the theme started with vm_brk() and vm_munmap():
vm_mmap() does the same thing as do_mmap(), but additionally does the
required VM locking.

This uninlines (and rewrites it to be clearer) do_mmap(), which sadly
duplicates it in mm/mmap.c and mm/nommu.c.  But that way we don't have
to export our internal do_mmap_pgoff() function.

Some day we hopefully don't have to export do_mmap() either, if all
modular users can become the simpler vm_mmap() instead.  We're actually
very close to that already, with the notable exception of the (broken)
use in i810, and a couple of stragglers in binfmt_elf.

Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>VM: add "vm_munmap()" helper function</title>
<updated>2012-04-21T00:29:13+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2012-04-20T23:20:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a46ef99d80817a167477ed1c8b4d90ee0c2e726f'/>
<id>a46ef99d80817a167477ed1c8b4d90ee0c2e726f</id>
<content type='text'>
Like the vm_brk() function, this is the same as "do_munmap()", except it
does the VM locking for the caller.

Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Like the vm_brk() function, this is the same as "do_munmap()", except it
does the VM locking for the caller.

Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm: drop setting vm_file to filp</title>
<updated>2012-03-05T11:19:08+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2012-02-23T11:37:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=966e0cdd504657333415f43de6a219197511ebff'/>
<id>966e0cdd504657333415f43de6a219197511ebff</id>
<content type='text'>
Talking to Al Viro on irc, we can see no possible reason for doing
this, the upper mmap code does it. The code has been there since
first import into drm tree I can find.

Al tracked down this as a requirement pre 2.3.51 hasn't been needed since.

Acked-by: Al Viro &lt;viro@zeniv.linux.org.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>
Talking to Al Viro on irc, we can see no possible reason for doing
this, the upper mmap code does it. The code has been there since
first import into drm tree I can find.

Al tracked down this as a requirement pre 2.3.51 hasn't been needed since.

Acked-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm: move pci bus master enable into driver.</title>
<updated>2012-02-16T18:31:07+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2011-12-19T11:15:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=466e69b8b03b8c1987367912782bc12988ad8794'/>
<id>466e69b8b03b8c1987367912782bc12988ad8794</id>
<content type='text'>
The current enabling of bus mastering in the drm midlayer allows a large
race condition under kexec. When a kexec'ed kernel re-enables bus mastering
for the GPU, previously setup dma blocks may cause writes to random pieces
of memory. On radeon the writeback mechanism can cause these sorts of issues.

This patch doesn't fix the problem, but it moves the bus master enable under
the individual drivers control so they can move enabling it until later in
their load cycle and close the race.

Fix for radeon kms driver will be in a follow-up patch.

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The current enabling of bus mastering in the drm midlayer allows a large
race condition under kexec. When a kexec'ed kernel re-enables bus mastering
for the GPU, previously setup dma blocks may cause writes to random pieces
of memory. On radeon the writeback mechanism can cause these sorts of issues.

This patch doesn't fix the problem, but it moves the bus master enable under
the individual drivers control so they can move enabling it until later in
their load cycle and close the race.

Fix for radeon kms driver will be in a follow-up patch.

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "drm/i810: cleanup reclaim_buffers"</title>
<updated>2012-01-30T09:31:25+00:00</updated>
<author>
<name>Daniel Vetter</name>
<email>daniel.vetter@ffwll.ch</email>
</author>
<published>2012-01-29T16:05:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6e877b576ddf7cde5db2e9a6dcb56fef0ea77e64'/>
<id>6e877b576ddf7cde5db2e9a6dcb56fef0ea77e64</id>
<content type='text'>
This reverts commit 87499ffdcb1c70f66988cd8febc4ead0ba2f9118.

Where is that paper bag ... ah here.

I've failed to take an odd interaction between my other cleanups and
this reclaim_buffers patch into account and also failed to properly
test it. Looks like there are more dragons and hidden trapdoors in the
drm release path than actual lines of code.

Until I get a clue, let's just revert this.

Signed-Off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit 87499ffdcb1c70f66988cd8febc4ead0ba2f9118.

Where is that paper bag ... ah here.

I've failed to take an odd interaction between my other cleanups and
this reclaim_buffers patch into account and also failed to properly
test it. Looks like there are more dragons and hidden trapdoors in the
drm release path than actual lines of code.

Until I get a clue, let's just revert this.

Signed-Off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
