On 03.04.2010 23:09, Carl-Daniel Hailfinger wrote:
> On 03.04.2010 01:28, Urja Rannikko wrote:
>
>> This seems to "fix" this for me - the delay loop is still unreliable, but
>> atleast the recalibration attempts only take 5s instead of minutes. This is
>> a combined diff for both my fix and the % fix.
>>
>> Index: udelay.c
>> ===================================================================
>> --- udelay.c (revision 990)
>> +++ udelay.c (working copy)
>> @@ -66,6 +66,7 @@
>> printf("Calibrating delay loop... ");
>>
>> recalibrate:
>> + count = 1000;
>> while (1) {
>> timeusec = measure_delay(count);
>> if (timeusec > 1000000 / 4)
>>
>>
>
> Does the timing get more reliable if you try the following stuff:
>
> - change the comparison above to
>
> if (timeusec > 1000)
>
>
> - Make sure there are no CPU frequency changes or sleep states
>
>
>
>> @@ -93,7 +94,7 @@
>> */
>> for (i = 0; i < 4; i++) {
>> if (measure_delay(100) < 90) {
>> - msg_pdbg("delay more than 10% too short, "
>> + msg_pdbg("delay more than 10%% too short, "
>> "recalculating... ");
>> goto recalibrate;
>> }
>> Signed-off-by: Urja Rannikko <[email protected]>
>>
>>
>
> In general, I like your patch. I just hope to get more input if reducing
> the abort condition in the loop from 250 ms to 1 ms helps as well.
>
By the way, issuing a sleep/yield command before starting the timer
calibration could help to make sure we start calibrating at the start of
an OS scheduler timeslice, and with 1 ms calibration measurements there
is a fair chance that the complete calibration happens during one
timeslice. That should rule out all scheduler interaction.
Side note: flashrom was never designed to run on machines where any
other process uses significant amounts of CPU since that totally messes
up the delay loop.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
_______________________________________________
flashrom mailing list
[email protected]
http://www.flashrom.org/mailman/listinfo/flashrom
