Timur Tabi wrote:
On Wed, Mar 11, 2009 at 11:51 AM, Scott Wood <scottw...@freescale.com> wrote:
One jiffy is fine, but two is just too long?
Any number of jiffies is *not* too long if a timeout occurs. However,
I think even one jiffy is too long if that's the normal condition.
I was under the impression that we were only talking about timeouts, and
that the common case was significantly shorter than that.
Unfortunately, the driver may not have any choice in some
circumstances. If the hardware is just too slow to respond, and it
doesn't provide interrupts, but the code is running in atomic context,
and the function what else can it do?
Rework the driver to poll from a periodic timer (like we do with PHYs).
However, that's overkill when the hardware is supposed to respond in a
handful of clocks, and preemption is enabled in case the timeout path
does happen.
Disallow that, enforced with a call to might_sleep().
I think we need to be able to allow this function to work in atomic
context. Is jiffies updated in atomic context?
If it's atomic because preemption was disabled, yes -- but even a rare
extended spin in such a context would be bad for hard realtime. If
interrupts are disabled, or the code is executing from a timer interrupt
(or possibly other interrupts depending on the hardware and its priority
scheme), no.
Alternatively, do something with get_cycles(), and have some sort of #define
by which arches can say if get_cycles actually works. In the absence of a
working get_cycles() or equivalent, timeouts with interrupts disabled aren't
going to happen whether we abstract it with a macro or not.
I think I can live with that.
Another option is to use udelay() on platforms without a working
get_cycles().
-Scott
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
