On Fri, 25 Nov 2016, Sakari Ailus wrote: > Hi Alan and others, > > On Thu, Nov 24, 2016 at 09:15:39PM -0500, Alan Stern wrote: > > On Fri, 25 Nov 2016, Laurent Pinchart wrote: > > > > > Dear linux-pm developers, what's the suggested way to ensure that a runtime- > > > pm-enabled driver can run fine on a system with CONFIG_PM disabled ? > > > > The exact point of your question isn't entirely clear. In the most > > literal sense, the best ways to ensure this are (1) audit the code, and > > (2) actually try it. > > > > I have a feeling this doesn't quite answer your question, however. :-) > > The question is related to devices that require certain power-up and > power-down sequences that are now implemented as PM runtime hooks that, > without CONFIG_PM defined, will not be executed. Is there a better way than > to handle this than have an implementation in the driver for the PM runtime > and non-PM runtime case separately? Yes, there is a better way. For the initial power-up and final power-down sequences, don't rely on the PM core to invoke the callbacks. Just call them directly, yourself. For example, as part of the probe routine, instead of doing this: pm_runtime_set_suspended(dev); pm_runtime_enable(dev); pm_runtime_get_sync(dev); Do this: pm_runtime_set_active(dev); pm_runtime_get_noresume(dev); pm_runtime_enable(dev); /* * In case CONFIG_PM is disabled, invoke the runtime-resume * callback directly. */ my_runtime_resume(dev); Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
