Re: [PATCH 2/2 updated] Measure transition latency at driver initialization

[Eric Piel <Eric.Piel@lifl.fr>]

12/02/2005 12:34 AM, Mattia Dongili wrote/a écrit:
> Fine with me. Following your suggested code, I only changed the order
> of the assigment and the printk because it might still be interesting to
> see the measured value without having to enable cpufreq_debug.
Yes, that's a good idea :-)

> 
> So, to summarize:
> the attached patch introduces runtime latency measurement for many
> speedstep based processors instead of using CPUFREQ_ETERNAL. It includes
> some sanity checks in case the measured value is out of range and
> assigns a safe value of 500uSec that should still be enough on
> problematics chipsets (current testing report values ~200uSec).
Again, I though it was done... and then Ville showed that's it's plainly 
wrong to assume anything with speedstep-smi: it could take up to 1 
second to change of frequency or few uSec. So we should probably back 
out the smi part.

What I propose: modify slightly the interface of speedstep_get_freqs(): 
  * if transition_latency is NULL, we don't try to update the transition 
latency,
* otherwise we so as usual.
Then, in speedstep-smi we can call speedstep_get_freqs() with NULL, 
voila :-)

Later we could change the transition latency of speedstep-smi from 
ETERNAL to 1s... but that's not going to help much anyway for the 
ondemand governor.

Eric