Re: [Ksummit-discuss] [TECH TOPIC] Addressing complex dependencies and semantics (v2)

[Lars-Peter Clausen <lars@metafoo.de>]

On 07/28/2016 01:03 PM, Laurent Pinchart wrote:
[...]
>> Do we need to capture 100% of all the weird and wonderful dependencies? I
>> think (speaking for the media subsystem) that the vast majority of the
>> dependencies are pretty simple trees without cycles. Being able to capture
>> that would be a huge help. The remaining more complex devices could still
>> fall back on deferred probe, I'd say.
> 
> When dealing with a single type of resources dependency graphs are very rarely 
> cyclic. However, when merging multiple resource dependency graphs, cycles 
> become quite common.

I've brought this up in my presentation about DAPM (Dynamic Audio Power
Management). I'd like to make DAPM, which is currently only available as
part of the ASoC framework, more generic and export concepts that have
been pioneered there to the general kernel
(http://events.linuxfoundation.org/sites/events/files/slides/dapm.pdf#page=45).
DAPM was designed to able to handle these kinds of dependencies since
they are very common in audio systems. This is done by splitting the
power management process into two phases. First phase is to compute what
needs to be powered up based on a dependency graph. The dependencies are
not expressed between devices, but device subblocks, so called widgets
in DAPM terminology. E.g. if you have a clock chip with multiple clock
output each would get their own widget. Phase 2 in DAPM consists of the
actual power-up/power-down sequencing. This is done in a order that
avoids glitching and ensures all dependencies are powered-up before and
powered-down after the dependent.

This is different to classical power and resource management where you
have reference counted enable/disable callbacks, where only when the
callback is invoked the driver calculates which other resources need to
be enabled and then potentially invokes another callback. E.g. a clock
might need a regulator. The clockchip driver would call
regulator_enable() from it's clk_prepare() callback. And then the
regulator chip driver might enable other resources from its
regulator_enable() callback. This approach easily can lead to cyclic
dependencies that can newer be turned back off again. Whereas DAPM can
resolve this.

One issue with this approach is that you need a power-sequence scheduler
which sits above all devices. E.g. there is no master device that tells
another device it now needs to turn its resources on, but all devices
are equal in the graph and might be both resource provider and resource
consumer. If there is only one scheduler the graph would contain all
devices and be quite big and you'd run into lock contention issues if
operations are performed on different subgraphs at the same time. If you
have multiple schedulers how do you decide which device is managed by
which scheduler as dependencies might be added and removed at runtime.

Also this obviously does not address the probe order issues, but there
is potential to use the same graph structures.