On Tue, 2010-11-30 at 21:57 +0100, Laurent Pinchart wrote:
> Hi Marek,
>
> On Tuesday 30 November 2010 11:39:41 Marek Szyprowski wrote:
> > On Monday, November 29, 2010 10:51 AM Laurent Pinchart wrote:
> > > On Friday 19 November 2010 16:55:40 Marek Szyprowski wrote:
> > > > From: Pawel Osciak <p.osciak@xxxxxxxxxxx>
> > > >
> > > > Add an implementation of contiguous virtual memory allocator and
> > > > handling routines for videobuf2, implemented on top of
> > > > vmalloc()/vfree() calls.
> > > >
> > > > Signed-off-by: Pawel Osciak <p.osciak@xxxxxxxxxxx>
> > > > Signed-off-by: Kyungmin Park <kyungmin.park@xxxxxxxxxxx>
> > > > Signed-off-by: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>
> > > > CC: Pawel Osciak <pawel@xxxxxxxxxx>
>
> [snip]
>
> > > > +static void *vb2_vmalloc_alloc(const struct vb2_alloc_ctx *alloc_ctx,
> > > > + unsigned long size)
> > > > +{
> > > > + struct vb2_vmalloc_buf *buf;
> > > > +
> > > > + buf = kzalloc(sizeof *buf, GFP_KERNEL);
> > > > + if (!buf)
> > > > + return NULL;
> > > > +
> > > > + buf->size = size;
> > > > + buf->vaddr = vmalloc_user(buf->size);
> > >
> > > Some drivers might need vmalloc_32_user instead.
> >
> > Which driver might require this? I'm quite surprised.
I don't think this a driver issue, but a hardware issue.
Legacy PCI address space is 32 bits. DMA engines on Legacy PCI cards
can't access addresses larger than 2^32. A hardware IOMMU or the
SWIOTLB software IOMMU in the kernel is needed for these devices to
write to physical memory addresses above 2^32.
( http://en.wikipedia.org/wiki/IOMMU has a nice picture)
The SWIOTLB software IOMMU in the kernel uses bounce buffers with
physical addresses less than 2^32 and then uses the CPU copy them to the
final buffer location. That's a waste of memory and a performance hit
on systems without a hardware IOMMU that is worth avoiding. Also the
SWIOTLB has a bug in it, last I checked, that panics the system when one
requests too much memory.
> I thought that
> > vmalloced memory buffers are used only by the drivers that need to copy
> > video data with CPU anyway.
The CX23418 has a DMA engine that handles scatter-gather lists. The
cx18 driver calls these Memory Descriptor Lists or MDLs. Right now the
driver kmalloc()'s contiguous buffers at module load, so it only uses
MDLs trivially (except for raw YUV video streams)
http://git.linuxtv.org/awalls/media_tree.git?a=blob;f=drivers/media/video/cx18/cx18-queue.c;h=8884537bd62f9bf4685ea1a48c89f970cbb6f8b7;hb=linuxtv-v2.6.38#l347
I'd like to change that in the future to have the cx18 driver buffers
vmalloc'ed and have the CX23418 DMA engine directly fill the physical
chunks of the vmalloc'ed buffers. This is nicer on the user's system
memory, and also avoids manually reassembling the buffers pointed to by
the MDL for YUV video.
To do this, the CX23418 DMA engine needs to be given addresses less than
2^32.
> The OMAP3 ISP driver uses vmalloc_32_user to allocate memory for the MMAP
> method and then maps it to the device address space through the IOMMU. I'm not
> sure that's the best solution, but that's how it works now.
That seems unnecessary, since you have a hardware IOMMU. Addresses
larger than 2^32 can be remapped by the IOMMU to addresses lower than
2^32 in the address space on the IO bus.
Am I missing something?
Regards,
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
