From: Jacek Anaszewski <jacek.anaszewski@gmail.com>
To: Dan Murphy <dmurphy@ti.com>, pavel@ucw.cz
Cc: linux-leds@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v12 12/16] leds: lp55xx: Add multicolor framework support to lp55xx
Date: Sat, 12 Oct 2019 15:27:04 +0200 [thread overview]
Message-ID: <f018e5d4-ed28-e8bb-40ec-4bd8d5f29fe6@gmail.com> (raw)
In-Reply-To: <3cf3041b-5b91-0200-3e0f-ea5e89d14710@ti.com>
Dan,
On 10/12/19 2:50 AM, Dan Murphy wrote:
> Jacek
>
> On 10/11/19 3:36 PM, Jacek Anaszewski wrote:
>> Dan,
>>
>> On 10/11/19 3:06 PM, Dan Murphy wrote:
>>> Add multicolor framework support for the lp55xx family.
>>>
>>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>>> ---
>>> drivers/leds/Kconfig | 1 +
>>> drivers/leds/leds-lp55xx-common.c | 176 +++++++++++++++++++---
>>> drivers/leds/leds-lp55xx-common.h | 9 ++
>>> include/linux/platform_data/leds-lp55xx.h | 7 +
>>> 4 files changed, 169 insertions(+), 24 deletions(-)
>>>
>>> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
>>> index fb614a6b9afa..5706bf8d8bd1 100644
>>> --- a/drivers/leds/Kconfig
>>> +++ b/drivers/leds/Kconfig
>>> @@ -377,6 +377,7 @@ config LEDS_LP50XX
>>> config LEDS_LP55XX_COMMON
>>> tristate "Common Driver for TI/National
>>> LP5521/5523/55231/5562/8501"
>>> depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562 ||
>>> LEDS_LP8501
>>> + depends on OF
>>> select FW_LOADER
>>> select FW_LOADER_USER_HELPER
>>> help
>>> diff --git a/drivers/leds/leds-lp55xx-common.c
>>> b/drivers/leds/leds-lp55xx-common.c
>>> index 44ced02b49f9..1417df6df8a7 100644
>>> --- a/drivers/leds/leds-lp55xx-common.c
>>> +++ b/drivers/leds/leds-lp55xx-common.c
>>> @@ -131,14 +131,54 @@ static struct attribute *lp55xx_led_attrs[] = {
>>> };
>>> ATTRIBUTE_GROUPS(lp55xx_led);
>>> +static int lp55xx_map_channel(struct lp55xx_led *led, int color_id,
>>> + enum led_brightness brightness)
>>> +{
>>> + int i;
>>> +
>>> + for (i = 0; i < led->mc_cdev.num_leds; i++) {
>>> + if (led->color_component[i].color_id == color_id) {
>>> + led->color_component[i].brightness = brightness;
>>> + return 0;
>>> + }
>>> + }
>>> +
>>> + return -EINVAL;
>>> +}
>>> +
>>> static int lp55xx_set_brightness(struct led_classdev *cdev,
>>> enum led_brightness brightness)
>>> {
>>> + struct led_mc_color_conversion
>>> color_component[LP55XX_MAX_GROUPED_CHAN];
>>> struct lp55xx_led *led = cdev_to_lp55xx_led(cdev);
>>> struct lp55xx_device_config *cfg = led->chip->cfg;
>>> + int ret;
>>> + int i;
>>> - led->brightness = (u8)brightness;
>>> - return cfg->brightness_fn(led);
>>> + if (led->mc_cdev.num_leds > 1) {
>>> + if (!cfg->color_intensity_fn)
>>> + return -EINVAL;
>>> +
>>> + led_mc_calc_color_components(&led->mc_cdev, brightness,
>>> + color_component);
>>> +
>>> + for (i = 0; i < led->mc_cdev.num_leds; i++) {
>>> + ret = lp55xx_map_channel(led,
>>> + color_component[i].color_id,
>>> + color_component[i].brightness);
>>> + if (ret)
>>> + return ret;
>>> + }
>>> +
>>> + ret = cfg->color_intensity_fn(led);
>>> + if (ret)
>>> + return ret;
>>> + } else {
>>> + led->brightness = (u8)brightness;
>>> + ret = cfg->brightness_fn(led);
>>> + }
>>> +
>>> + return ret;
>>> }
>>> static int lp55xx_init_led(struct lp55xx_led *led,
>>> @@ -147,9 +187,9 @@ static int lp55xx_init_led(struct lp55xx_led *led,
>>> struct lp55xx_platform_data *pdata = chip->pdata;
>>> struct lp55xx_device_config *cfg = chip->cfg;
>>> struct device *dev = &chip->cl->dev;
>>> + int max_channel = cfg->max_channel;
>>> char name[32];
>>> int ret;
>>> - int max_channel = cfg->max_channel;
>>> if (chan >= max_channel) {
>>> dev_err(dev, "invalid channel: %d / %d\n", chan, max_channel);
>>> @@ -159,10 +199,34 @@ static int lp55xx_init_led(struct lp55xx_led *led,
>>> if (pdata->led_config[chan].led_current == 0)
>>> return 0;
>>> + if (pdata->led_config[chan].name) {
>>> + led->cdev.name = pdata->led_config[chan].name;
>>> + } else {
>>> + snprintf(name, sizeof(name), "%s:channel%d",
>>> + pdata->label ? : chip->cl->name, chan);
>>> + led->cdev.name = name;
>>> + }
>>> +
>>> + if (pdata->led_config[chan].num_colors > 1) {
>>> + led->mc_cdev.led_cdev = &led->cdev;
>>> + led->cdev.brightness_set_blocking = lp55xx_set_brightness;
>>> + led->cdev.groups = lp55xx_led_groups;
>>> + led->mc_cdev.num_leds = pdata->led_config[chan].num_colors;
>>> + led->mc_cdev.available_colors =
>>> + pdata->led_config[chan].available_colors;
>>> + memcpy(led->color_component,
>>> + pdata->led_config[chan].color_component,
>>> + sizeof(led->color_component));
>>> + } else {
>>> +
>>> + led->cdev.default_trigger =
>>> + pdata->led_config[chan].default_trigger;
>>> + led->cdev.brightness_set_blocking = lp55xx_set_brightness;
>>> + } led->cdev.groups = lp55xx_led_groups;
>>> +
>>> led->led_current = pdata->led_config[chan].led_current;
>>> led->max_current = pdata->led_config[chan].max_current;
>>> led->chan_nr = pdata->led_config[chan].chan_nr;
>>> - led->cdev.default_trigger =
>>> pdata->led_config[chan].default_trigger;
>>> if (led->chan_nr >= max_channel) {
>>> dev_err(dev, "Use channel numbers between 0 and %d\n",
>>> @@ -170,18 +234,11 @@ static int lp55xx_init_led(struct lp55xx_led *led,
>>> return -EINVAL;
>>> }
>>> - led->cdev.brightness_set_blocking = lp55xx_set_brightness;
>>> - led->cdev.groups = lp55xx_led_groups;
>>> -
>>> - if (pdata->led_config[chan].name) {
>>> - led->cdev.name = pdata->led_config[chan].name;
>>> - } else {
>>> - snprintf(name, sizeof(name), "%s:channel%d",
>>> - pdata->label ? : chip->cl->name, chan);
>>> - led->cdev.name = name;
>>> - }
>>> + if (pdata->led_config[chan].num_colors > 1)
>>> + ret = led_classdev_multicolor_register(dev, &led->mc_cdev);
>>> + else
>>> + ret = led_classdev_register(dev, &led->cdev);
>> Why not devm versions?
>
> I will change the multicolor but not the led_classdev
Having one devm and the other not will look awkward.
This does not seem to be a big effort. I propose to add a preceding
patch that will first switch monochrome led_classdev_register to devm,
and of course clean up error paths (remove lp55xx_unregister_leds()),
and update error paths in all callers which will be just removing
the calls to lp55xx_unregister_leds().
>>
>>> - ret = led_classdev_register(dev, &led->cdev);
>>> if (ret) {
>>> dev_err(dev, "led register err: %d\n", ret);
>>> return ret;
>>> @@ -466,7 +523,6 @@ int lp55xx_register_leds(struct lp55xx_led *led,
>>> struct lp55xx_chip *chip)
>>> dev_err(&chip->cl->dev, "empty brightness configuration\n");
>>> return -EINVAL;
>>> }
>>> -
>> This empty line removal was not intended I suppose.
>
> I can put it back
>
>
>>
>>> for (i = 0; i < num_channels; i++) {
>>> /* do not initialize channels that are not connected */
>>> @@ -538,6 +594,82 @@ void lp55xx_unregister_sysfs(struct lp55xx_chip
>>> *chip)
>>> }
>>> EXPORT_SYMBOL_GPL(lp55xx_unregister_sysfs);
>>> +static int lp5xx_parse_common_child(struct device_node *np,
>>> + struct lp55xx_led_config *cfg,
>>> + int chan_num, bool is_multicolor,
>>> + int color_num)
>>> +{
>>> + u32 led_number;
>>> + int ret;
>>> +
>>> + of_property_read_string(np, "chan-name",
>>> + &cfg[chan_num].name);
>>> + of_property_read_u8(np, "led-cur",
>>> + &cfg[chan_num].led_current);
>>> + of_property_read_u8(np, "max-cur",
>>> + &cfg[chan_num].max_current);
>>> +
>>> + ret = of_property_read_u32(np, "reg", &led_number);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + if (led_number < 0 || led_number > 6)
>>> + return -EINVAL;
>>> +
>>> + if (is_multicolor)
>>> + cfg[chan_num].color_component[color_num].output_num =
>>> + led_number;
>>> + else
>>> + cfg[chan_num].chan_nr = led_number;
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int lp5xx_parse_channel_child(struct device_node *np,
>>> + struct lp55xx_led_config *cfg,
>>> + int child_number)
>>> +{
>>> + struct device_node *child;
>>> + int channel_color;
>>> + int num_colors = 0;
>>> + u32 color_id;
>>> + int ret;
>>> +
>>> + cfg[child_number].default_trigger =
>>> + of_get_property(np, "linux,default-trigger", NULL);
>>> +
>>> + ret = of_property_read_u32(np, "color", &channel_color);
>>> + if (ret)
>>> + channel_color = ret;
>>> +
>>> +
>>> + if (channel_color == LED_COLOR_ID_MULTI) {
>>> + for_each_child_of_node(np, child) {
>>> + ret = lp5xx_parse_common_child(child, cfg,
>>> + child_number, true,
>>> + num_colors);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + ret = of_property_read_u32(child, "color", &color_id);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + cfg[child_number].color_component[num_colors].color_id =
>>> + color_id;
>>> + set_bit(color_id, &cfg[child_number].available_colors);
>>> + num_colors++;
>>> + }
>>> +
>>> + cfg[child_number].num_colors = num_colors;
>>> + } else {
>>> + return lp5xx_parse_common_child(np, cfg, child_number, false,
>>> + num_colors);
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>> struct lp55xx_platform_data *lp55xx_of_populate_pdata(struct device
>>> *dev,
>>> struct device_node *np)
>>> {
>>> @@ -546,6 +678,7 @@ struct lp55xx_platform_data
>>> *lp55xx_of_populate_pdata(struct device *dev,
>>> struct lp55xx_led_config *cfg;
>>> int num_channels;
>>> int i = 0;
>>> + int ret;
>>> pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>>> if (!pdata)
>>> @@ -565,14 +698,9 @@ struct lp55xx_platform_data
>>> *lp55xx_of_populate_pdata(struct device *dev,
>>> pdata->num_channels = num_channels;
>>> for_each_child_of_node(np, child) {
>>> - cfg[i].chan_nr = i;
>>> -
>>> - of_property_read_string(child, "chan-name", &cfg[i].name);
>>> - of_property_read_u8(child, "led-cur", &cfg[i].led_current);
>>> - of_property_read_u8(child, "max-cur", &cfg[i].max_current);
>>> - cfg[i].default_trigger =
>>> - of_get_property(child, "linux,default-trigger", NULL);
>>> -
>>> + ret = lp5xx_parse_channel_child(child, cfg, i);
>>> + if (ret)
>>> + return ERR_PTR(-EINVAL);
>>> i++;
>>> }
>>> diff --git a/drivers/leds/leds-lp55xx-common.h
>>> b/drivers/leds/leds-lp55xx-common.h
>>> index 783ed5103ce5..75d57fb835c3 100644
>>> --- a/drivers/leds/leds-lp55xx-common.h
>>> +++ b/drivers/leds/leds-lp55xx-common.h
>>> @@ -12,6 +12,8 @@
>>> #ifndef _LEDS_LP55XX_COMMON_H
>>> #define _LEDS_LP55XX_COMMON_H
>>> +#include <linux/led-class-multicolor.h>
>>> +
>>> enum lp55xx_engine_index {
>>> LP55XX_ENGINE_INVALID,
>>> LP55XX_ENGINE_1,
>>> @@ -109,6 +111,9 @@ struct lp55xx_device_config {
>>> /* access brightness register */
>>> int (*brightness_fn)(struct lp55xx_led *led);
>>> + /* access specific brightness register */
>>> + int (*color_intensity_fn)(struct lp55xx_led *led);
>> Wouldn't multicolor_brightness_fn be more accurate now ?
>
> So just change the name to multicolor_brightness_fn?
And the op implementations in the clients, like:
s/lp5521_led_intensity/lp5521_led_mc_brightness/
--
Best regards,
Jacek Anaszewski
next prev parent reply other threads:[~2019-10-12 13:27 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-11 13:06 [PATCH v12 00/16] Multicolor Framework v12 Dan Murphy
2019-10-11 13:06 ` [PATCH v12 01/16] dt: bindings: Add multicolor class dt bindings documention Dan Murphy
2019-10-11 13:06 ` [PATCH v12 02/16] dt-bindings: leds: Add multicolor ID to the color ID list Dan Murphy
2019-10-11 13:06 ` [PATCH v12 03/16] " Dan Murphy
2019-10-11 13:06 ` [PATCH v12 04/16] leds: multicolor: Introduce a multicolor class definition Dan Murphy
2019-10-11 19:53 ` Jacek Anaszewski
2019-10-14 6:18 ` kbuild test robot
2019-10-11 13:06 ` [PATCH v12 05/16] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers Dan Murphy
2019-10-11 13:06 ` [PATCH v12 06/16] leds: lp50xx: Add the LP50XX family of the RGB LED driver Dan Murphy
2019-10-11 20:04 ` Jacek Anaszewski
2019-10-14 9:17 ` kbuild test robot
2019-10-19 17:13 ` Jacek Anaszewski
2019-10-21 11:46 ` Dan Murphy
2019-10-11 13:06 ` [PATCH v12 07/16] dt: bindings: lp55xx: Be consistent in the document with LED acronym Dan Murphy
2019-10-11 13:06 ` [PATCH v12 08/16] dt: bindings: lp55xx: Update binding for Multicolor Framework Dan Murphy
2019-10-11 20:15 ` Jacek Anaszewski
2019-10-12 0:54 ` Dan Murphy
2019-10-12 13:32 ` Jacek Anaszewski
2019-10-11 13:06 ` [PATCH v12 09/16] ARM: dts: n900: Add reg property to the LP5523 channel node Dan Murphy
2019-10-11 13:06 ` [PATCH v12 10/16] ARM: dts: imx6dl-yapp4: Add reg property to the lp5562 " Dan Murphy
2019-10-11 13:06 ` [PATCH v12 11/16] ARM: dts: ste-href: Add reg property to the LP5521 channel nodes Dan Murphy
2019-10-11 13:06 ` [PATCH v12 12/16] leds: lp55xx: Add multicolor framework support to lp55xx Dan Murphy
2019-10-11 20:36 ` Jacek Anaszewski
2019-10-12 0:50 ` Dan Murphy
2019-10-12 13:27 ` Jacek Anaszewski [this message]
2019-10-11 13:06 ` [PATCH v12 13/16] leds: lp5523: Update the lp5523 code to add intensity function Dan Murphy
2019-10-11 13:06 ` [PATCH v12 14/16] leds: lp5521: Add multicolor framework intensity support Dan Murphy
2019-10-11 13:06 ` [PATCH v12 15/16] leds: lp55xx: Fix checkpatch file permissions issues Dan Murphy
2019-10-11 13:06 ` [PATCH v12 16/16] leds: lp5523: Fix checkpatch issues in the code Dan Murphy
2019-10-11 19:40 ` [PATCH v12 00/16] Multicolor Framework v12 Jacek Anaszewski
2019-10-12 0:48 ` Dan Murphy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f018e5d4-ed28-e8bb-40ec-4bd8d5f29fe6@gmail.com \
--to=jacek.anaszewski@gmail.com \
--cc=dmurphy@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=pavel@ucw.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).