Messages in this thread | | | Date | Thu, 28 Jul 2011 23:35:05 +0100 | From | Russell King <> | Subject | Re: [PATCHv2] DMAEngine: Let dmac drivers to set chan_id |
| |
On Thu, Jul 28, 2011 at 04:14:34PM +0530, Jaswinder Singh wrote: > For ex, for 'PITA' board, the dmac driver (via info directly gotten > from platform) will announce > cap_rs8 := 'MMC' | '2ndInstance' | 'Dev->Mem' //via probe of DMAC0 > cap_rs31 := 'MMC' | '2ndInstance' | 'Dev->Mem' //via probe of DMAC1 > cap_rs8 := 'MMC' | '2ndInstance' | 'Mem->Dev' //via probe of DMAC3 > cap_rs57 := 'MMC' | '2ndInstance' | 'Mem->Dev' //via probe of DMAC4
Most of this didn't look too bad until I got to here.
> Assuming > ************ > a) There are no more than 256 types of DMA'able devices > (MMC, USB, SPI etc) -- [8bits]
Who allocates the 'type of dma' number ?
> b) A type of device never has more than 16 instances in a platform > (MMC-0, MMC-1, MMC-2 etc) -- [4bits]
How is the instance number given to devices ?
Are we expecting to have subsystems register with some kind of entity which gives out 'type' and 'instance' numbers just to satisfy this?
In any case, if you look at Linus W's patches on LAKML for DMA on the Versatile/Realview platforms, or look at the way AMBA drivers like MMCI and PL011 UART deal with the 'filter' business, then I think you'd realize that there's ways to deal with this match problem which are far more flexible than your solution.
What we do there is:
1. We provide a match function from the platform to the peripheral driver. ==> this could be your special generic filter function. 2. We provide the match functions data from the platform to the peripheral driver. ==> this could be your special capability mask for that specific device.
So, as things stand _today_ if a platform wants to use your scheme, it can. But - and this is what makes things more flexible - if it needs to do something else which your scheme can't handle, such as controlling an external MUX which has nothing to do with the DMAC or peripheral apart from sitting in the middle between the two - then it can do it its own way.
I think that's a more flexible approach than any which enforces random kinds of capabilities.
-- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of:
| |