1. 23 9月, 2009 19 次提交
  2. 21 9月, 2009 1 次提交
  3. 29 8月, 2009 1 次提交
  4. 13 7月, 2009 1 次提交
  5. 01 7月, 2009 1 次提交
    • K
      fbdev: add mutex for fb_mmap locking · 537a1bf0
      Krzysztof Helt 提交于
      Add a mutex to avoid a circular locking problem between the mm layer
      semaphore and fbdev ioctl mutex through the fb_mmap() call.
      
      Also, add mutex to all places where smem_start and smem_len fields change
      so the mutex inside the fb_mmap() is actually used.  Changing of these
      fields before calling the framebuffer_register() are not mutexed.
      
      This is 2.6.31 material.  It removes one lockdep (fb_mmap() and
      register_framebuffer()) but there is still another one (fb_release() and
      register_framebuffer()).  It also cleans up handling of the smem_start and
      smem_len fields used by mutexed section of the fb_mmap().
      Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      537a1bf0
  6. 29 5月, 2009 1 次提交
  7. 16 5月, 2009 1 次提交
  8. 01 4月, 2009 2 次提交
  9. 24 1月, 2009 1 次提交
  10. 02 12月, 2008 1 次提交
  11. 25 11月, 2008 1 次提交
    • T
      ARM: OMAP: Remove broken LCD driver for SX1 · 7953031d
      Tony Lindgren 提交于
      Recently the omap McBSP code was cleaned up to get rid of
      direct McBSP register tinkering by the drivers. Looks like
      lcd_sx1.c never got converted, and now it breaks builds.
      
      It seems the lcd_sx1.c driver is attempting SPI mode, but
      doing it in a different way compared to omap_mcbsp_set_spi_mode().
      
      Remove the broken driver, patches welcome to add it back when
      done properly by patching both mcbsp.c and lcd_sx1.c.
      
      Cc: Vovan888@gmail.com
      Cc: linux-fbdev-devel@lists.sourceforge.net
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      7953031d
  12. 17 10月, 2008 1 次提交
  13. 06 9月, 2008 4 次提交
  14. 07 8月, 2008 2 次提交
  15. 27 7月, 2008 1 次提交
  16. 25 7月, 2008 1 次提交
    • A
      PAGE_ALIGN(): correctly handle 64-bit values on 32-bit architectures · 27ac792c
      Andrea Righi 提交于
      On 32-bit architectures PAGE_ALIGN() truncates 64-bit values to the 32-bit
      boundary. For example:
      
      	u64 val = PAGE_ALIGN(size);
      
      always returns a value < 4GB even if size is greater than 4GB.
      
      The problem resides in PAGE_MASK definition (from include/asm-x86/page.h for
      example):
      
      #define PAGE_SHIFT      12
      #define PAGE_SIZE       (_AC(1,UL) << PAGE_SHIFT)
      #define PAGE_MASK       (~(PAGE_SIZE-1))
      ...
      #define PAGE_ALIGN(addr)       (((addr)+PAGE_SIZE-1)&PAGE_MASK)
      
      The "~" is performed on a 32-bit value, so everything in "and" with
      PAGE_MASK greater than 4GB will be truncated to the 32-bit boundary.
      Using the ALIGN() macro seems to be the right way, because it uses
      typeof(addr) for the mask.
      
      Also move the PAGE_ALIGN() definitions out of include/asm-*/page.h in
      include/linux/mm.h.
      
      See also lkml discussion: http://lkml.org/lkml/2008/6/11/237
      
      [akpm@linux-foundation.org: fix drivers/media/video/uvc/uvc_queue.c]
      [akpm@linux-foundation.org: fix v850]
      [akpm@linux-foundation.org: fix powerpc]
      [akpm@linux-foundation.org: fix arm]
      [akpm@linux-foundation.org: fix mips]
      [akpm@linux-foundation.org: fix drivers/media/video/pvrusb2/pvrusb2-dvb.c]
      [akpm@linux-foundation.org: fix drivers/mtd/maps/uclinux.c]
      [akpm@linux-foundation.org: fix powerpc]
      Signed-off-by: NAndrea Righi <righi.andrea@gmail.com>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      27ac792c
  17. 03 2月, 2008 1 次提交