[src/trunk]: src/sys/external/bsd/drm2/dist/drm/i915 Don't map the GEM uvm_ao...

[riastradh <riastradh%NetBSD.org@localhost>]

details:   https://anonhg.NetBSD.org/src/rev/572f3db2a7d0
branches:  trunk
changeset: 329342:572f3db2a7d0
user:      riastradh <riastradh%NetBSD.org@localhost>
date:      Tue May 20 15:12:41 2014 +0000

description:
Don't map the GEM uvm_aobj copy-on-write -- what was I thinking?

Do transfer the GEM object reference to the uvm_aobj reference --
these are not the same thing.  (There's another uvm object whose
references are the same thing as the GEM object references, but
that's not the uao.)

With these changes, it looks like the GPU is no longer trying to draw
graphics all over kernel data structures.  Wish I had that month of
debugging back!

diffstat:

 sys/external/bsd/drm2/dist/drm/i915/i915_gem.c |  4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diffs (16 lines):

diff -r b699e980372e -r 572f3db2a7d0 sys/external/bsd/drm2/dist/drm/i915/i915_gem.c
--- a/sys/external/bsd/drm2/dist/drm/i915/i915_gem.c    Tue May 20 15:05:08 2014 +0000
+++ b/sys/external/bsd/drm2/dist/drm/i915/i915_gem.c    Tue May 20 15:12:41 2014 +0000
@@ -1490,9 +1490,11 @@
            obj->gemo_shm_uao, args->offset, 0,
            UVM_MAPFLAG((VM_PROT_READ | VM_PROT_WRITE),
                (VM_PROT_READ | VM_PROT_WRITE), UVM_INH_COPY, UVM_ADV_NORMAL,
-               UVM_FLAG_COPYONW));
+               0));
        if (ret)
                return ret;
+       uao_reference(obj->gemo_shm_uao);
+       drm_gem_object_unreference_unlocked(obj);
 #else
        addr = vm_mmap(obj->filp, 0, args->size,
                       PROT_READ | PROT_WRITE, MAP_SHARED,