"So can you not tracepoints to give EI results for up/down signals and
filter out the noise? ", Do you mean I don't need the debugfs at all?
For developer, he/she is able to trace anything including the point of
Turbo algorithm adjustment(+n/-n).
But as a black box, validation will not see the cause but only the result.
Boost / Idle function will set RP frequency to Max / Min, turbo
algorithm will +n / -n depends on our implementation.
My intention is to block the disturbance of Boost /Idle, then the RPS
frequency change can only cause bye Turbo algorithm.
- Daisy
On 5/5/2014 10:51 PM, Chris Wilson wrote:
On Mon, May 05, 2014 at 02:50:27PM -0700, Daisy Sun wrote:
RP frequency request is affected by 2 modules: normal turbo
algorithm and RPS boost algorithm. By adding RPS boost algorithm
to the mix, the final frequency becomes relatively unpredictable.
Add a switch to enable/disable RPS boost functionality. When
disabled, RP frequency will follow the normal turbo algorithm only.
Intention: when boost and idle are disabled, we have a clear vision
of turbo algorithm. It‘s very helpful to verify if the turbo
algorithm is working as expected.
Without debugfs hooks, the RPS boost or idle may kick in at
anytime and any circumstances.
The algorithm is still not the same as you "intended". So can you not
tracepoints to give EI results for up/down signals and filter out the
noise?
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
