1. 15 2月, 2011 1 次提交
  2. 08 7月, 2009 1 次提交
    • T
      ALSA: Fix SG-buffer DMA with non-coherent architectures · cc6a8acd
      Takashi Iwai 提交于
      Using SG-buffers with dma_alloc_coherent() is often very inefficient
      on non-coherent architectures because a tracking record could be
      allocated in addition for each dma_alloc_coherent() call.
      Instead, simply disable SG-buffers but just allocate normal continuous
      buffers on non-supported (currently all but x86) architectures.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      cc6a8acd
  3. 29 8月, 2008 3 次提交
  4. 25 8月, 2008 2 次提交
  5. 13 8月, 2008 1 次提交
  6. 19 5月, 2008 1 次提交
  7. 29 4月, 2008 1 次提交
  8. 01 2月, 2008 1 次提交
  9. 16 10月, 2007 2 次提交
  10. 24 9月, 2007 1 次提交
  11. 09 2月, 2007 1 次提交
  12. 01 7月, 2006 1 次提交
  13. 22 3月, 2006 3 次提交
  14. 03 1月, 2006 1 次提交
  15. 23 11月, 2005 1 次提交
    • H
      [PATCH] unpaged: fix sound Bad page states · f3d48f03
      Hugh Dickins 提交于
      Earlier I unifdefed PageCompound, so that snd_pcm_mmap_control_nopage and
      others can give out a 0-order component of a higher-order page, which won't
      be mistakenly freed when zap_pte_range unmaps it.  But many Bad page states
      reported a PG_reserved was freed after all: I had missed that we need to
      say __GFP_COMP to get compound page behaviour.
      
      Some of these higher-order pages are allocated by snd_malloc_pages, some by
      snd_malloc_dev_pages; or if SBUS, by sbus_alloc_consistent - but that has
      no gfp arg, so add __GFP_COMP into its sparc32/64 implementations.
      
      I'm still rather puzzled that DRM seems not to need a similar change.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f3d48f03
  16. 28 10月, 2005 1 次提交
  17. 09 10月, 2005 1 次提交
  18. 12 9月, 2005 1 次提交
  19. 30 8月, 2005 2 次提交
  20. 28 7月, 2005 1 次提交
  21. 22 6月, 2005 1 次提交
  22. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4