LEDs support for collie
RFC PATCH 1/1 LEDs support for collie
This adds support for controlling LEDs on sharp zaurus sl-5500. It may look a little bit complex, but it probably needs to be complex -- blinking is pretty much mandatory when you only have two leds, and we want to support charging led (controlled by kernel).
From: John Lenz <[email protected]>
drivers/Kconfig +2 -0
@@ -54,6 +54,8 @@ source "drivers/mfd/Kconfig" source "drivers/media/Kconfig" +source "drivers/leds/Kconfig" + source "drivers/video/Kconfig" source "sound/Kconfig"
drivers/Makefile +1 -0
@@ -67,3 +67,4 @@ obj-$(CONFIG_INFINIBAND) += infiniband/ obj-$(CONFIG_SGI_IOC4) += sn/ obj-y += firmware/ obj-$(CONFIG_CRYPTO) += crypto/ +obj-$(CONFIG_CLASS_LEDS) += leds/
drivers/leds/Kconfig new file +20 -0
@@ -0,0 +1,20 @@ + +menu "LED devices" + +config CLASS_LEDS + tristate "LED support" + depends on EXPERIMENTAL + help + This option provides the generic support for the leds class. + LEDs can be accessed from /sys/class/leds. It will also allow you + to select individual drivers for LED devices. If unsure, say N. + +config LEDS_LOCOMO + tristate "LED Support for Locomo device" + depends CLASS_LEDS && SHARP_LOCOMO + help + This option enables support for the LEDs on Sharp Locomo. + Zaurus models SL-5500 and SL-5600. + +endmenu +
drivers/leds/Makefile new file +4 -0
@@ -0,0 +1,4 @@ + +# Core functionality. +obj-$(CONFIG_CLASS_LEDS) += ledscore.o +obj-$(CONFIG_LEDS_LOCOMO) += locomo.o
drivers/leds/ledscore.c new file +460 -0
460 lines not on this page · raw message
drivers/leds/locomo.c new file +124 -0
124 lines not on this page · raw message
new file mode 100644
include/linux/leds.h new file +63 -0
63 lines not on this page · raw message
Signature · 1 line
Thanks, Sharp!
Quoted 4 lines · Pavel Machek
This adds support for controlling LEDs on sharp zaurus sl-5500. It may look a little bit complex, but it probably needs to be complex -- blinking is pretty much mandatory when you only have two leds, and we want to support charging led (controlled by kernel).
Isn't "blinking" a kind of policy, as is brightness (== duty cycle of a high speed toggling)? What if someone wants synchronised toggling?
I still think anything over a very simple interface being exported to userspace is completely overkill and completely bloated. Hell, I got laughed at for creating an abstracted LEDs interface in the first place because many thought the current version was far too bloated.
I _know_ people have issues with the current interface, whinging that "it only exports the colour" but that's something which is actually very trivially solvable and therefore _not_ a major problem to solve.
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core
Hi!
Quoted 5 lines
Quoted 4 lines
This adds support for controlling LEDs on sharp zaurus sl-5500. It may look a little bit complex, but it probably needs to be complex -- blinking is pretty much mandatory when you only have two leds, and we want to support charging led (controlled by kernel).
Quoted 7 lines
Isn't "blinking" a kind of policy, as is brightness (== duty cycle of a high speed toggling)? What if someone wants synchronised toggling?
I still think anything over a very simple interface being exported to userspace is completely overkill and completely bloated. Hell, I got laughed at for creating an abstracted LEDs interface in the first place because many thought the current version was far too bloated.
Well, waking userspace for every blink is going to be expensive, power-wise. Plus we really need the blinking in kernel -- to communicate charger error to user.
Quoted 3 lines
I _know_ people have issues with the current interface, whinging that "it only exports the colour" but that's something which is actually very trivially solvable and therefore _not_ a major problem to solve.
Where's the current interface? I'll be happy to plug collie into that one...
Pavel
Signature · 1 line
Thanks, Sharp!
Quoted 6 lines · Russell King
Quoted 4 lines · Pavel Machek
This adds support for controlling LEDs on sharp zaurus sl-5500. It may look a little bit complex, but it probably needs to be complex -- blinking is pretty much mandatory when you only have two leds, and we want to support charging led (controlled by kernel).
Quoted 7 lines
Isn't "blinking" a kind of policy, as is brightness (== duty cycle of a high speed toggling)? What if someone wants synchronised toggling?
I still think anything over a very simple interface being exported to userspace is completely overkill and completely bloated. Hell, I got laughed at for creating an abstracted LEDs interface in the first place because many thought the current version was far too bloated.
I can strip out the timer stuff.... without the frequency stuff the patch is an interface that allows userspace and other kernel code to adjust the color and brightness of leds.
Then Richard can implement his triggers code, which uses the exported in-kernel api for controlling leds. That triggers code can do whatever, including blink the led on a frequency. (And the discussion of the triggers stuff can continue unrelated to this basic led framework).
Now that I think about it more, the frequency stuff should really be ripped out of the led code and put somewhere else (like either userspace or some other triggers code).
Quoted 5 lines
I _know_ people have issues with the current interface, whinging that "it only exports the colour" but that's something which is actually very trivially solvable and therefore _not_ a major problem to solve.
I believe it is already solved this using my patch ignoring the frequency....
John