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

[Mike Frysinger <vapier@gentoo.org>]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110823/a55c6093/attachment.pgp