From: Pavel Machek <pavel@ucw.cz>
To: Dan Murphy <dmurphy@ti.com>
Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>,
linux-leds@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, dachaac@gmail.com,
robh+dt@kernel.org
Subject: Re: RGB LED class Re: [PATCH v2 2/2] leds: lp50xx: Add the LP50XX family of the RGB LED driver
Date: Tue, 29 Jan 2019 00:03:51 +0100 [thread overview]
Message-ID: <20190128230351.GA5728@amd> (raw)
In-Reply-To: <b7ee7c2b-0878-962c-71ee-3ef281f6de0f@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2556 bytes --]
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
next prev parent reply other threads:[~2019-01-28 23:03 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-14 21:17 [PATCH v2 1/2] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers Dan Murphy
2019-01-14 21:17 ` [PATCH v2 2/2] leds: lp50xx: Add the LP50XX family of the RGB LED driver Dan Murphy
2019-01-15 21:47 ` Jacek Anaszewski
2019-01-15 22:22 ` Pavel Machek
2019-01-16 0:20 ` Dan Murphy
2019-01-16 10:55 ` Pavel Machek
2019-01-16 18:41 ` Dan Murphy
2019-01-16 22:04 ` Pavel Machek
2019-01-16 23:33 ` Dan Murphy
2019-01-17 10:06 ` Pavel Machek
2019-01-17 13:27 ` Dan Murphy
2019-01-17 21:10 ` Jacek Anaszewski
2019-01-18 0:02 ` RGB LED class " Pavel Machek
2019-01-18 15:57 ` Dan Murphy
2019-01-28 23:03 ` Pavel Machek [this message]
2019-01-18 22:13 ` Jacek Anaszewski
2019-01-19 21:36 ` Pavel Machek
2019-01-20 15:30 ` Jacek Anaszewski
2019-01-21 19:38 ` Jacek Anaszewski
2019-01-28 23:04 ` Pavel Machek
2019-01-18 13:45 ` Dan Murphy
2019-01-18 13:58 ` Dan Murphy
2019-01-20 6:42 ` Vesa Jääskeläinen
2019-01-22 21:39 ` Jacek Anaszewski
2019-01-22 22:44 ` Dan Murphy
2019-01-23 21:52 ` Jacek Anaszewski
2019-01-24 21:00 ` Dan Murphy
2019-01-24 21:55 ` Jacek Anaszewski
2019-01-29 13:56 ` Dan Murphy
2019-01-29 20:19 ` Jacek Anaszewski
2019-01-29 20:26 ` Dan Murphy
2019-01-29 21:45 ` Pavel Machek
2019-01-29 21:46 ` Dan Murphy
2019-01-29 21:53 ` Jacek Anaszewski
2019-01-20 15:32 ` Jacek Anaszewski
2019-01-17 21:08 ` Jacek Anaszewski
2019-01-19 19:11 ` Vesa Jääskeläinen
2019-01-19 21:46 ` Pavel Machek
2019-01-19 22:44 ` Vesa Jääskeläinen
2019-01-20 6:51 ` Vesa Jääskeläinen
2019-01-21 13:27 ` Dan Murphy
2019-01-21 15:12 ` Vesa Jääskeläinen
2019-01-24 20:32 ` Dan Murphy
2019-01-24 21:14 ` Jacek Anaszewski
2019-01-15 21:42 ` [PATCH v2 1/2] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers Jacek Anaszewski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190128230351.GA5728@amd \
--to=pavel@ucw.cz \
--cc=dachaac@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=dmurphy@ti.com \
--cc=jacek.anaszewski@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).