1. 10 10月, 2007 2 次提交
  2. 09 10月, 2007 1 次提交
  3. 05 8月, 2007 2 次提交
  4. 10 10月, 2007 1 次提交
  5. 25 7月, 2007 1 次提交
  6. 03 8月, 2007 1 次提交
  7. 24 7月, 2007 1 次提交
  8. 12 7月, 2007 4 次提交
  9. 25 6月, 2007 1 次提交
  10. 12 7月, 2007 1 次提交
    • R
      Blackfin arch: initial supporting for BF548-EZKIT · 24a07a12
      Roy Huang 提交于
      The ADSP-BF54x was specifically designed to meet the needs of convergent multimedia
      applications where system performance and cost are essential ingredients. The
      integration of multimedia, human interface, and connectivity peripherals combined
      with increased system bandwidth and on-chip memory provides customers a platform to
      design the most demanding applications.
      
      Since now, ADSP-BF54x will be supported in the Linux kernel and bunch of related drivers
      such as USB OTG, ATAPI, NAND flash controller, LCD framebuffer, sound, touch screen will
      be submitted later.
      
      Please enjoy the show.
      Signed-off-by: NRoy Huang <roy.huang@analog.com>
      Signed-off-by: NBryan Wu <bryan.wu@analog.com>
      24a07a12
  11. 11 6月, 2007 1 次提交
  12. 22 5月, 2007 2 次提交
  13. 17 5月, 2007 1 次提交
    • C
      Slab allocators: define common size limitations · 0aa817f0
      Christoph Lameter 提交于
      Currently we have a maze of configuration variables that determine the
      maximum slab size.  Worst of all it seems to vary between SLAB and SLUB.
      
      So define a common maximum size for kmalloc.  For conveniences sake we use
      the maximum size ever supported which is 32 MB.  We limit the maximum size
      to a lower limit if MAX_ORDER does not allow such large allocations.
      
      For many architectures this patch will have the effect of adding large
      kmalloc sizes.  x86_64 adds 5 new kmalloc sizes.  So a small amount of
      memory will be needed for these caches (contemporary SLAB has dynamically
      sizeable node and cpu structure so the waste is less than in the past)
      
      Most architectures will then be able to allocate object with sizes up to
      MAX_ORDER.  We have had repeated breakage (in fact whenever we doubled the
      number of supported processors) on IA64 because one or the other struct
      grew beyond what the slab allocators supported.  This will avoid future
      issues and f.e.  avoid fixes for 2k and 4k cpu support.
      
      CONFIG_LARGE_ALLOCS is no longer necessary so drop it.
      
      It fixes sparc64 with SLAB.
      Signed-off-by: NChristoph Lameter <clameter@sgi.com>
      Signed-off-by: N"David S. Miller" <davem@davemloft.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0aa817f0
  14. 08 5月, 2007 1 次提交