[U-Boot] [PATCH] tegra: mmc: Support operation with dcache enabled
Andy Fleming
afleming at gmail.com
Mon Jan 9 03:36:00 CET 2012
On Sun, Jan 8, 2012 at 2:42 AM, Mike Frysinger <vapier at gentoo.org> wrote:
> On Wednesday 21 December 2011 16:10:16 Stephen Warren wrote:
>> Simon Glass wrote at Wednesday, December 21, 2011 1:03 PM:
>> > When the data cache is enabled we must flush on write and invalidate
>> > on read. We also check that buffers are aligned to data cache lines
>> > boundaries. With recent work in U-Boot this should generally be the case
>> > but the warnings will catch problems.
>>
>> Conceptually this seems fine, but shouldn't the MMC driver core be doing
>> the cache management, so all platforms without cache coherency can
>> benefit from it?
>
> if the driver bitbangs things out (like SPI/MMC), then the core doing it would
> be a waste wouldn't it ?
>
> a better question might be how does Linux handle it ? does it force the
> drivers to do it, or does the core take care of things ?
As I understand it, drivers are responsible for handling this on their
own. However, they use an intermediate DMA API to map a buffer into
DMA-capable memory space, and then to unmap it when it's done. There's
also a "flush" function. We could theoretically provide a similar
capability.
I think, for now, doing this by hand in each driver is fine. A full
DMA layer would require some design, and would, I think, devolve into
essentially just cache-flushing. I'm not aware of any U-Boot drivers
which would require actual mapping calls to deal with things like
using 36-bits of physical memory. Yet.
Andy
More information about the U-Boot
mailing list