Hi,
On Tue, Apr 03, 2018 at 12:49:08PM +0200, Pavel Machek wrote:
> > +enum ti_lmu_bl_type {
> > + TI_LMU_BL, /* backlight userspace interface */
> > + TI_LMU_LED, /* led userspace interface */
> > +};
> ...
> > +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.
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.
-- Sebastian
Attachment:
signature.asc
Description: PGP signature
