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

[Anton Staaf]

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:
>> On Fri, 19 Aug 2011 11:35:50 -0400 Mike Frysinger wrote:
>> > On Friday, August 19, 2011 11:28:18 Lukasz Majewski wrote:
>> > > On Fri, 19 Aug 2011 09:57:10 -0400 Mike Frysinger wrote:
>> > > > On Friday, August 19, 2011 05:25:13 Lukasz Majewski wrote:
>> > > > also, what is the code size increase with your patch ?
>> > >
>> > > Code size overhead (s5p_goni target):
>> > > Without proposed changes: 167928 B (u-boot.bin)
>> > > With changes: 168208 B (u-boot.bin)
>> > >
>> > > Delta: 280 B
>> >
>> > np if it gives significant (more than system noise) speedups.  any
>> > details on that ?
>>
>> 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.
> -mike

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.

Lukasz, I also have been using memalign to clean up accesses in local
patches, so you've got my vote there. I am curious as to whether we
should provide a single block allocation API or if each subsection
should add lazy memalign allocations to create aligned buffers when
they are needed...

Thanks,
    Anton

> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>