1. 02 12月, 2006 6 次提交
  2. 26 11月, 2006 1 次提交
  3. 23 11月, 2006 2 次提交
    • L
      [AGP] Allocate AGP pages with GFP_DMA32 by default · 66c669ba
      Linus Torvalds 提交于
      Not all graphic page remappers support physical addresses over the 4GB
      mark for remapping, so while some do (the AMD64 GART always did, and I
      just fixed the i965 to do so properly), we're safest off just forcing
      GFP_DMA32 allocations to make sure graphics pages get allocated in the
      low 32-bit address space by default.
      
      AGP sub-drivers that really care, and can do better, could just choose
      to implement their own allocator (or we could add another "64-bit safe"
      default allocator for their use), but quite frankly, you're not likely
      to care in practice.
      
      So for now, this trivial change means that we won't be allocating pages
      that we can't map correctly by mistake on x86-64.
      
      [ On traditional 32-bit x86, this could never happen, because GFP_KERNEL
        would never allocate any highmem memory anyway ]
      Acked-by: NAndi Kleen <ak@suse.de>
      Acked-by: NDave Jones <davej@redhat.com>
      Cc: Eric Anholt <eric@anholt.net>
      Cc: Keith Packard <keithp@keithp.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      66c669ba
    • L
      [AGP] Fix intel 965 AGP memory mapping function · 7d915a38
      Linus Torvalds 提交于
      This introduces a i965-specific "mask_memory()" function that knows
      about the extended physical addresses that the i965 supports.  This
      allows us to correctly map in physical memory in the >4GB range into the
      GTT.
      
      Also simplify/clean-up the i965 case for the aperture sizing by just
      returning the fixed 512kB size from "fetch_size()".  We don't really
      care that not all of the aperture may be visible - the only thing that
      cares about the aperture size is the Intel "stolen memory" calculation,
      which depends on the fixed size.
      
      Cc: Keith Packard <keithp@keithp.com>
      Cc: Eric Anholt <eric@anholt.net>
      Cc: Dave Jones <davej@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      7d915a38
  4. 21 11月, 2006 1 次提交
  5. 17 11月, 2006 1 次提交
    • Z
      [PATCH] ipmi: use platform_device_add() instead of platform_device_register()... · b48f5457
      Zhang, Yanmin 提交于
      [PATCH] ipmi: use platform_device_add() instead of platform_device_register() to register device allocated dynamically
      
      I got below warning when running 2.6.19-rc5-mm1 on my ia64 machine.
      
      WARNING at lib/kobject.c:172 kobject_init()
      
      Call Trace:
       [<a0000001000137c0>] show_stack+0x40/0xa0
                                      sp=e0000002ff9f7bc0 bsp=e0000002ff9f0d10
       [<a000000100013850>] dump_stack+0x30/0x60
                                      sp=e0000002ff9f7d90 bsp=e0000002ff9f0cf8
       [<a000000100407bb0>] kobject_init+0x90/0x160
                                      sp=e0000002ff9f7d90 bsp=e0000002ff9f0cd0
       [<a0000001005ae080>] device_initialize+0x40/0x1c0
                                      sp=e0000002ff9f7da0 bsp=e0000002ff9f0cb0
       [<a0000001005b88c0>] platform_device_register+0x20/0x60
                                      sp=e0000002ff9f7dd0 bsp=e0000002ff9f0c90
       [<a000000100592560>] try_smi_init+0xbc0/0x11e0
                                      sp=e0000002ff9f7dd0 bsp=e0000002ff9f0c50
       [<a000000100594900>] init_ipmi_si+0xaa0/0x12e0
                                      sp=e0000002ff9f7de0 bsp=e0000002ff9f0bd8
       [<a000000100009910>] init+0x350/0x780
                                      sp=e0000002ff9f7e00 bsp=e0000002ff9f0ba8
       [<a000000100011d30>] kernel_thread_helper+0x30/0x60
                                      sp=e0000002ff9f7e30 bsp=e0000002ff9f0b80
       [<a0000001000090c0>] start_kernel_thread+0x20/0x40
                                      sp=e0000002ff9f7e30 bsp=e0000002ff9f0b80
      WARNING at lib/kobject.c:172 kobject_init()
      
      Call Trace:
       [<a0000001000137c0>] show_stack+0x40/0xa0
                                      sp=e0000002ff9f7b40 bsp=e0000002ff9f0db0
       [<a000000100013850>] dump_stack+0x30/0x60
                                      sp=e0000002ff9f7d10 bsp=e0000002ff9f0d98
       [<a000000100407bb0>] kobject_init+0x90/0x160
                                      sp=e0000002ff9f7d10 bsp=e0000002ff9f0d70
       [<a0000001005ae080>] device_initialize+0x40/0x1c0
                                      sp=e0000002ff9f7d20 bsp=e0000002ff9f0d50
       [<a0000001005b88c0>] platform_device_register+0x20/0x60
                                      sp=e0000002ff9f7d50 bsp=e0000002ff9f0d30
       [<a00000010058ac00>] ipmi_register_smi+0xcc0/0x18e0
                                      sp=e0000002ff9f7d50 bsp=e0000002ff9f0c90
       [<a000000100592600>] try_smi_init+0xc60/0x11e0
                                      sp=e0000002ff9f7dd0 bsp=e0000002ff9f0c50
       [<a000000100594900>] init_ipmi_si+0xaa0/0x12e0
                                      sp=e0000002ff9f7de0 bsp=e0000002ff9f0bd8
       [<a000000100009910>] init+0x350/0x780
                                      sp=e0000002ff9f7e00 bsp=e0000002ff9f0ba8
       [<a000000100011d30>] kernel_thread_helper+0x30/0x60
                                      sp=e0000002ff9f7e30 bsp=e0000002ff9f0b80
       [<a0000001000090c0>] start_kernel_thread+0x20/0x40
                                      sp=e0000002ff9f7e30 bsp=e0000002ff9f0b80
      
      The root cause is the device struct is initialized twice.
      
      If the device is allocated dynamically by platform_device_alloc,
      platform_device_alloc will initialize struct device, then,
      platform_device_add should be used to register the device.
      
      The difference between platform_device_register and platform_device_add is
      platform_device_register will initiate the device while platform_device_add
      won't.
      Signed-off-by: NZhang Yanmin <yanmin.zhang@intel.com>
      Cc: Corey Minyard <minyard@acm.org>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b48f5457
  6. 15 11月, 2006 1 次提交
  7. 13 11月, 2006 2 次提交
  8. 09 11月, 2006 3 次提交
  9. 04 11月, 2006 1 次提交
  10. 30 10月, 2006 1 次提交
  11. 26 10月, 2006 3 次提交
  12. 24 10月, 2006 3 次提交
  13. 22 10月, 2006 1 次提交
  14. 21 10月, 2006 1 次提交
  15. 18 10月, 2006 1 次提交
  16. 17 10月, 2006 5 次提交
  17. 16 10月, 2006 3 次提交
  18. 15 10月, 2006 1 次提交
  19. 14 10月, 2006 1 次提交
  20. 13 10月, 2006 2 次提交
    • L
      Include proper header file for PFN_DOWN() · b8a3ad5b
      Linus Torvalds 提交于
      The recent commit (99a10a60) to fix up
      mmap_kmem() broke compiles because it used PFN_DOWN() without including
      <linux/pfn.h>.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b8a3ad5b
    • F
      [PATCH] Fix up mmap_kmem · 99a10a60
      Franck Bui-Huu 提交于
      vma->vm_pgoff is an pfn _offset_ relatif to the begining
      of the memory start. The previous code was doing at first:
      
      	vma->vm_pgoff << PAGE_SHIFT
      
      which results into a wrong physical address since some
      platforms have a physical mem start that can be different
      from 0. After that the previous call __pa() on this
      wrong physical address, however __pa() is used to convert
      a _virtual_ address into a physical one.
      
      This patch rewrites this convertion. It calculates the
      pfn of PAGE_OFFSET which is the pfn of the mem start
      then it adds the vma->vm_pgoff to it.
      
      It also uses virt_to_phys() instead of __pa() since the
      latter shouldn't be used by drivers.
      Signed-off-by: NFranck Bui-Huu <fbuihuu@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      99a10a60