Linux-LEDs Archive on lore.kernel.org
 help / color / Atom feed
From: Dan Murphy <dmurphy@ti.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: <jacek.anaszewski@gmail.com>, <robh+dt@kernel.org>,
	<linux-leds@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v5 2/9] documention: leds: Add multicolor class documentation
Date: Thu, 12 Sep 2019 21:09:22 -0500
Message-ID: <61ccb700-88df-03c0-3fb0-7f955d2b6cb2@ti.com> (raw)
In-Reply-To: <20190912205551.GA13514@amd>

Hello Pavel

Thanks for looking at this again

On 9/12/19 3:55 PM, Pavel Machek wrote:
> Hi!
>
>> +Directory Layout Example
>> +========================
>> +root:/sys/class/leds/rgb:grouped_leds# ls -lR colors/
>> +colors/:
>> +drwxr-xr-x    2 root     root             0 Jun 28 20:21 blue
>> +drwxr-xr-x    2 root     root             0 Jun 28 20:21 green
>> +drwxr-xr-x    2 root     root             0 Jun 28 20:21 red
>> +-rw-------    1 root     root          4096 Jun 28 20:21 color_mix
>> +
>> +colors/blue:
>> +-rw-------    1 root     root          4096 Jun 28 20:21 intensity
>> +-r--------    1 root     root          4096 Jun 28 20:27 max_intensity
>> +-r--------    1 root     root          4096 Jun 28 20:21 color_id
> I don't really like the directories... A bit too much complexity, and
> it will have a memory footprint, too.

The directories should be fine to have I am not seeing the complexity. 
Is memory footprint really an issue? Maybe in the IoT space but this is 
small and memory footprint should be able to handle this for IoT and 
larger systems.

Having dedicated directories and files clears up issues for user space 
to know about the parameters for each LED especially with the color_mix 
file which I still am not a fan of, but conceded and implemented 
anyway.  It also gives the user space flexibility to call the monochrome 
LEDs specific intensity file.  The user space can either use the color 
intensity file or the color_mix file it is a choice for them to make.

This code was modeled off the LP50xx device which has individual LED 
intensity controls as well as a overall brightness control. Since we 
have no feedback from user space folks I feel we have to give some 
options not very many but some.

>
> I'd expect max_intensity to be same for all the leds in
> rgb:grouped_leds... Could we simply rely on max_brightness file?

I went under the assumption that not all grouped LEDs would have the 
same max_intensity.

I don't have specific use cases but wanted this as an option.

Dan

> [If not, would one "max_intensity" file in rgb:grouped_leds be
> enough?]
>
> Best regards,
> 							Pavel
> 							

  reply index

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-11 18:01 [PATCH v5 0/9] Multicolor FW update Dan Murphy
2019-09-11 18:01 ` [PATCH v5 1/9] leds: multicolor: Add sysfs interface definition Dan Murphy
2019-09-15 13:57   ` Jacek Anaszewski
2019-09-16 13:56     ` Dan Murphy
2019-09-16 18:31       ` Jacek Anaszewski
2019-09-11 18:01 ` [PATCH v5 2/9] documention: leds: Add multicolor class documentation Dan Murphy
2019-09-12 20:55   ` Pavel Machek
2019-09-13  2:09     ` Dan Murphy [this message]
2019-09-15 12:45     ` Jacek Anaszewski
2019-09-11 18:01 ` [PATCH v5 3/9] dt: bindings: Add multicolor class dt bindings documention Dan Murphy
2019-09-15 14:01   ` Jacek Anaszewski
2019-09-16 13:58     ` Dan Murphy
2019-09-11 18:01 ` [PATCH v5 4/9] dt-bindings: leds: Add multicolor ID to the color ID list Dan Murphy
2019-09-11 18:01 ` [PATCH v5 5/9] " Dan Murphy
2019-09-11 18:01 ` [PATCH v5 6/9] leds: multicolor: Introduce a multicolor class definition Dan Murphy
2019-09-15 16:20   ` Jacek Anaszewski
2019-09-16 14:04     ` Dan Murphy
2019-09-16 18:34     ` Dan Murphy
2019-09-16 20:18       ` Jacek Anaszewski
2019-09-11 18:01 ` [PATCH v5 7/9] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers Dan Murphy
2019-09-11 18:01 ` [PATCH v5 8/9] leds: lp50xx: Add the LP50XX family of the RGB LED driver Dan Murphy
2019-09-11 18:01 ` [PATCH v5 9/9] leds: Update the lp55xx to use the multi color framework Dan Murphy
2019-09-15 16:28   ` Jacek Anaszewski
2019-09-16 14:03     ` Dan Murphy

Reply instructions:

You may reply publically 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=61ccb700-88df-03c0-3fb0-7f955d2b6cb2@ti.com \
    --to=dmurphy@ti.com \
    --cc=jacek.anaszewski@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --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

Linux-LEDs Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-leds/0 linux-leds/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-leds linux-leds/ https://lore.kernel.org/linux-leds \
		linux-leds@vger.kernel.org linux-leds@archiver.kernel.org
	public-inbox-index linux-leds


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-leds


AGPL code for this site: git clone https://public-inbox.org/ public-inbox