lkml.org 
[lkml]   [2008]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: dmaengine.c: question about device_alloc_chan_resources
On Sun, 21 Sep 2008, Haavard Skinnemoen wrote:

> > 2/ What about platform specific concerns where dma_cap_mask_t is not
> > descriptive enough e.g. only one memcpy channel can address a certain
> > bus? Currently a client implementation can have some intelligence to
> > return DMA_DUP for channels that do not have the platform capability.
>
> Currently, clients requesting the DMA_SLAVE capability can specify
> which particular DMA device they need. Would it make sense to allow
> other clients to do that as well?

This is how it is documented in dmaengine.h:

* @slave: data for preparing slave transfer. Must be non-NULL iff the
* DMA_SLAVE capability is requested.

But, looking at dma_client_chan_alloc() it seems, any client requesting a
channel can provide a slave and link it to a specific dma_dev, regardless
what capabilities the client is requesting, or am I missing something? If
so, then yes, please, let's allow all do this. Wouldn't it be better to
move the .dma_dev member to dma_client?

> Also, struct dma_slave can be extended with
> controller-/platform-specific fields. Maybe we need a similar mechanism
> for passing platform-specific constraints when requesting "regular"
> channels?

As far as I understand, this extension can only be done by "wrapping"
dma_slave with driver-specific data:
* If dma_dev is non-NULL, the client can not be bound to other DMA
* masters than the one corresponding to this device. The DMA master
* driver may use this to determine if there is controller-specific
* data wrapped around this struct. Drivers of platform code that sets
* the dma_dev field must therefore make sure to use an appropriate
* controller-specific dma slave structure wrapping this struct.

i.e., there is no "void *priv" or similar. So, the same "wrapping" can be
used with dma_client, even more conveniently so, if we move .dma_dev into
it.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer

\
 
 \ /
  Last update: 2008-09-21 21:53    [from the cache]
©2003-2011 Jasper Spaans