Messages in this thread | | | Date | Mon, 25 Jul 2011 11:55:45 -0700 | Subject | Re: [PATCHv2] DMAEngine: Let dmac drivers to set chan_id | From | "Williams, Dan J" <> |
| |
On Fri, Jul 22, 2011 at 8:56 PM, Jaswinder Singh <jaswinder.singh@linaro.org> wrote: > On 23 July 2011 03:53, Williams, Dan J <dan.j.williams@intel.com> wrote: > >> >> Unless you guaranteed that every id is globally unique I don't see how >> they are generically usable by common clients? >> > Yes. And the first step is to allow DMAC drivers to freely set chan_id value. > Platform could pass the list and mapping of supported 'global channels' > via platform_data(?) which the DMAC drivers could set in chan_id > And I am not sure of defining a new variable for that, because chan_id > is actually used only by some dmac drivers for internal purpose only - > which they could do by private variables.
Yes, it does appear to have grown a lot of dubious usage in drivers/dma/ for something that is described as just a "channel ID for sysfs". The intent was for drivers that need to maintain their own hardware specific identification to define a local id scheme (like iop-adma does in the iop3xx case).
I can sort of see why it is attractive for the goal of having clients being able to talk to multiple DMACs since it is a field that all channels already implement. But, I don't think we should be mixing sysfs presentation details with a capability that indicates a certain compatibility level in a DMAC driver implementation. If the goal is to be able to use a single client with multiple drivers that, to me, is asking for a new capability bit (dma_transaction_type) rather than an id. Do you have an example of the client and the DMACs that would first take advantage of such a cross DMAC compatibility?
> Proposal to have global cross-platform enum of channel-IDs defined by > client drivers, was to be my next patch. > Though I think, this patch is valid in it's own light.
This is not the purpose of chan_id.
-- Dan
| |