Peter Zijlstra <[email protected]> writes: > On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote: >> > [mtg: ] This has been a pain point for the PM_QOS implementation. >> They change the constrain back and forth at the transaction level of >> the i2c driver. The pm_qos code really wasn't made to deal with such >> hot path use, as each such change triggers a re-computation of what >> the aggregate qos request is. >> >> That should be trivial in the usual case because 99% of the time you can >> hot path >> >> the QoS entry changing is the latest one >> there have been no other changes >> If it is valid I can use the cached previous aggregate I cunningly >> saved in the top QoS entry when I computed the new one >> >> (ie most of the time from the kernel side you have a QoS stack) > > Why would the kernel change the QoS state of a task? Why not have two > interacting QoS variables, one for the task, one for the subsystem in > question, and the action depends on their relative value?
Yes, having a QoS parameter per-subsystem (or even per-device) is very important for SoCs that have independently controlled powerdomains. If all devices/subsystems in a particular powerdomain have QoS parameters that permit, the power state of that powerdomain can be lowered independently from system-wide power state and power states of other power domains. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
