Hi again Rafael,
On Sat, Aug 1, 2009 at 3:53 AM, Rafael J. Wysocki<rjw@xxxxxxx> 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?
> 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?
Thanks for your help!
/ magnus
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
