Em Tue, 22 Jan 2013 10:32:07 +0000
James Bottomley <james.bottom...@hansenpartnership.com> escreveu:
> On Tue, 2013-01-22 at 10:16 +0000, James Bottomley wrote:
> > [adding Mauro and v4l since they're the only non-arm consumers]
> > On Tue, 2013-01-22 at 10:13 +0000, James Bottomley wrote:
> > > 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
> > > > > <james.bottom...@hansenpartnership.com> 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
> > > > > >> > <vineet.gup...@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.
> > > > > >
> > > > > > 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.
> >
> > Mauro, will this work for you and the v4l guys? You've got a use
> > embedded in
> >
> > drivers/media/v4l2-core/videobuf2-dma-contig.c
> >
> > Which I can't tell how extensive it might be.
>
> Also, this implementation is really not done well.
>
> ppc has this:
>
> arch/powerpc/include/asm/dma-mapping.h:#define ARCH_HAS_DMA_MMAP_COHERENT
>
> But no other architecture does.
>
> Nothing is gated on this except pcm_native.c which has this wonderful
> snippet:
>
> #ifndef ARCH_HAS_DMA_MMAP_COHERENT
> /* This should be defined / handled globally! */
> #ifdef CONFIG_ARM
> #define ARCH_HAS_DMA_MMAP_COHERENT
> #endif
> #endif
>
> Since there's no documentation at all, it's hard to tell what's going
> on.
>
> However, I'd suggest
>
> 1. Move to an API that is at least capable of implementation on all
> architectures
> 2. Utilize ARCH_HAS_DMA_MMAP_COHERENT to fix the compile problems
> within the architectures
> 3. Document whatever is chosen so we don't end up in this mess
> again.
Agreed.
I remember some efforts were done in the past years moving toward a common
interface, when DMABUF were introduced (and people explicitly mentioned
ARCH_HAS_DMA_MMAP_COHERENT on such discussions), like on this thread:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg30487.html
While I followed part of that discussion, I didn't actually track the
arm-specific patches. So, I'm not sure why ARCH_HAS_DMA_MMAP_COHERENT
is not defined on arm.
Maybe Tomasz or Marek may have more details.
Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
