On 11/02/2012 04:10 PM, Marek Vasut wrote:
Dear Stephen Warren,
On 11/02/2012 03:28 PM, Marek Vasut wrote:
Dear Stephen Warren,
On 11/02/2012 02:38 PM, Marek Vasut wrote:
...
Dumb question -- might be unrelated. Does the tegra mmc driver do DMA? And if so, what happens if you do raw read to unaligned address (aka. how come you don't need the bounce buffer)?
Yes, it does DMA, I believe. (At least if it doesn't, I have no idea why the driver is flushing caches!)
I guess we only support the use of aligned addresses, so e.g. the following would work:
ext2load mmc 0:1 0x00100000 /file
but the following wouldn't:
ext2load mmc 0:1 0x00100004 /file
which while I suppose it is an artificial restriction, hasn't been an issue in practice.
Then just enable the bounce buffer and it will work ;-)
You suggested that last time, and it made no difference then... In fact, the config option you mentioned isn't used anywhere in the srouce tree except adding bouncebuf.o
Bouncebuf.o ?
common/bouncebuf.c
into the build right now; which config option do you think I should use?
CONFIG_BOUNCE_BUFFER
It's used on mx28-based boards.
Ahah, there's much more to it than just defining the config option, and grep'ing for the config option doesn't reveal that.
Defining CONFIG_BOUNCE_BUFFER simply pulls in bouncebuf.o into the build. It's then up to the individual MMC/... driver to actually make use of the new functions - i.e. explicitly call e.g. bounce_buffer_start(). The MXS MMC driver calls these without any ifdef CONFIG_BOUNCE_BUFFER, and hence doesn't show up when you grep for that. I had assumed that such functionality would be a conditional part of the MMC core rather than the individual drivers, hence had missed the usage in the MXS driver.
So, that config option plus some changes to the Tegra MMC driver might work - I'll take a look. However, making that change will simply hide any unaligned buffer and reduce performance, so I'd still prefer to require that buffers be aligned in the future where possible.