On Thursday 01 of December 2011 at 18:17:58, Tony Lindgren wrote: > * Janusz Krzysztofik <jkrzyszt@xxxxxxxxxxxx> [111201 01:20]: [snip] > > Perhaps > > we should rather think of reverting a few commits which caused all these > > problems if fixing them all during rc cycle seems not possible? I > > haven't bisected them yet, rather concentrated on providing fixes, but I > > can still try to do it, starting back from the original issue > > (http://www.spinics.net/lists/linux-omap/msg60052.html), if so decided. > > We can't revert that because the SRAM init has been moved to later for > map_io. Yes, I know that. What I don't know yet is what else should be reverted to fix the original issue other than applying e9b7086b80c4d9e354f4edc9e280ae85a60df408, which seems to introduce (or maybe 'exhibit' is a better word here) more bugs than it fixes. > But if that patch changed the behaviour on your board, then that's > the problem we should fix. > > If you're now stuck at 60MHz rate, care to see if the following patch > makes the kernel behave the same way as before for you? [snip] > > --- a/arch/arm/mach-omap1/clock_data.c > +++ b/arch/arm/mach-omap1/clock_data.c > @@ -927,7 +927,7 @@ int __init omap1_clk_init(void) > > void __init omap1_clk_late_init(void) > { > - if (ck_dpll1.rate >= OMAP1_DPLL1_SANE_VALUE) > + if (ck_dpll1.rate > OMAP1_DPLL1_SANE_VALUE) > return; > > /* Find the highest supported frequency and enable it */ This change really makes sense to me, however, knowing the initial (bootloader selected) clock rate my board boots at, which is unfortunately raw 12 MHz, I would be surprised if that helped. Before e9b7086b80c4d9e354f4edc9e280ae85a60df408, omap1_select_table_rate() was returning the rate selected with .config because it was called early, with ck_dpll1_p->rate uninitialized. Now it is not, and returns nothing, resulting in 60 MHz default. Then, the only way I can see to correct the problem is something like patch 3/5, which you are justifiably affraid of of always switching to 216 MHz with omap1_defconfig. Thanks, Janusz -- 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
