On 09/06/15 09:54, George Spelvin wrote: > It's fundamentally the same, but more robust to occasional long delays > when accessing the PIT. > > In particular, the old code was susceptible to failing if the initial > PIT read was slow. This revised code will move the timing start if > it's a sufficient improvement. > > Another small change that simplified the code was to give up after the > 55 ms PIT timer wraparound, rather than 50 ms. > > I have a test machine where the old code fails reliably and this > code works. > > I've gone wild with the comments, but I don't think the code is much > more complex. > > Comments solicited.
Hi I am not really sure what problem you are trying to solve. I tried this patch on my problem hardware but it failed both with ONE_BYTE_PIT set to 0 and set to 1. I am not sure it addresses the 'really-long-latency to read the counter' problem that I have. A bigger issue for my case is that "slow" calibration is not that slow, taking only 10ms anyway which is much better than the 50ms max for so-called "quick" calibration. So I much prefer the second patch that I posted, which just skips out of quick_pit_calibrate() if the read latency is too long to succeed. Regards Adrian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
