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