[lkml]   [2018]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver
Hi All,

On 19/12/2018 23.50, Dan Murphy wrote:
> On 12/19/2018 03:36 PM, Jacek Anaszewski wrote:
>> Hi Dan and Pavel,
>> Some time ago we had discussion with Vesa Jääskeläinen about possible
>> approaches to RGB LEDs [0]. What seemed to be the most suitable
>> variation of the discussed out-of-tree approach was the "color" property
>> and array of color triplets defined in Device Tree per each color.
> Why does Device tree define the color?
> Rob indicated that Device tree is supposed to define the hardware.
> This thread seems to be defining the operation.
> Shouldn't the color be done via user space and not dt?
> Especially if they want to change the color real time?
> Dan
>> Please refer to [0] for the details.
>> [0]

Idea was to define preset colors in device tree as an example when you
are dealing with multi-color LEDs without PWM. In that case you only
have GPIOs to control and then have a problem what does those GPIO's mean.

With preset definitions one can use color names to act as a shortcut to
configure GPIO's to proper state for that particular color.

For more flexible setups where you have PWM or such control you have
larger space of available colors. In this case you need to somehow
define also meaning of those controls.

Also we may not have LED with only red, green and blue elements. There
might in example be amber, ultraviolet, white elements.

This is where device tree is concerned. It helps us craft the logical
definition for LED so that we can control it from user space in common way.

Now the next problem then is how does user space work then.

For multi-color LEDs it it important to change the color atomically so
that no wrong colors are being shown as user space got interrupted when
controlling it.

Also we have brightness setting that would be useful for PWM controlled

Setting color is easy when you use preset names then you only need to
deal with brightness value (eg. RGB -> HSV * brightness -> RGB). Of
course here additional problem is other color elements are they then
scaled according to brightness value?.

Setting color as "raw" values is then next problem. In order to do it
atomically it needs to be one atomic activation and could be eg. one
write to "color" sysfs entry with combination of all color elements and
perhaps additionally also brightness value. Next question is then what
is the format for such entry then? What are the value ranges? In here we
can utilize device tree definition to help define what kind of LED we do
have and what kind of capabilities it does have.

Additional problem risen also in discussion was non-linearity of some
control mechanisms vs. perceived color. So there might be a need for
curve mapping similarly what is with backlight control and that would be
defined either in device tree and possibly in user space if there is a
need for that. I suppose golden curve definition in device tree should
be good enough.

Then there was additional discussion about possible animation support
but I would leave that for future design as that would then be utilizing
the same framework.

I suppose color space handling and that kind of stuff should be in some
led core functionality and then raw control should be part of physical
led driver.

I was planning to play with it during holiday season but lets see how it
goes. Feel free to also experiment with the idea.

Vesa Jääskeläinen

 \ /
  Last update: 2018-12-20 13:42    [W:0.189 / U:25.660 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site