On Wed, Jun 09, 2010 at 05:53:53PM -0700, Mike Chan wrote: > On Tue, Jun 8, 2010 at 8:05 PM, mark gross <640e9920@xxxxxxxxx> wrote: > > 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. > > > > Are you thinking of having a (possible) pm qos constraint for each > struct device_driver? Or struct bus_type ? This would probably work if I'm thinking ever struct bus_type at the moment, but really this is somehting hat has been getting handwaving at so far. > for something like i2c. I'm not sure how this would work for memory > bus. If you did not want to tie memory bus performance to cpu speeds, > since (at least from what I"ve seen in omap / msm / tegra) there's no > device_driver for a memory bus clock, but I could be wrong so someone > correct me if I'm mistaken. it hasn't been thought out yet by me yet, WRT dependency expressions that have more global scope than a given bus like what I think you are talking about. --mgross > > Typically I've seen (on msm / tegra / omap) if cpu is running at > frequency X, then set mem bus clock to Y. Which leads to a bunch of > hacks with drivers requesting frequency X, when really they need the > faster memory speed. > > Perhaps both per bus-type pm qos parameter as well as a new global > memory bus (per cpu for numa systems?) parameter. > > I'm worried about trying to over-engineer a solution here for > non-existing (or non-interested) customers. Ideally something that > will fit our needs with Android on msm / omap / tegra platforms but > still flexible enough for non-SOC. > > -- Mike > > > They are not the same as the more global system wide pm_qos parameters, > > and they would be unlikely things ever exposed to usermode. > > > > I don't think we care about exposing this to userspace for our needs. > > > 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 > > > > _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
