On Mon, 2008-10-06 at 09:33 -0700, David Brownell wrote: > This would seem like a good motivation to add some features > to the LED framework. Here are three types of LED that it > doesn't support well today: > > - Bicolor leds with two leads ... R-or-G, two wires, > opposite diode directions. > > - Bicolor LEDs with three leads ... like R-and-Y, three > wires, common anode or common cathode > > - RGB leds, four leads ... like R-and-G-and-B, etc > > Except for the first case, these can be stuffed into the > framework by modeling them as multiple LEDs. But when you > do that it gets awkward to make sure that for example you > get a purple (+R, -G, +B) blink, since the timers need to > be exactly in phase. Or to combine blinking with PWM, so > you could for example mix in a little green... > > Surely some features that would support RGB (RG, YG, etc) > LEDs better could support both fancy (lp5521) and simple > (GPIO without PWM) implementations ... The question is how and what you add to the class to support these types. It could be as simple as some more obvious naming conventionto associate LEDs and a way of sharing triggers amongst LEDs I guess... Cheers, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
