Hi!

quoted

quoted

+static int ti_lmu_bl_add_device(struct ti_lmu_bank *lmu_bank)
+{
+	switch (lmu_bank->type) {
+	case TI_LMU_BL:
+		return ti_lmu_bl_register_backlight(lmu_bank);
+	case TI_LMU_LED:
+		return ti_lmu_bl_register_led(lmu_bank);
+	default:
+		return -EINVAL;
+	}
+}

Ok, this is somehow unusual/crazy. Single driver with two
interfaces.

Do we need the LED interface for something?

If yes, I believe reasonable solution would be to always provide LED
interface, and then have "backlight-trigger" which that would provide
backlight interface for arbitrary LED.

Userspace expects keyboard backlight to be exposed via the LED
subsystem and display backlight via the backlight subsystem.

Ok.

I considered always exposing the banks via the LED subsystem and
using a generic backlight driver. That brings its own problems,
since there is a dependency between the display and the backlight.
This is described in DT using a phandle. Getting the right backlight
device from the phandle will become very tricky with this approach.

I believe we have to do this.

Virtually any LED can be used as a backlight, and we don't really want
to add two personalities to all the LED drivers.

And it should not be too bad: LED will just have default trigger,
which will say this LED corresponds to this display device. I believe
someone wanted to do that for USB/ethernet activity.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html