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.
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.