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

[Anton Staaf]

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 <vapier at 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 <vapier at 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
>