Yes, this would be a much preferable approach. The only problem that I encountered when attempting to do that in the Chromium U-Boot was that there are exposed stand alone U-Boot API's that can pass in pointers that make their way all the way down to the device driver. Two solutions occurred to me. One was to put an Error or assert as high up as possible and expect violators to fix their code, the other was to patch things up in lower layers (right now we have a bounce buffer in the tegra MMC driver to deal with unaligned buffers). My intent was that this would give us a functional U-Boot while we took the time to clean up as many of the unaligned buffers that U-Boot uses, and then tackle the question of stand alone applications.
-Anton On Mon, Aug 22, 2011 at 10:17 AM, Mike Frysinger <vap...@gentoo.org> wrote: > 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 > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
