| Message ID | cover.1578324703.git.agx@sigxcpu.org |
|---|---|
| Headers | show |
| Series | leds: lm3692x: Allow to set ovp and brigthness mode | expand |
Hi! > Overvoltage protection and brightness mode are currently hardcoded > as 29V and disabled in the driver. Make these configurable via DT. > > This v4 moves the exponential brightness mode to the back of the series > as per Pavel's request: > > https://lore.kernel.org/linux-next/20200106103233.GA32426@amd/T/#m93270a9bf10b88e060f4e4cf5701c527476de985 > > The end result is identical and i've tested everything still works when > dropping the last to patches and checked compiltion via Thank you. Applied 1-4 (with some reformatting of changelog, and led->LED). Exponential mode: We should decide if LEDs should be linear or not. Most LEDs are linear now, and we may want to make it part of the API. Additional advantage is that linear is "well defined". It is actually quite important for RGB LEDs, because you get wrong colors otherwise. (Non-linear can have advantages, too... like needing less bits.) So, my suggestion is to document LEDs as linear, and leave exponential->linear conversion to someone else. Best regards, Pavel
Hi Pavel, On Tue, Jan 07, 2020 at 02:31:20PM +0100, Pavel Machek wrote: > Hi! > > > Overvoltage protection and brightness mode are currently hardcoded > > as 29V and disabled in the driver. Make these configurable via DT. > > > > This v4 moves the exponential brightness mode to the back of the series > > as per Pavel's request: > > > > https://lore.kernel.org/linux-next/20200106103233.GA32426@amd/T/#m93270a9bf10b88e060f4e4cf5701c527476de985 > > > > The end result is identical and i've tested everything still works when > > dropping the last to patches and checked compiltion via > > Thank you. Applied 1-4 (with some reformatting of changelog, and > led->LED). > > Exponential mode: > > We should decide if LEDs should be linear or not. Most LEDs are linear > now, and we may want to make it part of the API. Additional advantage > is that linear is "well defined". It is actually quite important for > RGB LEDs, because you get wrong colors otherwise. > > (Non-linear can have advantages, too... like needing less bits.) > > So, my suggestion is to document LEDs as linear, and leave > exponential->linear conversion to someone else. That would mean doing a conversion in the kernel that can be done by the chip. Would exposing non-linearity like in /sys/class/backlight/<backlight>/scale be an option? Cheers, -- Guido > > Best regards, > > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Overvoltage protection and brightness mode are currently hardcoded as 29V and disabled in the driver. Make these configurable via DT. This v4 moves the exponential brightness mode to the back of the series as per Pavel's request: https://lore.kernel.org/linux-next/20200106103233.GA32426@amd/T/#m93270a9bf10b88e060f4e4cf5701c527476de985 The end result is identical and i've tested everything still works when dropping the last to patches and checked compiltion via git rebase -i ... -exec 'make ... Image dtbs' Patches are against linux-leds-next. Changes from v3 - Move exponential mode patches to the back of the series https://lore.kernel.org/linux-next/20200106103233.GA32426@amd/T/#m93270a9bf10b88e060f4e4cf5701c527476de985 - Add Rob's Reviewed-by:, thanks! Changes from v2 - As per review comment from Pavel Machek https://lore.kernel.org/linux-leds/20191226100615.GA4033@amd/T/#u - Use default value in DT example https://lore.kernel.org/linux-leds/20191226100842.GC4033@amd/T/#u - Use uppercase LED in commit message https://lore.kernel.org/linux-leds/20191226101336.GD4033@amd/T/#u - Fix typo in commit message - Use correct return value when checking if property is present - Fold in https://lore.kernel.org/linux-leds/20191226101419.GE4033@amd/T/#t - Add Acked-By's from Pavel Machek, thanks! Changes from v1 - As per review comments by Dan Murphy https://lore.kernel.org/linux-leds/3d66b07d-b4c5-43e6-4378-d63cc84b8d43@ti.com/ - Split commits per propoerty - Add new properties to DT example too - Drop dev_dbg() statements - ovp: fix 21V value parsing - ovp: Set correct default value if DT parsing fails - As per review comments by Pavel Machek https://lore.kernel.org/linux-leds/20191221191515.GF32732@amd/ - Fix defaults (which is 29V) - Use uV as Unit for ovp property - Change property name to 'ti,ovp-microvolt' to make it shorter - Honor led-max-microamp to not exceed the maximum led current Guido Günther (6): leds: lm3692x: Make sure we don't exceed the maximum led current leds: lm3692x: Move lm3692x_init and rename to lm3692x_leds_enable leds: lm3692x: Split out lm3692x_leds_disable leds: lm3692x: Disable chip on brightness 0 dt: bindings: lm3692x: Add ti,brightness-mapping-exponential property leds: lm3692x: Allow to configure brigthness mode .../devicetree/bindings/leds/leds-lm3692x.txt | 3 + drivers/leds/leds-lm3692x.c | 165 ++++++++++++------ 2 files changed, 113 insertions(+), 55 deletions(-)