> Are you thinking of having a (possible) pm qos constraint for each > struct device_driver? Or struct bus_type ? This would probably work if > 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. I'm imagining QoS classes similar to pm_qos. Bandwidth, cpu latency, etc. Each driver decides what to do for each type, if anything. This gets passed up the tree and aggregated by a parent, which I think would be a bus driver but could be anyone who cares. The QoS sink, for lack of a better term, decides what it wants to do with that data. For a memory bus, it would be possible to add up all bandwidth requests and scale the bus clock accordingly. It could also look at the active status of it's children, decide that the bus is inactive, and completely shut it off. This is where having arch-specific bus drivers is necessary. What each QoS sink does will vary drastically from platform to platform, but the input data should be somewhat consistent. That's why I'm looking into extending runtime_pm in this manner. > 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. Picking the right QoS constraints will always be a problem. It's possible to abuse pm_qos today in the same manner. > 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 In general, I share your dislike for over-engineering. This doesn't feel like that quite yet. From a high level at least, it would seem to fit in nicely with runtime_pm. From Mark's comments it sounds like others are having similar thoughts. - Bryan _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
