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.)
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.
--
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
