On Thu, Jul 21, 2011 at 1:41 PM, Russell King - ARM Linux
<linux@xxxxxxxxxxxxxxxx> wrote:
> On Thu, Jul 21, 2011 at 12:47:49AM +0530, Jassi Brar wrote:
>> On Wed, Jul 20, 2011 at 4:16 PM, Boojin Kim <boojin.kim@xxxxxxxxxxx> wrote:
>> > + if (slave_config->direction == DMA_TO_DEVICE) {
>> > + if (slave_config->dst_addr)
>> > + peri->fifo_addr = slave_config->dst_addr;
>> > + if (slave_config->dst_addr_width)
>> > + peri->burst_sz = __ffs(slave_config->dst_addr_width);
>> > + } else if (slave_config->direction == DMA_FROM_DEVICE) {
>> > + if (slave_config->src_addr)
>> > + peri->fifo_addr = slave_config->src_addr;
>> > + if (slave_config->src_addr_width)
>> > + peri->burst_sz = __ffs(slave_config->src_addr_width);
>> > + }
>> PL330 has fixed channels to peripherals.
>> So FIFO addresses(burst_sz too?) should already be set via platform data.
>> Client drivers shouldn't bother.
>
> That's utter crap, and isn't what the DMA engine API is about.
>
> The above looks correctly implemented. Slave DMA engine users are
> supposed to supply the device DMA register address via this
> DMA_SLAVE_CONFIG call. Doing this via platform data for the DMA
> device is braindead.
Rather than have 32 client drivers expect fifo_address from the
platform and then
provide to the DMAC, IMHO it is better for a single driver(DMAC) to
get 32 addresses
from the platform.
Esp when the DMAC driver already expect similar h/w parameter -- *direction*.
I don't understand why is 'fifo_address' a property much different
than 'direction' of the
channel ?
If a channel is flexible enough to change it's 'fifo_address', most probably it
could also change direction of transfers.
So, why do we want to take seriously 'fifo_address' provided by the
client drivers
and not the 'direction' ?
--
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
