Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote:
quoted text
> 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?

Yes, that's basically what I'm suggesting.

quoted text
> > 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:

Correct.

quoted text
>  * 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.

Except that usually, struct dma_client is already embedded into a
client-specific struct. So you can't really extend it with
controller-specific data without tying the client to one specific DMA
engine at compile time.

Since struct dma_slave is accessed through a pointer, the client driver
can get a controller-specific struct through device.platform_data or
something similar.

We could probably solve this by adding a "void *controller_data" field
to struct dma_client though.

Haavard
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/