Re: [PATCH v2] PM / Sleep: Add pm_generic functions to re-use runtime PM callbacks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>
> We first need to clarify the terminology as that seems to be the source of
> the confusion to some extent at least.
>
> When I (or Alan presumably too) say "a subsystem", I mean a bus type, a device
> type or a device class as represented by struct bus_type, struct device_type
> and struct class, respectively.  So "a subsystem callback" means the specific
> callback defined in the given bus type, device type or device class object.
> You can think about that as of "subsystem level" if that's easier.  So that's
> what we mean when we talk about subsystems, not the whole collection of drivers
> and the code above them.

Thanks, this makes it perfectly clear now. I will try to improve while
communicating.

So we have subsystems, power domains and drivers to consider.

>
> Now, say you have a bus type.  Usually, the bus type's PM callbacks will run
> device drivers' PM callbacks.  Quite often they will do things to hardware
> in addition to what the drivers do.  But if your driver's .suspend_late()
> depends on the runtime PM status of the device, then the bus type's .suspend()
> needs to preserve that status.  That is, it cannot do anything to the hardware
> that may cause the runtime PM status of the device to become stale.  That makes
> the .suspend() somewhat special, doesn't it?

I agree, but I can see why this should be a problem for each and every
driver/bus.

Do note that idea here is only to provide the option of allowing
runtime PM callbacks to be executed as a part of the suspend_late ->
resume_early sequence. It is not a rule, it will have to be decided
for each subsystem/driver it they can benefit from this set up.

>
> Now I *guess* that your goal is something like "if that device has been
> runtime suspended, don't touch it", which is a reasonable goal to have.  I'd
> like to implement something like that too, but I think that it needs to be done
> differently.

That is just a minor important part, but nice to have. Please have
look at the recently submitted patch set, "[PATCH 0/5] PM: Enable
option of re-use runtime PM callbacks at system suspend", I hope the
"cover letter" will describe my intention better.

>
> Actually, my idea is to allow the subsystem-level .prepare() callback to let
> the core know if the device needs to be handled during the given suspend/resume
> cycle.  It may be arranged, for example, so that if the subsystem-level (e.g.
> bus type) .prepare() returns a positive number, the core will put the device
> into a special list and it won't take it into consideration at all during the
> whole cycle.
>
> Why this way?  Because subsystems have much better ways to determine whether
> or not it is necessary to access the device during the upcoming system
> suspend/resume cycle than the core does.

I am not sure I understand how this will solve my issues (except the
minor "if that device has been runtime suspended, don't touch it" -
thing).

I will still have to have a complex power domain and still
drivers/buses need wrapper functions around their the runtime PM
callbacks to invoke them during system suspend, if they need them.

In my view, I don't think your idea is conflict or can replace what I
suggest. Both can improve the situation, but maybe for different
scenarios.

Kind regards
Ulf Hansson

>
> Thanks!
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux