> That is not true. Yes, and due to the setpoint being less than > 100, which is needed or the driver won't work at all, there is > a tendency to drive the target pstate upwards. > However that is tempered by both the PID proportional gain, > and ultimately integer math. More importantly, the CPU > itself tells the driver when it is operating below the target > pstate and driver responds. > > Additionally, the tendency to drive up the target pstate > too much is exasperated by some extra rounding up at a > couple of spots. Dirk has a pending fix. > > > And a few iterations > > later, we will reach max (possible) frequency, > > then we are effectively performance governor > > (highest frequency all the time). > > Please do not confuse highest target pstate with > highest frequency. They are not the same. The processor > itself can back off. > Hi Doug, All you said is about the hardware will not give whatever software wants (e.g., requested freq too high). Agreed. But does it matter to this discussion? Yuyang -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
