Hi Tony On Thu, 30 Jun 2011, Tony Lindgren wrote: > NAK for this patch. We don't want any of this in init_early. > > The problem is with hwmod core code that wrongly assumes it > can just reset all devices. I don't think the hwmod core code has any way of knowing which devices shouldn't be reset unless the board file specifically tells it. Even if the reset happens right before the hwmod enable (as called by the device driver), the 4460 boards would still crash when the GPIO driver starts. What you suggested below should allow those omap_hwmod_no_setup_reset() calls to live in init_machine, rather than init_early. Hopefully that is acceptable? So I did a test implementation of your idea, and learned some good news and bad news. The good news is that it seems to work for the PM runtime-converted drivers. omap_hwmod_no_setup_reset() calls can go into init_machine code. We should also be able to get rid of the postsetup code in mach-omap2/io.c. The bad news is that the unused IP block reset code will reset IP blocks used by drivers that haven't been converted to use runtime PM. The hwmod core code doesn't know that those IP blocks are in use, since omap_hwmod_enable() is never called for them. The unused IP block reset code will then reset those blocks after the drivers have already probed, and the drivers are not expecting this :-) GPTIMER and HSMMC drivers are the obvious problems in terms of getting a successful boot, but DSS is another one that may cause some problems here. There are HSMMC and DSS driver PM runtime conversion patches posted, hopefully they will go into mainline soon, but there are probably some other important drivers yet to be converted or yet to be pushed. Here are some options that come to mind: 1. Wait until the driver runtime PM conversion is finished before doing anything. In the meantime, boards with IP blocks that can't be reset - N810, TI 4460 boards - will have problems. 2. Merge the lazy/unused hwmod reset code, but prevent IP blocks controlled by non-runtime PM drivers from being reset. We'd have to maintain a list of these somewhere, perhaps in some common code called by board file init_machine code. Then we'd need to redact that list as new driver runtime PM conversions complete. 3. Merge the lazy/unused hwmod reset code, but disable the unused hwmod reset code until the driver runtime PM conversion is finished. This could cause problems with driverless devices that are left configured by bootloaders or ROM code, and that problem would reoccur for each new OMAP chip. Do you have a preference as to which approach to take? > We should fix the hwmod code to lazily only reset devices as they > are enabled, and only reset unused devices with late_initcall > when we have decent debug output. And the reset of unused devices > should be possible to turn off with some kernel cmdline option. - Paul -- 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
