Re: [Linux-c6x-dev] [PATCH 3/9] c6x: Provide dma_mmap_coherent() and dma_get_sgtable()

[James Bottomley <James.Bottomley@HansenPartnership.com>]

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@synopsys.com> 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.

> There are common, already defined and widely used user interfaces (like 
> mentioned
> fbdev, v4l2, alsa) which rely on mmaping coherent buffers to userspace. 
> There are
> drivers which use coherent buffers for those interfaces. It is already 
> an issue
> to implement mmap call for those drivers as it requires some architecture
> specific assumptions. We wanted to remove those assumptions from the 
> drivers and
> move them to some common dma-mapping calls.
> 
> I agree that this might not be directly possible on non-mmu systems, 
> where mmap
> syscall is handled differently. Some architectures might also have some 
> hardware
> limitations, which prevents implementing such interface. That's ok, as 
> probably
> there is no drivers which will use this interface on this architecture.
> 
> > 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.
> 
> How such API would look like? What syscall might be used for it?

See next email.

James