Re: [PATCH] synclink_gt add gpio feature

Paul Fulghum <paulkf@xxxxxxxxxxxxx> wrote:

On Fri, 2006-03-24 at 15:12 -0800, Andrew Morton wrote:
Paul Fulghum <paulkf@xxxxxxxxxxxxx> wrote:
The wrapper seems to be the minimal and most efficient
way of implementing this. Maybe I missed some existing
infrastructure that implements the same features?

wait_on_bit()/wake_up_bit() might be usable?

Interesting, I had not noticed this previously.
There are similarities to what I am doing.

The difference is that a conditional wait allows a caller
to wait for one or more 'bits' (in my specific case one
or more signal transitions) with a single wait call.
The caller wakes when at least one of the conditions is met.

wake_up_bit does not directly allow communicating state back
to the waiter, because the only state the waiter is interested
in is defined in the wait_on_bit call.

A concise description of the conditional wait is that each
wait queue implements an event type where additional wake
discrimination is provided by an arbitrary input data field.
The same data field allows arbitrary per waiter state to be passed back
to the waiter. Interpretation of the input and output data
is specific to an event type and the associated waiter/waker code.

In my case I use this facility to allow a waiter to say:
wait for one or more specific GPIO transitions
and tell me the state of all GPIO when at least
one of the specified transitions occur.


It should be possible to communicate between waker and waiter via
__wait_queue.private and __wait_queue.func. Make ->private point at some
on-stack thing, let the waker read and write that.

That'd involve some rather low-level poking at waitqueues, but I don't
expect those facilities are going away.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [PATCH] synclink_gt add gpio feature
    ... or more signal transitions) with a single wait call. ... to the waiter, because the only state the waiter is interested ... The same data field allows arbitrary per waiter state to be passed back ... wait for one or more specific GPIO transitions ...
    (Linux-Kernel)
  • [PATCH] 2.6.16 - futex: small optimization (?)
    ... I found a problem in the futexes, during a futex_wake, if the waiter has a higher priority than the waker. ... This is specially expensive on UP or if both threads are on the same CPU, due to the two task-switchings. ...
    (Linux-Kernel)
  • Re: [PATCH] 2.6.16 - futex: small optimization (?)
    ... I found a problem in the futexes, during a futex_wake, if the waiter has a higher priority than the waker. ... It works for me on kernel 2.6.16, but the kernel hangs if I use it with -rt patch from Ingo Molnar. ... unlock cond var ...
    (Linux-Kernel)