[U-Boot] [PATCH] mmc:dcache: Cache line size aligned internal MMC buffers

Mike Frysinger
2011-08-22T17:17:34Z

On Monday, August 22, 2011 12:42:06 Anton Staaf wrote:
> On Mon, Aug 22, 2011 at 9:08 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> > On Monday, August 22, 2011 03:29:52 Lukasz Majewski wrote:
> >> No tests performed yet. The goal of those patches is to preserve the
> >> MMC subsystem functionality when dcache is enabled (the ext_csd[512]
> >> corruption is observed with d-cache enabled).
> >
> > so you're papering over a bug in some controller's cache handling ?
> > shouldnt you fix the controller in question by having it flush its
> > caches ? aligning random buffers to make cache issues "go away" isnt
> > the right way for anything.
>
> No, this isn't something that can be fixed in the controller driver
> code. This is a fundamental problem with buffers in U-Boot that needs
> to be resolved by aligning all buffers used for DMA. The main problem
> is that invalidating a non-cache line aligned buffer is not a safe
> operation. There have been a number of threads discussing this. The
> general consensus was to make attempting to invalidate an unaligned
> buffer an error and then to clean up the unaligned buffers as we find
> them.

Linux has taken the approach of the callers providing dma safe buffers instead
of having lower layers trying to fix things up all the time. and for obvious
reasons: you avoid the double allocation, the memcpy, and you avoid unclear
documentation between layers where multiple layers attempt to fixup the
callers thus futher multiplying the duplicated allocations/copies/etc...

so in this case, why not fix the caller that is passing a dma unaligned buffer
down to the mmc code ?
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110822/fc8a2c9e/attachment.pgp