Messages in this thread | | | Subject | Re: [PATCH v3 1/5] leds: lm3532: Fix brightness control for i2c mode | From | Dan Murphy <> | Date | Wed, 28 Aug 2019 10:28:01 -0500 |
| |
Jacek
On 8/27/19 4:14 PM, Jacek Anaszewski wrote: > Dan, > > On 8/27/19 2:44 PM, Dan Murphy wrote: >> Tony >> >> On 8/27/19 7:18 AM, Pavel Machek wrote: >>> On Mon 2019-08-26 15:44:37, Tony Lindgren wrote: >>>> * Pavel Machek <pavel@ucw.cz> [190826 22:14]: >>>>> On Mon 2019-08-26 14:58:22, Tony Lindgren wrote: >>>>>> Hi, >>>>>> >>>>>> * Dan Murphy <dmurphy@ti.com> [190820 19:53]: >>>>>>> Fix the brightness control for I2C mode. Instead of >>>>>>> changing the full scale current register update the ALS target >>>>>>> register for the appropriate banks. >>>>>>> >>>>>>> In addition clean up some code errors and random misspellings found >>>>>>> during coding. >>>>>>> >>>>>>> Tested on Droid4 as well as LM3532 EVM connected to a BeagleBoneBlack >>>>>>> >>>>>>> Fixes: e37a7f8d77e1 ("leds: lm3532: Introduce the lm3532 LED driver") >>>>>>> Reported-by: Pavel Machek <pavel@ucw.cz> >>>>>>> Signed-off-by: Dan Murphy <dmurphy@ti.com> >>>>>>> --- >>>>>>> >>>>>>> v3 - Removed register define updates - >>>>>>> https://lore.kernel.org/patchwork/patch/1114542/ >>>>>> Looks like starting with this patch in Linux next the LCD on droid4 >>>>>> is so dim it's unreadable even with brightness set to 255. Setting >>>>>> brightness to 0 does blank it completely though. >>>>>> >>>>>> Did something maybe break with the various patch revisions or are >>>>>> we now missing some dts patch? >>>>> Maybe missing dts patch. We should provide maximum current the LED can >>>>> handle... >>>> Or i2c control is somehow broken and only als control now works? >> With only setting CONFIG_LEDS_LM3532=m to the next branch I get full >> brightness with 255. >> >> I also see half brightness at 128 with the ramp down working. >> >> I am not able to reproduce this issue on my device. >> >>> Well, max current led is obviously missing. Plus code does not check >>> the return from reading led-max-microamp. >> led-max-microamp is optional so there is no need to check the return. > It's also ugly to not check it when you have it assigned. > We'll soon receive complaints from static checkers about pointless > assignment. > > I'd distinguish between cases when parsing failed, > and when property has not been provided. > > if (fwnode_property_present(child, "led-max-microamp")) { > if (fwnode_property_read_u32(child, "led-max-microamp", > &led->full_scale_current); > dev_err(&priv->client->dev, > "Failed to parse led-max-microamp property\n")
I am OK with doing this but I think the else case logging is extra.
Again the property is optional and if the user decides not to populate it then there should not
be a log of that it is missing.
Dan
> } else { > dev_info(&priv->client->dev, > led-max-microamp property is missing\n") > } > >> full_scale_current should be 0 if not populated and in the init only if >> this variable is set does >> >> the code program the register otherwise it is default of 20.2 mA.
| |