* Paul Walmsley <paul@xxxxxxxxx> [110705 14:42]: > On Tue, 5 Jul 2011, Tony Lindgren wrote: > > > > Can't we always reset the registered hwmods automatically one at a time when > > omap_device_build is called? > > The experimental series that I wrote, but haven't posted yet, resets each > IP block during the first time it's enabled -- which is probably going to > be when omap_device_build() is called. OK > > > 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? > > If a driver doesn't reset its device(s) when it starts, then disabling all > reset might allow the kernel to boot when the board file is missing some > omap_hwmod_no_setup_reset() calls. > > Consider the 4460 GPIO case. If someone hasn't added in the > omap_hwmod_no_setup_reset(gpioX_hwmod) call into the 4460 board file's > init_machine(), then these boards would still crash on boot. > > This would definitely be considered a bug in the board file, that it's > missing that omap_hwmod_no_setup_reset() call. But having a general > 'hwmod_no_reset' might make it easier during initial board bring-up to > determine whether a problem is caused by reset. > > In any case, it doesn't matter too much to me whether a 'hwmod_no_reset' > option is preserved or not; this is just based on our discussion of the > issue a few months ago. Yeah. Sounds like for passing the board specific flags for special case devices is best done with omap2_init_devices() like you suggested. Tony -- 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
