Re: [PATCH 1/1] smiapp: Implement power-on and power-off sequences without runtime PM

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Alan,

On Friday 25 Nov 2016 10:21:21 Alan Stern wrote:
> On Fri, 25 Nov 2016, Sakari Ailus wrote:
> > 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);

Wouldn't it be cleaner for drivers not to have to handle this manually (which 
gives an opportunity to get it wrong) but instead have pm_runtime_enable() 
call the runtime resume callback when CONFIG_PM is disabled ?

-- 
Regards,

Laurent Pinchart