Re: PM QoS dynamic resource manager

[mark gross <640e9920@gmail.com>]

On Tue, Jun 08, 2010 at 04:03:20PM -0700, Bryan Huntsman wrote:
> >>http://lkml.org/lkml/2010/4/22/213  (I guess the details are in the
> >>archives)  I'm happy to re-visit it.
> >>
> >
> >Interesting patch, it looks like having a "system wide bus" doesn't
> >easily apply to msm and tegra platforms.
> >An example of some things I would like to be able to control are i2c
> >and memory bus.
> >
> >I'm tempted to suggest adding two types memory and i2c but I'm not
> >sure how future proof this will be given the growing complexity in the
> >embedded hardware road-map.
> >What about the possibility of registering not one but several buses?
> >You could add a bus qos param, with a type enum, or bind to some
> >platform_driver or bus_driver
> >
> >Then there's the issue of having to deal with platform specific buses,
> >do you add this type to pm qos with only one user? Or have some
> >platform bus types defined somewhere. The generic code of min / max
> >for resource X can be useful so everyone doesn't spin their own
> >resource framework in their own architecture.
> >
> >-- Mike
> 
> 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.
>

Something like that is what Kevin Hilman was thinking too.  It would
bring a qos concept to the LDM for each bus driver object.  Picking what
qos parameters to use (I recommend latency and bandwidth) and how "local"
the parameters effect of these bus_qos interfaces are.  

They are not the same as the more global system wide pm_qos parameters,
and they would be unlikely things ever exposed to usermode.

Yes I think something like this is inevitable and will happen.  But we
need some good applications to roll out the idea with.  (I think.)

--mgross