* [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs
@ 2020-03-19 18:16 Marek Behún
2020-03-21 15:33 ` Pavel Machek
` (3 more replies)
0 siblings, 4 replies; 29+ messages in thread
From: Marek Behún @ 2020-03-19 18:16 UTC (permalink / raw)
To: linux-leds; +Cc: Jacek Anaszewski, Pavel Machek, Marek Behún
This adds basic support for LEDs on the front side of CZ.NIC's Turris
Omnia router.
There are 12 RGB LEDs. The controller supports HW triggering mode for
the LEDs, but this driver does not support it yet, and sets all the LEDs
into SW mode upon probe.
The user can either group all three channels of one RGB LED into one LED
classdev, or expose each channel as an individual LED classdev. This is
done by utilizing the 'led-sources' and 'color' DT properties.
In the following example the first RGB LED is exposed as one LED
classdev with color WHITE, and the second RGB LED is exposed as three
classdevs, one per each channel:
led@0 {
reg = <0>;
led-sources = <0 1 2>;
color = <LED_COLOR_ID_WHITE>;
};
led@1,0 {
reg = <1>;
led-sources = <3>;
color = <LED_COLOR_ID_RED>;
};
led@1,1 {
reg = <1>;
led-sources = <4>;
color = <LED_COLOR_ID_GREEN>;
};
led@1,2 {
reg = <1>;
led-sources = <5>;
color = <LED_COLOR_ID_BLUE>;
};
I am not comfortable with the 'reg' property being same for multiple
nodes. Perhaps the 'reg' property shouldn't be used, since the
information needed by the driver can be deduced from the 'led-sources'.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
---
drivers/leds/Kconfig | 14 ++
drivers/leds/Makefile | 1 +
drivers/leds/leds-turris-omnia.c | 295 +++++++++++++++++++++++++++++++
3 files changed, 310 insertions(+)
create mode 100644 drivers/leds/leds-turris-omnia.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index d82f1dea3711..c33159370bcb 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -145,6 +145,20 @@ config LEDS_EL15203000
To compile this driver as a module, choose M here: the module
will be called leds-el15203000.
+config LEDS_TURRIS_OMNIA
+ tristate "LED support for CZ.NIC's Turris Omnia"
+ depends on LEDS_CLASS
+ depends on I2C
+ depends on MACH_ARMADA_38X || COMPILE_TEST
+ depends on OF
+ help
+ This option enables basic support for the LEDs found on the front
+ side of CZ.NIC's Turris Omnia router. There are 12 RGB LEDs on the
+ front panel.
+ This driver does not currently support setting LED colors, only
+ brightness. Also HW triggering is disabled when the controller is
+ probed by this driver.
+
config LEDS_LM3530
tristate "LCD Backlight driver for LM3530"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index d7e1107753fb..95feaf4bea81 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -86,6 +86,7 @@ obj-$(CONFIG_LEDS_TI_LMU_COMMON) += leds-ti-lmu-common.o
obj-$(CONFIG_LEDS_LM3697) += leds-lm3697.o
obj-$(CONFIG_LEDS_LM36274) += leds-lm36274.o
obj-$(CONFIG_LEDS_TPS6105X) += leds-tps6105x.o
+obj-$(CONFIG_LEDS_TURRIS_OMNIA) += leds-turris-omnia.o
# LED SPI Drivers
obj-$(CONFIG_LEDS_CR0014114) += leds-cr0014114.o
diff --git a/drivers/leds/leds-turris-omnia.c b/drivers/leds/leds-turris-omnia.c
new file mode 100644
index 000000000000..7e8345b2ac4f
--- /dev/null
+++ b/drivers/leds/leds-turris-omnia.c
@@ -0,0 +1,295 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// CZ.NIC's Turris Omnia LEDs driver
+//
+// 2020 by Marek Behun <marek.behun@nic.cz>
+
+#include <linux/i2c.h>
+#include <linux/leds.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+#include <uapi/linux/uleds.h>
+#include "leds.h"
+
+#define OMNIA_BOARD_LEDS 12
+
+#define CMD_LED_MODE 3
+#define CMD_LED_MODE_LED(l) ((l) & 0x0f)
+#define CMD_LED_MODE_USER 0x10
+
+#define CMD_LED_STATE 4
+#define CMD_LED_STATE_LED(l) ((l) & 0x0f)
+#define CMD_LED_STATE_ON 0x10
+
+#define CMD_LED_COLOR 5
+#define CMD_LED_SET_BRIGHTNESS 7
+#define CMD_LED_GET_BRIGHTNESS 8
+
+#define OMNIA_CMD 0
+
+#define OMNIA_CMD_LED_COLOR_LED 1
+#define OMNIA_CMD_LED_COLOR_R 2
+#define OMNIA_CMD_LED_COLOR_G 3
+#define OMNIA_CMD_LED_COLOR_B 4
+#define OMNIA_CMD_LED_COLOR_LEN 5
+
+struct omnia_led {
+ struct led_classdev cdev;
+ int reg, color;
+};
+
+#define to_omnia_led(l) container_of(l, struct omnia_led, cdev)
+
+struct omnia_leds {
+ struct i2c_client *client;
+ struct mutex lock;
+ u8 cache[OMNIA_BOARD_LEDS][3];
+ int nleds;
+ struct omnia_led leds[0];
+};
+
+static int omnia_led_brightness_set_blocking(struct led_classdev *cdev,
+ enum led_brightness brightness)
+{
+ static const u8 color2cmd[] = {
+ [LED_COLOR_ID_RED] = OMNIA_CMD_LED_COLOR_R,
+ [LED_COLOR_ID_GREEN] = OMNIA_CMD_LED_COLOR_G,
+ [LED_COLOR_ID_BLUE] = OMNIA_CMD_LED_COLOR_B,
+ };
+ struct omnia_leds *leds = dev_get_drvdata(cdev->dev->parent);
+ struct omnia_led *led = to_omnia_led(cdev);
+ u8 buf[OMNIA_CMD_LED_COLOR_LEN], state;
+ int ret;
+
+ mutex_lock(&leds->lock);
+
+ buf[OMNIA_CMD] = CMD_LED_COLOR;
+ buf[OMNIA_CMD_LED_COLOR_LED] = led->reg;
+
+ if (led->color == LED_COLOR_ID_WHITE) {
+ buf[OMNIA_CMD_LED_COLOR_R] = brightness;
+ buf[OMNIA_CMD_LED_COLOR_G] = brightness;
+ buf[OMNIA_CMD_LED_COLOR_B] = brightness;
+ } else {
+ buf[OMNIA_CMD_LED_COLOR_R] = leds->cache[led->reg][0];
+ buf[OMNIA_CMD_LED_COLOR_G] = leds->cache[led->reg][1];
+ buf[OMNIA_CMD_LED_COLOR_B] = leds->cache[led->reg][2];
+ buf[color2cmd[led->color]] = brightness;
+ }
+
+ state = CMD_LED_STATE_LED(led->reg);
+ if (buf[OMNIA_CMD_LED_COLOR_R] || buf[OMNIA_CMD_LED_COLOR_G] ||
+ buf[OMNIA_CMD_LED_COLOR_B])
+ state |= CMD_LED_STATE_ON;
+
+ ret = i2c_smbus_write_byte_data(leds->client, CMD_LED_STATE, state);
+ if (ret >= 0 && (state & CMD_LED_STATE_ON))
+ ret = i2c_master_send(leds->client, buf, 5);
+
+ leds->cache[led->reg][0] = buf[OMNIA_CMD_LED_COLOR_R];
+ leds->cache[led->reg][1] = buf[OMNIA_CMD_LED_COLOR_G];
+ leds->cache[led->reg][2] = buf[OMNIA_CMD_LED_COLOR_B];
+
+ mutex_unlock(&leds->lock);
+
+ return ret;
+}
+
+static int omnia_led_register(struct omnia_leds *leds,
+ struct fwnode_handle *node)
+{
+ struct i2c_client *client = leds->client;
+ struct led_init_data init_data = {};
+ struct device *dev = &client->dev;
+ struct omnia_led *led;
+ int ret, nsources, color;
+ u32 reg, led_sources[3];
+
+ led = &leds->leds[leds->nleds];
+
+ ret = fwnode_property_read_u32(node, "reg", ®);
+ if (ret) {
+ dev_err(dev, "Node %pfw: 'reg' read failed!\n", node);
+ return ret;
+ }
+
+ if (reg >= OMNIA_BOARD_LEDS) {
+ dev_warn(dev, "Node %pfw: invalid 'reg' value %u\n", node, reg);
+ return 0;
+ }
+
+ nsources = fwnode_property_count_u32(node, "led-sources");
+ if (nsources != 1 && nsources != 3) {
+ dev_warn(dev, "Node %pfw: either 1 or 3 'led-sources' must be specified!\n",
+ node);
+ return 0;
+ }
+
+ ret = fwnode_property_read_u32_array(node, "led-sources", led_sources,
+ nsources);
+ if (ret) {
+ dev_err(dev, "Node %pfw: 'led-sources' read failed: %i\n",
+ node, ret);
+ return ret;
+ }
+
+ ret = fwnode_property_read_u32(node, "color", &led->color);
+ if (ret) {
+ dev_warn(dev, "Node %pfw: 'color' read failed!\n",
+ node);
+ return 0;
+ }
+
+ if (nsources == 3) {
+ if (led_sources[0] != 3 * reg ||
+ led_sources[1] != 3 * reg + 1 ||
+ led_sources[2] != 3 * reg + 2) {
+ dev_warn(dev, "Node %pfw has invalid 'led-sources'!\n",
+ node);
+ return 0;
+ }
+
+ color = LED_COLOR_ID_WHITE;
+ } else {
+ const int led_source_to_color[3] = {
+ LED_COLOR_ID_RED,
+ LED_COLOR_ID_GREEN,
+ LED_COLOR_ID_BLUE
+ };
+ color = led_source_to_color[led_sources[0] % 3];
+
+ if (led_sources[0] < 3 * reg || led_sources[0] > 3 * reg + 2) {
+ dev_warn(dev, "Node %pfw has invalid 'led-sources'!\n",
+ node);
+ return 0;
+ }
+ }
+
+ if (led->color != color) {
+ dev_warn(dev, "Node %pfw: 'color' should be %s!\n", node,
+ led_colors[color]);
+ return 0;
+ }
+
+ init_data.devicename = "omnia";
+ init_data.fwnode = node;
+ init_data.devname_mandatory = true;
+
+ led->reg = reg;
+ led->cdev.max_brightness = 255;
+ led->cdev.brightness_set_blocking = omnia_led_brightness_set_blocking;
+
+ fwnode_property_read_string(node, "linux,default-trigger",
+ &led->cdev.default_trigger);
+
+ /* put the LED into software mode */
+ ret = i2c_smbus_write_byte_data(client, CMD_LED_MODE,
+ CMD_LED_MODE_LED(reg) |
+ CMD_LED_MODE_USER);
+ if (ret < 0) {
+ dev_err(dev, "Cannot set LED %pfw to software mode: %i\n", node,
+ ret);
+ return ret;
+ }
+
+ /* disable the LED */
+ ret = i2c_smbus_write_byte_data(client, CMD_LED_STATE,
+ CMD_LED_STATE_LED(reg));
+ if (ret < 0) {
+ dev_err(dev, "Cannot set LED %pfw brightness: %i\n", node, ret);
+ return ret;
+ }
+
+ ret = devm_led_classdev_register_ext(dev, &led->cdev, &init_data);
+ if (ret < 0) {
+ dev_err(dev, "Cannot register LED %pfw: %i\n", node, ret);
+ return ret;
+ }
+
+ ++leds->nleds;
+
+ return 0;
+}
+
+static int omnia_leds_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct device *dev = &client->dev;
+ struct device_node *np = dev->of_node, *child;
+ struct omnia_leds *leds;
+ int ret, count;
+
+ count = of_get_available_child_count(np);
+ if (!count) {
+ dev_err(dev, "LEDs are not defined in device tree!\n");
+ return -ENODEV;
+ } else if (count > 3 * OMNIA_BOARD_LEDS) {
+ dev_err(dev, "Too many LEDs defined in device tree!\n");
+ return -EINVAL;
+ }
+
+ leds = devm_kzalloc(dev, sizeof(*leds) + count * sizeof(leds->leds[0]),
+ GFP_KERNEL);
+ if (!leds)
+ return -ENOMEM;
+
+ leds->client = client;
+ i2c_set_clientdata(client, leds);
+
+ mutex_init(&leds->lock);
+
+ for_each_available_child_of_node(np, child) {
+ ret = omnia_led_register(leds, &child->fwnode);
+ if (ret < 0)
+ return ret;
+ }
+
+ return 0;
+}
+
+static int omnia_leds_remove(struct i2c_client *client)
+{
+ u8 buf[OMNIA_CMD_LED_COLOR_LEN];
+
+ /* put all LEDs into default (HW triggered) mode */
+ i2c_smbus_write_byte_data(client, CMD_LED_MODE,
+ CMD_LED_MODE_LED(OMNIA_BOARD_LEDS));
+
+ /* set all LEDs color to [255, 255, 255] */
+ buf[OMNIA_CMD] = CMD_LED_COLOR;
+ buf[OMNIA_CMD_LED_COLOR_LED] = OMNIA_BOARD_LEDS;
+ buf[OMNIA_CMD_LED_COLOR_R] = 255;
+ buf[OMNIA_CMD_LED_COLOR_G] = 255;
+ buf[OMNIA_CMD_LED_COLOR_B] = 255;
+
+ i2c_master_send(client, buf, 5);
+
+ return 0;
+}
+
+static const struct of_device_id of_omnia_leds_match[] = {
+ { .compatible = "cznic,turris-omnia-leds", },
+ {},
+};
+
+static const struct i2c_device_id omnia_id[] = {
+ { "omnia", 0 },
+ { }
+};
+
+static struct i2c_driver omnia_leds_driver = {
+ .probe = omnia_leds_probe,
+ .remove = omnia_leds_remove,
+ .id_table = omnia_id,
+ .driver = {
+ .name = "leds-turris-omnia",
+ .of_match_table = of_omnia_leds_match,
+ },
+};
+
+module_i2c_driver(omnia_leds_driver);
+
+MODULE_AUTHOR("Marek Behun <marek.behun@nic.cz>");
+MODULE_DESCRIPTION("CZ.NIC's Turris Omnia LEDs");
+MODULE_LICENSE("GPL v2");
--
2.24.1
^ permalink raw reply related [flat|nested] 29+ messages in thread* Re: [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs
2020-03-19 18:16 [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs Marek Behún
@ 2020-03-21 15:33 ` Pavel Machek
2020-03-28 12:08 ` Jacek Anaszewski
2020-03-21 15:34 ` Pavel Machek
` (2 subsequent siblings)
3 siblings, 1 reply; 29+ messages in thread
From: Pavel Machek @ 2020-03-21 15:33 UTC (permalink / raw)
To: Marek Behún; +Cc: linux-leds, Jacek Anaszewski
[-- Attachment #1: Type: text/plain, Size: 431 bytes --]
Hi!
> This adds basic support for LEDs on the front side of CZ.NIC's Turris
> Omnia router.
Looks good, I had to apply it by hand, by I took it. I realize that
dts interface may not be final, but I do not want to solve Makefile
rejects in future.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs
2020-03-21 15:33 ` Pavel Machek
@ 2020-03-28 12:08 ` Jacek Anaszewski
2020-03-28 12:27 ` Marek Behun
0 siblings, 1 reply; 29+ messages in thread
From: Jacek Anaszewski @ 2020-03-28 12:08 UTC (permalink / raw)
To: Pavel Machek, Marek Behún; +Cc: linux-leds
Hi Pavel.
On 3/21/20 4:33 PM, Pavel Machek wrote:
> Hi!
>
>> This adds basic support for LEDs on the front side of CZ.NIC's Turris
>> Omnia router.
>
> Looks good, I had to apply it by hand, by I took it. I realize that
> dts interface may not be final, but I do not want to solve Makefile
> rejects in future.
I don't think it is a good idea to merge it without bindings,
and with DT parser that will certainly undergo essential changes.
Besides, you appear as the commit author in your tree and moreover
the patch has a broken title. Also the commit message contains
DT bindings that will have different shape eventually.
NACK for merging this patch in this shape.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs
2020-03-28 12:08 ` Jacek Anaszewski
@ 2020-03-28 12:27 ` Marek Behun
2020-03-28 12:36 ` Marek Behun
2020-04-06 20:42 ` Pavel Machek
0 siblings, 2 replies; 29+ messages in thread
From: Marek Behun @ 2020-03-28 12:27 UTC (permalink / raw)
To: Jacek Anaszewski; +Cc: Pavel Machek, linux-leds
On Sat, 28 Mar 2020 13:08:02 +0100
Jacek Anaszewski <jacek.anaszewski@gmail.com> wrote:
> Hi Pavel.
>
> On 3/21/20 4:33 PM, Pavel Machek wrote:
> > Hi!
> >
> >> This adds basic support for LEDs on the front side of CZ.NIC's Turris
> >> Omnia router.
> >
> > Looks good, I had to apply it by hand, by I took it. I realize that
> > dts interface may not be final, but I do not want to solve Makefile
> > rejects in future.
>
> I don't think it is a good idea to merge it without bindings,
> and with DT parser that will certainly undergo essential changes.
>
> Besides, you appear as the commit author in your tree and moreover
> the patch has a broken title. Also the commit message contains
> DT bindings that will have different shape eventually.
>
> NACK for merging this patch in this shape.
>
This was only RFC, please do not merge.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs
2020-03-28 12:27 ` Marek Behun
@ 2020-03-28 12:36 ` Marek Behun
2020-03-28 13:01 ` Jacek Anaszewski
2020-04-06 20:42 ` Pavel Machek
1 sibling, 1 reply; 29+ messages in thread
From: Marek Behun @ 2020-03-28 12:36 UTC (permalink / raw)
To: Jacek Anaszewski; +Cc: Pavel Machek, linux-leds
> This was only RFC, please do not merge.
Jacek, Pavel,
I decided to abandon the microcontroller driver path.
But nonetheless there is still one thing I would like to solve.
The front button on Omnia is used to control the global brightness of
the RGB LEDs, so that user can change it if the LEDs glow too much.
The microcontroller does this as such: there is another PWM on top of
all the LED PWMs, and this value can be manipulated via the same i2c
interface as the LEDs, but via another command.
The thing is that I would like to somehow export this global brightness
setting to userspace, because otherwise it gets reset after reboot, and
I want the user to be able to set this global brightness by software,
so that they won't have to change it after every reboot manually by
pressing the front button.
I am wondering how to do this. Last year I proposed this by adding a
sysfs attribute file to the device which is parent to the LEDs, but you
did not agree :(
Marek
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs
2020-03-28 12:36 ` Marek Behun
@ 2020-03-28 13:01 ` Jacek Anaszewski
2020-03-28 17:20 ` Marek Behun
2020-04-06 21:08 ` Pavel Machek
0 siblings, 2 replies; 29+ messages in thread
From: Jacek Anaszewski @ 2020-03-28 13:01 UTC (permalink / raw)
To: Marek Behun; +Cc: Pavel Machek, linux-leds
Hi Marek,
On 3/28/20 1:36 PM, Marek Behun wrote:
>> This was only RFC, please do not merge.
>
> Jacek, Pavel,
>
> I decided to abandon the microcontroller driver path.
> But nonetheless there is still one thing I would like to solve.
>
> The front button on Omnia is used to control the global brightness of
> the RGB LEDs, so that user can change it if the LEDs glow too much.
> The microcontroller does this as such: there is another PWM on top of
> all the LED PWMs, and this value can be manipulated via the same i2c
> interface as the LEDs, but via another command.
>
> The thing is that I would like to somehow export this global brightness
> setting to userspace, because otherwise it gets reset after reboot, and
> I want the user to be able to set this global brightness by software,
> so that they won't have to change it after every reboot manually by
> pressing the front button.
>
> I am wondering how to do this. Last year I proposed this by adding a
> sysfs attribute file to the device which is parent to the LEDs, but you
> did not agree :(
I already proposed adding a "luma" LED class device for similar
case [0], but didn't here any feedback from Pavel so far.
[0]
https://lore.kernel.org/linux-leds/1583502010-16210-1-git-send-email-nbelin@baylibre.com/T/#mf52c8d4f68260a445223c26957c61e6267e0932d
--
Best regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs
2020-03-28 13:01 ` Jacek Anaszewski
@ 2020-03-28 17:20 ` Marek Behun
2020-03-29 12:53 ` Jacek Anaszewski
2020-04-06 21:08 ` Pavel Machek
1 sibling, 1 reply; 29+ messages in thread
From: Marek Behun @ 2020-03-28 17:20 UTC (permalink / raw)
To: Jacek Anaszewski; +Cc: Pavel Machek, linux-leds
On Sat, 28 Mar 2020 14:01:47 +0100
Jacek Anaszewski <jacek.anaszewski@gmail.com> wrote:
> I already proposed adding a "luma" LED class device for similar
> case [0], but didn't here any feedback from Pavel so far.
>
> [0]
> https://lore.kernel.org/linux-leds/1583502010-16210-1-git-send-email-nbelin@baylibre.com/T/#mf52c8d4f68260a445223c26957c61e6267e0932d
>
Hi Jacek,
in the case you mentioned there is a one "global" brightness setting per
each RGB LED. On Omnia, all 12 RGB LEDs have just one "global"
brightness property. Ie. I press the button, and all 12 LEDs glow get
dimmer. So there could be a 13th LED device with color LUMA, but what
function should it be given in DTS?
Marek
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs
2020-03-28 17:20 ` Marek Behun
@ 2020-03-29 12:53 ` Jacek Anaszewski
2020-04-02 14:29 ` Marek Behun
0 siblings, 1 reply; 29+ messages in thread
From: Jacek Anaszewski @ 2020-03-29 12:53 UTC (permalink / raw)
To: Marek Behun; +Cc: Pavel Machek, linux-leds
Hi Marek,
On 3/28/20 6:20 PM, Marek Behun wrote:
> On Sat, 28 Mar 2020 14:01:47 +0100
> Jacek Anaszewski <jacek.anaszewski@gmail.com> wrote:
>
>> I already proposed adding a "luma" LED class device for similar
>> case [0], but didn't here any feedback from Pavel so far.
>>
>> [0]
>> https://lore.kernel.org/linux-leds/1583502010-16210-1-git-send-email-nbelin@baylibre.com/T/#mf52c8d4f68260a445223c26957c61e6267e0932d
>>
>
> Hi Jacek,
>
> in the case you mentioned there is a one "global" brightness setting per
> each RGB LED. On Omnia, all 12 RGB LEDs have just one "global"
> brightness property. Ie. I press the button, and all 12 LEDs glow get
> dimmer. So there could be a 13th LED device with color LUMA, but what
> function should it be given in DTS?
Then, in this particular case, adding devicename prefix for the whole
family of LEDs would be justified. The question is whether it should be
hardware related name or rather something different.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs
2020-03-29 12:53 ` Jacek Anaszewski
@ 2020-04-02 14:29 ` Marek Behun
2020-04-02 20:19 ` Jacek Anaszewski
0 siblings, 1 reply; 29+ messages in thread
From: Marek Behun @ 2020-04-02 14:29 UTC (permalink / raw)
To: Jacek Anaszewski; +Cc: Pavel Machek, linux-leds
On Sun, 29 Mar 2020 14:53:57 +0200
Jacek Anaszewski <jacek.anaszewski@gmail.com> wrote:
> > in the case you mentioned there is a one "global" brightness setting per
> > each RGB LED. On Omnia, all 12 RGB LEDs have just one "global"
> > brightness property. Ie. I press the button, and all 12 LEDs glow get
> > dimmer. So there could be a 13th LED device with color LUMA, but what
> > function should it be given in DTS?
>
> Then, in this particular case, adding devicename prefix for the whole
> family of LEDs would be justified. The question is whether it should be
> hardware related name or rather something different.
Hi Jacek,
so now we have
device:color:function
what if we made it so that there was a 4th part of LED name, ie
group:device:color:function
?
Would this be a problem?
Marek
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs
2020-04-02 14:29 ` Marek Behun
@ 2020-04-02 20:19 ` Jacek Anaszewski
2020-04-02 20:57 ` Marek Behun
0 siblings, 1 reply; 29+ messages in thread
From: Jacek Anaszewski @ 2020-04-02 20:19 UTC (permalink / raw)
To: Marek Behun; +Cc: Pavel Machek, linux-leds
On 4/2/20 4:29 PM, Marek Behun wrote:
> On Sun, 29 Mar 2020 14:53:57 +0200
> Jacek Anaszewski <jacek.anaszewski@gmail.com> wrote:
>
>>> in the case you mentioned there is a one "global" brightness setting per
>>> each RGB LED. On Omnia, all 12 RGB LEDs have just one "global"
>>> brightness property. Ie. I press the button, and all 12 LEDs glow get
>>> dimmer. So there could be a 13th LED device with color LUMA, but what
>>> function should it be given in DTS?
>>
>> Then, in this particular case, adding devicename prefix for the whole
>> family of LEDs would be justified. The question is whether it should be
>> hardware related name or rather something different.
>
> Hi Jacek,
>
> so now we have
> device:color:function
> what if we made it so that there was a 4th part of LED name, ie
> group:device:color:function
> ?
>
> Would this be a problem?
Indeed, the device alone would not be a sufficient differentiator
since it is possible to have more than one LED controller of the
same type on the board.
Nonetheless, I'd rather avoid the addition of a new generic section.
Probably we would have to make it specific to this device.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs
2020-04-02 20:19 ` Jacek Anaszewski
@ 2020-04-02 20:57 ` Marek Behun
2020-04-02 21:00 ` Jacek Anaszewski
0 siblings, 1 reply; 29+ messages in thread
From: Marek Behun @ 2020-04-02 20:57 UTC (permalink / raw)
To: Jacek Anaszewski; +Cc: Pavel Machek, linux-leds
On Thu, 2 Apr 2020 22:19:50 +0200
Jacek Anaszewski <jacek.anaszewski@gmail.com> wrote:
> On 4/2/20 4:29 PM, Marek Behun wrote:
> > On Sun, 29 Mar 2020 14:53:57 +0200
> > Jacek Anaszewski <jacek.anaszewski@gmail.com> wrote:
> >
> >>> in the case you mentioned there is a one "global" brightness setting per
> >>> each RGB LED. On Omnia, all 12 RGB LEDs have just one "global"
> >>> brightness property. Ie. I press the button, and all 12 LEDs glow get
> >>> dimmer. So there could be a 13th LED device with color LUMA, but what
> >>> function should it be given in DTS?
> >>
> >> Then, in this particular case, adding devicename prefix for the whole
> >> family of LEDs would be justified. The question is whether it should be
> >> hardware related name or rather something different.
> >
> > Hi Jacek,
> >
> > so now we have
> > device:color:function
> > what if we made it so that there was a 4th part of LED name, ie
> > group:device:color:function
> > ?
> >
> > Would this be a problem?
>
> Indeed, the device alone would not be a sufficient differentiator
> since it is possible to have more than one LED controller of the
> same type on the board.
>
> Nonetheless, I'd rather avoid the addition of a new generic section.
> Probably we would have to make it specific to this device.
>
Ok, in that case I will do it so that devicename is "omnia".
devicename_mandatory should be set to true, yes?
Marek
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs
2020-04-02 20:57 ` Marek Behun
@ 2020-04-02 21:00 ` Jacek Anaszewski
2020-04-06 21:10 ` Pavel Machek
0 siblings, 1 reply; 29+ messages in thread
From: Jacek Anaszewski @ 2020-04-02 21:00 UTC (permalink / raw)
To: Marek Behun; +Cc: Pavel Machek, linux-leds
On 4/2/20 10:57 PM, Marek Behun wrote:
> On Thu, 2 Apr 2020 22:19:50 +0200
> Jacek Anaszewski <jacek.anaszewski@gmail.com> wrote:
>
>> On 4/2/20 4:29 PM, Marek Behun wrote:
>>> On Sun, 29 Mar 2020 14:53:57 +0200
>>> Jacek Anaszewski <jacek.anaszewski@gmail.com> wrote:
>>>
>>>>> in the case you mentioned there is a one "global" brightness setting per
>>>>> each RGB LED. On Omnia, all 12 RGB LEDs have just one "global"
>>>>> brightness property. Ie. I press the button, and all 12 LEDs glow get
>>>>> dimmer. So there could be a 13th LED device with color LUMA, but what
>>>>> function should it be given in DTS?
>>>>
>>>> Then, in this particular case, adding devicename prefix for the whole
>>>> family of LEDs would be justified. The question is whether it should be
>>>> hardware related name or rather something different.
>>>
>>> Hi Jacek,
>>>
>>> so now we have
>>> device:color:function
>>> what if we made it so that there was a 4th part of LED name, ie
>>> group:device:color:function
>>> ?
>>>
>>> Would this be a problem?
>>
>> Indeed, the device alone would not be a sufficient differentiator
>> since it is possible to have more than one LED controller of the
>> same type on the board.
>>
>> Nonetheless, I'd rather avoid the addition of a new generic section.
>> Probably we would have to make it specific to this device.
>>
>
> Ok, in that case I will do it so that devicename is "omnia".
> devicename_mandatory should be set to true, yes?
If you want to have four sections then you must compose LED
name yourself and not use new *ext() API. But please hold on,
since I suppose Pavel will have something to add to that.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs
2020-04-02 21:00 ` Jacek Anaszewski
@ 2020-04-06 21:10 ` Pavel Machek
0 siblings, 0 replies; 29+ messages in thread
From: Pavel Machek @ 2020-04-06 21:10 UTC (permalink / raw)
To: Jacek Anaszewski; +Cc: Marek Behun, linux-leds
[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]
Hi!
> >>> so now we have
> >>> device:color:function
> >>> what if we made it so that there was a 4th part of LED name, ie
> >>> group:device:color:function
> >>> ?
> >>>
> >>> Would this be a problem?
> >>
> >> Indeed, the device alone would not be a sufficient differentiator
> >> since it is possible to have more than one LED controller of the
> >> same type on the board.
> >>
> >> Nonetheless, I'd rather avoid the addition of a new generic section.
> >> Probably we would have to make it specific to this device.
> >>
> >
> > Ok, in that case I will do it so that devicename is "omnia".
> > devicename_mandatory should be set to true, yes?
>
> If you want to have four sections then you must compose LED
> name yourself and not use new *ext() API. But please hold on,
> since I suppose Pavel will have something to add to that.
Lets just handle global brightness outside LED subsystem.
And drop the omnia: .. it is useless. For some of your leds it should
be "ethX:...:activity".
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs
2020-03-28 13:01 ` Jacek Anaszewski
2020-03-28 17:20 ` Marek Behun
@ 2020-04-06 21:08 ` Pavel Machek
1 sibling, 0 replies; 29+ messages in thread
From: Pavel Machek @ 2020-04-06 21:08 UTC (permalink / raw)
To: Jacek Anaszewski; +Cc: Marek Behun, linux-leds
[-- Attachment #1: Type: text/plain, Size: 1883 bytes --]
Hi!
> > I decided to abandon the microcontroller driver path.
> > But nonetheless there is still one thing I would like to solve.
> >
> > The front button on Omnia is used to control the global brightness of
> > the RGB LEDs, so that user can change it if the LEDs glow too much.
> > The microcontroller does this as such: there is another PWM on top of
> > all the LED PWMs, and this value can be manipulated via the same i2c
> > interface as the LEDs, but via another command.
> >
> > The thing is that I would like to somehow export this global brightness
> > setting to userspace, because otherwise it gets reset after reboot, and
> > I want the user to be able to set this global brightness by software,
> > so that they won't have to change it after every reboot manually by
> > pressing the front button.
> >
> > I am wondering how to do this. Last year I proposed this by adding a
> > sysfs attribute file to the device which is parent to the LEDs, but you
> > did not agree :(
This is really special feature, with button interaction. I don't
expect to see it elsewhere. Can you put it into /sys somewhere close
to the other controls for your platform? I have /proc/acpi/ibm on this
machine. It should not be /proc in new code, but you get the idea...
> I already proposed adding a "luma" LED class device for similar
> case [0], but didn't here any feedback from Pavel so far.
I dislike that. Luma is not really a color. Plus, this is different
case AFAICT, as global brightness affects all the LEDs at the same
time.
> [0]
> https://lore.kernel.org/linux-leds/1583502010-16210-1-git-send-email-nbelin@baylibre.com/T/#mf52c8d4f68260a445223c26957c61e6267e0932d
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs
2020-03-28 12:27 ` Marek Behun
2020-03-28 12:36 ` Marek Behun
@ 2020-04-06 20:42 ` Pavel Machek
1 sibling, 0 replies; 29+ messages in thread
From: Pavel Machek @ 2020-04-06 20:42 UTC (permalink / raw)
To: Marek Behun; +Cc: Jacek Anaszewski, linux-leds
[-- Attachment #1: Type: text/plain, Size: 374 bytes --]
Hi!
> > NACK for merging this patch in this shape.
>
> This was only RFC, please do not merge.
Ok, dropped. But it would be good to merge some basic version, soon,
before we get even more requirements :-).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs
2020-03-19 18:16 [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs Marek Behún
2020-03-21 15:33 ` Pavel Machek
@ 2020-03-21 15:34 ` Pavel Machek
2020-03-21 18:01 ` Jacek Anaszewski
2020-03-21 18:55 ` Jacek Anaszewski
2020-03-21 21:53 ` Marek Behun
3 siblings, 1 reply; 29+ messages in thread
From: Pavel Machek @ 2020-03-21 15:34 UTC (permalink / raw)
To: Marek Behún; +Cc: linux-leds, Jacek Anaszewski
[-- Attachment #1: Type: text/plain, Size: 625 bytes --]
Hi!
> + if (led->color != color) {
> + dev_warn(dev, "Node %pfw: 'color' should be %s!\n", node,
> + led_colors[color]);
> + return 0;
> + }
> +
> + init_data.devicename = "omnia";
> + init_data.fwnode = node;
> + init_data.devname_mandatory = true;
How will this look in the /sys/class/leds?
We don't want to see omnia:xxx:xx there. For the ethernet activity
leds, it would be nice to get something like eth0:red:activity...?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs
2020-03-21 15:34 ` Pavel Machek
@ 2020-03-21 18:01 ` Jacek Anaszewski
2020-03-21 20:50 ` Marek Behun
0 siblings, 1 reply; 29+ messages in thread
From: Jacek Anaszewski @ 2020-03-21 18:01 UTC (permalink / raw)
To: Pavel Machek, Marek Behún; +Cc: linux-leds
On 3/21/20 4:34 PM, Pavel Machek wrote:
> Hi!
>
>> + if (led->color != color) {
>> + dev_warn(dev, "Node %pfw: 'color' should be %s!\n", node,
>> + led_colors[color]);
>> + return 0;
>> + }
>> +
>> + init_data.devicename = "omnia";
>> + init_data.fwnode = node;
>> + init_data.devname_mandatory = true;
>
> How will this look in the /sys/class/leds?
>
> We don't want to see omnia:xxx:xx there. For the ethernet activity
> leds, it would be nice to get something like eth0:red:activity...?
devicename and devicename_mandatory should be removed.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs
2020-03-21 18:01 ` Jacek Anaszewski
@ 2020-03-21 20:50 ` Marek Behun
2020-03-22 15:51 ` Jacek Anaszewski
0 siblings, 1 reply; 29+ messages in thread
From: Marek Behun @ 2020-03-21 20:50 UTC (permalink / raw)
To: Jacek Anaszewski; +Cc: Pavel Machek, linux-leds
On Sat, 21 Mar 2020 19:01:15 +0100
Jacek Anaszewski <jacek.anaszewski@gmail.com> wrote:
> > How will this look in the /sys/class/leds?
> >
> > We don't want to see omnia:xxx:xx there. For the ethernet activity
> > leds, it would be nice to get something like eth0:red:activity...?
>
> devicename and devicename_mandatory should be removed.
>
Without this I have:
omnialeds /sys/class/leds # ls
blue:power red:power white:lan-2 white:pci-1 white:user-1
green:power white:lan-0 white:lan-3 white:pci-2 white:user-2
mmc0:: white:lan-1 white:lan-4 white:pci-3 white:wan
(the mmc0:: is not created by this driver).
Is this okay?
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs
2020-03-21 20:50 ` Marek Behun
@ 2020-03-22 15:51 ` Jacek Anaszewski
2020-04-06 8:34 ` Pavel Machek
0 siblings, 1 reply; 29+ messages in thread
From: Jacek Anaszewski @ 2020-03-22 15:51 UTC (permalink / raw)
To: Marek Behun; +Cc: Pavel Machek, linux-leds
Marek,
On 3/21/20 9:50 PM, Marek Behun wrote:
> On Sat, 21 Mar 2020 19:01:15 +0100
> Jacek Anaszewski <jacek.anaszewski@gmail.com> wrote:
>
>>> How will this look in the /sys/class/leds?
>>>
>>> We don't want to see omnia:xxx:xx there. For the ethernet activity
>>> leds, it would be nice to get something like eth0:red:activity...?
>>
>> devicename and devicename_mandatory should be removed.
>>
>
> Without this I have:
>
> omnialeds /sys/class/leds # ls
> blue:power red:power white:lan-2 white:pci-1 white:user-1
> green:power white:lan-0 white:lan-3 white:pci-2 white:user-2
> mmc0:: white:lan-1 white:lan-4 white:pci-3 white:wan
You might want to associate the LED with actual eth interface,
as Pavel mentioned, but that would require some more work.
Anyway, "omnia" alone doesn't allow to tell the location of the
LED either.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs
2020-03-22 15:51 ` Jacek Anaszewski
@ 2020-04-06 8:34 ` Pavel Machek
2020-04-06 13:53 ` Marek Behun
0 siblings, 1 reply; 29+ messages in thread
From: Pavel Machek @ 2020-04-06 8:34 UTC (permalink / raw)
To: Jacek Anaszewski; +Cc: Marek Behun, linux-leds
[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]
On Sun 2020-03-22 16:51:02, Jacek Anaszewski wrote:
> Marek,
>
> On 3/21/20 9:50 PM, Marek Behun wrote:
> > On Sat, 21 Mar 2020 19:01:15 +0100
> > Jacek Anaszewski <jacek.anaszewski@gmail.com> wrote:
> >
> >>> How will this look in the /sys/class/leds?
> >>>
> >>> We don't want to see omnia:xxx:xx there. For the ethernet activity
> >>> leds, it would be nice to get something like eth0:red:activity...?
> >>
> >> devicename and devicename_mandatory should be removed.
> >>
> >
> > Without this I have:
> >
> > omnialeds /sys/class/leds # ls
> > blue:power red:power white:lan-2 white:pci-1 white:user-1
> > green:power white:lan-0 white:lan-3 white:pci-2 white:user-2
> > mmc0:: white:lan-1 white:lan-4 white:pci-3 white:wan
>
> You might want to associate the LED with actual eth interface,
> as Pavel mentioned, but that would require some more work.
Yes please.
> Anyway, "omnia" alone doesn't allow to tell the location of the
> LED either.
ACK.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs
2020-04-06 8:34 ` Pavel Machek
@ 2020-04-06 13:53 ` Marek Behun
0 siblings, 0 replies; 29+ messages in thread
From: Marek Behun @ 2020-04-06 13:53 UTC (permalink / raw)
To: Pavel Machek; +Cc: Jacek Anaszewski, linux-leds
On Mon, 6 Apr 2020 10:34:23 +0200
Pavel Machek <pavel@ucw.cz> wrote:
> Yes please.
>
> > Anyway, "omnia" alone doesn't allow to tell the location of the
> > LED either.
>
> ACK.
Pavel, what about the other thread (starting with message ID
<20200402162950.5c2847be@nic.cz>, sent at 04/02/2020 16:29) ?
Marek
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs
2020-03-19 18:16 [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs Marek Behún
2020-03-21 15:33 ` Pavel Machek
2020-03-21 15:34 ` Pavel Machek
@ 2020-03-21 18:55 ` Jacek Anaszewski
2020-03-21 20:44 ` Marek Behun
2020-03-21 21:53 ` Marek Behun
3 siblings, 1 reply; 29+ messages in thread
From: Jacek Anaszewski @ 2020-03-21 18:55 UTC (permalink / raw)
To: Marek Behún, linux-leds; +Cc: Pavel Machek
Hi Marek,
Thank you for the patch.
On 3/19/20 7:16 PM, Marek Behún wrote:
> This adds basic support for LEDs on the front side of CZ.NIC's Turris
> Omnia router.
>
> There are 12 RGB LEDs. The controller supports HW triggering mode for
> the LEDs, but this driver does not support it yet, and sets all the LEDs
> into SW mode upon probe.
>
> The user can either group all three channels of one RGB LED into one LED
> classdev, or expose each channel as an individual LED classdev. This is
> done by utilizing the 'led-sources' and 'color' DT properties.
>
> In the following example the first RGB LED is exposed as one LED
> classdev with color WHITE, and the second RGB LED is exposed as three
> classdevs, one per each channel:
> led@0 {
> reg = <0>;
> led-sources = <0 1 2>;
> color = <LED_COLOR_ID_WHITE>;
> };
>
> led@1,0 {
> reg = <1>;
> led-sources = <3>;
> color = <LED_COLOR_ID_RED>;
> };
>
> led@1,1 {
> reg = <1>;
> led-sources = <4>;
> color = <LED_COLOR_ID_GREEN>;
> };
>
> led@1,2 {
> reg = <1>;
> led-sources = <5>;
> color = <LED_COLOR_ID_BLUE>;
> };
>
> I am not comfortable with the 'reg' property being same for multiple
> nodes. Perhaps the 'reg' property shouldn't be used, since the
> information needed by the driver can be deduced from the 'led-sources'.
I agree. You can name the sub-nodes like led0,led1,led2 etc.
reg is convenient if each sub-node refers to single iout, but
in this case it is unnecessary complication. You can infer the
reg in dt parser basing on led-sources.
And we need these bindings in a separate patch adding a new file
in Documentation/devicetree/bindings/leds.
You should also mention what are the allowed led-sources
configurations, i.e. I presume that only groups of (0,1,2),
(2,3,4) etc. are allowed, or a single iout per child node.
[...]
> +static int omnia_leds_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct device *dev = &client->dev;
> + struct device_node *np = dev->of_node, *child;
> + struct omnia_leds *leds;
> + int ret, count;
> +
> + count = of_get_available_child_count(np);
> + if (!count) {
> + dev_err(dev, "LEDs are not defined in device tree!\n");
> + return -ENODEV;
> + } else if (count > 3 * OMNIA_BOARD_LEDS) {
> + dev_err(dev, "Too many LEDs defined in device tree!\n");
> + return -EINVAL;
> + }
> +
> + leds = devm_kzalloc(dev, sizeof(*leds) + count * sizeof(leds->leds[0]),
> + GFP_KERNEL);
> + if (!leds)
> + return -ENOMEM;
> +
> + leds->client = client;
> + i2c_set_clientdata(client, leds);
> +
> + mutex_init(&leds->lock);
> +
> + for_each_available_child_of_node(np, child) {
> + ret = omnia_led_register(leds, &child->fwnode);
> + if (ret < 0)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int omnia_leds_remove(struct i2c_client *client)
> +{
> + u8 buf[OMNIA_CMD_LED_COLOR_LEN];
> +
> + /* put all LEDs into default (HW triggered) mode */
> + i2c_smbus_write_byte_data(client, CMD_LED_MODE,
> + CMD_LED_MODE_LED(OMNIA_BOARD_LEDS));
> +
> + /* set all LEDs color to [255, 255, 255] */
> + buf[OMNIA_CMD] = CMD_LED_COLOR;
> + buf[OMNIA_CMD_LED_COLOR_LED] = OMNIA_BOARD_LEDS;
> + buf[OMNIA_CMD_LED_COLOR_R] = 255;
> + buf[OMNIA_CMD_LED_COLOR_G] = 255;
> + buf[OMNIA_CMD_LED_COLOR_B] = 255;
What is the rationale behind setting all LEDs to max_brighntess
on driver removal?
--
Best regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs
2020-03-21 18:55 ` Jacek Anaszewski
@ 2020-03-21 20:44 ` Marek Behun
2020-03-22 15:28 ` Jacek Anaszewski
0 siblings, 1 reply; 29+ messages in thread
From: Marek Behun @ 2020-03-21 20:44 UTC (permalink / raw)
To: Jacek Anaszewski; +Cc: linux-leds, Pavel Machek
On Sat, 21 Mar 2020 19:55:15 +0100
Jacek Anaszewski <jacek.anaszewski@gmail.com> wrote:
> What is the rationale behind setting all LEDs to max_brighntess
> on driver removal?
>
For each RGB LED the microcontroller has ON/OFF setting, and color
setting. When in HW triggering mode, the HW triggering manipulates the
ON/OFF setting and the LED blinks with the color set by the color
setting.
If I did not set color to white before driver removal, then the HW
triggering would blink the LEDs with the color they had set by the
user. That could be [0,0,0], so the LEDs wouldn't blink at all.
So on driver removal the LEDs are set into state in which they are after
reset.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs
2020-03-21 20:44 ` Marek Behun
@ 2020-03-22 15:28 ` Jacek Anaszewski
0 siblings, 0 replies; 29+ messages in thread
From: Jacek Anaszewski @ 2020-03-22 15:28 UTC (permalink / raw)
To: Marek Behun; +Cc: linux-leds, Pavel Machek
Hi Marek,
On 3/21/20 9:44 PM, Marek Behun wrote:
> On Sat, 21 Mar 2020 19:55:15 +0100
> Jacek Anaszewski <jacek.anaszewski@gmail.com> wrote:
>
>> What is the rationale behind setting all LEDs to max_brighntess
>> on driver removal?
>>
>
> For each RGB LED the microcontroller has ON/OFF setting, and color
> setting. When in HW triggering mode, the HW triggering manipulates the
> ON/OFF setting and the LED blinks with the color set by the color
> setting.
>
> If I did not set color to white before driver removal, then the HW
> triggering would blink the LEDs with the color they had set by the
> user. That could be [0,0,0], so the LEDs wouldn't blink at all.
>
> So on driver removal the LEDs are set into state in which they are after
> reset.
Sounds reasonable, ack.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs
2020-03-19 18:16 [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs Marek Behún
` (2 preceding siblings ...)
2020-03-21 18:55 ` Jacek Anaszewski
@ 2020-03-21 21:53 ` Marek Behun
2020-03-21 22:16 ` Pavel Machek
3 siblings, 1 reply; 29+ messages in thread
From: Marek Behun @ 2020-03-21 21:53 UTC (permalink / raw)
To: linux-leds; +Cc: Jacek Anaszewski, Pavel Machek
Hmm.
The microcontroller on Turris Omnia supports more settings than just
LEDs (usb3 port power and input button for example).
I am wondering if this approach (registering LED driver to
communicate with the microcontroller) is correct, since the
microcontroller can do other things.
For Turris Mox firmware I created a driver in
drivers/firmware/turris-mox-rwtm.c.
Maybe I should create I driver in drivers/firmware/ for the Omnia
microcontroller, and then the LED driver could use functions exported
by the microcontroller driver to manipulate LEDs.
What do you think?
Marek
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs
2020-03-21 21:53 ` Marek Behun
@ 2020-03-21 22:16 ` Pavel Machek
2020-03-21 22:36 ` Marek Behun
0 siblings, 1 reply; 29+ messages in thread
From: Pavel Machek @ 2020-03-21 22:16 UTC (permalink / raw)
To: Marek Behun; +Cc: linux-leds, Jacek Anaszewski
[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]
Hi!
> The microcontroller on Turris Omnia supports more settings than just
> LEDs (usb3 port power and input button for example).
>
> I am wondering if this approach (registering LED driver to
> communicate with the microcontroller) is correct, since the
> microcontroller can do other things.
>
> For Turris Mox firmware I created a driver in
> drivers/firmware/turris-mox-rwtm.c.
this should be drivers/platform/turris/, I believe. It is not
_firmware_, is it?
> Maybe I should create I driver in drivers/firmware/ for the Omnia
> microcontroller, and then the LED driver could use functions exported
> by the microcontroller driver to manipulate LEDs.
>
> What do you think?
So... you can do that, but you'll have multiple maintainers
coordinating updates at that point. Feel free to split LED support
into two files so that it can be moved to different directory later...
Best regards,
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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs
2020-03-21 22:16 ` Pavel Machek
@ 2020-03-21 22:36 ` Marek Behun
2020-03-22 15:50 ` Dan Murphy
2020-04-06 8:40 ` Pavel Machek
0 siblings, 2 replies; 29+ messages in thread
From: Marek Behun @ 2020-03-21 22:36 UTC (permalink / raw)
To: Pavel Machek; +Cc: linux-leds, Jacek Anaszewski
On Sat, 21 Mar 2020 23:16:53 +0100
Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
> > The microcontroller on Turris Omnia supports more settings than just
> > LEDs (usb3 port power and input button for example).
> >
> > I am wondering if this approach (registering LED driver to
> > communicate with the microcontroller) is correct, since the
> > microcontroller can do other things.
> >
> > For Turris Mox firmware I created a driver in
> > drivers/firmware/turris-mox-rwtm.c.
>
> this should be drivers/platform/turris/, I believe. It is not
> _firmware_, is it?
>
It is code that interacts with the firmware. It already is merged in
drivers/firmware/. The raspberrypi firmware interacting drivers is also
there...
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs
2020-03-21 22:36 ` Marek Behun
@ 2020-03-22 15:50 ` Dan Murphy
2020-04-06 8:40 ` Pavel Machek
1 sibling, 0 replies; 29+ messages in thread
From: Dan Murphy @ 2020-03-22 15:50 UTC (permalink / raw)
To: Marek Behun, Pavel Machek; +Cc: linux-leds, Jacek Anaszewski
Marek
On 3/21/20 5:36 PM, Marek Behun wrote:
> On Sat, 21 Mar 2020 23:16:53 +0100
> Pavel Machek <pavel@ucw.cz> wrote:
>
>> Hi!
>>
>>> The microcontroller on Turris Omnia supports more settings than just
>>> LEDs (usb3 port power and input button for example).
>>>
>>> I am wondering if this approach (registering LED driver to
>>> communicate with the microcontroller) is correct, since the
>>> microcontroller can do other things.
>>>
>>> For Turris Mox firmware I created a driver in
>>> drivers/firmware/turris-mox-rwtm.c.
>> this should be drivers/platform/turris/, I believe. It is not
>> _firmware_, is it?
>>
> It is code that interacts with the firmware. It already is merged in
> drivers/firmware/. The raspberrypi firmware interacting drivers is also
> there...
Would a MFD driver be better here?
Dan
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs
2020-03-21 22:36 ` Marek Behun
2020-03-22 15:50 ` Dan Murphy
@ 2020-04-06 8:40 ` Pavel Machek
1 sibling, 0 replies; 29+ messages in thread
From: Pavel Machek @ 2020-04-06 8:40 UTC (permalink / raw)
To: Marek Behun; +Cc: linux-leds, Jacek Anaszewski
[-- Attachment #1: Type: text/plain, Size: 1428 bytes --]
On Sat 2020-03-21 23:36:38, Marek Behun wrote:
> On Sat, 21 Mar 2020 23:16:53 +0100
> Pavel Machek <pavel@ucw.cz> wrote:
>
> > Hi!
> >
> > > The microcontroller on Turris Omnia supports more settings than just
> > > LEDs (usb3 port power and input button for example).
> > >
> > > I am wondering if this approach (registering LED driver to
> > > communicate with the microcontroller) is correct, since the
> > > microcontroller can do other things.
> > >
> > > For Turris Mox firmware I created a driver in
> > > drivers/firmware/turris-mox-rwtm.c.
> >
> > this should be drivers/platform/turris/, I believe. It is not
> > _firmware_, is it?
>
> It is code that interacts with the firmware. It already is merged in
> drivers/firmware/. The raspberrypi firmware interacting drivers is
> also
Everything has firmware these days, so everything is interacting with
firmware. We have drivers/platform, not drivers/firmware/sata.
drivers/firmware is for firmware that runs on _main_ CPU.
drivers/platform is for talking with embedded controllers (that may
have their own firmware).
But I suggest you put it all into drivers/leds for now, and then maybe
move it, because otherwise it will be nightmare for maintainers.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2020-04-06 21:10 UTC | newest]
Thread overview: 29+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-03-19 18:16 [PATCH RFC leds-next] leds: initial support for Turris Omnia LEDs Marek Behún
2020-03-21 15:33 ` Pavel Machek
2020-03-28 12:08 ` Jacek Anaszewski
2020-03-28 12:27 ` Marek Behun
2020-03-28 12:36 ` Marek Behun
2020-03-28 13:01 ` Jacek Anaszewski
2020-03-28 17:20 ` Marek Behun
2020-03-29 12:53 ` Jacek Anaszewski
2020-04-02 14:29 ` Marek Behun
2020-04-02 20:19 ` Jacek Anaszewski
2020-04-02 20:57 ` Marek Behun
2020-04-02 21:00 ` Jacek Anaszewski
2020-04-06 21:10 ` Pavel Machek
2020-04-06 21:08 ` Pavel Machek
2020-04-06 20:42 ` Pavel Machek
2020-03-21 15:34 ` Pavel Machek
2020-03-21 18:01 ` Jacek Anaszewski
2020-03-21 20:50 ` Marek Behun
2020-03-22 15:51 ` Jacek Anaszewski
2020-04-06 8:34 ` Pavel Machek
2020-04-06 13:53 ` Marek Behun
2020-03-21 18:55 ` Jacek Anaszewski
2020-03-21 20:44 ` Marek Behun
2020-03-22 15:28 ` Jacek Anaszewski
2020-03-21 21:53 ` Marek Behun
2020-03-21 22:16 ` Pavel Machek
2020-03-21 22:36 ` Marek Behun
2020-03-22 15:50 ` Dan Murphy
2020-04-06 8:40 ` Pavel Machek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox