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.
Jean-Jacques Hiblot (2):
leds: of: create a child device if the LED node contains a
"compatible" string
devicetree: Update led binding
Tomi Valkeinen (2):
backlight: add led-backlight driver
devicetree: Add led-backlight binding
.../devicetree/bindings/leds/common.txt | 3 +
.../video/backlight/led-backlight.txt | 39 ++++
drivers/leds/led-class.c | 16 ++
drivers/video/backlight/Kconfig | 7 +
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/led_bl.c | 217 ++++++++++++++++++
include/linux/leds.h | 11 +
7 files changed, 294 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/backlight/led-backlight.txt
create mode 100644 drivers/video/backlight/led_bl.c
--
2.17.1
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?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
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?
I spent a little time thinking about that during the recent round of
reviews.
My rough thoughts were that LED triggers would be a good way to
handle it in the kernel code and would trivially solve a backlight
composed of multiple LED devices (since all could attach to the same
trigger). However I think it would be difficult to use the existing DT
bindings for triggers to express things like brightness curves and to
handle systems with multiple heads.
I'm not *too* worried about conflict with the existing backlight trigger
(which isn't actually a backlight... just a hook into the framebuffer
code to operate a binary LED). People like Daniel Vetter are
labouring diligently to get rid of the notifier it depends on so turning
it into a proper backlight device would probably help with that effort.
Anyhow... having thought the above I then shook myself a bit and
figured it was more important to focus on sane bindings that on what
the kernel does under the covers to realize them ;-) and decided to keep
quiet until the next set of bindings is proposed.
However... since you asked...
Daniel.
On 05/07/2019 12:14, Pavel Machek wrote:
> On Mon 2019-07-01 17:14:19, Jean-Jacques Hiblot wrote:
>>
>> 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?
I don't know how this would fit in the model where multiple panels are
used, each with its own backlight.
Also the notification is only about blanking.
> Pavel
>
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