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

[Kevin Hilman <khilman@baylibre.com>]

Andrzej Hajda <a.hajda@samsung.com> writes:

> On 07/27/2016 06:50 PM, Luis R. Rodriguez wrote:
>> (first e-mail bounced)
>>
>> Rafael has proposed has a set of patches to help deal with functional
>> dependencies between devices to help with power management. Mauro has
>> spoken briefly before over the media controller feature graph used to help
>> build relationship between complex dynamic dependencies. Dmitry has taken on
>> to help enable asynchronous probe, however for built-in devices this requires
>> very specific platform knowledge otherwise using async probe will blow up
>> your kernel -- if you get it right though, using async probe can help with
>> boot. Even if you sort things out well -- there are current limitations with
>> ordering semantics available, case in point the x86 IOMMUs already have a small
>> sort run which expand beyond the core init entries allowed, and on top of this
>> the you still have device driver dependencies which are implicitly setting
>> order via link order: consider the ordering between AMD IOMMUv1, AMD IOMMUv2,
>> AMD KFD, and AMD radeon. This has made us realize that at the module front the
>> current 2 levels of init calls limits our ordering semantics leaving only link
>> order as a last measure when things are built-in. Likewise I've recently have
>> had to look into dependency issues early in boot been due to differences
>> between paravirtualization and non-PV kernels, this lead to some current work
>> to help generalize custom section uses (linker tables) and then for us to
>> consider expanding x86 semantics early in boot to address some of the
>> shortcomings implicit by the some paravirtualized boot path.
>>
>> The goal behind Rafael's work's goal is essentially to avoid code duplication
>> (as without doing that in the core many drivers potentially need to do the same
>> thing in the same way) and help to address the asynchronous system
>> suspend/resume case that cannot be addressed by any driver by itself anyway.
>> The effort behind Rafael's, Mauro's, Dmitry's and my work are all independent
>> however the patterns are very similar: addressing complex dependencies and
>> relationships at run time and available semantics for these.
>
> I am also interested in this topic. I have sent some times ago few
> early RFCs proposing solution for 'resource' life-time tracking:

[...]

> The framework can be easily expanded to help with power management

[sorry to be late to the party, catching up on this after some holidays]

I'm also interested in the PM / performance aspects of this topic.

Specifically, I'm working on QoS/performance/PM issues where we need a
way to "link" one device to another, where that link also includes any
busses, IOMMUs etc. that are on the path between the two endpoints.

Because the busses involved have dynamic voltage and frequency scaling
(DVFS) capabilities, the goal is to have dynamic QoS for the whole
link/path so that the busses on that path can aggregate QoS requirements
and do DVFS in order to meet the bandwidth/throughput requirements, but
also to scale back when performance is not needed to save power.

We can do much of this today using per-device pm_qos and runtime
PM/genpd for individual devices, but I'm looking for a way to do similar
for a "path" that has 2 endpoint devices, and some busses in between,
especially when these paths are not represented in the parent-child
relationships.

I had a brief look at Rafael's and your patches, but I need to look
closer at them to see if/how they might be used for this.

Kevin