Re: PM QoS dynamic resource manager

[Bryan Huntsman <bryanh@codeaurora.org>]

>> Mike, one idea I'm exploring is having platform-specific busses with QoS
>> constraints specified via runtime_pm as part of the LDM.  Adding dynamic
>> class creation within pm_qos, or a type enum as you suggest, would work.
>>  However, I think this kind of behavior would fit nicely within runtime_pm.
>>
> 
> I'm not too familiar with the current work in runtime pm and LDM.
> However platform specific buses sounds like a good thing, at least
> more future proof. This works in the embedded SOC world but I'm
> wondering what happens when you have re-configurable hardware and now
> your same peripheral is sourcing a different bus?

My current thought is to have the board file enumerate the device on the 
proper bus.  This configuration is target-specific.  Each driver would 
register on as many buses as it needs to.  Some of the driver/bus 
registrations would be extraneous but the driver/device binding would 
only be possible on one bus.

> Does runtime pm hook into pm qos similar to how cpuidle uses pm qos?
> So the platform-specific buses would be aa pm rumtime or a pm qos
> addition?
> 
> -- Mike

Not to my knowledge.  I'm considering modeling the runtime_pm 
enhancements after pm_qos.  Meaning, there would be additional 
add/update/remove_requirements() callbacks added to struct dev_pm_ops 
for runtime_pm.  Instead of having a system-wide QoS sink per QoS class, 
the requirements would be passed up the LDM tree.  This way, a bus 
driver would be able to receive QoS constraints from all of it's devices 
and, combined with the active state of it's children from runtime_pm, be 
able to do some useful power management.  The entire bus could be 
throttled or idled in this manner.  This scheme would require the SW 
device topology to match the HW topology and not just have everything 
hang off the platform bus.

- Bryan