On Tue, Aug 23, 2011 at 10:30 AM, Mike Frysinger vapier@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