From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Pavel Machek <pavel@suse.cz>
Cc: John Lenz <lenz@cs.wisc.edu>,
Robert Schwebel <robert@schwebel.de>,
Robert Schwebel <r.schwebel@pengutronix.de>,
vojtech@suse.cz, rpurdie@rpsys.net,
kernel list <linux-kernel@vger.kernel.org>
Subject: Re: best way to handle LEDs
Date: Thu, 3 Nov 2005 14:49:04 +0000 [thread overview]
Message-ID: <20051103144904.GG28038@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20051103095725.GA703@openzaurus.ucw.cz>
On Thu, Nov 03, 2005 at 10:57:26AM +0100, Pavel Machek wrote:
> Hi!
>
> > > Except the led code that is being proposed CAN sit on top of a generic
> > > GPIO layer.
> >
> > I also have issues with a generic GPIO layer. As I mentioned in the
> > past, there's serious locking issues with any generic abstraction of
> > GPIOs.
> >
> > 1. You want to be able to change GPIO state from interrupts. This
> > implies you can not sleep in GPIO state changing functions.
> >
> > 2. Some GPIOs are implemented on I2C devices. This means that to
> > change state, you must sleep.
>
> Can't you just busywait? Yes, it is ugly in general, but perhaps it
> is better than alternatives...
Does the i2c layer support busy waiting or are you suggesting something
else?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
next prev parent reply other threads:[~2005-11-03 14:49 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-01 23:44 best way to handle LEDs Pavel Machek
2005-11-02 0:39 ` Richard Purdie
2005-11-02 1:03 ` John Lenz
2005-11-02 8:01 ` Chase Venters
2005-11-02 13:56 ` Pavel Machek
2005-11-02 14:38 ` Richard Purdie
2005-11-02 21:11 ` Pavel Machek
2005-11-02 22:05 ` Richard Purdie
2005-11-02 1:57 ` root
2005-11-02 11:40 ` Geert Uytterhoeven
2005-11-02 2:47 ` Ben Dooks
2005-11-02 9:48 ` Alessandro Zummo
2005-11-02 9:51 ` Pavel Machek
2005-11-03 2:31 ` John Lenz
2005-11-07 23:30 ` Pavel Machek
2005-11-08 0:27 ` John Lenz
2005-11-08 9:28 ` Pavel Machek
2005-11-08 12:07 ` Richard Purdie
2005-11-08 13:14 ` Pavel Machek
2005-11-02 10:18 ` Paul Mundt
2005-11-02 20:26 ` Robert Schwebel
2005-11-02 21:13 ` Pavel Machek
2005-11-02 21:33 ` Robert Schwebel
2005-11-03 2:52 ` John Lenz
2005-11-03 6:21 ` Robert Schwebel
2005-11-03 8:15 ` Russell King
2005-11-03 9:57 ` Pavel Machek
2005-11-03 14:49 ` Russell King [this message]
2005-11-03 15:34 ` Vojtech Pavlik
2005-11-03 16:01 ` Russell King
2005-11-03 16:11 ` Vojtech Pavlik
2005-11-03 16:38 ` linux-os (Dick Johnson)
2005-11-03 16:35 ` Pavel Machek
2005-11-04 0:41 ` Stefan Smietanowski
2005-11-03 14:26 ` Rich Walker
2005-11-03 3:09 ` Rob Landley
2005-11-03 8:37 ` Geert Uytterhoeven
2005-11-03 9:59 ` Pavel Machek
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=20051103144904.GG28038@flint.arm.linux.org.uk \
--to=rmk+lkml@arm.linux.org.uk \
--cc=lenz@cs.wisc.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@suse.cz \
--cc=r.schwebel@pengutronix.de \
--cc=robert@schwebel.de \
--cc=rpurdie@rpsys.net \
--cc=vojtech@suse.cz \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.