[Linaro-mm-sig] [RFCv2 PATCH 2/9 - 4/4] v4l: vb2-dma-contig: update and code refactoring

Tomasz Stanislawski t.stanislaws at samsung.com
Thu Mar 22 09:18:53 PDT 2012


On 03/22/2012 03:52 PM, Subash Patel wrote:
> Hi Laurent,
> 
> On 03/22/2012 08:12 PM, Laurent Pinchart wrote:
>> Hi Tomasz,
>>
>> On Thursday 22 March 2012 14:36:33 Tomasz Stanislawski wrote:
>>> Hi Laurent,
>>> Thank you very much for your comments and question.
>>> They were very useful.
>>
>> You're welcome.
>>
>>> Please refer to the comments below.
>>>
>>> On 03/22/2012 11:50 AM, Laurent Pinchart wrote:
>>>> On Thursday 22 March 2012 11:02:23 Laurent Pinchart wrote:
>>>>> From: Tomasz Stanislawski<t.stanislaws at samsung.com>
>>>>>

[snip]

>>> The physical address is already present in buf->dma_addr, but it is only
>>> valid if the device has no MMU. Notice that vb2-dma-contig possess no
>>> knowledge if MMU is present for a given device.
>>
>> That's why buf->dma_addr can't be considered as a physical address. It's only
>> useful in the device context.
>>
>>> The sg list is not going to be single-entry if the device is provided with
>>> its own MMU.
>>
>> There's something I don't get then. vb2-dma-contig deals with physically
>> contiguous buffers. The buffer is backed by physically contiguous pages, so
>> the sg list should have a single entry.
>>
> I think at present, vb2-dma-contig is abused for any kind of memory allocation (continuous or not). Wouldnt it be good to have a
> proper working setup for videobuf2-dma-sg instead? Driver which chooses to use continuous, shall assign vb2_queue->mem_ops =
> vb2_dma_contig_memops. The devices which know they have a MMU backing can assign the same to vb2_dma_sg_memops. But as of now,
> we try to use vb2_dma_contig_memops for all kind of operation. I have also done this mistake, and wish I repaired it and posted
> it before :(
> 

Hi Subash,

At first, I do not think that vb2-dma-contig is abused for any kind of
allocation. It is used only for DMA coherent contiguous mapping what is
very close to vb2-dma-contig's original purpose.

One thing has to be said loudly:

"The driver does not need to and should not know if IOMMU is present or not."

The DMA framework must know if device uses IOMMU or not.
Reason: the memory is allocated, free, flushed, mapped only by DMA framework.

Usage of vb2-dma-contig or vb2-dma-sg depends only on the way how the memory is
configured into the device. Most of embedded devices use only buffer's
start address and buffer size (often indirectly specified by width/height and format).
It mean that device needs a buffer that is contiguous for its DMA engine.

In such a case, the driver should ALWAYS use vb2-dma-contig.

The DMA framework hidden deep in dma_alloc_coherent internals will deal with
IOMMU configuration.

I hope you find this information useful.

Regards,
Tomasz Stanislawski


More information about the dri-devel mailing list