Re: [PATCH v4] introduce macro spin_event_timeout()

[Grant Likely <grant.likely@secretlab.ca>]

On Thu, Mar 12, 2009 at 9:03 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
>
>> But that's the thing - I don't want a required delay inside the loop.
>>
>> I guess I'm going to have to think about this for a while.  I'd like
>> to see something like cycles_per_usec() as a companion function to
>> get_cycles().
>
> I think that's where you're wrong :-)

And I disagree.  :-)

> Just require the delay inside the loop, it will make everything nicer.
> There are also some good reasons to do that:
>
>  - The delay between "polls" of the register may have to be controlled,
> for example some HW will choke if polled too fast

Yes, but not all HW does.  There have been several times that I've
needed to spin on a register without any delay.  Requiring the loop
block to include an explicit delay nullifies most of usefulness to me.

>  - If you aren't in an atomic section, you may want to use msleep() and
> thus be schedule friendly

This I agree with, and I see a real use for.  However, if the contents
of the block don't have any form of constant delay, then it is less
clear how long the loop is going to run for.

OTOH, for the kind of delays that I see myself using it for, it if
doesn't have a resolution in the range of timebase ticks, then it
probably isn't going to be useful for me.  I certainly am not
interested in spinning for more than a handful of ticks if I can help
it.

>  - It fixes all the problems mentioned earlier

On another note; I'd consider calling it loop_event_timeout() instead
of spin_event_timeout() since it would allow the block contents to
sleep, and hence it wouldn't be spinning anymore.  :-)

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.