On Fri, May 27, 2011 at 14:38, Kevin Hilman <khilman@xxxxxx> wrote: > > "Cousson, Benoit" <b-cousson@xxxxxx> writes: > > [...] > > > In general we do not want to reset nor idle an IP that was potentially > > already properly configured by bootloader or early Linux boot code. > > Actually, the opposite is true. > > The kernel should not make any assumptions about what the bootloader has > or has not done. We need to have a kernel that can boot from any > bootloader (or none, like using kexec) and be able to start from a known > hardware state. > > Any use of HWMOD_INIT_NO_IDLE, HWMOD_INIT_NO_RESET should be a rare > exception and well documented. Looking deeper to find the rootcause, I see this: a) TI provides a reference schematics design that is usually copied on to most of the platforms - e.g. blaze and panda etc.. this may not be the norm, but tends to be same except for intrepid board designers who like to go into unexplored areas. b) in this case, I tracked the issue down. Here is what is happening (given NDA restrictions as the datasheet of the PMIC is not pubic yet, I am being vague here. Apologies on the same :(): This PMIC has one voltage output which drives MPU - just like the 1vsel per rail as we had in TWL series, here we have an option of storing n values in n vsel registers and selecting one of them. the selection is based on x pins that may be driven by the MPU. In this particular case, one of the pins is connected to OMAP GPIO1 block allowing PMIC to set the voltage from one of two options inside the PMIC - This could have been used like we'd have done in OMAP2 days with VMODE pin. However, in our TI's x-loader case it sets it to 1, and since hwmod reset happens here, it gets set to 0, selecting a much lower voltage than what is needed for functioning causing system to hangup. Now, with this reference design, many things are possible - folks following TI x-loader might pull the pin high, could pull the pin low or even go and ground the pin and free up the GPIO itself. now we have two cases: a) folks who follow TI's recommendations verbatim b) intrepid folks who like doing their own things. What should the default kernel look like here? I think I agree - it should be board files that is usually tied to a particular bootloader (exception being devel boards like Beagle, Panda, Blaze etc where people do develop bootloaders as well..). I agree with kevin here - this should be done by board file. Regards, Nishanth Menon -- 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
