On Tue, Aug 23, 2011 at 10:30 AM, Mike Frysinger <vap...@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
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
