Re: [PATCHv2] DMAEngine: Let dmac drivers to set chan_id

[Russell King]

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:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/