Messages in this thread | | | Date | Fri, 5 Jul 2019 11:29:59 +0100 | From | Daniel Thompson <> | Subject | Re: [PATCH 0/4] Add a generic driver for LED-based backlight |
| |
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.
| |