From: Paul Fulghum <paulkf@microgate.com>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] synclink_gt add gpio feature
Date: Fri, 24 Mar 2006 18:02:49 -0600 [thread overview]
Message-ID: <1143244969.2594.24.camel@localhost.localdomain> (raw)
In-Reply-To: <20060324151245.299ff2c1.akpm@osdl.org>
On Fri, 2006-03-24 at 15:12 -0800, Andrew Morton wrote:
> Paul Fulghum <paulkf@microgate.com> 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.
--
Paul
next prev parent reply other threads:[~2006-03-25 0:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-24 16:04 Paul Fulghum
2006-03-24 22:19 ` Andrew Morton
2006-03-24 22:52 ` Paul Fulghum
2006-03-24 23:12 ` Andrew Morton
2006-03-25 0:02 ` Paul Fulghum [this message]
2006-03-25 0:13 ` Andrew Morton
2006-03-25 1:52 ` Paul Fulghum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1143244969.2594.24.camel@localhost.localdomain \
--to=paulkf@microgate.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome