On Thu, Jul 21, 2011 at 4:28 PM, Jassi Brar <jassisinghbrar@xxxxxxxxx> wrote: > [Me] >> Therefore I introduced this to confine the different registers into >> the driver itself and ask the DMA engine to transfer to a specific >> address. > > While that does make sense, it makes mandatory the ritual of calling > DMA_SLAVE_CONFIG mandatory for most of the cases. > And I think the effort to set fifo_addr for peripherals is overrated. Oh well. I beg to differ, maybe I'm poisoned by stuff like this: http://en.wikipedia.org/wiki/Encapsulation_%28object-oriented_programming%29 so let's say we agree to disagree on this then. > Of course there are ways to set the direction... but whatever we do > it can't really be changed from what h/w can only do. > And that is my point. Let clients not bother trying to 'configure' what is > the only supported option by h/w. The interface is generic, and as is demonstrated in the U300 COH901318 and also I think ARM RealView and Versatile reference designs, the DMA channel for the MMCI block is bidirectional, so you really change the direction of the channel at runtime, it's not like I'm making it up and introducing that possibility just for fun :-D So the generic case is that you can request a direction for the channel, and if the hardware doesn't support that, then NAK any tries to set it to a direction which is illegal. Yes, some abstraction but generalization does have a price, and I think it's worth it. Yours, Linus Walleij -- 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
 |