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.119 / U:0.832 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site