linux-kernel - Re: RGB LED class Re: [PATCH v2 2/2] leds: lp50xx: Add the LP50XX family of the RGB LED driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190128230351.GA5728@amd>
Date:   Tue, 29 Jan 2019 00:03:51 +0100
From:   Pavel Machek <pavel@....cz>
To:     Dan Murphy <dmurphy@...com>
Cc:     Jacek Anaszewski <jacek.anaszewski@...il.com>,
        linux-leds@...r.kernel.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, dachaac@...il.com, robh+dt@...nel.org
Subject: Re: RGB LED class Re: [PATCH v2 2/2] leds: lp50xx: Add the LP50XX
 family of the RGB LED driver

Hi!

> > First, I think we want to decide if RGB LED should be presented as
> > 3 LEDs or as 1 LED... and what to do with existing RGB leds being
> > presented as 3 LEDs.
> 
> What do we do with RGBW drivers?  Like the LP5562.  RGB can be grouped as a single
> LED but does the white LED get grouped too or should it register as a new LED?
> 
> I am assuming the answer is that it would register as a new LED.

We could extend this to more than three channels, and specify "color"
for each channel. We could probably specify wavelength for
monochromatic LEDs and color temperature for white LEDs....

> >     pwm_channels -- "1000 240 300" -- "red part should be full on, green
> >     should be pwm controlled to 240/1000, blue should be 300/1000"
> > 
> 
> Why 1000?  Why not based on a duty cycle percentage and let the LED driver figure out
> what that means to the device?
> 
> pwm_channels -- "100 24 30" -- red part is full on 100%, green is 24% duty cycle and
> blue is 30% duty cycle.

Percentage would work, too. Having base of 1000 (not 100) gives a bit
more precision.

> >     pwm_white -- "1000 500 400" -- tells userspace what to write to PWM
> >     channels to get approximately white color.
> > 
> 
> Same as above on the duty cycle.
> 
> But I still am in disagreement with the kernel detailing what is white or how to
> achieve white.
> 
> Based on my earlier email about light pipes and the LED vendors and aging I think product
> developers will need to fine tune what is "white" on their product from user space or even a DT node.
>

Yes, this needs to be in the DT and kernel needs to expose it to
userspace in sysfs.

> >     This would assume that RGB LEDs are always pwm controlled. That
> >     seems to be true for hardware I seen.
> > 
> 
> GPIO LEDs can be binary or use PWM depending on what is needed.
> 
> >     + no complex math in kernel
> 
> We can eliminate the math if we use the "color" file that was proposed and pass in absolute
> hex/decimal numbers for color.

No you can't.

> >     + userspace knows enough to display arbitrary colors
> > 
> >     + userspace can use full range of available PWM intensities
> > 
> 
> Do we need a pwm_max file to indicate to the user space what the max values of the pwm
> is for each color?

Maybe. I'd assume brightness_max would be equal to max pwm.

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

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)