From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Frysinger Date: Tue, 23 Aug 2011 14:35:13 -0400 Subject: [U-Boot] [PATCH] mmc:dcache: Cache line size aligned internal MMC buffers In-Reply-To: References: <1313745913-28672-1-git-send-email-l.majewski@samsung.com> <201108231330.15663.vapier@gentoo.org> Message-ID: <201108231435.15771.vapier@gentoo.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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