On Monday, August 22, 2011 12:42:06 Anton Staaf wrote: > On Mon, Aug 22, 2011 at 9:08 AM, Mike Frysinger <vap...@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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
