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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
