[RESEND,v17,00/17] Multi Color LED Framework
mbox series

Message ID 20200127150032.31350-1-dmurphy@ti.com
Headers show
Series
  • Multi Color LED Framework
Related show

Message

Dan Murphy Jan. 27, 2020, 3 p.m. UTC
Hello

This is a re-send of the v17 multi color LED framework.  I removed the last
patch from the series.  In addition I rebased this series on Pavel's for-next
LED branch and added all ACKs from the list.

Dan

Dan Murphy (17):
  dt-bindings: leds: Add multicolor ID to the color ID list
  leds: Add multicolor ID to the color ID list
  leds: multicolor: Introduce a multicolor class definition
  dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers
  leds: lp50xx: Add the LP50XX family of the RGB LED driver
  dt: bindings: lp55xx: Be consistent in the document with LED acronym
  dt: bindings: lp55xx: Update binding for Multicolor Framework
  ARM: dts: n900: Add reg property to the LP5523 channel node
  ARM: dts: imx6dl-yapp4: Add reg property to the lp5562 channel node
  ARM: dts: ste-href: Add reg property to the LP5521 channel nodes
  leds: lp55xx: Convert LED class registration to devm_*
  leds: lp55xx: Add multicolor framework support to lp55xx
  leds: lp5523: Update the lp5523 code to add multicolor brightness
    function
  leds: lp5521: Add multicolor framework multicolor brightness support
  leds: lp55xx: Fix checkpatch file permissions issues
  leds: lp5523: Fix checkpatch issues in the code
  dt: bindings: Update lp55xx binding to recommended LED naming

 .../ABI/testing/sysfs-class-led-multicolor    |  36 +
 .../devicetree/bindings/leds/leds-lp50xx.txt  | 148 ++++
 .../devicetree/bindings/leds/leds-lp55xx.txt  | 163 +++-
 Documentation/leds/index.rst                  |   1 +
 Documentation/leds/leds-class-multicolor.rst  | 100 +++
 arch/arm/boot/dts/imx6dl-yapp4-common.dtsi    |  14 +-
 arch/arm/boot/dts/omap3-n900.dts              |  29 +-
 arch/arm/boot/dts/ste-href.dtsi               |  22 +-
 drivers/leds/Kconfig                          |  22 +
 drivers/leds/Makefile                         |   2 +
 drivers/leds/led-class-multicolor.c           | 272 ++++++
 drivers/leds/led-core.c                       |   1 +
 drivers/leds/leds-lp50xx.c                    | 799 ++++++++++++++++++
 drivers/leds/leds-lp5521.c                    |  43 +-
 drivers/leds/leds-lp5523.c                    |  62 +-
 drivers/leds/leds-lp5562.c                    |  22 +-
 drivers/leds/leds-lp55xx-common.c             | 235 ++++--
 drivers/leds/leds-lp55xx-common.h             |  14 +-
 drivers/leds/leds-lp8501.c                    |  23 +-
 include/dt-bindings/leds/common.h             |   3 +-
 include/linux/led-class-multicolor.h          | 139 +++
 include/linux/platform_data/leds-lp55xx.h     |   8 +
 22 files changed, 1998 insertions(+), 160 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-class-led-multicolor
 create mode 100644 Documentation/devicetree/bindings/leds/leds-lp50xx.txt
 create mode 100644 Documentation/leds/leds-class-multicolor.rst
 create mode 100644 drivers/leds/led-class-multicolor.c
 create mode 100644 drivers/leds/leds-lp50xx.c
 create mode 100644 include/linux/led-class-multicolor.h

Comments

Dan Murphy Feb. 12, 2020, 1:09 p.m. UTC | #1
Hello

On 1/27/20 9:00 AM, Dan Murphy wrote:
> Hello
>
> This is a re-send of the v17 multi color LED framework.  I removed the last
> patch from the series.  In addition I rebased this series on Pavel's for-next
> LED branch and added all ACKs from the list.
>
> Dan
>
> Dan Murphy (17):
>    dt-bindings: leds: Add multicolor ID to the color ID list
>    leds: Add multicolor ID to the color ID list
>    leds: multicolor: Introduce a multicolor class definition
>    dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers
>    leds: lp50xx: Add the LP50XX family of the RGB LED driver
>    dt: bindings: lp55xx: Be consistent in the document with LED acronym
>    dt: bindings: lp55xx: Update binding for Multicolor Framework
>    ARM: dts: n900: Add reg property to the LP5523 channel node
>    ARM: dts: imx6dl-yapp4: Add reg property to the lp5562 channel node
>    ARM: dts: ste-href: Add reg property to the LP5521 channel nodes
>    leds: lp55xx: Convert LED class registration to devm_*
>    leds: lp55xx: Add multicolor framework support to lp55xx
>    leds: lp5523: Update the lp5523 code to add multicolor brightness
>      function
>    leds: lp5521: Add multicolor framework multicolor brightness support
>    leds: lp55xx: Fix checkpatch file permissions issues
>    leds: lp5523: Fix checkpatch issues in the code
>    dt: bindings: Update lp55xx binding to recommended LED naming

I have no open comments on this patchset except for a DT change 
requested by Shawn Gao but this change should wait till after this 
patchset is merged.

Is there something holding this up?

Dan
Pavel Machek Feb. 25, 2020, 10:19 a.m. UTC | #2
Hi!

> >   leds: lp5521: Add multicolor framework multicolor brightness support
> >   leds: lp55xx: Fix checkpatch file permissions issues
> >   leds: lp5523: Fix checkpatch issues in the code
> >   dt: bindings: Update lp55xx binding to recommended LED naming
> 
> I have no open comments on this patchset except for a DT change requested by
> Shawn Gao but this change should wait till after this patchset is merged.
> 
> Is there something holding this up?

Yes... my time; sorry about that.

The fact that it changes API makes it important to get it right, and
hard/impossible to fix it once it is merged... and I don't think this
is the right interface (sorry).

In particular, I don't think having directory per channel is a good
idea. It makes atomic updates impossible (minor), but will also
increase memory consuption (to a point where led-per-channel might
be cheaper), and will make userspace do 3x ammount of syscalls in the
common case.

And we can do better; sysfs files with arrays are okay. So I'd like to
see

channel_intensity (file containing array of u32's)

channel_names (usually containing "red green blue")

(I'm not sure if max_intensity is good idea; i believe we could simply
fix it to UINT32_MAX without bad effects).

And yes, I realize I should have spoken up sooner / more
forcefully. Sorry again.

Best regards,

									Pavel
Jacek Anaszewski Feb. 25, 2020, 10:17 p.m. UTC | #3
On 2/25/20 11:19 AM, Pavel Machek wrote:
> Hi!
> 
>>>   leds: lp5521: Add multicolor framework multicolor brightness support
>>>   leds: lp55xx: Fix checkpatch file permissions issues
>>>   leds: lp5523: Fix checkpatch issues in the code
>>>   dt: bindings: Update lp55xx binding to recommended LED naming
>>
>> I have no open comments on this patchset except for a DT change requested by
>> Shawn Gao but this change should wait till after this patchset is merged.
>>
>> Is there something holding this up?
> 
> Yes... my time; sorry about that.
> 
> The fact that it changes API makes it important to get it right, and
> hard/impossible to fix it once it is merged... and I don't think this
> is the right interface (sorry).
> 
> In particular, I don't think having directory per channel is a good
> idea. It makes atomic updates impossible (minor), 

It is possible via brightness file, although it will need first writing
intensity files, which only will cache colors, and actual write to hw
occurs on write to brightness file. This has been discussed dozen of
times throughout last year, and you even proposed the formula for
calculating per-color-subled brightness basing on global brightness and
intensity set for each color.

> but will also
> increase memory consuption (to a point where led-per-channel might
> be cheaper), and will make userspace do 3x ammount of syscalls in the
> common case.
> 
> And we can do better; sysfs files with arrays are okay. So I'd like to
> see

Let's first achieve broader consensus on this statement before we
move forward with such design. Sysfs maintainer seems to be the best
person to consult at first.

> channel_intensity (file containing array of u32's)
> 
> channel_names (usually containing "red green blue")

> (I'm not sure if max_intensity is good idea; i believe we could simply
> fix it to UINT32_MAX without bad effects).
> 
> And yes, I realize I should have spoken up sooner / more
> forcefully. Sorry again.
Dan Murphy Feb. 25, 2020, 10:44 p.m. UTC | #4
Hello

On 2/25/20 4:17 PM, Jacek Anaszewski wrote:
> On 2/25/20 11:19 AM, Pavel Machek wrote:
>> Hi!
>>
>>>>    leds: lp5521: Add multicolor framework multicolor brightness support
>>>>    leds: lp55xx: Fix checkpatch file permissions issues
>>>>    leds: lp5523: Fix checkpatch issues in the code
>>>>    dt: bindings: Update lp55xx binding to recommended LED naming
>>> I have no open comments on this patchset except for a DT change requested by
>>> Shawn Gao but this change should wait till after this patchset is merged.
>>>
>>> Is there something holding this up?
>> Yes... my time; sorry about that.
>>
>> The fact that it changes API makes it important to get it right, and
>> hard/impossible to fix it once it is merged... and I don't think this
>> is the right interface (sorry).
>>
>> In particular, I don't think having directory per channel is a good
>> idea. It makes atomic updates impossible (minor),
> It is possible via brightness file, although it will need first writing
> intensity files, which only will cache colors, and actual write to hw
> occurs on write to brightness file. This has been discussed dozen of
> times throughout last year, and you even proposed the formula for
> calculating per-color-subled brightness basing on global brightness and
> intensity set for each color.

I actually just got your reply Pavel.  Unfortunately I don't have the 
band width to spin any more major framework changes and as you know this 
has been discussed over and over and over again with multiple iterations 
and multiple designs.

I still don't agree with some nebulous unbound array being passed into 
the driver via sysfs. As we have discussed at length in the past this 
implementation is just as bad if not worse then what I am proposing. I 
also have provided that particular array implementation and it failed to 
get any ACKs as it violated sysfs rules and was wrought with corner 
cases and mismatches of color to intensity values.  And calling the 
sysfs node channel_intensity and channel_names is not correct this is a 
LP55xx naming convention and should not be applied.

But as Jacek indicated lets have the sysfs maintainer provide the 
consultation on the array implementation again.

And as I have stated above my time has run out on trying to get this 
framework completed so I will just re-write the lp50xx driver against 
the standard LED class implementation and abandon any hope of actually 
improving the LED subsystem for multi color ICs.  As I don't have 
another year or two to debate this interface again and try to implement 
the code just for it to get another NACK in the end and having to 
rewrite the framework again.

Dan
Pavel Machek Feb. 26, 2020, 12:59 p.m. UTC | #5
Hi!

> > The fact that it changes API makes it important to get it right, and
> > hard/impossible to fix it once it is merged... and I don't think this
> > is the right interface (sorry).
> > 
> > In particular, I don't think having directory per channel is a good
> > idea. It makes atomic updates impossible (minor), 
> 
> It is possible via brightness file, although it will need first writing
> intensity files, which only will cache colors, and actual write to hw
> occurs on write to brightness file. This has been discussed dozen of
> times throughout last year, and you even proposed the formula for
> calculating per-color-subled brightness basing on global brightness and
> intensity set for each color.

You are right, it is possible to make updates atomic with right kind
of latching (which is quite confusing).

> > but will also
> > increase memory consuption (to a point where led-per-channel might
> > be cheaper), and will make userspace do 3x ammount of syscalls in the
> > common case.
> > 
> > And we can do better; sysfs files with arrays are okay. So I'd like to
> > see
> 
> Let's first achieve broader consensus on this statement before we
> move forward with such design. Sysfs maintainer seems to be the best
> person to consult at first.

This is actually documented:

Documentation/filesystems/sysfs.txt

<quote>
Attributes should be ASCII text files, preferably with only one value
per file. It is noted that it may not be efficient to contain only one
value per file, so it is socially acceptable to express an array of
values of the same type.

Mixing types, expressing multiple lines of data, and doing fancy
formatting of data is heavily frowned upon. Doing these things may get
you publicly humiliated and your code rewritten without notice.
</quote>

Best regards,
									Pavel
Jacek Anaszewski Feb. 26, 2020, 8:45 p.m. UTC | #6
Hi Greg,

We have here long lasting discussion related to LED multicolor class
sysfs interface design. We went through several iterations and worked
out the solution with individual file per each color sub-LED in the
color directory as shown below:

/sys/class/leds/<led>/colors/<color>_intensity

This is in line with one-value-per-file sysfs rule, that is being
frequently highlighted, and we even had not so long ago a patch
for led cpu trigger solving the problem caused by this rule not
being adhered to.

Now we have the voice below bringing to attention another caveat
from sysfs documentation:

"it is socially acceptable to express an array of values of the same
type"

and proposing the interface in the form of two files:

channel_intensity (file containing array of u32's)
channel_names (usually containing "red green blue")

In order to have this clarified once and for all, could you please
provide us with guidance on whether the fragment from
Documentation/filesystems/sysfs.txt is still in force and we
can benefit from it for LED multicolor framework, or not and then
it should be removed from the doc then?

Best regards,
Jacek Anaszewski

On 2/26/20 1:59 PM, Pavel Machek wrote:
> Hi!
> 
>>> The fact that it changes API makes it important to get it right, and
>>> hard/impossible to fix it once it is merged... and I don't think this
>>> is the right interface (sorry).
>>>
>>> In particular, I don't think having directory per channel is a good
>>> idea. It makes atomic updates impossible (minor), 
>>
>> It is possible via brightness file, although it will need first writing
>> intensity files, which only will cache colors, and actual write to hw
>> occurs on write to brightness file. This has been discussed dozen of
>> times throughout last year, and you even proposed the formula for
>> calculating per-color-subled brightness basing on global brightness and
>> intensity set for each color.
> 
> You are right, it is possible to make updates atomic with right kind
> of latching (which is quite confusing).
> 
>>> but will also
>>> increase memory consuption (to a point where led-per-channel might
>>> be cheaper), and will make userspace do 3x ammount of syscalls in the
>>> common case.
>>>
>>> And we can do better; sysfs files with arrays are okay. So I'd like to
>>> see
>>
>> Let's first achieve broader consensus on this statement before we
>> move forward with such design. Sysfs maintainer seems to be the best
>> person to consult at first.
> 
> This is actually documented:
> 
> Documentation/filesystems/sysfs.txt
> 
> <quote>
> Attributes should be ASCII text files, preferably with only one value
> per file. It is noted that it may not be efficient to contain only one
> value per file, so it is socially acceptable to express an array of
> values of the same type.
> 
> Mixing types, expressing multiple lines of data, and doing fancy
> formatting of data is heavily frowned upon. Doing these things may get
> you publicly humiliated and your code rewritten without notice.
> </quote>
> 
> Best regards,
> 									Pavel
>
Dan Murphy Feb. 26, 2020, 10:10 p.m. UTC | #7
Hello

On 2/26/20 2:45 PM, Jacek Anaszewski wrote:
> Hi Greg,
>
> We have here long lasting discussion related to LED multicolor class
> sysfs interface design. We went through several iterations and worked
> out the solution with individual file per each color sub-LED in the
> color directory as shown below:
>
> /sys/class/leds/<led>/colors/<color>_intensity
>
> This is in line with one-value-per-file sysfs rule, that is being
> frequently highlighted, and we even had not so long ago a patch
> for led cpu trigger solving the problem caused by this rule not
> being adhered to.
>
> Now we have the voice below bringing to attention another caveat
> from sysfs documentation:
>
> "it is socially acceptable to express an array of values of the same
> type"
>
> and proposing the interface in the form of two files:
>
> channel_intensity (file containing array of u32's)
> channel_names (usually containing "red green blue")
>
> In order to have this clarified once and for all, could you please
> provide us with guidance on whether the fragment from
> Documentation/filesystems/sysfs.txt is still in force and we
> can benefit from it for LED multicolor framework, or not and then
> it should be removed from the doc then?

I spent some time trying to find the conversation on the array 
implementation for the multi color framework.

It is buried here

https://lore.kernel.org/patchwork/patch/1026515/

The response from GKH on array's was sited in the above here:

https://www.spinics.net/lists/devicetree/msg69730.html

Repeating my objections to using arrays.

Would this array of colors be fixed?  Well the answer is it would be 
fixed per DT entries.  So if a user populates 10 LEDs for color then we 
will have 10 entries in the array.  Another DT entry may only have 3.  
So the array size is variable but bounded for now assuming no additional 
colors are added.

Another issue with this implementation is we expect channel_names and 
channel_intensity arrays to be aligned.  Two different arrays need to 
line up so that each element value in channel_intensity matches the 
color in the channel_name.   This can be very easily mixed up in the 
HLOS if the proper array tracking is not done. Can we guarantee that the 
values we are getting are for the LED they are targeted for?

Would this array be bounded?  Bounded yes by the number of supported 
color IDs we have defined in the LED file.  But the size of the array is 
completely variable from device to device

Specific LEDs cannot be updated without re-sending the whole array.  If 
the user would like to change just 1 color and it is the nth position 
(possibly 10th from above) then all color intensities need to be 
passed.  There would be no way to say I want "red" at the 10th position 
to be 128 without passing in all the other color values as well.  So the 
caller needs to keep a cache of the current values or call the framework 
to get the current values just to pass them back in. This seems more 
expensive then writing 2 sysfs files as writing to the color/<color> 
intensity file does not perform any I/O it merely caches the values.  
With the array the framework would need to process all the elements in 
the array every time the array is passed.  And then still call the 
brightness file to update the color outputs.  So we still have at 
minimum two sysfs accesses.

Neither implementation is perfect.

Maybe we need to ask GKH to host this in the staging directory and 
actually get some feedback from users as opposed to imposing our will on 
people.

Not sure if the ABI's can change in staging.

Dan
Pavel Machek Feb. 27, 2020, 10:58 a.m. UTC | #8
Hi, Jacek!

(and thanks for doing this).

> We have here long lasting discussion related to LED multicolor class
> sysfs interface design. We went through several iterations and worked
> out the solution with individual file per each color sub-LED in the
> color directory as shown below:
> 
> /sys/class/leds/<led>/colors/<color>_intensity
> 
> This is in line with one-value-per-file sysfs rule, that is being
> frequently highlighted, and we even had not so long ago a patch
> for led cpu trigger solving the problem caused by this rule not
> being adhered to.

Yep. One of the problems is that it is nice to change all the hardware
channels at once to produce color (it is often on i2c -- and slow), so
current proposals use "interesting" kind of latching.

> Now we have the voice below bringing to attention another caveat
> from sysfs documentation:
> 
> "it is socially acceptable to express an array of values of the same
> type"
> 
> and proposing the interface in the form of two files:
> 
> channel_intensity (file containing array of u32's)
> channel_names (usually containing "red green blue")

And thus I want to have it in one file, so it is naturaly atomic. RGB
leds with 3 channels are common; I have not user yet, but there are
RGBW with 4 channels (and some more exotic stuff). I don't expect to
have more than 5 channels.

Best regards,
								Pavel
Greg Kroah-Hartman Feb. 27, 2020, 12:43 p.m. UTC | #9
On Thu, Feb 27, 2020 at 11:58:08AM +0100, Pavel Machek wrote:
> Hi, Jacek!
> 
> (and thanks for doing this).
> 
> > We have here long lasting discussion related to LED multicolor class
> > sysfs interface design. We went through several iterations and worked
> > out the solution with individual file per each color sub-LED in the
> > color directory as shown below:
> > 
> > /sys/class/leds/<led>/colors/<color>_intensity
> > 
> > This is in line with one-value-per-file sysfs rule, that is being
> > frequently highlighted, and we even had not so long ago a patch
> > for led cpu trigger solving the problem caused by this rule not
> > being adhered to.
> 
> Yep. One of the problems is that it is nice to change all the hardware
> channels at once to produce color (it is often on i2c -- and slow), so
> current proposals use "interesting" kind of latching.
> 
> > Now we have the voice below bringing to attention another caveat
> > from sysfs documentation:
> > 
> > "it is socially acceptable to express an array of values of the same
> > type"
> > 
> > and proposing the interface in the form of two files:
> > 
> > channel_intensity (file containing array of u32's)
> > channel_names (usually containing "red green blue")
> 
> And thus I want to have it in one file, so it is naturaly atomic. RGB
> leds with 3 channels are common; I have not user yet, but there are
> RGBW with 4 channels (and some more exotic stuff). I don't expect to
> have more than 5 channels.

Writing 3 or 4 or 5 numbers all at once in a single sysfs file to
represent a single output should be fine.

thanks,

greg k-h
Dan Murphy Feb. 27, 2020, 1:07 p.m. UTC | #10
Pavel

On 2/27/20 6:43 AM, Greg KH wrote:
> On Thu, Feb 27, 2020 at 11:58:08AM +0100, Pavel Machek wrote:
>> Hi, Jacek!
>>
>> (and thanks for doing this).
>>
>>> We have here long lasting discussion related to LED multicolor class
>>> sysfs interface design. We went through several iterations and worked
>>> out the solution with individual file per each color sub-LED in the
>>> color directory as shown below:
>>>
>>> /sys/class/leds/<led>/colors/<color>_intensity
>>>
>>> This is in line with one-value-per-file sysfs rule, that is being
>>> frequently highlighted, and we even had not so long ago a patch
>>> for led cpu trigger solving the problem caused by this rule not
>>> being adhered to.
>> Yep. One of the problems is that it is nice to change all the hardware
>> channels at once to produce color (it is often on i2c -- and slow), so
>> current proposals use "interesting" kind of latching.
>>
>>> Now we have the voice below bringing to attention another caveat
>>> from sysfs documentation:
>>>
>>> "it is socially acceptable to express an array of values of the same
>>> type"
>>>
>>> and proposing the interface in the form of two files:
>>>
>>> channel_intensity (file containing array of u32's)
>>> channel_names (usually containing "red green blue")
>> And thus I want to have it in one file, so it is naturaly atomic. RGB
>> leds with 3 channels are common; I have not user yet, but there are
>> RGBW with 4 channels (and some more exotic stuff). I don't expect to
>> have more than 5 channels.

This is not an accurate statement.  Right now a user can have up to 8 
channels to cover all the LEDs defined in the LED core

And if the led_colors array expands then this array can expand.

We have no control on how many entries the user will put in their DT so 
again this number is completely arbitrary.

Dan

> Writing 3 or 4 or 5 numbers all at once in a single sysfs file to
> represent a single output should be fine.
> thanks,
>
> greg k-h
Dan Murphy Feb. 27, 2020, 1:29 p.m. UTC | #11
Removing GKH

On 2/27/20 7:07 AM, Dan Murphy wrote:
> Pavel
>
> On 2/27/20 6:43 AM, Greg KH wrote:
>> On Thu, Feb 27, 2020 at 11:58:08AM +0100, Pavel Machek wrote:
>>> Hi, Jacek!
>>>
>>> (and thanks for doing this).
>>>
>>>> We have here long lasting discussion related to LED multicolor class
>>>> sysfs interface design. We went through several iterations and worked
>>>> out the solution with individual file per each color sub-LED in the
>>>> color directory as shown below:
>>>>
>>>> /sys/class/leds/<led>/colors/<color>_intensity
>>>>
>>>> This is in line with one-value-per-file sysfs rule, that is being
>>>> frequently highlighted, and we even had not so long ago a patch
>>>> for led cpu trigger solving the problem caused by this rule not
>>>> being adhered to.
>>> Yep. One of the problems is that it is nice to change all the hardware
>>> channels at once to produce color (it is often on i2c -- and slow), so
>>> current proposals use "interesting" kind of latching.
>>>
>>>> Now we have the voice below bringing to attention another caveat
>>>> from sysfs documentation:
>>>>
>>>> "it is socially acceptable to express an array of values of the same
>>>> type"
>>>>
>>>> and proposing the interface in the form of two files:
>>>>
>>>> channel_intensity (file containing array of u32's)
>>>> channel_names (usually containing "red green blue")
>>> And thus I want to have it in one file, so it is naturaly atomic. RGB
>>> leds with 3 channels are common; I have not user yet, but there are
>>> RGBW with 4 channels (and some more exotic stuff). I don't expect to
>>> have more than 5 channels.
>
> This is not an accurate statement.  Right now a user can have up to 8 
> channels to cover all the LEDs defined in the LED core
>
> And if the led_colors array expands then this array can expand.
>
> We have no control on how many entries the user will put in their DT 
> so again this number is completely arbitrary.
>
> Dan
>
The more I think about my above statement it is actually worse to do the 
arrays.  What checks will we have to implement that the DT won't define 
an array like this

[red green blue white red green white IR blue yellow]

This array is unbounded at this point.  The sysfs framework will not 
allow creating files under the directory with the same name so we can 
bound this to 1 LED color to a file and there will be no duplicates.

Sure we can NACK DT's that do create unbounded color arrays but that 
means we would have to review every DT file that would add a LED node.

What is expected and what is exposed as capability are two different things.

We don't expect developers to have more then 5 channels but if given the 
capabilities of doing it eventually it will be done and the framework 
will break.

Dan
Jacek Anaszewski Feb. 27, 2020, 9:22 p.m. UTC | #12
On 2/27/20 2:07 PM, Dan Murphy wrote:
> Pavel
> 
> On 2/27/20 6:43 AM, Greg KH wrote:
>> On Thu, Feb 27, 2020 at 11:58:08AM +0100, Pavel Machek wrote:
>>> Hi, Jacek!
>>>
>>> (and thanks for doing this).
>>>
>>>> We have here long lasting discussion related to LED multicolor class
>>>> sysfs interface design. We went through several iterations and worked
>>>> out the solution with individual file per each color sub-LED in the
>>>> color directory as shown below:
>>>>
>>>> /sys/class/leds/<led>/colors/<color>_intensity
>>>>
>>>> This is in line with one-value-per-file sysfs rule, that is being
>>>> frequently highlighted, and we even had not so long ago a patch
>>>> for led cpu trigger solving the problem caused by this rule not
>>>> being adhered to.
>>> Yep. One of the problems is that it is nice to change all the hardware
>>> channels at once to produce color (it is often on i2c -- and slow), so
>>> current proposals use "interesting" kind of latching.
>>>
>>>> Now we have the voice below bringing to attention another caveat
>>>> from sysfs documentation:
>>>>
>>>> "it is socially acceptable to express an array of values of the same
>>>> type"
>>>>
>>>> and proposing the interface in the form of two files:
>>>>
>>>> channel_intensity (file containing array of u32's)
>>>> channel_names (usually containing "red green blue")
>>> And thus I want to have it in one file, so it is naturaly atomic. RGB
>>> leds with 3 channels are common; I have not user yet, but there are
>>> RGBW with 4 channels (and some more exotic stuff). I don't expect to
>>> have more than 5 channels.
> 
> This is not an accurate statement.  Right now a user can have up to 8
> channels to cover all the LEDs defined in the LED core
> 
> And if the led_colors array expands then this array can expand.
> 
> We have no control on how many entries the user will put in their DT so
> again this number is completely arbitrary.

I believe that some of mechanisms that were devised for the most
recent implementation proposal of LED mc class will need
to be reused for the array approach. E.g. available_colors bitmask
will make the parsing resistant to duplicates.

Of course LED multicolor DT node design should be applicable as well
to the array approach.

>> Writing 3 or 4 or 5 numbers all at once in a single sysfs file to
>> represent a single output should be fine.
>> thanks,

Thank you for making this clear.

Effectively, the way to go as I see it now is just moving from
colors directory to channel_intensity and channel_names files.

Besides that, since the issue of backwards compatibility with
LED class still remains, we need to apply the already worked out
formula for mapping brightness to color iout values.

This implies that color values written to channel_intensity file
will be written unchanged to the hw only when global brightness
is equal to max_brightness. This is because they will be multiplied
by brightness / max_brightness ratio.

Do you agree, Pavel?
Greg Kroah-Hartman Feb. 28, 2020, 7:42 a.m. UTC | #13
On Thu, Feb 27, 2020 at 10:22:43PM +0100, Jacek Anaszewski wrote:
> On 2/27/20 2:07 PM, Dan Murphy wrote:
> > Pavel
> > 
> > On 2/27/20 6:43 AM, Greg KH wrote:
> >> On Thu, Feb 27, 2020 at 11:58:08AM +0100, Pavel Machek wrote:
> >>> Hi, Jacek!
> >>>
> >>> (and thanks for doing this).
> >>>
> >>>> We have here long lasting discussion related to LED multicolor class
> >>>> sysfs interface design. We went through several iterations and worked
> >>>> out the solution with individual file per each color sub-LED in the
> >>>> color directory as shown below:
> >>>>
> >>>> /sys/class/leds/<led>/colors/<color>_intensity
> >>>>
> >>>> This is in line with one-value-per-file sysfs rule, that is being
> >>>> frequently highlighted, and we even had not so long ago a patch
> >>>> for led cpu trigger solving the problem caused by this rule not
> >>>> being adhered to.
> >>> Yep. One of the problems is that it is nice to change all the hardware
> >>> channels at once to produce color (it is often on i2c -- and slow), so
> >>> current proposals use "interesting" kind of latching.
> >>>
> >>>> Now we have the voice below bringing to attention another caveat
> >>>> from sysfs documentation:
> >>>>
> >>>> "it is socially acceptable to express an array of values of the same
> >>>> type"
> >>>>
> >>>> and proposing the interface in the form of two files:
> >>>>
> >>>> channel_intensity (file containing array of u32's)
> >>>> channel_names (usually containing "red green blue")
> >>> And thus I want to have it in one file, so it is naturaly atomic. RGB
> >>> leds with 3 channels are common; I have not user yet, but there are
> >>> RGBW with 4 channels (and some more exotic stuff). I don't expect to
> >>> have more than 5 channels.
> > 
> > This is not an accurate statement.  Right now a user can have up to 8
> > channels to cover all the LEDs defined in the LED core
> > 
> > And if the led_colors array expands then this array can expand.
> > 
> > We have no control on how many entries the user will put in their DT so
> > again this number is completely arbitrary.
> 
> I believe that some of mechanisms that were devised for the most
> recent implementation proposal of LED mc class will need
> to be reused for the array approach. E.g. available_colors bitmask
> will make the parsing resistant to duplicates.
> 
> Of course LED multicolor DT node design should be applicable as well
> to the array approach.
> 
> >> Writing 3 or 4 or 5 numbers all at once in a single sysfs file to
> >> represent a single output should be fine.
> >> thanks,
> 
> Thank you for making this clear.
> 
> Effectively, the way to go as I see it now is just moving from
> colors directory to channel_intensity and channel_names files.

Wait, we already have an interface for this and you want to create a
competing one?  Why?  What's wrong with what you have now?

Do you have a pointer to the Documentation/ABI/ entries that you have
now that you feel do not work well?

thanks,

greg k-h
Pavel Machek Feb. 28, 2020, 9:34 a.m. UTC | #14
Hi!

> > >> Writing 3 or 4 or 5 numbers all at once in a single sysfs file to
> > >> represent a single output should be fine.
> > >> thanks,
> > 
> > Thank you for making this clear.
> > 
> > Effectively, the way to go as I see it now is just moving from
> > colors directory to channel_intensity and channel_names files.
> 
> Wait, we already have an interface for this and you want to create a
> competing one?  Why?  What's wrong with what you have now?
> 
> Do you have a pointer to the Documentation/ABI/ entries that you have
> now that you feel do not work well?

No, we don't have ABI for RGB LEDs, but there's well-known proposal on
the list Jacek is talking about.

We currently handle RGB LED as three separate LEDs, and that does not
work well.

Best regards,
								Pavel
Pavel Machek Feb. 28, 2020, 9:39 a.m. UTC | #15
Hi!

> >> Writing 3 or 4 or 5 numbers all at once in a single sysfs file to
> >> represent a single output should be fine.
> >> thanks,
> 
> Thank you for making this clear.
> 
> Effectively, the way to go as I see it now is just moving from
> colors directory to channel_intensity and channel_names files.

Yes.

> Besides that, since the issue of backwards compatibility with
> LED class still remains, we need to apply the already worked out
> formula for mapping brightness to color iout values.
> 
> This implies that color values written to channel_intensity file
> will be written unchanged to the hw only when global brightness
> is equal to max_brightness. This is because they will be multiplied
> by brightness / max_brightness ratio.
> 
> Do you agree, Pavel?

Yes. That seems like possible solution.

								Pavel
Dan Murphy Feb. 28, 2020, 12:30 p.m. UTC | #16
Greg

On 2/28/20 1:42 AM, Greg KH wrote:
> On Thu, Feb 27, 2020 at 10:22:43PM +0100, Jacek Anaszewski wrote:
>> On 2/27/20 2:07 PM, Dan Murphy wrote:
>>> <snip>
>>> This is not an accurate statement.  Right now a user can have up to 8
>>> channels to cover all the LEDs defined in the LED core
>>>
>>> And if the led_colors array expands then this array can expand.
>>>
>>> We have no control on how many entries the user will put in their DT so
>>> again this number is completely arbitrary.
>> I believe that some of mechanisms that were devised for the most
>> recent implementation proposal of LED mc class will need
>> to be reused for the array approach. E.g. available_colors bitmask
>> will make the parsing resistant to duplicates.
>>
>> Of course LED multicolor DT node design should be applicable as well
>> to the array approach.
>>
>>>> Writing 3 or 4 or 5 numbers all at once in a single sysfs file to
>>>> represent a single output should be fine.
>>>> thanks,
>> Thank you for making this clear.
>>
>> Effectively, the way to go as I see it now is just moving from
>> colors directory to channel_intensity and channel_names files.
> Wait, we already have an interface for this and you want to create a
> competing one?  Why?  What's wrong with what you have now?
>
> Do you have a pointer to the Documentation/ABI/ entries that you have
> now that you feel do not work well?

Here is the proposal we have been working on for some time.

Series:

https://lore.kernel.org/patchwork/project/lkml/list/?series=427513

ABI Documentation and support code:

https://lore.kernel.org/patchwork/patch/1186194/

Dan

> thanks,
>
> greg k-h