[Ksummit-discuss] [TECH TOPIC] PM dependencies

Rafael J. Wysocki rjw at rjwysocki.net
Tue May 13 22:27:47 UTC 2014


On Monday, May 12, 2014 11:07:29 PM Mark Brown wrote:
> On Mon, May 12, 2014 at 11:16:57PM +0200, Tomasz Figa wrote:
> > On 12.05.2014 22:31, Mark Brown wrote:
> 
> > > It also solves the system suspend dependencies.  Why don't the
> > > runtime PM dependencies just work with reference counting?
> 
> > Runtime PM dependencies work with reference counting just fine, but
> > only for topologies matching Linux driver model, e.g. devices with
> > exactly one device they depend on, e.g. SPI controller and SPI devices
> > on the bus driven by it. Add there an IOMMU and other various strange
> > things that should be transparent to the drivers and it stops working.
> 
> There's no reason why runtime PM references have to follow the topology
> - you do get a default reference count up to any parent (though we break
> that sometimes, as is the case with SPI controllers being suspended even
> though the devices below them are active) but there's nothing stopping
> references being taken outside the topology.

Precisely.

> > I'm still investigating this issue, so more uses cases are yet to be
> > found, but I also guess this is the purpose of this thread. Anyway,
> > for some reason .suspend_late() and .resume_early() callbacks exist in
> > dev_pm_ops struct and I believe that at least some of the cases
> > "solved" by them might be related to the issue being discussed here.
> 
> Yes, they're partly solving a particular common case for this sort of
> interdependency (though I guess they do also do things like allow us to
> make sure the hardware came back in a state where it won't be harmful
> to the rest of the system if we start enabling things).

The original reason why .suspend_late/.resume_early were introduced was to
allow the same callback routines to be run for runtime and for system-wide PM.
Specifically, the idea was that .suspend_late may point to the same routine
as .runtime_suspend, for example, because of the analogy of the conditions
in which they are called (the device is known to be not in use).

That didn't work out perfectly, but those callbacks turn out to be useful
nonetheless.

And yes, I'm interested in this topic too.

Rafael (who wonders why he wasn't CCed in this thread to start with)



More information about the Ksummit-discuss mailing list