Messages in this thread | | | From | Linus Torvalds <> | Date | Tue, 31 Oct 2017 10:58:19 -0700 | Subject | Re: [RFC] Improving udelay/ndelay on platforms where that is possible |
| |
On Tue, Oct 31, 2017 at 10:45 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > So I'm very much open to udelay improvements, and if somebody sends > patches for particular platforms to do particularly well on that > platform, I think we should merge them. But ...
Side note: this is obviously a negative feedback circle, where because we know we can't do all that great in general, few platforms really bother to do as well as they perhaps could, since nobody should generally care that deeply due to the generic problem..
Again, if a driver that has tight timing requirements can just generate the timings from its own hardware, that tends to JustWorks(tm).
It was what people used to do traditionally at least on the PC/AT platform. None of this "udelay()" crud, you knew that doing a single PIO read took one usec, so you'd just delay that way. Then the hardware moved from ISA to EISA, and everything sped up, but that was ok, because now it needed a shorter delay anyway...
Doing things like a status register read is often a good way (sometimes the _only_ way) to make sure preceding writes have been flushed all the way to the device anyway, so it can have those kinds of incidental advantages.
Of course, all of this is relevant only for delays on the scale of individual device accesses. But that's also when udelay/ndelay() tends to have the most problems.
Linus
| |