"Rafael J. Wysocki" <rafael@xxxxxxxxxx> writes: > On Wed, Jun 20, 2018 at 11:27 AM, Felipe Balbi <balbi@xxxxxxxxxx> wrote: >> >> Hi, >> >> Tony Lindgren <tony@xxxxxxxxxxx> writes: >>> * Felipe Balbi <balbi@xxxxxxxxxx> [180619 01:23]: >>>> This is a direct consequence of not paying attention to the order of >>>> things. If driver were to assume that pm_domain->activate() would do the >>>> right thing for the device -- meaning that probe would run with an >>>> active device --, then we wouldn't need that pm_runtime_get() call on >>>> probe at all. Rather we would follow the sequence: >>>> >>>> pm_runtime_forbid() > > Why do you need the _forbid() thing? > > Does the default user space control setting need to be changed? wouldn't that race with a udev rule writing "auto" power/control as soon as device is added? >>>> (If you need to know why the pm_runtime_put_noidle(), remember that >>>> pm_runtime_set_active() increments the usage counter, so >>>> pm_runtime_put_noidle is basically allowing pm_runtime to happen as soon >>>> as userspace writes "auto" to /sys/..../power/control) >>> >>> I wonder if we could also remove the need for drivers to call >>> pm_runtime_putnoidle() at the end of the probe? If we had >>> pm_runtime_init_enabled() implemented. >> >> probably not. We want to block runtime pm during probe, until the device >> is fully initialized, the only way to do that is to increment rpm usage >> counter. > > That or enable it only at the end. But I guess you want to > runtime-resume it earlier, don't you? well, if arch implements pm_domain->activate() and guarantees that device is already running, with clocks stable during probe, then enabling runtime pm at the end is probably the best idea. -- balbi
Attachment:
signature.asc
Description: PGP signature
