[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190705232312.uxh7rlin6r6jwn3e@earth.universe>
Date: Sat, 6 Jul 2019 01:23:12 +0200
From: Sebastian Reichel <sre@...nel.org>
To: Pavel Machek <pavel@....cz>
Cc: Jean-Jacques Hiblot <jjhiblot@...com>, mark.rutland@....com,
daniel.thompson@...aro.org, jingoohan1@...il.com,
tomi.valkeinen@...com, linux-kernel@...r.kernel.org,
dri-devel@...ts.freedesktop.org, robh+dt@...nel.org,
jacek.anaszewski@...il.com, lee.jones@...aro.org,
linux-leds@...r.kernel.org, dmurphy@...com
Subject: Re: [PATCH 0/4] Add a generic driver for LED-based backlight
Hi,
On Fri, Jul 05, 2019 at 12:14:34PM +0200, Pavel Machek wrote:
> On Mon 2019-07-01 17:14:19, Jean-Jacques Hiblot wrote:
> > This series aims to add a led-backlight driver, similar to pwm-backlight,
> > but using a LED class device underneath.
> >
> > A few years ago (2015), Tomi Valkeinen posted a series implementing a
> > backlight driver on top of a LED device:
> > https://patchwork.kernel.org/patch/7293991/
> > https://patchwork.kernel.org/patch/7294001/
> > https://patchwork.kernel.org/patch/7293981/
> >
> > The discussion stopped because Tomi lacked the time to work on it.
> >
> > This series takes it from there and implements the binding that was
> > discussed in https://patchwork.kernel.org/patch/7293991/. In this new
> > binding the backlight device is a child of the LED controller instead of
> > being another platform device that uses a phandle to reference a LED.
>
> Other option would be to have backlight trigger. What are
> advantages/disadvantages relative to that?
One advantage of having something like this is the possibility to
reference the backlight in DT. This means the system has an idea
how backlights are mapped. E.g.:
panelA {
compatible = "random-panel";
backlight = <&backlight1>;
}
panelB {
compatible = "random-panel";
backlight = <&backlight2>;
}
-- Sebastian
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists