Hi Tony On Mon, 4 Jul 2011, Tony Lindgren wrote: > * Paul Walmsley <paul@xxxxxxxxx> [110702 21:09]: > > > 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? > > I think #3 above is the safest option. How about make it only happen with > hwmod_reset=1 cmdline with 0 being the default value? With the patch that was posted, that would disable all reset. Probably we want to reset devices that have drivers with PM runtime support? That would allow drivers to assume that they are starting from consistent device state. It also should prevent some power management problems that are dependent on particular bootloaders. How about if we add a second parameter, hwmod_reset_unused? The default could be 'no' and then only devices with PM runtime-enabled drivers would be reset first. - 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
