On Tuesday, August 23, 2011 14:12:09 Anton Staaf wrote:
On Tue, Aug 23, 2011 at 10:30 AM, Mike Frysinger 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.
and more importantly, we're already doing these things on the stack ;)
Are you thinking something like:
#define dma_buffer_alloca(size) alloca(size + get_dcache_line_size() -
- & ~(get_dcache_line_size() - 1);
yes, exactly
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'm not sure we should cater to buggy get_dcache_line_size implementations
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. :)
if the stack lives in a place that dma can't access, but that'd already be a problem for these funcs -mike