1. 18 11月, 2010 6 次提交
  2. 27 10月, 2010 1 次提交
    • P
      mm: stack based kmap_atomic() · 3e4d3af5
      Peter Zijlstra 提交于
      Keep the current interface but ignore the KM_type and use a stack based
      approach.
      
      The advantage is that we get rid of crappy code like:
      
      	#define __KM_PTE			\
      		(in_nmi() ? KM_NMI_PTE : 	\
      		 in_irq() ? KM_IRQ_PTE :	\
      		 KM_PTE0)
      
      and in general can stop worrying about what context we're in and what kmap
      slots might be appropriate for that.
      
      The downside is that FRV kmap_atomic() gets more expensive.
      
      For now we use a CPP trick suggested by Andrew:
      
        #define kmap_atomic(page, args...) __kmap_atomic(page)
      
      to avoid having to touch all kmap_atomic() users in a single patch.
      
      [ not compiled on:
        - mn10300: the arch doesn't actually build with highmem to begin with ]
      
      [akpm@linux-foundation.org: coding-style fixes]
      [akpm@linux-foundation.org: fix up drivers/gpu/drm/i915/intel_overlay.c]
      Acked-by: NRik van Riel <riel@redhat.com>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: NChris Metcalf <cmetcalf@tilera.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: David Miller <davem@davemloft.net>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Dave Airlie <airlied@linux.ie>
      Cc: Li Zefan <lizf@cn.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3e4d3af5
  3. 25 10月, 2010 1 次提交
  4. 19 10月, 2010 1 次提交
  5. 07 10月, 2010 1 次提交
    • D
      drm: don't drop handle reference on unload · dab8dcfa
      Dave Airlie 提交于
      since the handle references are all tied to a file_priv, and when it disappears
      all the handle refs go with it.
      
      The fbcon ones we'd only notice on unload, but the nouveau notifier one
      would would happen on reboot.
      
      nouveau: Reported-by: Marc Dionne <marc.c.dionne@gmail.com>
      nouveau: Tested-by: Marc Dionne <marc.c.dionne@gmail.com>
      i915 unload: Reported-by: Keith Packard <keithp@keithp.com>
      Acked-by: NBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      dab8dcfa
  6. 06 10月, 2010 3 次提交
  7. 05 10月, 2010 22 次提交
  8. 01 10月, 2010 1 次提交
    • D
      drm/gem: handlecount isn't really a kref so don't make it one. · 29d08b3e
      Dave Airlie 提交于
      There were lots of places being inconsistent since handle count
      looked like a kref but it really wasn't.
      
      Fix this my just making handle count an atomic on the object,
      and have it increase the normal object kref.
      
      Now i915/radeon/nouveau drivers can drop the normal reference on
      userspace object creation, and have the handle hold it.
      
      This patch fixes a memory leak or corruption on unload, because
      the driver had no way of knowing if a handle had been actually
      added for this object, and the fbcon object needed to know this
      to clean itself up properly.
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      29d08b3e
  9. 24 9月, 2010 4 次提交