[PATCH V4 03-1/13] DMA: PL330: Support DMA_SLAVE_CONFIG command

[Jassi Brar]

On Thu, Jul 21, 2011 at 8:53 PM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Thu, Jul 21, 2011 at 08:42:40PM +0530, Jassi Brar wrote:
>> On Thu, Jul 21, 2011 at 4:59 PM, Russell King - ARM Linux
>> <linux at arm.linux.org.uk> wrote:
>> > Does your hardware have a hardware block from the device itself containing
>> > all the systems FIFOs ?
>> I am not sure what you ask, but let me say what I know.
>> In this case atleast, all PL330 DMA channels have fixed source/destination
>> address on the device side. So it's not like developer doesn't know
>> fifo_addr here.
>
> Even so, your approach is _conceptually_ wrong.  Think about it.
>
> You declare your devices giving the bus address where they're located.
> So, lets say for argument that your UART is located at 0x10001000.
>
> Your UART driver knows that the FIFO register is at offset 0x20 from
> the base address.  Your platform data provides the UART driver with a
> DMA match function and data specific for that match function.  This
> data encodes the specific DMA channel.
>
> Now, why should you have to encode into the DMA drivers platform data
> that DMA channel X has its FIFO at 0x10001020?  Not only do you have
> to declare the base address of the UART but also you have to know the
> offset into the UART.
>
> Why not just let the UART driver - which knows that the base address
> is 0x10001000, and the FIFO is at offset 0x20 above that - tell the
> DMA driver that's where the FIFO is located?
Yes I understand, the idea was to avoid optional DMA_SLAVE_CONFIG call.
Apparently we give different weightage to the pros and cons.

Anyways, I accept your opinion.

Though you might want to consider changing the DMA_SLAVE_CONFIG API from
optional to mandatory for Slave capable DMACs. Otherwise I don't see common
client drivers working over different DMACs.

Thanks.