* Paul Walmsley <p...@pwsan.com> [110705 00:35]: > Hi Tony > > On Mon, 4 Jul 2011, Tony Lindgren wrote: > > > * Paul Walmsley <p...@pwsan.com> [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?
Can't we always reset the registered hwmods automatically one at a time when omap_device_build is called? > 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. Yes I think hwmod_reset_unsed would be a better name, but do we actually need any other reset option in addition to that? TOny -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
