lkml.org 
[lkml]   [2009]   [Aug]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH update] PM: Introduce core framework for run-time PM of I/O devices (rev. 11)
Date
On Monday 03 August 2009, Magnus Damm wrote:
> Hi again Rafael,

Hi,

> On Sat, Aug 1, 2009 at 3:53 AM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
> > On Friday 31 July 2009, Magnus Damm wrote:
> >> [Runtime PM v11]
>
> >> > @@ -202,7 +203,9 @@ int driver_probe_device(struct device_dr
> >> > pr_debug("bus: '%s': %s: matched device %s with driver %s\n",
> >> > drv->bus->name, __func__, dev_name(dev), drv->name);
> >> >
> >> > + pm_runtime_get_noresume(dev);
> >> > ret = really_probe(dev, drv);
> >> > + pm_runtime_put_noidle(dev);
> >> >
> >> > return ret;
> >> > }
> >>
> >> This creates problems when drivers want to performing runtime resume
> >> from within probe(). For more details please have a look at "[PATCH
> >> 04/04] video: Runtime PM hack for SuperH LCDC driver".
> >
> > Ah, I see. You'd like to call pm_runtime_get_sync() from .probe(), but that
> > sees the usage counter different from zero and exits immediately.
>
> Exactly.
>
> > OTOH, I think we should prevent suspends from racing with .probe() at the core
> > level. Hmm.
>
> Doesn't it make more sense to allow runtime suspend and resume to
> happen after the pm_runtime_enable() call? What case are you trying to
> protect against?

If runtime PM is enabled before .probe() and then .probe() itself doesn't
use pm_runtime_get_*(), then theory it is possible to have ->runtime_suspend()
called while .probe() is running and there's no synchronization between the
two. So, we prevent ->runtime_suspend() from being called while .proble()
is running with the help of the usage counter.

> > One possible approach could be to call pm_runtime_resume() from
> > sh_mobile_lcdc_probe() instead of pm_runtime_put_noidle(). Then, the platform
> > code will have a chance to turn the device on and the later pm_runtime_get*()
> > and pm_runtime_put*() calls will be balanced. Of course, in that case the
> > pm_runtime_get_noresume() in sh_mobile_lcdc_probe() won't be necessary any
> > more. Am I overlooking anything?
>
> So for drivers that want to access hardware from .probe(), calling
> pm_runtime_resume() after pm_runtime_enable() in should be enough?

Yes, that should be sufficient (as long as the pm_runtime_resume() is
successful).

Best,
Rafael


\
 
 \ /
  Last update: 2009-08-03 17:17    [W:0.055 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site