| Message ID | 20190701151423.30768-1-jjhiblot@ti.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add a generic driver for LED-based backlight | expand |
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
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
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