On Thursday 01 of December 2011 at 19:22:54, Tony Lindgren wrote: > * Janusz Krzysztofik <jkrzyszt@xxxxxxxxxxxx> [111201 01:35]: > > On Wednesday 30 of November 2011 at 23:28:38, Tony Lindgren wrote: > > > > > > We should also now be able to remove all the CONFIG_OMAP_ARM_XXXMHZ options > > > too, right? > > > > Right, but then, perhaps the initial version of patch 2a/5, which > > already started removing them, from omap1_defconfig for now, then going > > into the right direction while unblocking another regression fix (3/5), > > _is_ a good candidate for an rc fix? > > But we did not allow dpll1 reprogramming earlier either, Wrong. Without OMAP_CLOCKS_SET_BY_BOOTLOADER selected, we always did, but only once, early at boot, before ck_dpll1_p->rate was set first from omap1_clk_init(), and never retried later, that's why that check which I removed with 3/5 was never in the game until e9b7086b80c4d9e354f4edc9e280ae85a60df408. > so we should > not need to make all these changes during the -rc cycle. I'm suspecting > that we've had this same behaviour for a really long time, and we just > have not seen it as omap1_defconfig had OMAP_CLOCKS_SET_BY_BOOTLOADER > option set. > > So I'm baffled how your board would be booting at a different rate > compared to v3.1, it seems that the logic has not changed there. Or > else we have some simple bug somewhere. > > Care to try to verify at what point your system started booting at > 60MHz rate? Since e9b7086b80c4d9e354f4edc9e280ae85a60df408, I guess, and it's hard to confirm wituout bisecting the issue with too early sram call, back until things still worked like before map_io related changes. I will do that if you decide we should try to revert. 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
