I did find that DJGPP documents its clock resolution to be only 50ms (since DOS only provides a 20 Hz timer), so only using clock-based delays would be a very large (~500x) performance hit on DJGPP. I think we should keep a calibrated delay loop for DOS only, since we can expect other OSes to have much better timing support (and it seems less likely that a system will be using CPU frequency scaling of any kind when running DOS).
As for performance changes from sleeping more aggressively, I've done some experimentation on an Intel system using the ichspi programmer and found that even reducing the sleep threshold to 10 microseconds doesn't affect overall performance because almost every delay that gets used is 10 microseconds or less. By doing some grepping through the source tree, it looks like delays used tend to either be 1-10 microseconds or multiple milliseconds. For instance, almost every chip sets its probe delay to none, and only four have a probe delay of more than 10 microseconds. Since there are very few situations where we actually end up sleeping even with a 100 microsecond sleep threshold, I don't think it's important to use realtime priority. Especially because of the risks involved in using realtime priority (possibly making the system completely unresponsive if an error causes flashrom to get stuck), I no longer believe we should automatically try to use it (leaving it up to callers to select a high priority if desired).
> I am wondering, since this is a big chunk of work, how to maybe plan it
> into phases: but this can be discussed later.
It actually doesn't seem like very much work to me. Removing the calibrated loop is pretty easy (I've already written a change that does that), and the rest is mostly fiddling to ensure the program can still build on weird/old platforms like DJGPP. You can expect a short chain of patches in fairly short order, unless I encounter unexpected difficulties. :)