Handle insufficient DOS timer precision by measuring a 100 ms delay instead of a 100 us delay. This should reduce the likelihood of flashrom timer complaints from 100% to 50%. If you want less complaints, use 1000 ms instead. This is mostly a proof of concept and I'd appreciate tests.
Once I know which #defines to look for on MinGW and Cygwin, I can modify the #if to cover them as well.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Index: flashrom-measure_delay_precision_dos/udelay.c =================================================================== --- flashrom-measure_delay_precision_dos/udelay.c (Revision 1008) +++ flashrom-measure_delay_precision_dos/udelay.c (Arbeitskopie) @@ -93,7 +93,19 @@ * a scheduler delay or something similar. */ for (i = 0; i < 4; i++) { - if (measure_delay(100) < 90) { +#if !defined(__DJGPP__) + timeusec = measure_delay(100); +#else + /* This zero delay workaround should be active for + * DOS and Windows and maybe libpayload. The criterion + * here is insufficient (worse than 100 us) OS timer + * resolution which will result in measure_delay(100)=0 + * whereas a longer delay (100 ms) will be sufficient + * to get a nonzero time measurement. + */ + timeusec = measure_delay(100000) / 1000; +#endif + if (timeusec < 90) { msg_pdbg("delay more than 10%% too short, " "recalculating... "); goto recalibrate;