On 21/04/2020 13:48, Daniel Thompson wrote:
On Tue, Apr 21, 2020 at 08:52:02AM +0300, Tomi Valkeinen wrote:
On 20/04/2020 19:01, Daniel Thompson wrote:
On Fri, Apr 17, 2020 at 02:33:12PM +0300, Tomi Valkeinen wrote:
led_bl_parse_levels() is rather difficult to follow. Rewrite it with a
more obvious code flow.
... that introduces new behaviour.
There's a couple of new behaviours here but the one that particular
attracted my attention is the disregarding the "default-brightness-level" if
there is no table. That looks like a bug to me.
I think the previous behavior was a (minor) bug: how can there be default
brightness level if there are no brightness levels?
I don't think this was a bug.
If there is no brightness table then backlight will adopt a 1:1 mapping
versus the underlying LED meaning the concept of default brightness
applies equally well whether or not a brightness table is supplied.
The led-backlight.txt is
a bit lacking (another thing to improve...) but led-backlight mimics
pwm-backlight, and pwm-backlight.txt says
default-brightness-level: The default brightness level (index into the array
defined by the "brightness-levels" property)
I think this implies we should improve the binding documentation!
The parenthetic text's main purpose is to make clear which scale should
be used when interpreting the default brightness. Just because the scale
is 1:1 doesn't render it meaningless.
If I read pwm_bl.c right, that's not how the code works. If pwm_bl has no 'brightness-levels', then
'default-brightness-level' is ignored. Which matches the binding documentation.
What you suggest makes sense, though, so I can adjust this patch to make led_bl behave like that.
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
