mm: iommu: The Virtual Contiguous Memory Manager
in [Kernel]
|
Prev: [PATCH v2]kernel.h Move preprocessor #warning about using kernel headers in userpsace to types.h
Next: scsi/sg: remove casts from void*
From: Alan Cox on 13 Jul 2010 04:20 > Why video4linux can't use the DMA API? Doing DMA with vmalloc'ed > buffers is a thing that we should avoid (there are some exceptions > like xfs though). Vmalloc is about the only API for creating virtually linear memory areas. The video stuff really needs that to avoid lots of horrible special cases when doing buffer processing and the like. Pretty much each driver using it has a pair of functions 'rvmalloc' and 'rvfree' so given a proper "vmalloc_for_dma()" type interface can easily be switched Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: FUJITA Tomonori on 13 Jul 2010 04:40 On Tue, 13 Jul 2010 09:20:12 +0100 Alan Cox <alan(a)lxorguk.ukuu.org.uk> wrote: > > Why video4linux can't use the DMA API? Doing DMA with vmalloc'ed > > buffers is a thing that we should avoid (there are some exceptions > > like xfs though). > > Vmalloc is about the only API for creating virtually linear memory areas. > The video stuff really needs that to avoid lots of horrible special cases > when doing buffer processing and the like. > > Pretty much each driver using it has a pair of functions 'rvmalloc' and > 'rvfree' so given a proper "vmalloc_for_dma()" type interface can easily > be switched We already have helper functions for DMA with vmap pages, flush_kernel_vmap_range and invalidate_kernel_vmap_range. I think that the current DMA API with the above helper functions should work well drivers that want virtually linear large memory areas (such as xfs). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on 13 Jul 2010 04:40 On Tue, 13 Jul 2010 17:30:43 +0900 FUJITA Tomonori <fujita.tomonori(a)lab.ntt.co.jp> wrote: > On Tue, 13 Jul 2010 09:20:12 +0100 > Alan Cox <alan(a)lxorguk.ukuu.org.uk> wrote: > > > > Why video4linux can't use the DMA API? Doing DMA with vmalloc'ed > > > buffers is a thing that we should avoid (there are some exceptions > > > like xfs though). > > > > Vmalloc is about the only API for creating virtually linear memory areas. > > The video stuff really needs that to avoid lots of horrible special cases > > when doing buffer processing and the like. > > > > Pretty much each driver using it has a pair of functions 'rvmalloc' and > > 'rvfree' so given a proper "vmalloc_for_dma()" type interface can easily > > be switched > > We already have helper functions for DMA with vmap pages, > flush_kernel_vmap_range and invalidate_kernel_vmap_range. I'm not sure they help at all because the DMA user for these pages isn't the video driver - it's the USB layer, and the USB layer isn't specifically aware it is being passed vmap pages. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: FUJITA Tomonori on 13 Jul 2010 04:50 On Tue, 13 Jul 2010 09:42:44 +0100 Alan Cox <alan(a)lxorguk.ukuu.org.uk> wrote: > On Tue, 13 Jul 2010 17:30:43 +0900 > FUJITA Tomonori <fujita.tomonori(a)lab.ntt.co.jp> wrote: > > > On Tue, 13 Jul 2010 09:20:12 +0100 > > Alan Cox <alan(a)lxorguk.ukuu.org.uk> wrote: > > > > > > Why video4linux can't use the DMA API? Doing DMA with vmalloc'ed > > > > buffers is a thing that we should avoid (there are some exceptions > > > > like xfs though). > > > > > > Vmalloc is about the only API for creating virtually linear memory areas. > > > The video stuff really needs that to avoid lots of horrible special cases > > > when doing buffer processing and the like. > > > > > > Pretty much each driver using it has a pair of functions 'rvmalloc' and > > > 'rvfree' so given a proper "vmalloc_for_dma()" type interface can easily > > > be switched > > > > We already have helper functions for DMA with vmap pages, > > flush_kernel_vmap_range and invalidate_kernel_vmap_range. > > I'm not sure they help at all because the DMA user for these pages isn't > the video driver - it's the USB layer, and the USB layer isn't > specifically aware it is being passed vmap pages. Drivers can tell the USB layer that these are vmapped buffers? Adding something to struct urb? I might be totally wrong since I don't know anything about the USB layer. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Russell King - ARM Linux on 13 Jul 2010 05:10
On Tue, Jul 13, 2010 at 05:45:39PM +0900, FUJITA Tomonori wrote: > Drivers can tell the USB layer that these are vmapped buffers? Adding > something to struct urb? I might be totally wrong since I don't know > anything about the USB layer. With non-DMA coherent aliasing caches, you need to know where the page is mapped into the virtual address space, so you can deal with aliases. You'd need to tell the USB layer about the other mappings of the page which you'd like to be coherent (such as the vmalloc area - and there's also the possible userspace mapping to think about too, but that's a separate issue.) I wonder if we should have had: vmalloc_prepare_dma(void *, size_t, enum dma_direction) vmalloc_finish_dma(void *, size_t, enum dma_direction) rather than flush_kernel_vmap_range and invalidate_kernel_vmap_range, which'd make their use entirely obvious. However, this brings up a question - how does the driver (eg, v4l, xfs) which is preparing the buffer for another driver (eg, usb host, block dev) know that DMA will be performed on the buffer rather than PIO? That's a very relevant question, because for speculatively prefetching CPUs, we need to invalidate caches after a DMA-from-device operation - but if PIO-from-device happened, this would destroy data read from the device. That problem goes away if we decide that PIO drivers must have the same apparant semantics as DMA drivers - in that data must end up beyond the point of DMA coherency (eg, physical page) - but that's been proven to be very hard to achieve, especially with block device drivers. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |