Re: best way to handle LEDs

[Russell King <rmk+lkml@arm.linux.org.uk>]

On Thu, Nov 03, 2005 at 04:34:45PM +0100, Vojtech Pavlik wrote:
> On Thu, Nov 03, 2005 at 02:49:04PM +0000, Russell King wrote:
> > 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?
> 
> It usually doesn't support anything else. At least on the controllers
> I've seen the drivers for.

I think you misunderstand me.  Please read:

  http://dictionary.reference.com/search?q=busywait

Since the i2c transfer functions allow drivers to sleep (and some do)
you can't "just busywait" without modifying the i2c layer to tell
drivers to busy wait instead of sleeping.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/