>-----Original Message----- >From: Kevin Hilman [mailto:[email protected]] >Sent: Thursday, June 03, 2010 7:43 AM >To: Peter Zijlstra >Cc: Alan Cox; Gross, Mark; Florian Mickler; James Bottomley; Arve >Hjønnevåg; Neil Brown; [email protected]; LKML; Thomas Gleixner; Linux OMAP >Mailing List; Linux PM; [email protected] >Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8) > >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. > This seems similar to that pm_qos generalization into bus drivers we where waving our hands at during the collab summit in April? We never did get into meaningful detail at that time.
--mgross -- 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
