Messages in this thread | | | Date | Sat, 20 Sep 2008 16:00:40 -0700 | From | "Dan Williams" <> | Subject | Re: dmaengine.c: question about device_alloc_chan_resources |
| |
On Fri, Sep 19, 2008 at 7:34 AM, Timur Tabi <timur@freescale.com> wrote: > Haavard Skinnemoen wrote: > >> Yes, or maybe provide an interface for simply requesting a channel >> without having to register any callbacks. > > I could use this feature. The sound drivers for our MPC8610 processor use DMA, > but the drivers need to control the DMA hardware directly, so I can't use > dmaengine. I would like to be able to just reserve the channels and program > them as I see fit. >
I think its a good idea especially since it would be best not to needlessly proliferate client implementations with competing channel allocation schemes. However it would need to be more descriptive than:
struct dma_chan *dma_request_channel(dma_cap_mask_t request_mask);
Why: 1/ What if the requester initializes before a dmaengine device has been registered? What if a device is never registered? 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.
At the very least clients should be allowed to set an 'exclusive' bit to prevent the channel from leaking elsewhere.
-- Dan
| |