[S] Change in flashrom[main]: udelay: clock_getres() does not provide clock_gettime() resolution

[Brian Norris (Code Review)]

Attention is currently required from: Brian Norris, Nikolai Artemiev, Stefan Reinauer.

Hello Nikolai Artemiev, Stefan Reinauer, build bot (Jenkins),

I'd like you to reexamine a change. Please visit

https://review.coreboot.org/c/flashrom/+/80806?usp=email

to look at the new patch set (#2).

The following approvals got outdated and were removed:
Code-Review+2 by Nikolai Artemiev, Verified+1 by build bot (Jenkins)

Change subject: udelay: clock_getres() does not provide clock_gettime() resolution
......................................................................

udelay: clock_getres() does not provide clock_gettime() resolution

POSIX doesn't give a clear definition of how clock_getres() and
clock_gettime() relate, but Linux makes this clearer. See:

https://git.kernel.org/linus/01679b5db7172b898be325ff272e10aebd412911
posix-timers: Document sys_clock_getres() correctly

The deleted comments are quite clear:

"Clock resolution is used to round up timer and interval times, NOT to
   report clock times"

The new comments instead tell how the resolution is only related to
clock_settime() and to the precision of *timers* -- not to the precision
of clock_gettime() itself.

This is particularly relevant depending on the Linux sysctl `sysctl
kernel.timer_highres`. When enabled, resolution is always 1 nanosecond;
when disabled, it follow the CONFIG_HZ of the kernel in question. But in
neither case does this result actually assist determining the quality of
the use case in question: busy-looping over clock_gettime().

In practice, any system with a typical CPU clock will have good enough
clock_gettime() resolution, and trusting clock_getres() for this is
actively misleading (and, wasteful on systems with
kernel.timer_highres==0). Any system that doesn't trust the precision of
clock_gettime() should simply be building with HAS_CLOCK_GETTIME=no.

Therefore, avoid ever looking at clock_getres(), and instead always use
clock_gettime() if we're allowed to. This saves a bunch of wasted time
in "calibration", which is itself not actually accurate in the presence
of hybrid CPUs or CPU DFS. Notably, calibration time-wastage has been
the subject of a few past stalled efforts:

https://review.coreboot.org/c/flashrom/+/39864
https://review.coreboot.org/c/flashrom/+/44517

BUG=b:325539928
TEST=flashrom never resorts to "Calibrating delay loop" when
     clock_gettime is available
TEST=flashrom works at the same speed (wall clock time) with
     `sysctl kernel.timer_highres=1` and `sysctl kernel.timer_highres=0`

Change-Id: Icdc6e184eacb14d3bd27029e3fc75be4431d82b4
Signed-off-by: Brian Norris 
---
M udelay.c
1 file changed, 15 insertions(+), 22 deletions(-)

git pull ssh://review.coreboot.org:29418/flashrom refs/changes/06/80806/2