[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8bc77441-eb22-8748-b00b-59d403794c24@ti.com>
Date: Thu, 20 Dec 2018 08:03:29 -0600
From: Dan Murphy <dmurphy@...com>
To: Pavel Machek <pavel@....cz>
CC: <jacek.anaszewski@...il.com>, <linux-leds@...r.kernel.org>,
kernel list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver
On 12/20/2018 03:06 AM, Pavel Machek wrote:
> Hi!
>
>>> Anyway, if your 36 channels can be set independently, I believe you
>>> just want them to export as 36 LEDs.
>>
>> I am not sure that is what the "customers" would want to have to set 36 different nodes or even declare those 36 nodes.
>> That is 36 independent user space to kernel space calls that are very expensive just to set a LED color and brightness.
>>
>
> No, 36 independend calls to kernel space are not that expensive.
But they are time consuming.
Also note that even if I set the OUTX color mix register the LEDX brightness register controls the output intensity.
So if the brightness is 0x0 and the Mix register is 0xff then the LED is still off.
I am sticking with the driver as is. I think this is a better representation of the part and its capability then presenting x number of
sysfs nodes that will have no affect on the LED if set until the corresponding brightness register is not set properly.
This will also keep the device tree entries down to a minimum. The LEDx brightness register actually
controls the output and there are only 7 of these.
Dan
>
> Pavel
>
--
------------------
Dan Murphy
Powered by blists - more mailing lists