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() - > 1) & ~(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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
