* Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> [120418 14:19]:
> On Wed, Apr 18, 2012 at 02:01:44PM -0700, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> [120418 13:28]:
> > > I'd like to have the same thing happen on OMAP1 as well (it's actually
> > > quite simple to do) and it means that this DMA engine implementation
> > > detail is (correctly) hidden from the drivers - provided there's no
> > > dependencies on each individual scatterlist entry back to the peripheral
> > > driver.
> >
> > That would be nice. If the DMA engine driver can't dynamically adjust the
> > frame size for each SG entry, then maybe we can work around that by not doing
> > DMA for entries that are below the frame sizes?
>
> I don't think it has to in this case, though I am thinking that we
> may have to adjust the frame size for other peripherals.
>
> In the case of the OMAP1 MMC driver, let me pull out that chunk of code
> again:
>
> frame = data->blksz;
> if (cpu_is_omap15xx() && frame > 32)
> frame = 32;
> else if (frame > 64)
> frame = 64;
> frame >>= 1;
> if (!(data->flags & MMC_DATA_WRITE)) {
> buf = 0x800f | ((frame - 1) << 8);
> } else {
> buf = 0x0f80 | ((frame - 1) << 0);
> }
> OMAP_MMC_WRITE(host, BUF, buf);
>
> Nothing there depends on the size of an individual scatterlist entry -
> the dependencies for the frame size are the smaller of the FIFO size
> and the data block size. I believe we can cope with that quite well on
> a per-transfer basis, and I _think_ we can get away with writing this
> BUF register just once per transfer (similar to what happens for PIO
> transfers.)
OK, let's see if that works :)
> However, this is going to be rather hit and miss for me - all I can do
> is create a patch and check that it builds. I have no way (that I know
> of) to test this change as I don't have any OMAP1 nor OMAP2 hardware.
I can certainly test it on at least for 1710 on 770 and 2420 on N800.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
