[PATCH] driver core / PM: Add callbacks for PM domain initialization/cleanup

[Rafael J. Wysocki]

On Thursday, March 19, 2015 04:48:22 PM Ulf Hansson wrote:
> On 19 March 2015 at 17:04, Rafael J. Wysocki <rjw at rjwysocki.net> wrote:
> > On Thursday, March 19, 2015 04:37:26 PM Ulf Hansson wrote:
> >> On 19 March 2015 at 16:44, Rafael J. Wysocki <rjw at rjwysocki.net> wrote:
> >> > On Thursday, March 19, 2015 03:45:07 PM Ulf Hansson wrote:
> >> >> On 19 March 2015 at 15:20, Alan Stern <stern at rowland.harvard.edu> wrote:
> >> >> > On Thu, 19 Mar 2015, Rafael J. Wysocki wrote:
> >> >> >
> >> >> >> > This doesn't make sense to me.  A bus just called bus_add_device, it can
> >> >> >> > do whatever it wanted to right before calling this function, no need for
> >> >> >> > another callback.
> >> >> >>
> >> >> >> The only caller of bus_add_device() is device_add().
> >> >> >>
> >> >> >> What do you mean by "bus just called bus_add_device"?  Do you think that
> >> >> >> the pm_domain pointer should be populated before calling device_add()?
> >> >> >>
> >> >> >> That wouldn't work for the ACPI PM domain at least, because ACPI companions
> >> >> >> are generally added during device_add() and we arguably cannot point a
> >> >> >> device to the ACPI PM domain before its ACPI companion is set.
> >> >> >
> >> >> >
> >> >> >> There are two alternatives to them.  One is to do PM domain attach/detach in
> >> >> >> the bus type's ->probe and ->remove, but that's suboptimal, because it is
> >> >> >> then carried out every time a driver is probed/removed for a device.  The
> >> >> >> other one would be to have each interested bus type register a bus type
> >> >> >> notifier for itself, but that would be rather ugly, wouldn't it?
> >> >> >
> >> >> > Driver probing and removal is not a hot path.  Successful probes
> >> >> > usually occur only once for each device.  I don't know how many
> >> >> > unsuccessful probes there are on average, but probably not many.
> >> >> >
> >> >> > Doing the PM domain attach/detach in ->probe and ->remove makes sense
> >> >> > to me.
> >> >>
> >> >> Let me elaborate a bit on the current approach, with PM domain
> >> >> attach/detach in ->probe() and ->remove(). This comes with the
> >> >> following limitations.
> >> >>
> >> >> 1) If the device gets probed earlier than the PM domain has been
> >> >> initialized, we can't return -EPROBE_DEFER since we just don't know
> >> >> anything about the PM domain yet.
> >> >>
> >> >> 2) The PM domain won't be able to operate on a device without having a
> >> >> driver bound to it, since the device's PM domain pointer is removed at
> >> >> ->remove().
> >> >>
> >> >> Perhaps Rafael want to add something to these? I don't know whether we
> >> >> think it's okay to keep these limitations or not.
> >> >
> >> > There are arguments both ways as you can see.
> >> >
> >> > At this point, the most straightforward approach would be to apply the Russell's
> >> > patch adding the ->sync callback alone.
> >> >
> >> > I will then need the ->activate callback for another use case (a PM domain that
> >> > may not be ready for the device to be probed), but in that case I actually know
> >> > that the pm_domain pointer is populated at the really_probe() time.
> >>
> >> Then, how about adding only the ->sync() and ->activate() callback in
> >> one patch - and invoke them from really_probe()? That's seems to fit
> >> both our short and long term approach.
> >>
> >> Genpd may then implement the ->sync() callback, which is similar to
> >> Russell's patch, except that it will now cover all buses and not just
> >> the platform bus as it where before.
> >
> > OK
> >
> > So do we need to do ->sync at the driver removal time too?  I guess we do?
> 
> For genpd, it will currently not matter since the device will be
> detached from its PM domain before that ->sync() would be called.
> 
> Though, to prepare for the "long term" solution we could decide to add it...

OK, at that time.

Fine, I'll send an update, then.


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.