[Linaro-mm-sig] Minutes from V4L2 update call

[Tomasz Stanislawski]

On 04/17/2012 03:03 PM, Daniel Vetter wrote:
> On Tue, Apr 17, 2012 at 01:40:47PM +0200, Tomasz Stanislawski wrote:
>> Hello everyone,
>> I would like to ask about the agreement on a behavior of
>> a DMABUF exporter for dma_buf_map_attachment.
>>
>> According to the DMABUF spec the exporter should return a scatterlist
>> mapped into importers DMA space. However there were issues about the concept.
>>
>> I made a short survey for mapping strategy for DMABUF patches for some drivers:
>>
>> 1. V4L2 - support for dmabuf importing hopefully consistent with dmabuf spec.
>>    The patch "v4l: vb2-dma-contig: change map/unmap behaviour for importers"
>>    implement DMA mapping performed on the importer side. However the patch
>>    can be dropped at no cost.
>> 2. Exynos DRM - the latest version implements mapping on the exporter side
>> 3. Omap/DRM - 'mapping' is done on exporter side by setting a physical address
>>    as DMA address in the scatterlist. The dma_map_sg should be used for this
>>    purpose
>> 4. nouveau/i915 by Dave Airlie - mapping for client is done on importer side.
>>    http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-dmabuf2
>>
>> Does it mean that it is agreed that the exporter is responsible for
>> mapping into the client space?

Hi Daniel,

> 
> No, and imo you're examples are void:
> 4. Dave Airlie's latest rfc patches implement dma api mapping on the
> importers side. For i915 see e.g. commit
> http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-dmabuf2&id=f5c6bc7c5483ceaa79ed23c6b0af9b967ebc009f
> which directly grabs the sg list from the dma_buf exporter and shoves it
> into the into the intel gtt functions that require and already dma mapped
> sg list.

Sorry, my mistake. I was thinking about 'exporter' when I wrote 'importer'.
I agree that i915 is consistent with DMABUF spec. Sorry for the confusion.

> 
> 3. Omap: Afaik the address returned is from the TILER, which can be
> accessed from any hw device. So it's already mapped into device address
> space, just not through an iommu managed by dma-api (but conceptually on
> the same level). This use case is very much one fo the reasons for
> exporting the sg list already mapped.

No. If the client driver has IOMMU then it cannot access the TILER
by basing only on physical address. The client has to map the physical
address to the device's address space. It can be done by transforming
paddr into a scatterlist and mapping it using dma_map_sg. Otherwise
the physical address is useless from the perspective of the client
device.

Therefore returning a phys address as a dma_address is not a valid
way of mapping a memory.

Of course if none of HW pieces uses IOMMU everything works fine.
However, imo an introduction of IOMMU for some client device should
__not__ force any change to the exporter code.

> 
> 2. Exynos uses the iommu api as a nice interface to handle it's graphics
> aperture (akin to omap tiler or i915 gtt). Last time I've checked the
> discussion about how this should be integrated (and at what level) with
> the dma api is still ongoing. So it's imo way to early to conclude that
> exynos doesn't return device dma addresses because this iommu might not
> end up being managed by the core dma api.
> 
> 1. That's your code ;-)
> 
> Last but not least your dma_pages_from_sg (or whatever it's called) trick

The function was called dma_get_pages. As it was mentioned before this
function was a workaround for deficiencies in DMA api.
I agree that it is not possible to transform a buffer into a list of
pages in general case i.e. there might be no struct pages for a given
range of physical address at which RAM is available.

However if it is possible to transform a DMA buffer into a list of pages
then the DMA subsystem is the best place to do it. That is why
dma_get_pages was introduced to DMA api in my RFC. The alternative
might be dma_get_sg to obtain the scatterlist but it is only a cosmetic
difference from dma_get_pages.

You can criticize as you like but please try to help us to find a better
way to export a DMA buffer allocated by DMA api using function like
dma_alloc_{coherent/noncoherent/writecombine}.

> is one gross layering hack which can easily blow up. I pretty much expect
> drm/i915 (and also other drivers) to dma_buf export objects that are _not_
> backed by struct pages sooner or later.
> 
> Cheers, Daniel

To everyone:

I see that there are multiple issues about DMABUF. My proposition is to
organize a brainstorming session (circa 3 days) in Warsaw similar to
V4L brainstorming that happened about a year ago. It will focus
on topic related to DMA mapping and DMABUF.

What do you think about this idea?
Who would like to attend?

Regards,
Tomasz Stanislawski