Hello Shuah,
We agree that the streaming API was originally *intended* for short
map-unmap DMA sessions, and that dma_alloc_noncoherent() was the
*intended* API for those who want to hold the DMA during a device's
lifetime.
We also agree that on some platforms, DMA mappings are precious, an
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
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 realiz
On Fri, Jun 06, 2014 at 02:45:06PM +0300, Eli Billauer wrote:
> Hello Joerg.
>
>
> On 05/06/14 00:25, Joerg Roedel wrote:
> >
> >What you are trying to do should work with dma_alloc_noncoherent(). The
> >API allows partial syncs on this memory, so you should be fine.
> Please try to put yourself
Hello Joerg.
On 05/06/14 00:25, Joerg Roedel wrote:
What you are trying to do should work with dma_alloc_noncoherent(). The
API allows partial syncs on this memory, so you should be fine.
Please try to put yourself in my position: I have a driver that I care
about, which works fine for a
Hi,
On Wed, Jun 04, 2014 at 06:03:36PM +0300, Eli Billauer wrote:
> I believe that I need a managed dma_map_single() my own driver,
> which doesn't fall in the case of a single use: The driver allocates
> its buffers with __get_free_pages() (or the to-be managed version of
> it). Then it cuts the
Hi,
I believe that I need a managed dma_map_single() my own driver, which
doesn't fall in the case of a single use: The driver allocates its
buffers with __get_free_pages() (or the to-be managed version of it).
Then it cuts the allocated memory into smaller buffers (in some cases,
and with ce
Hello,
On Wed, Jun 04, 2014 at 04:12:11PM +0200, Joerg Roedel wrote:
> Yes, but those drivers usually get DMA buffers at init time with the
> dma_alloc_* interfaces. The dma_map_* interfaces discussed here belong
> to the streaming DMA-API, so they are usually used for only one DMA
> transaction b
On Wed, Jun 04, 2014 at 10:04:08AM -0400, Tejun Heo wrote:
> Hmmm? Don't we have drivers which map dma buffers on device init and
> release them on exit? For dynamic usages, its usefulness is limited
> especially given that dynamic tracking of buffers usually would
> involve tracking of other inf
Hello,
On Wed, Jun 04, 2014 at 01:39:07AM +0200, Joerg Roedel wrote:
> I fully agree with the points Shuah brought up here. I don't think it is
> a good idea to add this kind of resource management to runtime-allocated
> (and de-allocated) resources of device drivers.
>
> Also DMA handles are not
On Tue, Jun 03, 2014 at 03:24:20PM -0600, Shuah Khan wrote:
> On 06/01/2014 01:01 AM, Eli Billauer wrote:
> I see the value of this interface in unmap case, this type of wrapper
> can release dma buffers, drivers neglected to release leaving dangling
> buffers.
>
> However, driver writers should g
On 06/01/2014 01:01 AM, Eli Billauer wrote:
dmam_map_single() and dmam_unmap_single() are the managed counterparts
for the respective dma_* functions.
Note that dmam_map_single() returns a status value rather than the DMA handle.
The DMA handle is passed to the caller through a pointer in the ar
dmam_map_single() and dmam_unmap_single() are the managed counterparts
for the respective dma_* functions.
Note that dmam_map_single() returns a status value rather than the DMA handle.
The DMA handle is passed to the caller through a pointer in the arguments.
The reason for this API change is th
13 matches
Mail list logo
