2014-04-16 5:56 GMT+08:00 Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>: > On Tue, Apr 15, 2014 at 06:13:27PM +0800, Barry Song wrote: >> 2014-04-15 18:00 GMT+08:00 Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>: >> > On Tue, Apr 15, 2014 at 05:49:02PM +0800, Barry Song wrote: >> >> From: Barry Song <Baohua.Song@xxxxxxx> >> >> >> >> L2 cache size has been read by l2x0_init(), it is useless to set >> >> WAY_SIZE and ASSOCIATIVITY in prima2. >> >> >> >> Cc: Russell King <linux@xxxxxxxxxxxxxxxx> >> >> Signed-off-by: Barry Song <Baohua.Song@xxxxxxx> >> >> --- >> >> -Derived from Russell's "ARM: l2c: prima2: remove cache size override" >> > >> > You're a SMP architecture... it would be much better to initialise the >> > L2 cache before the secondary CPUs are brought online. >> >> ok, it seems we still need to hook this into the callback of this >> specific machine instead of using a global early_initcall(). since now >> the dt compatible field has been generic enough, it will cause other >> platforms to execute l2x0_of_init() too. > > What I did for Versatile Express was to move it to the init_irq stage. > I'm not condoning using init_irq() for non-IRQ stuff, but that was > just to see whether it was possible (the .init_early is too early for > it.) Let me put it another way: I'm not thrilled by the idea of > having it in init_irq() but that's a better location to call L2 cache > initialisation than half-way through the kernel's initialisation. i would like to believe you are right since you have dug into the callbacks and finally thinks init_irq() is the suitable stage for it even though it looks misnamed. > >> > In any case, across the board, it's preferable that the L2 cache is >> > enabled before the delay loop calibration as it can have an effect on >> > the calibrated value. >> >> what if the real case is that l2x0 has been enabled in bootloader? > > If the L2 cache has already been enabled, l2x0_of_init() handles it - > in that situation, we can't re-do the enable (because writing to the > aux ctrl register is not allowed) so we merely setup the outer cache > function pointers and don't try to do any configuration or enabling. yes. i meant if that has been done in bootloader, it turns out we don't care about which callback is better any more. and for linux running in non-security, same. > > -- > FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly > improving, and getting towards what was expected from it. - barry _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-arm-kernel