Messages in this thread | | | Date | Mon, 22 Sep 2008 09:44:11 +0200 | From | Haavard Skinnemoen <> | Subject | Re: dmaengine.c: question about device_alloc_chan_resources |
| |
Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote: > 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.
> > 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.
> * 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
| |