[PATCH v5] introduce macro spin_event_timeout()

[Scott Wood]

Timur Tabi wrote:
> On Wed, Mar 11, 2009 at 11:51 AM, Scott Wood <scottwood at 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