Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver

[Pavel Machek <pavel@ucw.cz>]

[-- Attachment #1: Type: text/plain, Size: 3868 bytes --]

Hi!

> >And... LEDs are linear-enough as it is. That is not a problem. But RGB
> >does _not_ expect linear response. That's why colors are _way_ off currently.
> 
> Example what I was given was some LEDs are off for let's say 20% of PWM
> linearity and then there is non-linear curve for PWM value vs. intensity
> (this was in context of white LCD backlight).

Well, we'll do non-linear curve calibration if we have to. 

> As such I have nothing against adding support for HSL or other color space
> based brightness calculations. It might just need to be configurable what
> kind of mode is being used based on hardware solution in place. HSL seem to
> need a bit of fixed point math. Got floating point version working already
> but that does not work with kernel space so one needs to adapt it to fixed
> point.

First, we need _some_ kind of solution. Then we can decide kernel
vs. library. We can do floats in kernel too, if really required.

> One problem here is to figure out is if user configures some color -- is it
> configured with 100% brightness eg. Should one calculate RGB->HSL and then
> scale L with brightness and calculate RGB back for setting color -- or does
> it mean replacing L with brightness value?

I don't understand the question here.

> Additional problem is then if you have let's say yellow LED color element
> there. How would one scale that then? Linear is of course easy. If you need
> to configure this to some color space then how does one define the color in
> device tree so that such color space conversion is possible? One possible
> solution is to calibrate the curve (like what you do with LCD calibration)
> and then just assume brightness as linear brightness value in that
> case.

Calibrated curves would be nice...

For leds, you should be able to list the wavelength, right?

> Or if you have multi-color LED with red and green but no other color
> elements. How does brightness scaling work with this one?

I'd ignore that for now.

> >You say it is "rather slow" to change all 3 colors. How long does it
> >take, and how long do you need it to take?
> 
> Some times in embedded linux systems you can see "stalls" in operation of an
> application flow eg. time is spent in different places. I believe "slowest"
> CPU with embedded linux we are using is Atmel's AT91 series (ARM9) and
> executing code in there can at times be a bit time consuming.
> 
> I have seen delays like 18ms in TI's AM335x CPU series (Cortex-A8) and not
> even too high load situations (eg. breaking some serial protocols because of
> breaks in transmission in-between transfer without being a problem in
> application code as such). It is completely different story when there is a
> bit of load in system or some special situation in the kernel/OS.
> 
> Running high priority thread for configuring LEDs to avoid problems sounds
> like a wrong solution.
> 
> Co-worker of mine tried multi-color LED brightness sliding from user space
> with current PWM led driver and it was visible from eye that it was not
> timed smoothly.

Ok, 18msec is _way_ higher than sysfs overhead (like 400x?). If you
have slow i2c or something, then you'll get fun stuff, no matter what
the kernel<->user interface.

> For PWM controlled multi-color LEDs we don't yet have a solution. We need
> configurable color kernel based blinking.

> If we could figure out acceptable solution for color transition problem then
> I suppose all parties would be happy?

If you can get LEDs to display the colors in similar way monitors do,
that will be major step forward. Then we can design the rest, or maybe
ressurect the HSV patch.

									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]