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:
- 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.
- Exynos DRM - the latest version implements mapping on the exporter side
- 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
- 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=f5c6... 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.
- 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.
- 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.
- 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