On Thu, Jul 21, 2011 at 8:53 PM, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html