On Mon, 2013-01-21 at 22:59 +0000, James Bottomley wrote: > On Mon, 2013-01-21 at 21:00 +0100, Geert Uytterhoeven wrote: > > On Tue, Jan 15, 2013 at 5:56 PM, James Bottomley > > <[email protected]> wrote: > > > On Tue, 2013-01-15 at 15:07 +0100, Marek Szyprowski wrote: > > >> On 1/15/2013 10:13 AM, Geert Uytterhoeven wrote: > > >> > Marek? > > >> > > > >> > On Tue, Jan 15, 2013 at 5:16 AM, Vineet Gupta > > >> > <[email protected]> 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. > > > > > > For PA-RISC (and all other VIPT, I assume) I need an API which allows me > > > to remap the virtual address of the kernel component (probably using the > > > kmap area) so the user space and kernel space addresses are congruent. > > > > So what are we gonna do for 3.8? I'd like to get my allmodconfig build > > green again ;-) > > > > Change the API? > > Well, if we want the API to work universally, we have to. As I said, > for VIPT systems, the only coherency mechanism we have is the virtual > address ... we have to fix that in the kernel to be congruent with the > userspace virtual address if we want coherency between the kernel and > userspace. > > However, if it only needs to work on ARM and x86, it can stay the way it > is and we could just pull it out of the generic core. > > Who actually wants to use this API, and what for? > > > Keep the API but do a best-effort fix to unbreak the builds? > > - Apply my patches that got acks (avr32/blackfin/cris/m68k), > > - Use static inlines that return -EINVAL for the rest > > (c6x/frv/mn10300/parisc/xtensa). > > I still have a few m68k fixes queued for 3.8, for which I've been > > postponing the > > pull request to get this sorted out, so I could include the above. > > > > Any other solution? > > If it's an API that only works on ARM and x86, there's not much point > pretending it's universal, so we should remove it from the generic arch > code and allow only those architectures which can use it.
There might be a simple solution: just replace void *cpu_addr with void **cpu_addr in the API. This is a bit nasty since compilers think that void ** to void * conversion is quite legal, so it would be hard to pick up misuse of this (uint8_t ** would be better). That way VIPT could remap the kernel pages to a coherent address. This would probably have to change in the dma_mmap_attr() and dma_ops structures. All consumers would have to expect cpu_addr might change, but that seems doable. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
