Op 25 nov 2008, om 22:26 heeft David Brownell het volgende geschreven:
On Tuesday 25 November 2008, Koen Kooi wrote:Op 25 nov 2008, om 21:06 heeft David Brownell het volgende geschreven:On Tuesday 25 November 2008, Koen Kooi wrote:How about a standard LED driver (optionally with a brightness control) and the newish "backlight" trigger?Does the backlight trigger hook into the backlight class?It doesn't seem to call backlight_device_register(), though I don't know why not. It just looks like it hooks into the same notification events the backlight class does.Re "why not" ... partial answer: because it doesn't have a way to associate itself with the panel whose backlight it's supplying. Seems like that should be solvable.
Most userspace doesn't support more than one panel, it takes the first entry that has a 'brightness' node. Fragile, but valid for almost all current devices. Things like the BUG with an option for 2 LCD panels will break that assumption, but lets cross that bridge when we get there.
If you think that's trouble, it would probably be a good thing to bring that up with the author of that new trigger code (drivers/leds/ledtrig-backlight.c) ... it's very new, and I'd expect such userspace interface goofs still ought to be fixable.Our mails on this subject crossed eachother :) Short recap: the backlight trigger is usefull for turnign on/off e.g. status leds at the same the the backlight goes on/off, but shouldn't be (ab)used for backlight control.That's not what its Kconfig description says. So I think that if you care about this, you should raise the issue with someone more involved.
From a conversation earlier tonight: Koen: Maybe the doc entry of the triggers needs a warning :)Richard Purdie: Yes, we probably need to try and stop this before it starts...
So the led tree will warn against improper use of the backlight trigger soon :)
regards, Koen
Mark Brown in that thread [1] does raise an interesting use-case,i.e [2] ... a simpler situation than we have with TWL4030, where we have LED signals supporting - real LEDs * simple leds that don't really need PWM brightness controls: Beagle LEDB == pmu_stat * backlights which probably *do* want PWM controls: on those two EVMs, LEDA == backlight, using more of its peak 160 mA current draw - general GPIO usage, where PWM capability "must not" kick in: Beagle LEDA == nEN_USB_PWR His comment focussed on the two "real LEDs" cases.since we are in the same boat. A solution is needed, but I guess the wolfson people can work it out :)Or maybe the Pandora people. ;) If they're using the LEDA or LEDB PWMs, providing and exporting a brightness control would be easy. If they're using the other two PWMs, it'd be more work. - Dave[1] http://linux.derkeiler.com/Mailing-Lists/Kernel/2008-10/threads.html#02359[2] http://linux.derkeiler.com/Mailing-Lists/Kernel/2008-10/msg02610.html --To unsubscribe from this list: send the line "unsubscribe linux- omap" inthe body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
Attachment:
PGP.sig
Description: This is a digitally signed message part
