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

[Mike Frysinger <vapier@gentoo.org>]

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