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

[Anton Staaf]

On Tue, Aug 23, 2011 at 10:30 AM, Mike Frysinger <vapier at gentoo.org> wrote:
> On Tuesday, August 23, 2011 05:19:39 Lukasz Majewski wrote:
>> On Mon, 22 Aug 2011 11:57:57 -0700 Anton Staaf wrote:
>> > drivers/mmc/mmc.c: ext_csd in mmc_change_freq is allocated on the stac
>> > drivers/mmc/mmc.c: scr and switch_status in sd_change_freq are
>> > allocated on the stack.
>> > drivers/mmc/mmc.c: ext_csd in mmc_startup is allocated on the stack.
>>
>> This allocations are already fixed:
>>
>> http://patchwork.ozlabs.org/patch/110300/
>> http://patchwork.ozlabs.org/patch/109790/
>>
>> If any doubts/comments/ideas, please let me know :-)
>
> hmm, i wish we had a memalign_alloca().  and all this copy & pasting of
> get_dcache_line_size() makes me unhappy as we're encoding too-low-of-a-level
> logic into funcs.
>
> what about adding a new func like:
> #define dma_buffer_alloca(size)

I generally avoid large allocations on the stack, they can confuse
virtual stack management and blow out small embedded stacks.  But
neither of these are really a problem for most U-Boot targets.  Are
you thinking something like:

#define dma_buffer_alloca(size) alloca(size + get_dcache_line_size() -
1) & ~(get_dcache_line_size() - 1);

Subtracting one from the total allocated size is technically correct,
but could fail poorly if the get_dcache_line_size function returned 0
for some reason.  Perhaps because it's called on a target with no
cache so the implementer figured 0 was as good as any value to return.

I have a nagging suspicion that I'm forgetting something though.  I
know I looked at using alloca first when I was starting to deal with
cache and DMA issues on the Tegra.  And I seem to recall a reason not
to use it.  But it's not coming back to me now.  Perhaps someone else
will think of it.  :)

Thanks,
    Anton

> and it would take care of allocating a big enough aligned buffer on the stack.
> -mike
>