Re: [PATCH v8 8/9] leds: lp50xx: Add the LP50XX family of the RGB LED driver

[Jacek Anaszewski]

Dan,

On 9/23/19 7:56 PM, Dan Murphy wrote:
> Jacek
> 
> On 9/21/19 10:11 AM, Jacek Anaszewski wrote:
>> Dan,
>>
>> On 9/20/19 7:41 PM, Dan Murphy wrote:
>>> Introduce the LP5036/30/24/18/12/9 RGB LED driver.
>>> The difference in these parts are the number of
>>> LED outputs where the:
>>>
>>> LP5036 can control 36 LEDs
>>> LP5030 can control 30 LEDs
>>> LP5024 can control 24 LEDs
>>> LP5018 can control 18 LEDs
>>> LP5012 can control 12 LEDs
>>> LP509 can control 9 LEDs
>>>
>>> The device has the ability to group LED output into control banks
>>> so that multiple LED banks can be controlled with the same mixing and
>>> brightness. Inversely the LEDs can also be controlled independently.
>>>
>>> Signed-off-by: Dan Murphy<dmurphy@xxxxxx>
>>> ---
>>> Â drivers/leds/KconfigÂÂÂÂÂÂ |ÂÂ 7 +
>>> Â drivers/leds/MakefileÂÂÂÂÂ |ÂÂ 1 +
>>> Â drivers/leds/leds-lp50xx.c | 785 +++++++++++++++++++++++++++++++++++++
>>> Â 3 files changed, 793 insertions(+)
>>> Â create mode 100644 drivers/leds/leds-lp50xx.c
>>>
>>> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
>>> index cfb1ebb6517f..1c0cacb100e6 100644
>>> --- a/drivers/leds/Kconfig
>>> +++ b/drivers/leds/Kconfig
>>> @@ -363,6 +363,13 @@ config LEDS_LP3952
>>> ÂÂÂÂÂÂÂ To compile this driver as a module, choose M here: the
>>> ÂÂÂÂÂÂÂ module will be called leds-lp3952.
>>> Â +config LEDS_LP50XX
>>> +ÂÂÂ tristate "LED Support for TI LP5036/30/24/18 LED driver chip"
>>> +ÂÂÂ depends on LEDS_CLASS && REGMAP_I2C
>> && OF
> 
> Not sure why I would add that since we are using fw_node calls not
> of_property calls.
> 
> The fw_node calls are built in as default kernel so these should always
> be available.

Ah, right. Forget it.

[...]
>>> +static int lp50xx_brightness_set(struct led_classdev *cdev,
>>> +ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ enum led_brightness brightness)
>>> +{
>>> +ÂÂÂ struct lp50xx_led *led = container_of(cdev, struct lp50xx_led,
>>> led_dev);
>>> +ÂÂÂ int ret = 0;
>>> +ÂÂÂ u8 reg_val;
>>> +
>>> +ÂÂÂ mutex_lock(&led->priv->lock);
>>> +
>>> +ÂÂÂ if (led->ctrl_bank_enabled)
>>> +ÂÂÂÂÂÂÂ reg_val = led->priv->chip_info->bank_brt_reg;
>>> +ÂÂÂ else
>>> +ÂÂÂÂÂÂÂ reg_val = led->priv->chip_info->led_brightness0_reg +
>>> +ÂÂÂÂÂÂÂÂÂÂÂÂÂ led->led_number;
>>> +
>>> +ÂÂÂ ret = regmap_write(led->priv->regmap, reg_val, brightness);
>>> +ÂÂÂ if (ret)
>>> +ÂÂÂÂÂÂÂ goto err_out;
>>> +
>>> +ÂÂÂ ret = lp50xx_set_intensity(led);
>>> +err_out:
>>> +ÂÂÂ mutex_unlock(&led->priv->lock);
>>> +ÂÂÂ return ret;
>>> +}
>>> +
>>> +static enum led_brightness lp50xx_brightness_get(struct led_classdev
>>> *cdev)
>> Do we really need this op? Is it possible that the device will alter
>> brightness autonomously ? IOW can't we rely on what we've written
>> previously to the hw?
> 
> How can we be sure that the previous I/O actually wrote to the device?

brightness_set* op returned 0?

> If set_brightness fails does the LED class not modify the current
> brightness setting?

It does modify it on every brightness setting op in
led_set_brightness_nosleep().

> So we have mismatched values and with this call back we can refresh the
> right setting.
> 
> But I can remove it if you see no value in doing get_brightness call back.

If write to the device fails it signifies much more serious problem
than resulting mismatched values. Have you experienced that?

>>> +{
>>> +ÂÂÂ struct lp50xx_led *led = container_of(cdev, struct lp50xx_led,
>>> led_dev);
>>> +ÂÂÂ unsigned int brt_val;
>>> +ÂÂÂ u8 reg_val;
>>> +ÂÂÂ int ret;
>>> +
>>> +ÂÂÂ mutex_lock(&led->priv->lock);
>>> +
>>> +ÂÂÂ if (led->ctrl_bank_enabled)
>>> +ÂÂÂÂÂÂÂ reg_val = led->priv->chip_info->bank_brt_reg;
>>> +ÂÂÂ else
>>> +ÂÂÂÂÂÂÂ reg_val = led->priv->chip_info->led_brightness0_reg +
>>> led->led_number;
>>> +
>>> +ÂÂÂ ret = regmap_read(led->priv->regmap, reg_val, &brt_val);
>>> +
>>> +ÂÂÂ mutex_unlock(&led->priv->lock);
>>> +
>>> +ÂÂÂ return brt_val;
>>> +}
>>> +
>>> +static int lp50xx_set_color(struct led_classdev_mc *mcled_cdev,
>>> +ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ int color, int value)
>>> +{
>>> +ÂÂÂ struct lp50xx_led *led = mcled_cdev_to_led(mcled_cdev);
>>> +
>>> +ÂÂÂ led->led_intensity[color] = value;
>>> +
>>> +ÂÂÂ return 0;
>>> +}
>>> +
>>> +static int lp50xx_set_banks(struct lp50xx *priv, u32 led_strings[])
>> This is a bit misleading to introduce "strings" when the function
>> claims to set "banks". Let's have the parameter name "led_banks".
> Ack
>>
>>> +{
>>> +ÂÂÂ u8 led_ctrl_enable = 0;
>>> +ÂÂÂ u8 led1_ctrl_enable = 0;
>>> +ÂÂÂ u8 ctrl_ext = 0;
>> Let's have below instead of the above three variables:
>>
>> ÂÂÂÂu32 bank_enable_mask = 0;
>> ÂÂÂÂu8 led_config_lo, led_config_hi;
> 
> Ack but I have to keep the initialization to 0 as the compiler
> complained that these values may not be set.

It was because in your code values are assigned in a loop that
may or may not execute at all, depending on num_leds.
In my example variables will be assigned unconditionally
so there should be no compiler complaints.


-- 
Best regards,
Jacek Anaszewski