> -----Original Message----- > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > owner@xxxxxxxxxxxxxxx] On Behalf Of Kevin Hilman > Sent: Wednesday, November 17, 2010 12:19 AM > To: Nishanth Menon > Cc: linux-omap; linux-arm; Mans Rullgard > Subject: Re: [PATCH] omap4: enable L2 prefetching > > Nishanth Menon <nm@xxxxxx> writes: > > > From: Mans Rullgard <mans@xxxxxxxxx> > > > > Enabling L2 prefetching improves performance as shown on Panda > > ES2.1 board with mem test, and it has measurable impact on > > performances. I think we should consider it, even though it damages > > "writes" a bit. (rebased to k.org) > > Usually the prefetch is used at both levels together L1 + L2, however, > > to enable the CP15 prefetch engines, these are under security, and on > > GP devices, we cannot enable it(e.g. on PandaBoard). However, just > > enabling PL310 prefetch seems to provide performance improvement, > > as shown in the data below (from Ubuntu) and would be a great thing > > to pull in. > > [...] > > > arch/arm/mach-omap2/omap4-common.c | 6 +++++- > > 1 files changed, 5 insertions(+), 1 deletions(-) > > > > diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach- > omap2/omap4-common.c > > index 2f89555..a5e6126 100644 > > --- a/arch/arm/mach-omap2/omap4-common.c > > +++ b/arch/arm/mach-omap2/omap4-common.c > > @@ -64,6 +64,10 @@ static int __init omap_l2_cache_init(void) > > l2cache_base = ioremap(OMAP44XX_L2CACHE_BASE, SZ_4K); > > BUG_ON(!l2cache_base); > > > > > > + if (omap_rev() != OMAP4430_REV_ES1_0) > > + omap_smc1(0x109, 0x7e470000); > > > > /* Enable PL310 L2 Cache controller */ > > omap_smc1(0x102, 0x1); > > > > @@ -75,7 +79,7 @@ static int __init omap_l2_cache_init(void) > > if (omap_rev() == OMAP4430_REV_ES1_0) > > l2x0_init(l2cache_base, 0x0e050000, 0xc0000fff); > > else > > - l2x0_init(l2cache_base, 0x0e070000, 0xc0000fff); > > + l2x0_init(l2cache_base, 0x7e470000, 0xc0000fff); > > > > /* > > * Override default outer_cache.disable with a OMAP4 > > Adding/updaing the in-code comments would be helpful as well. > > The exiting use of all the hard-coded constants in this code is rather > unreadable and would be much more readable with symbolic constants, and > this change just continues the pattern. > > Ideally, switching this code to use symbolic constants and then adding > the new feature would be a cleaner approach. > I have cleaned up a code a bit based on the comments from Kevin and also updated change log in Man's patch. Also added couple of relevant patches as part of this series which I haven't posted yet. Will post the series on the list soon Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
