Re: [Ksummit-discuss] [TECH TOPIC] PM dependencies

["Rafael J. Wysocki" <rjw@rjwysocki.net>]

On Wednesday, May 14, 2014 12:34:56 AM Rafael J. Wysocki wrote:
> On Wednesday, May 14, 2014 12:27:47 AM Rafael J. Wysocki wrote:
> > 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.
> 
> BTW, I guess that the problem is resume and specifically the fact that if
> a child device resumes, the parent will also resume automatically, but the
> other devices the child may depend on will not (the child's resume may need
> to resume them directly).
> 
> But I'm not sure why that is a problem, so can anyone please share some details?

Thinking more about this, there seem to be two cases:

(a) The driver knows that its device (X) depends on another device (Y).
(b) The driver doesn't know that there is the dependency (there is a framework
    having that information, but drivers only access it indirectly, for
    example).

In principle (a) may be addressed by the driver itself if it is careful enough
to reference count Y in addition to X during runtime PM operations.  The async
(system) suspend case is more problematic, because it also requies the driver
of Y to wait for X to suspend (that is not required if both X and Y are "sync",
but that case is kind of suboptimal).

However, (b) cannot be taken care of by the driver itself and it looks like some
coordination mechanism would be necessary to address it.

I proposed something like that a few years ago (https://lkml.org/lkml/2009/8/26/485),
but people generally didn't like it and it has locking problems.  Admittedly, I'd
do it differently today, but if there's interest, I can refresh that approach.

Rafael