On Sat, 2013-12-14 at 21:59 +0100, Arnd Bergmann wrote:

Have you checked that the nsleep definition actually does the
right thing here? 450 nanoseconds must be close the latency
you get from calling schedule_hrtimeout(). I'd suggest using
either ndelay() or usleep_range() instead, depending on your
needs.

Documentation/timers/timers-howto.txt stated there was a significant
overhead when setting up usleep_range. I studied implementation and
found that schedule_hrtimeout was certainly less than 520000 CPU cycles
that udelay(1) would consume.

It worked. I haven't checked actual delay time. However, machines with
the driver (based on 3.8) are in production since May 2013 without
issues.

If nsleep is really useful here, we should probably add that
as a generic API rather than having it in one driver.

I've also used this nsleep for driving RTC clock (DS1302) since May
2013.

Now I see that my code is a clone of usleep_range(x, x). I will convert
my code to use it.