On Tuesday 22 January 2013 03:52 PM, James Bottomley wrote: > On Tue, 2013-01-22 at 11:15 +0100, Marek Szyprowski wrote: >> Hello, >> >> On 1/15/2013 5:56 PM, James Bottomley wrote: >>> On Tue, 2013-01-15 at 15:07 +0100, Marek Szyprowski wrote: >>>> Hello, >>>> >>>> On 1/15/2013 10:13 AM, Geert Uytterhoeven wrote: >>>>> Marek? >>>>> >>>>> On Tue, Jan 15, 2013 at 5:16 AM, Vineet Gupta >>>>> <Vineet.Gupta1@xxxxxxxxxxxx> wrote: >>>>>> On Monday 14 January 2013 09:07 PM, Mark Salter wrote: >>>>>>> On Sun, 2013-01-13 at 11:44 +0100, Geert Uytterhoeven wrote: >>>>>>>> c6x/allmodconfig (assumed): >>>>>>>> >>>>>>>> drivers/media/v4l2-core/videobuf2-dma-contig.c: In function ‘vb2_dc_mmap’: >>>>>>>> drivers/media/v4l2-core/videobuf2-dma-contig.c:204: error: implicit declaration of function ‘dma_mmap_coherent’ >>>>>>>> drivers/media/v4l2-core/videobuf2-dma-contig.c: In function ‘vb2_dc_get_base_sgt’: >>>>>>>> drivers/media/v4l2-core/videobuf2-dma-contig.c:387: error: implicit declaration of function ‘dma_get_sgtable’ >>>>>>>> >>>>>>>> For architectures using dma_map_ops, dma_mmap_coherent() and >>>>>>>> dma_get_sgtable() are provided in <asm-generic/dma-mapping-common.h>. >>>>>>>> >>>>>>>> C6x does not use dma_map_ops, hence it should implement them as inline >>>>>>>> stubs using dma_common_mmap() and dma_common_get_sgtable(). >>>>>>>> >>>>>>> So are dma_mmap_coherent() and dma_get_sgtable() part of the DMA API >>>>>>> now? I don't them in Documentation/DMA*.txt anywhere. >>>>>>> >>>>>>> Why does the default dma_common_mmap() for !CONFIG_MMU return an >>>>>>> error? >>>>>>> >>>>>>> Wouldn't it be better to provide default implementations that an arch >>>>>>> could override rather than having to patch all "no dma_map_ops" >>>>>>> architectures? >>>>>>> >>>>>> Speaking for the still-reviewed ARC Port, I completely agree with Mark. >>>> >>>> dma_mmap_coherent() was partially in the DMA mapping API for some time, but >>>> it was available only on a few architectures (afair ARM, powerpc and avr32). >>>> This caused significant problems for writing unified device drivers or some >>>> device helper modules which were aimed to work on more than one >>>> architecture. >>>> >>>> dma_get_sgtable() is an extension discussed during the Linaro meetings. It >>>> is required to correctly implement buffer sharing between device driver >>>> without hacks or any assumptions about memory layout in the device drivers. >>>> >>>> I have implemented some generic code for both of those two functions, >>>> keeping >>>> in mind that on some hardware architectures (like already mentioned VIVT) >>>> it might be not possible to provide coherent mapping to userspace. It is >>>> perfectly fine for those functions to return an error in such case. >>> >>> It's not possible on VIPT either. This means that the API is unusable >>> on quite a large number of architectures. Surely, if we're starting to >>> write drivers using this, we need to fix the API before more people try >>> to use it. >> >> I don't get this one. On ARM coherent mappings are implemented as >> non-cacheable, >> both in userspace and kernel-space, so having a coherent mapping is >> possible on >> VIPT architecture. > > Only if you have an uncacheable bit in the architecture page table ... > which some of ours don't. > > Regardless, setting pages Uncacheable is really a hack job on shared > buffers because it creates a huge slow down .... like an order of > magnitude more than simply copying the page, which I believe is the > current solution. IMHO, setting the page uncached, even for shared buffer, is the only option for arches with non snooping DMA - independent of VIPT issue. -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
