drm fixup 2/2 - optimise i8x0 accesses..

drm fixup 2/2 - optimise i8x0 accesses..

[Dave Airlie]

   the patch below optimises the drm code to not do put_user() on memory the
   kernel allocated and then mmap-installed to userspace, but instead makes it
   use the kernel virtual address directly instead.

   From: Arjan van de Ven <arjanv@redhat.com>
   Signed-off-by: Dave Airlie <airlied@linux.ie>


diff -Nru a/drivers/char/drm/i810_dma.c b/drivers/char/drm/i810_dma.c
--- a/drivers/char/drm/i810_dma.c	Sat Aug 28 00:01:57 2004
+++ b/drivers/char/drm/i810_dma.c	Sat Aug 28 00:01:57 2004
@@ -844,13 +844,10 @@
 	if (buf_priv->currently_mapped == I810_BUF_MAPPED) {
 		unsigned int prim = (sarea_priv->vertex_prim & PR_MASK);

-		put_user((GFX_OP_PRIMITIVE | prim |
-					     ((used/4)-2)),
-		(u32 __user *)buf_priv->virtual);
+		*(u32 *)buf_priv->kernel_virtual = ((GFX_OP_PRIMITIVE | prim | ((used/4)-2)));

 		if (used & 4) {
-			put_user(0,
-			(u32 __user *)((u32)buf_priv->virtual + used));
+			*(u32 *)((u32)buf_priv->kernel_virtual + used) = 0;
 			used += 4;
 		}

diff -Nru a/drivers/char/drm/i830_dma.c b/drivers/char/drm/i830_dma.c
--- a/drivers/char/drm/i830_dma.c	Sat Aug 28 00:01:57 2004
+++ b/drivers/char/drm/i830_dma.c	Sat Aug 28 00:01:57 2004
@@ -1166,19 +1166,19 @@
    	DRM_DEBUG(  "start + used - 4 : %ld\n", start + used - 4);

 	if (buf_priv->currently_mapped == I830_BUF_MAPPED) {
-		u32  __user *vp = buf_priv->virtual;
+		u32 *vp = buf_priv->kernel_virtual;

-		put_user( (GFX_OP_PRIMITIVE |
-			 sarea_priv->vertex_prim |
-			  ((used/4)-2)), &vp[0]);
+		vp[0] = (GFX_OP_PRIMITIVE |
+			sarea_priv->vertex_prim |
+			((used/4)-2));

 		if (dev_priv->use_mi_batchbuffer_start) {
-			put_user(MI_BATCH_BUFFER_END, &vp[used/4]);
+			vp[used/4] = MI_BATCH_BUFFER_END;
 			used += 4;
 		}

 		if (used & 4) {
-			put_user(0, &vp[used/4]);
+			vp[used/4] = 0;
 			used += 4;
 		}

Re: drm fixup 2/2 - optimise i8x0 accesses..

[David S. Miller]

On Fri, 27 Aug 2004 15:13:54 +0100 (IST)
Dave Airlie <airlied@linux.ie> wrote:

>    the patch below optimises the drm code to not do put_user() on memory the
>    kernel allocated and then mmap-installed to userspace, but instead makes it
>    use the kernel virtual address directly instead.

This might cause major problems on systems with virtually indexed
caches if precautions are not made at buffer allocation time such
that the virtual cache color of the kernel mapping is the same
as the user mapping.

Arjan, you should know better :-)

I also don't understand what this "optimization" is?  You don't need
a verify_area, therefore you can use __put_user() which amounts to
a load/store and an integer move instruction.

Re: drm fixup 2/2 - optimise i8x0 accesses..

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 634 bytes --]

On Fri, Aug 27, 2004 at 01:04:15PM -0700, David S. Miller wrote:
> On Fri, 27 Aug 2004 15:13:54 +0100 (IST)
> Dave Airlie <airlied@linux.ie> wrote:
> 
> >    the patch below optimises the drm code to not do put_user() on memory the
> >    kernel allocated and then mmap-installed to userspace, but instead makes it
> >    use the kernel virtual address directly instead.
> 
> This might cause major problems on systems with virtually indexed
> caches if precautions are not made at buffer allocation time such
> that the virtual cache color of the kernel mapping is the same
> as the user mapping.

actually it's uncachable memory ;)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: drm fixup 2/2 - optimise i8x0 accesses..

[David S. Miller]

On Fri, 27 Aug 2004 22:08:15 +0200
Arjan van de Ven <arjanv@redhat.com> wrote:

> On Fri, Aug 27, 2004 at 01:04:15PM -0700, David S. Miller wrote:
> > On Fri, 27 Aug 2004 15:13:54 +0100 (IST)
> > Dave Airlie <airlied@linux.ie> wrote:
> > 
> > >    the patch below optimises the drm code to not do put_user() on memory the
> > >    kernel allocated and then mmap-installed to userspace, but instead makes it
> > >    use the kernel virtual address directly instead.
> > 
> > This might cause major problems on systems with virtually indexed
> > caches if precautions are not made at buffer allocation time such
> > that the virtual cache color of the kernel mapping is the same
> > as the user mapping.
> 
> actually it's uncachable memory ;)

Then no problem :-)  Thanks for clearing that up.