On 06/06/2014 10:21 AM, Eli Billauer wrote:
On 06/06/14 19:01, Greg KH wrote:
Please try to put yourself in my position: I have a driver that I care
> about, which works fine for a few years. It's based upon
dma_map_single(),
> which seems to be the common way to get non-coherent memory, even
for the
> driver's entire lifespan. I realize that dma_alloc_* was the
intended way to
> do it, but fact is that dma_map_* has become the common choice.
Is your driver in the kernel tree? If not, you really are on your own :(
It's the Xillybus driver in the staging area. I don't know if this
counts for being in the kernel tree...
The suggested patchset would allow replacing my use of dma_map_single()
with a managed version of that function. This will clean the driver's
code considerably.
But I think that the discussion here is if it's valid to use
dma_map_single() for a device-permanent DMA mapping, or if
dma_alloc_noncoherent() is the only way. If the answer is no, there's
quite obviously no point in a devres version for that function.
Eli,
dma_map_single() and dma_unmap_single() are streaming DMA APIs. These
are intended for one DMA transfer and unmapped right after it is done.
dma buffers are limited shared resources for streaming that are
shared by several drivers. Hence the need for use and release
model.
Please refer to the Using Streaming DMA mappings in DMA-API-HOWTO.txt
"- Streaming DMA mappings which are usually mapped for one DMA
transfer, unmapped right after it (unless you use dma_sync_* below)
and for which hardware can optimize for sequential accesses.
This of "streaming" as "asynchronous" or "outside the coherency
domain".
Good examples of what to use streaming mappings for are:
- Networking buffers transmitted/received by a device.
- Filesystem buffers written/read by a SCSI device."
If I understand your intended usage correctly, you are looking to
allocate and hold the buffers for the lifetime of the driver. For
such cases, dma_alloc_*() interfaces are the ones to use.
Please also refer to DMA-API.txt as well. Hope this helps.
-- Shuah
--
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah...@samsung.com | (970) 672-0658
_______________________________________________
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
