From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Frysinger Date: Sun, 6 Nov 2011 20:03:50 -0500 Subject: [U-Boot] [PATCH] ARM: Generic cache ops skeleton In-Reply-To: <201111061907.30014.marek.vasut@gmail.com> References: <1320542183-20309-1-git-send-email-marek.vasut@gmail.com> <201111061303.12677.vapier@gentoo.org> <201111061907.30014.marek.vasut@gmail.com> Message-ID: <201111062003.50817.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 Sunday 06 November 2011 13:07:29 Marek Vasut wrote: > > On Sunday 06 November 2011 07:39:56 Marek Vasut wrote: > > > > On Saturday 05 November 2011 21:16:23 Marek Vasut wrote: > > > > > This patch should allow a CPU to register it's own cache ops. This > > > > > shall allow multiple CPUs with different cache handlings to be > > > > > supported. > > > > > > > > sorry, what's the point ? this would make sense if you wanted to > > > > build one u- boot image to run on multiple SoCs, but since that > > > > doesn't make sense, i don't see what this patch gets you. > > > > > > Well that's the ultimate goal, isn't it ... > > > > is it actually ? i must have missed the memo. > > > > support for multiple-SoC-support-in-a-single-image shouldn't bloat the > > single SoC case. this code seems to do just that. so it sounds like you > > should find a CONFIG name for this setup and start putting everything > > behind that. > > That's a good point indeed. The other question is, if gcc4.6's LTO won't > fix that for us. Surely enough though, we can't rely on that. i don't think LTO would help here -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/20111106/0681fbed/attachment.pgp