[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/a0160c150bcd
branches:  trunk
changeset: 796103:a0160c150bcd
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 9d6a2aaaec5e -r a0160c150bcd 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,