* [PATCH v2 0/3] PWM backlight interpolation adjustments @ 2020-10-13 8:01 Alexandru Stan 2020-10-13 8:01 ` [PATCH v2 1/3] backlight: pwm_bl: Fix interpolation Alexandru Stan ` (2 more replies) 0 siblings, 3 replies; 13+ messages in thread From: Alexandru Stan @ 2020-10-13 8:01 UTC (permalink / raw) To: Thierry Reding, Uwe Kleine-König, Lee Jones, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz, Heiko Stuebner, Rob Herring, Andy Gross, Bjorn Andersson Cc: Douglas Anderson, Enric Balletbo i Serra, Matthias Kaehlcke, Alexandru Stan, devicetree, dri-devel, linux-arm-kernel, linux-arm-msm, linux-fbdev, linux-kernel, linux-pwm, linux-rockchip I was trying to adjust the brightness-levels for the trogdor boards: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2291209 Like on a lot of panels, trogdor's low end needs to be cropped, and now that we have the interpolation stuff I wanted to make use of it and bake in even the curve that's customary to have on chromebooks. I found the current behavior of the pwm_bl driver a little unintuitive and non-linear. See patch 1 for a suggested fix for this. A few veyron dts files were relying on this (perhaps weird) behavior. Those devices also want a minimum brightness like trogdor, so changed them to use the new way. Finally, given that trogdor's dts is part of linux-next now, add the brightness-levels to it, since that's the original reason I was looking at this. Changes in v2: - Fixed type promotion in the driver - Removed "backlight: pwm_bl: Artificially add 0% during interpolation", userspace works just fine without it because it already knows how to use bl_power for turning off the display. - Added brightness-levels to trogdor as well, now the dts is upstream. Alexandru Stan (3): backlight: pwm_bl: Fix interpolation ARM: dts: rockchip: veyron: Remove 0 point from brightness-levels arm64: dts: qcom: trogdor: Add brightness-levels arch/arm/boot/dts/rk3288-veyron-jaq.dts | 2 +- arch/arm/boot/dts/rk3288-veyron-minnie.dts | 2 +- arch/arm/boot/dts/rk3288-veyron-tiger.dts | 2 +- arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 9 +++ drivers/video/backlight/pwm_bl.c | 70 +++++++++----------- 5 files changed, 43 insertions(+), 42 deletions(-) -- 2.28.0 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v2 1/3] backlight: pwm_bl: Fix interpolation 2020-10-13 8:01 [PATCH v2 0/3] PWM backlight interpolation adjustments Alexandru Stan @ 2020-10-13 8:01 ` Alexandru Stan 2020-10-14 11:26 ` Daniel Thompson 2020-10-15 6:54 ` Geert Uytterhoeven 2020-10-13 8:01 ` [PATCH v2 2/3] ARM: dts: rockchip: veyron: Remove 0 point from brightness-levels Alexandru Stan 2020-10-13 8:01 ` [PATCH v2 3/3] arm64: dts: qcom: trogdor: Add brightness-levels Alexandru Stan 2 siblings, 2 replies; 13+ messages in thread From: Alexandru Stan @ 2020-10-13 8:01 UTC (permalink / raw) To: Thierry Reding, Uwe Kleine-König, Lee Jones, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz, Heiko Stuebner, Rob Herring, Andy Gross, Bjorn Andersson Cc: Douglas Anderson, Enric Balletbo i Serra, Matthias Kaehlcke, Alexandru Stan, dri-devel, linux-fbdev, linux-kernel, linux-pwm Whenever num-interpolated-steps was larger than the distance between 2 consecutive brightness levels the table would get really discontinuous. The slope of the interpolation would stick with integers only and if it was 0 the whole line segment would get skipped. Example settings: brightness-levels = <0 1 2 4 8 16 32 64 128 256>; num-interpolated-steps = <16>; The distances between 1 2 4 and 8 would be 1, and only starting with 16 it would start to interpolate properly. Let's change it so there's always interpolation happening, even if there's no enough points available (read: values in the table would appear more than once). This should match the expected behavior much more closely. Signed-off-by: Alexandru Stan <amstan@chromium.org> --- drivers/video/backlight/pwm_bl.c | 70 ++++++++++++++------------------ 1 file changed, 31 insertions(+), 39 deletions(-) diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c index dfc760830eb9..3e77f6b73fd9 100644 --- a/drivers/video/backlight/pwm_bl.c +++ b/drivers/video/backlight/pwm_bl.c @@ -230,8 +230,7 @@ static int pwm_backlight_parse_dt(struct device *dev, struct platform_pwm_backlight_data *data) { struct device_node *node = dev->of_node; - unsigned int num_levels = 0; - unsigned int levels_count; + unsigned int num_levels; unsigned int num_steps = 0; struct property *prop; unsigned int *table; @@ -260,12 +259,11 @@ static int pwm_backlight_parse_dt(struct device *dev, if (!prop) return 0; - data->max_brightness = length / sizeof(u32); + num_levels = length / sizeof(u32); /* read brightness levels from DT property */ - if (data->max_brightness > 0) { - size_t size = sizeof(*data->levels) * data->max_brightness; - unsigned int i, j, n = 0; + if (num_levels > 0) { + size_t size = sizeof(*data->levels) * num_levels; data->levels = devm_kzalloc(dev, size, GFP_KERNEL); if (!data->levels) @@ -273,7 +271,7 @@ static int pwm_backlight_parse_dt(struct device *dev, ret = of_property_read_u32_array(node, "brightness-levels", data->levels, - data->max_brightness); + num_levels); if (ret < 0) return ret; @@ -298,7 +296,13 @@ static int pwm_backlight_parse_dt(struct device *dev, * between two points. */ if (num_steps) { - if (data->max_brightness < 2) { + unsigned int num_input_levels = num_levels; + unsigned int i; + u32 x1, x2, x, dx; + u32 y1, y2; + s64 dy; + + if (num_input_levels < 2) { dev_err(dev, "can't interpolate\n"); return -EINVAL; } @@ -308,14 +312,7 @@ static int pwm_backlight_parse_dt(struct device *dev, * taking in consideration the number of interpolated * steps between two levels. */ - for (i = 0; i < data->max_brightness - 1; i++) { - if ((data->levels[i + 1] - data->levels[i]) / - num_steps) - num_levels += num_steps; - else - num_levels++; - } - num_levels++; + num_levels = (num_input_levels - 1) * num_steps + 1; dev_dbg(dev, "new number of brightness levels: %d\n", num_levels); @@ -327,24 +324,25 @@ static int pwm_backlight_parse_dt(struct device *dev, table = devm_kzalloc(dev, size, GFP_KERNEL); if (!table) return -ENOMEM; - - /* Fill the interpolated table. */ - levels_count = 0; - for (i = 0; i < data->max_brightness - 1; i++) { - value = data->levels[i]; - n = (data->levels[i + 1] - value) / num_steps; - if (n > 0) { - for (j = 0; j < num_steps; j++) { - table[levels_count] = value; - value += n; - levels_count++; - } - } else { - table[levels_count] = data->levels[i]; - levels_count++; + /* + * Fill the interpolated table[x] = y + * by draw lines between each (x1, y1) to (x2, y2). + */ + dx = num_steps; + for (i = 0; i < num_input_levels - 1; i++) { + x1 = i * dx; + x2 = x1 + dx; + y1 = data->levels[i]; + y2 = data->levels[i + 1]; + dy = (s64)y2 - y1; + + for (x = x1; x < x2; x++) { + table[x] = y1 + + div_s64(dy * ((s64)x - x1), dx); } } - table[levels_count] = data->levels[i]; + /* Fill in the last point, since no line starts here. */ + table[x2] = y2; /* * As we use interpolation lets remove current @@ -353,15 +351,9 @@ static int pwm_backlight_parse_dt(struct device *dev, */ devm_kfree(dev, data->levels); data->levels = table; - - /* - * Reassign max_brightness value to the new total number - * of brightness levels. - */ - data->max_brightness = num_levels; } - data->max_brightness--; + data->max_brightness = num_levels - 1; } return 0; -- 2.28.0 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH v2 1/3] backlight: pwm_bl: Fix interpolation 2020-10-13 8:01 ` [PATCH v2 1/3] backlight: pwm_bl: Fix interpolation Alexandru Stan @ 2020-10-14 11:26 ` Daniel Thompson 2020-10-15 6:54 ` Geert Uytterhoeven 1 sibling, 0 replies; 13+ messages in thread From: Daniel Thompson @ 2020-10-14 11:26 UTC (permalink / raw) To: Alexandru Stan Cc: Thierry Reding, Uwe Kleine-König, Lee Jones, Jingoo Han, Bartlomiej Zolnierkiewicz, Heiko Stuebner, Rob Herring, Andy Gross, Bjorn Andersson, Douglas Anderson, Enric Balletbo i Serra, Matthias Kaehlcke, dri-devel, linux-fbdev, linux-kernel, linux-pwm On Tue, Oct 13, 2020 at 01:01:01AM -0700, Alexandru Stan wrote: > Whenever num-interpolated-steps was larger than the distance > between 2 consecutive brightness levels the table would get really > discontinuous. The slope of the interpolation would stick with > integers only and if it was 0 the whole line segment would get skipped. > > Example settings: > brightness-levels = <0 1 2 4 8 16 32 64 128 256>; > num-interpolated-steps = <16>; > > The distances between 1 2 4 and 8 would be 1, and only starting with 16 > it would start to interpolate properly. Both comments a perilously close to nitpicking but enough that I wanted to reply... I'd suggest that the current behaviour as having two properties. 1. It was designed to generate strictly increasing tables (no repeated values). 2. It's implementation contains quantization errors when calculating the step size. This results in both the discards of some interpolated steps you mentioned (it is possible to insert extra steps between 4 and 8 whilst retaining a strictly increasing table). It also results in a potentially large undershoot when multiplying a step size (64 interpolated steps and a gap of 127 is likely to get a visual jump as we hop through 63 physical steps in one go). #1 can is a policy that can be changed. #2 is a bug that could be fixed. To be clear I don't object to generating a monotonically increasing table but I'd prefer the policy change to be explicitly described in the description. > Let's change it so there's always interpolation happening, even if > there's no enough points available (read: values in the table would > appear more than once). This should match the expected behavior much > more closely. > > Signed-off-by: Alexandru Stan <amstan@chromium.org> > --- > > drivers/video/backlight/pwm_bl.c | 70 ++++++++++++++------------------ > 1 file changed, 31 insertions(+), 39 deletions(-) > > diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c > index dfc760830eb9..3e77f6b73fd9 100644 > --- a/drivers/video/backlight/pwm_bl.c > +++ b/drivers/video/backlight/pwm_bl.c > @@ -230,8 +230,7 @@ static int pwm_backlight_parse_dt(struct device *dev, > struct platform_pwm_backlight_data *data) > { > struct device_node *node = dev->of_node; > - unsigned int num_levels = 0; > - unsigned int levels_count; > + unsigned int num_levels; > unsigned int num_steps = 0; > struct property *prop; > unsigned int *table; > @@ -260,12 +259,11 @@ static int pwm_backlight_parse_dt(struct device *dev, > if (!prop) > return 0; > > - data->max_brightness = length / sizeof(u32); > + num_levels = length / sizeof(u32); > > /* read brightness levels from DT property */ > - if (data->max_brightness > 0) { > - size_t size = sizeof(*data->levels) * data->max_brightness; > - unsigned int i, j, n = 0; > + if (num_levels > 0) { > + size_t size = sizeof(*data->levels) * num_levels; > > data->levels = devm_kzalloc(dev, size, GFP_KERNEL); > if (!data->levels) > @@ -273,7 +271,7 @@ static int pwm_backlight_parse_dt(struct device *dev, > > ret = of_property_read_u32_array(node, "brightness-levels", > data->levels, > - data->max_brightness); > + num_levels); > if (ret < 0) > return ret; > > @@ -298,7 +296,13 @@ static int pwm_backlight_parse_dt(struct device *dev, > * between two points. > */ > if (num_steps) { > - if (data->max_brightness < 2) { > + unsigned int num_input_levels = num_levels; > + unsigned int i; > + u32 x1, x2, x, dx; > + u32 y1, y2; > + s64 dy; > + > + if (num_input_levels < 2) { > dev_err(dev, "can't interpolate\n"); > return -EINVAL; > } > @@ -308,14 +312,7 @@ static int pwm_backlight_parse_dt(struct device *dev, > * taking in consideration the number of interpolated > * steps between two levels. > */ > - for (i = 0; i < data->max_brightness - 1; i++) { > - if ((data->levels[i + 1] - data->levels[i]) / > - num_steps) > - num_levels += num_steps; > - else > - num_levels++; > - } > - num_levels++; > + num_levels = (num_input_levels - 1) * num_steps + 1; > dev_dbg(dev, "new number of brightness levels: %d\n", > num_levels); > > @@ -327,24 +324,25 @@ static int pwm_backlight_parse_dt(struct device *dev, > table = devm_kzalloc(dev, size, GFP_KERNEL); > if (!table) > return -ENOMEM; > - > - /* Fill the interpolated table. */ > - levels_count = 0; > - for (i = 0; i < data->max_brightness - 1; i++) { > - value = data->levels[i]; > - n = (data->levels[i + 1] - value) / num_steps; > - if (n > 0) { > - for (j = 0; j < num_steps; j++) { > - table[levels_count] = value; > - value += n; > - levels_count++; > - } > - } else { > - table[levels_count] = data->levels[i]; > - levels_count++; > + /* > + * Fill the interpolated table[x] = y > + * by draw lines between each (x1, y1) to (x2, y2). > + */ > + dx = num_steps; > + for (i = 0; i < num_input_levels - 1; i++) { > + x1 = i * dx; > + x2 = x1 + dx; > + y1 = data->levels[i]; > + y2 = data->levels[i + 1]; > + dy = (s64)y2 - y1; > + > + for (x = x1; x < x2; x++) { > + table[x] = y1 + > + div_s64(dy * ((s64)x - x1), dx); I don't think it is possible for x - x1 to be negative (e.g. what is the s64 for). Obviously it makes little functional difference whether the cast is there or not but I don't like fixed point code that has been written with "just in case" casts. Daniel. > } > } > - table[levels_count] = data->levels[i]; > + /* Fill in the last point, since no line starts here. */ > + table[x2] = y2; > > /* > * As we use interpolation lets remove current > @@ -353,15 +351,9 @@ static int pwm_backlight_parse_dt(struct device *dev, > */ > devm_kfree(dev, data->levels); > data->levels = table; > - > - /* > - * Reassign max_brightness value to the new total number > - * of brightness levels. > - */ > - data->max_brightness = num_levels; > } > > - data->max_brightness--; > + data->max_brightness = num_levels - 1; > } > > return 0; > -- > 2.28.0 > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 1/3] backlight: pwm_bl: Fix interpolation 2020-10-13 8:01 ` [PATCH v2 1/3] backlight: pwm_bl: Fix interpolation Alexandru Stan 2020-10-14 11:26 ` Daniel Thompson @ 2020-10-15 6:54 ` Geert Uytterhoeven 2020-10-22 3:51 ` Alexandru Stan 1 sibling, 1 reply; 13+ messages in thread From: Geert Uytterhoeven @ 2020-10-15 6:54 UTC (permalink / raw) To: Alexandru Stan Cc: Thierry Reding, Uwe Kleine-König, Lee Jones, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz, Heiko Stuebner, Rob Herring, Andy Gross, Bjorn Andersson, Douglas Anderson, Enric Balletbo i Serra, Matthias Kaehlcke, DRI Development, Linux Fbdev development list, Linux Kernel Mailing List, Linux PWM List Hi Alexandru, On Tue, Oct 13, 2020 at 1:57 PM Alexandru Stan <amstan@chromium.org> wrote: > Whenever num-interpolated-steps was larger than the distance > between 2 consecutive brightness levels the table would get really > discontinuous. The slope of the interpolation would stick with > integers only and if it was 0 the whole line segment would get skipped. > > Example settings: > brightness-levels = <0 1 2 4 8 16 32 64 128 256>; > num-interpolated-steps = <16>; > > The distances between 1 2 4 and 8 would be 1, and only starting with 16 > it would start to interpolate properly. > > Let's change it so there's always interpolation happening, even if > there's no enough points available (read: values in the table would > appear more than once). This should match the expected behavior much > more closely. > > Signed-off-by: Alexandru Stan <amstan@chromium.org> Thanks for your patch! > --- a/drivers/video/backlight/pwm_bl.c > +++ b/drivers/video/backlight/pwm_bl.c > @@ -327,24 +324,25 @@ static int pwm_backlight_parse_dt(struct device *dev, > table = devm_kzalloc(dev, size, GFP_KERNEL); > if (!table) > return -ENOMEM; > - > - /* Fill the interpolated table. */ > - levels_count = 0; > - for (i = 0; i < data->max_brightness - 1; i++) { > - value = data->levels[i]; > - n = (data->levels[i + 1] - value) / num_steps; > - if (n > 0) { > - for (j = 0; j < num_steps; j++) { > - table[levels_count] = value; > - value += n; > - levels_count++; > - } > - } else { > - table[levels_count] = data->levels[i]; > - levels_count++; > + /* > + * Fill the interpolated table[x] = y > + * by draw lines between each (x1, y1) to (x2, y2). > + */ > + dx = num_steps; > + for (i = 0; i < num_input_levels - 1; i++) { > + x1 = i * dx; > + x2 = x1 + dx; > + y1 = data->levels[i]; > + y2 = data->levels[i + 1]; > + dy = (s64)y2 - y1; > + > + for (x = x1; x < x2; x++) { > + table[x] = y1 + > + div_s64(dy * ((s64)x - x1), dx); Yummy, 64-by-32 divisions. Shouldn't this use a rounded division? Nevertheless, I think it would be worthwhile to implement this using a (modified) Bresenham algorithm, avoiding multiplications and divisions, and possibly increasing accuracy as well. https://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm > } > } > - table[levels_count] = data->levels[i]; > + /* Fill in the last point, since no line starts here. */ > + table[x2] = y2; > > /* > * As we use interpolation lets remove current Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 1/3] backlight: pwm_bl: Fix interpolation 2020-10-15 6:54 ` Geert Uytterhoeven @ 2020-10-22 3:51 ` Alexandru Stan 0 siblings, 0 replies; 13+ messages in thread From: Alexandru Stan @ 2020-10-22 3:51 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Thierry Reding, Uwe Kleine-König, Lee Jones, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz, Heiko Stuebner, Rob Herring, Andy Gross, Bjorn Andersson, Douglas Anderson, Enric Balletbo i Serra, Matthias Kaehlcke, DRI Development, Linux Fbdev development list, Linux Kernel Mailing List, Linux PWM List On Wed, 14 Oct 2020 at 23:55, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Alexandru, > > On Tue, Oct 13, 2020 at 1:57 PM Alexandru Stan <amstan@chromium.org> wrote: > > Whenever num-interpolated-steps was larger than the distance > > between 2 consecutive brightness levels the table would get really > > discontinuous. The slope of the interpolation would stick with > > integers only and if it was 0 the whole line segment would get skipped. > > > > Example settings: > > brightness-levels = <0 1 2 4 8 16 32 64 128 256>; > > num-interpolated-steps = <16>; > > > > The distances between 1 2 4 and 8 would be 1, and only starting with 16 > > it would start to interpolate properly. > > > > Let's change it so there's always interpolation happening, even if > > there's no enough points available (read: values in the table would > > appear more than once). This should match the expected behavior much > > more closely. > > > > Signed-off-by: Alexandru Stan <amstan@chromium.org> > > Thanks for your patch! Thanks for your reply! I'm sorry I haven't replied earlier. Looks like your reply was marked as spam. Rest be assured my spam filter has been disciplined! :D > > > --- a/drivers/video/backlight/pwm_bl.c > > +++ b/drivers/video/backlight/pwm_bl.c > > @@ -327,24 +324,25 @@ static int pwm_backlight_parse_dt(struct device *dev, > > table = devm_kzalloc(dev, size, GFP_KERNEL); > > if (!table) > > return -ENOMEM; > > - > > - /* Fill the interpolated table. */ > > - levels_count = 0; > > - for (i = 0; i < data->max_brightness - 1; i++) { > > - value = data->levels[i]; > > - n = (data->levels[i + 1] - value) / num_steps; > > - if (n > 0) { > > - for (j = 0; j < num_steps; j++) { > > - table[levels_count] = value; > > - value += n; > > - levels_count++; > > - } > > - } else { > > - table[levels_count] = data->levels[i]; > > - levels_count++; > > + /* > > + * Fill the interpolated table[x] = y > > + * by draw lines between each (x1, y1) to (x2, y2). > > + */ > > + dx = num_steps; > > + for (i = 0; i < num_input_levels - 1; i++) { > > + x1 = i * dx; > > + x2 = x1 + dx; > > + y1 = data->levels[i]; > > + y2 = data->levels[i + 1]; > > + dy = (s64)y2 - y1; > > + > > + for (x = x1; x < x2; x++) { > > + table[x] = y1 + > > + div_s64(dy * ((s64)x - x1), dx); > > Yummy, 64-by-32 divisions. > Shouldn't this use a rounded division? It won't hurt. But it really doesn't make much of a difference either way. > > Nevertheless, I think it would be worthwhile to implement this using > a (modified) Bresenham algorithm, avoiding multiplications and > divisions, and possibly increasing accuracy as well. > > https://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm Sure, it might be a little faster to use Bresenham's line algorithm. Looks like to implement it I would have to deal with some fixed point math and still have to do divisions occasionally. I don't think performance is critical here, the values get calculated only once when the driver loads, and the algorithm's accuracy improvements might be at most 1 LSB. Meanwhile the formula I already implemented is almost the same as the formulas found at https://en.wikipedia.org/wiki/Linear_interpolation#:~:text=gives I would like to keep it as is, as straightforward as possible. > > > } > > } > > - table[levels_count] = data->levels[i]; > > + /* Fill in the last point, since no line starts here. */ > > + table[x2] = y2; > > > > /* > > * As we use interpolation lets remove current > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds Alexandru Stan (amstan) ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v2 2/3] ARM: dts: rockchip: veyron: Remove 0 point from brightness-levels 2020-10-13 8:01 [PATCH v2 0/3] PWM backlight interpolation adjustments Alexandru Stan 2020-10-13 8:01 ` [PATCH v2 1/3] backlight: pwm_bl: Fix interpolation Alexandru Stan @ 2020-10-13 8:01 ` Alexandru Stan 2020-10-14 14:19 ` Daniel Thompson 2020-10-13 8:01 ` [PATCH v2 3/3] arm64: dts: qcom: trogdor: Add brightness-levels Alexandru Stan 2 siblings, 1 reply; 13+ messages in thread From: Alexandru Stan @ 2020-10-13 8:01 UTC (permalink / raw) To: Thierry Reding, Uwe Kleine-König, Lee Jones, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz, Heiko Stuebner, Rob Herring, Andy Gross, Bjorn Andersson Cc: Douglas Anderson, Enric Balletbo i Serra, Matthias Kaehlcke, Alexandru Stan, devicetree, linux-arm-kernel, linux-kernel, linux-rockchip After the "PWM backlight interpolation adjustments" patches, the backlight interpolation works a little differently. The way these dts files were working before was relying on a bug (IMHO). Remove the 0-3 range since otherwise we would have a 252 long interpolation that would slowly go between 0 and 3, looking really bad in userspace. We don't need the 0% point, userspace seems to handle this just fine because it uses the bl_power property to turn off the display. Signed-off-by: Alexandru Stan <amstan@chromium.org> --- arch/arm/boot/dts/rk3288-veyron-jaq.dts | 2 +- arch/arm/boot/dts/rk3288-veyron-minnie.dts | 2 +- arch/arm/boot/dts/rk3288-veyron-tiger.dts | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/boot/dts/rk3288-veyron-jaq.dts b/arch/arm/boot/dts/rk3288-veyron-jaq.dts index af77ab20586d..4a148cf1defc 100644 --- a/arch/arm/boot/dts/rk3288-veyron-jaq.dts +++ b/arch/arm/boot/dts/rk3288-veyron-jaq.dts @@ -20,7 +20,7 @@ / { &backlight { /* Jaq panel PWM must be >= 3%, so start non-zero brightness at 8 */ - brightness-levels = <0 8 255>; + brightness-levels = <8 255>; num-interpolated-steps = <247>; }; diff --git a/arch/arm/boot/dts/rk3288-veyron-minnie.dts b/arch/arm/boot/dts/rk3288-veyron-minnie.dts index f8b69e0a16a0..82fc6fba9999 100644 --- a/arch/arm/boot/dts/rk3288-veyron-minnie.dts +++ b/arch/arm/boot/dts/rk3288-veyron-minnie.dts @@ -39,7 +39,7 @@ volum_up { &backlight { /* Minnie panel PWM must be >= 1%, so start non-zero brightness at 3 */ - brightness-levels = <0 3 255>; + brightness-levels = <3 255>; num-interpolated-steps = <252>; }; diff --git a/arch/arm/boot/dts/rk3288-veyron-tiger.dts b/arch/arm/boot/dts/rk3288-veyron-tiger.dts index 069f0c2c1fdf..52a84cbe7a90 100644 --- a/arch/arm/boot/dts/rk3288-veyron-tiger.dts +++ b/arch/arm/boot/dts/rk3288-veyron-tiger.dts @@ -23,7 +23,7 @@ / { &backlight { /* Tiger panel PWM must be >= 1%, so start non-zero brightness at 3 */ - brightness-levels = <0 3 255>; + brightness-levels = <3 255>; num-interpolated-steps = <252>; }; -- 2.28.0 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH v2 2/3] ARM: dts: rockchip: veyron: Remove 0 point from brightness-levels 2020-10-13 8:01 ` [PATCH v2 2/3] ARM: dts: rockchip: veyron: Remove 0 point from brightness-levels Alexandru Stan @ 2020-10-14 14:19 ` Daniel Thompson 2020-10-15 21:29 ` Alexandru M Stan 0 siblings, 1 reply; 13+ messages in thread From: Daniel Thompson @ 2020-10-14 14:19 UTC (permalink / raw) To: Alexandru Stan Cc: Thierry Reding, Uwe Kleine-König, Lee Jones, Jingoo Han, Bartlomiej Zolnierkiewicz, Heiko Stuebner, Rob Herring, Andy Gross, Bjorn Andersson, Douglas Anderson, Enric Balletbo i Serra, Matthias Kaehlcke, devicetree, linux-arm-kernel, linux-kernel, linux-rockchip On Tue, Oct 13, 2020 at 01:01:02AM -0700, Alexandru Stan wrote: > After the "PWM backlight interpolation adjustments" patches, the > backlight interpolation works a little differently. The way these > dts files were working before was relying on a bug (IMHO). > > Remove the 0-3 range since otherwise we would have a 252 long > interpolation that would slowly go between 0 and 3, looking really bad > in userspace. > > We don't need the 0% point, userspace seems to handle this just fine > because it uses the bl_power property to turn off the display. > > Signed-off-by: Alexandru Stan <amstan@chromium.org> Acked-by: Daniel Thompson <daniel.thompson@linaro.org> Note also shouldn't this be patch 1 of the set. AFAICT it makes sense whether or not the interpolation algorithm is changed. Daniel. > --- > > arch/arm/boot/dts/rk3288-veyron-jaq.dts | 2 +- > arch/arm/boot/dts/rk3288-veyron-minnie.dts | 2 +- > arch/arm/boot/dts/rk3288-veyron-tiger.dts | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/arch/arm/boot/dts/rk3288-veyron-jaq.dts b/arch/arm/boot/dts/rk3288-veyron-jaq.dts > index af77ab20586d..4a148cf1defc 100644 > --- a/arch/arm/boot/dts/rk3288-veyron-jaq.dts > +++ b/arch/arm/boot/dts/rk3288-veyron-jaq.dts > @@ -20,7 +20,7 @@ / { > > &backlight { > /* Jaq panel PWM must be >= 3%, so start non-zero brightness at 8 */ > - brightness-levels = <0 8 255>; > + brightness-levels = <8 255>; > num-interpolated-steps = <247>; > }; > > diff --git a/arch/arm/boot/dts/rk3288-veyron-minnie.dts b/arch/arm/boot/dts/rk3288-veyron-minnie.dts > index f8b69e0a16a0..82fc6fba9999 100644 > --- a/arch/arm/boot/dts/rk3288-veyron-minnie.dts > +++ b/arch/arm/boot/dts/rk3288-veyron-minnie.dts > @@ -39,7 +39,7 @@ volum_up { > > &backlight { > /* Minnie panel PWM must be >= 1%, so start non-zero brightness at 3 */ > - brightness-levels = <0 3 255>; > + brightness-levels = <3 255>; > num-interpolated-steps = <252>; > }; > > diff --git a/arch/arm/boot/dts/rk3288-veyron-tiger.dts b/arch/arm/boot/dts/rk3288-veyron-tiger.dts > index 069f0c2c1fdf..52a84cbe7a90 100644 > --- a/arch/arm/boot/dts/rk3288-veyron-tiger.dts > +++ b/arch/arm/boot/dts/rk3288-veyron-tiger.dts > @@ -23,7 +23,7 @@ / { > > &backlight { > /* Tiger panel PWM must be >= 1%, so start non-zero brightness at 3 */ > - brightness-levels = <0 3 255>; > + brightness-levels = <3 255>; > num-interpolated-steps = <252>; > }; > > -- > 2.28.0 > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 2/3] ARM: dts: rockchip: veyron: Remove 0 point from brightness-levels 2020-10-14 14:19 ` Daniel Thompson @ 2020-10-15 21:29 ` Alexandru M Stan 0 siblings, 0 replies; 13+ messages in thread From: Alexandru M Stan @ 2020-10-15 21:29 UTC (permalink / raw) To: Daniel Thompson Cc: Thierry Reding, Uwe Kleine-König, Lee Jones, Jingoo Han, Bartlomiej Zolnierkiewicz, Heiko Stuebner, Rob Herring, Andy Gross, Bjorn Andersson, Douglas Anderson, Enric Balletbo i Serra, Matthias Kaehlcke, devicetree, linux-arm-kernel, linux-kernel, open list:ARM/Rockchip SoC... On Wed, Oct 14, 2020 at 7:19 AM Daniel Thompson <daniel.thompson@linaro.org> wrote: > > On Tue, Oct 13, 2020 at 01:01:02AM -0700, Alexandru Stan wrote: > > After the "PWM backlight interpolation adjustments" patches, the > > backlight interpolation works a little differently. The way these > > dts files were working before was relying on a bug (IMHO). > > > > Remove the 0-3 range since otherwise we would have a 252 long > > interpolation that would slowly go between 0 and 3, looking really bad > > in userspace. > > > > We don't need the 0% point, userspace seems to handle this just fine > > because it uses the bl_power property to turn off the display. > > > > Signed-off-by: Alexandru Stan <amstan@chromium.org> > > Acked-by: Daniel Thompson <daniel.thompson@linaro.org> Thank you! > > Note also shouldn't this be patch 1 of the set. AFAICT it makes sense > whether or not the interpolation algorithm is changed. Yeah, I guess it could be. Sorry I didn't think of it that way before, I'm used to landing things in a group. In particular on veyron I assume it will almost be a noop without having my driver patch (especially with the findings of 0% not being that important). Feel free to land this independently. > > > Daniel. Alexandru Stan (amstan) ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v2 3/3] arm64: dts: qcom: trogdor: Add brightness-levels 2020-10-13 8:01 [PATCH v2 0/3] PWM backlight interpolation adjustments Alexandru Stan 2020-10-13 8:01 ` [PATCH v2 1/3] backlight: pwm_bl: Fix interpolation Alexandru Stan 2020-10-13 8:01 ` [PATCH v2 2/3] ARM: dts: rockchip: veyron: Remove 0 point from brightness-levels Alexandru Stan @ 2020-10-13 8:01 ` Alexandru Stan 2020-10-13 16:28 ` Doug Anderson 2 siblings, 1 reply; 13+ messages in thread From: Alexandru Stan @ 2020-10-13 8:01 UTC (permalink / raw) To: Thierry Reding, Uwe Kleine-König, Lee Jones, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz, Heiko Stuebner, Rob Herring, Andy Gross, Bjorn Andersson Cc: Douglas Anderson, Enric Balletbo i Serra, Matthias Kaehlcke, Alexandru Stan, devicetree, linux-arm-msm, linux-kernel Now that we have better interpolation for the backlight ("backlight: pwm_bl: Fix interpolation"), we can now add the curve to the trogdor boards, being careful to crop the low end. Signed-off-by: Alexandru Stan <amstan@chromium.org> --- arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi index bf875589d364..ccdabc6c4994 100644 --- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi +++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi @@ -179,6 +179,15 @@ pp3300_fp_tp: pp3300-fp-tp-regulator { backlight: backlight { compatible = "pwm-backlight"; + /* The panels don't seem to like anything below ~ 5% */ + brightness-levels = < + 196 256 324 400 484 576 676 784 900 1024 1156 1296 + 1444 1600 1764 1936 2116 2304 2500 2704 2916 3136 + 3364 3600 3844 4096 + >; + num-interpolated-steps = <64>; + default-brightness-level = <951>; + pwms = <&cros_ec_pwm 1>; enable-gpios = <&tlmm 12 GPIO_ACTIVE_HIGH>; power-supply = <&ppvar_sys>; -- 2.28.0 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH v2 3/3] arm64: dts: qcom: trogdor: Add brightness-levels 2020-10-13 8:01 ` [PATCH v2 3/3] arm64: dts: qcom: trogdor: Add brightness-levels Alexandru Stan @ 2020-10-13 16:28 ` Doug Anderson 2020-10-14 11:33 ` Daniel Thompson 0 siblings, 1 reply; 13+ messages in thread From: Doug Anderson @ 2020-10-13 16:28 UTC (permalink / raw) To: Alexandru Stan Cc: Thierry Reding, Uwe Kleine-König, Lee Jones, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz, Heiko Stuebner, Rob Herring, Andy Gross, Bjorn Andersson, Enric Balletbo i Serra, Matthias Kaehlcke, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-arm-msm, LKML Hi, On Tue, Oct 13, 2020 at 1:01 AM Alexandru Stan <amstan@chromium.org> wrote: > > Now that we have better interpolation for the backlight > ("backlight: pwm_bl: Fix interpolation"), we can now add the curve to > the trogdor boards, being careful to crop the low end. Just to make it clear, the patch this depends on hasn't landed yet. Presumably it will land in the v5.10 timeframe? That means that without extra coordination this patch can target v5.11. > Signed-off-by: Alexandru Stan <amstan@chromium.org> > --- > > arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi > index bf875589d364..ccdabc6c4994 100644 > --- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi > +++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi > @@ -179,6 +179,15 @@ pp3300_fp_tp: pp3300-fp-tp-regulator { > backlight: backlight { > compatible = "pwm-backlight"; > > + /* The panels don't seem to like anything below ~ 5% */ > + brightness-levels = < > + 196 256 324 400 484 576 676 784 900 1024 1156 1296 > + 1444 1600 1764 1936 2116 2304 2500 2704 2916 3136 > + 3364 3600 3844 4096 > + >; > + num-interpolated-steps = <64>; > + default-brightness-level = <951>; I haven't done lots of digging here, but this matches what Alexandru and Matthias agreed upon for the downstream tree and seems sane. Thus: Reviewed-by: Douglas Anderson <dianders@chromium.org> ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 3/3] arm64: dts: qcom: trogdor: Add brightness-levels 2020-10-13 16:28 ` Doug Anderson @ 2020-10-14 11:33 ` Daniel Thompson 2020-10-14 13:51 ` Doug Anderson 0 siblings, 1 reply; 13+ messages in thread From: Daniel Thompson @ 2020-10-14 11:33 UTC (permalink / raw) To: Doug Anderson Cc: Alexandru Stan, Thierry Reding, Uwe Kleine-König, Lee Jones, Jingoo Han, Bartlomiej Zolnierkiewicz, Heiko Stuebner, Rob Herring, Andy Gross, Bjorn Andersson, Enric Balletbo i Serra, Matthias Kaehlcke, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-arm-msm, LKML On Tue, Oct 13, 2020 at 09:28:38AM -0700, Doug Anderson wrote: > Hi, > > On Tue, Oct 13, 2020 at 1:01 AM Alexandru Stan <amstan@chromium.org> wrote: > > > > Now that we have better interpolation for the backlight > > ("backlight: pwm_bl: Fix interpolation"), we can now add the curve to > > the trogdor boards, being careful to crop the low end. > > Just to make it clear, the patch this depends on hasn't landed yet. > Presumably it will land in the v5.10 timeframe? That means that > without extra coordination this patch can target v5.11. You're talking about patch 1 from this set? Despite the title I view the patch as changing policy (albeit one that does also fix some annoying quantization errors at the same time) so it's not necessarily a candidate for merging outside the merge window (I've not checked with Lee but I think it likely the shutter is already down for features). Moreover I'm not clear why there a dependency here that would stop the changes landing in different trees. Daniel. > > Signed-off-by: Alexandru Stan <amstan@chromium.org> > > --- > > > > arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 9 +++++++++ > > 1 file changed, 9 insertions(+) > > > > diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi > > index bf875589d364..ccdabc6c4994 100644 > > --- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi > > +++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi > > @@ -179,6 +179,15 @@ pp3300_fp_tp: pp3300-fp-tp-regulator { > > backlight: backlight { > > compatible = "pwm-backlight"; > > > > + /* The panels don't seem to like anything below ~ 5% */ > > + brightness-levels = < > > + 196 256 324 400 484 576 676 784 900 1024 1156 1296 > > + 1444 1600 1764 1936 2116 2304 2500 2704 2916 3136 > > + 3364 3600 3844 4096 > > + >; > > + num-interpolated-steps = <64>; > > + default-brightness-level = <951>; > > I haven't done lots of digging here, but this matches what Alexandru > and Matthias agreed upon for the downstream tree and seems sane. > Thus: > > Reviewed-by: Douglas Anderson <dianders@chromium.org> ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 3/3] arm64: dts: qcom: trogdor: Add brightness-levels 2020-10-14 11:33 ` Daniel Thompson @ 2020-10-14 13:51 ` Doug Anderson 2020-10-15 9:15 ` Daniel Thompson 0 siblings, 1 reply; 13+ messages in thread From: Doug Anderson @ 2020-10-14 13:51 UTC (permalink / raw) To: Daniel Thompson Cc: Alexandru Stan, Thierry Reding, Uwe Kleine-König, Lee Jones, Jingoo Han, Bartlomiej Zolnierkiewicz, Heiko Stuebner, Rob Herring, Andy Gross, Bjorn Andersson, Enric Balletbo i Serra, Matthias Kaehlcke, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-arm-msm, LKML Hi, On Wed, Oct 14, 2020 at 4:33 AM Daniel Thompson <daniel.thompson@linaro.org> wrote: > > On Tue, Oct 13, 2020 at 09:28:38AM -0700, Doug Anderson wrote: > > Hi, > > > > On Tue, Oct 13, 2020 at 1:01 AM Alexandru Stan <amstan@chromium.org> wrote: > > > > > > Now that we have better interpolation for the backlight > > > ("backlight: pwm_bl: Fix interpolation"), we can now add the curve to > > > the trogdor boards, being careful to crop the low end. > > > > Just to make it clear, the patch this depends on hasn't landed yet. > > Presumably it will land in the v5.10 timeframe? That means that > > without extra coordination this patch can target v5.11. > > You're talking about patch 1 from this set? Despite the title I view > the patch as changing policy (albeit one that does also fix some annoying > quantization errors at the same time) so it's not necessarily a > candidate for merging outside the merge window (I've not checked with > Lee but I think it likely the shutter is already down for features). Ugh, I'm off by one. :( Right. New features prepared for v5.10 should already have been baking in linuxnext and merge requests have already started flowing towards Linus. After v5.10-rc1 then it'd just fixes and this doesn't really qualify. So the timing dictates that patch #1 will land in v5.11, not v5.10. > Moreover I'm not clear why there a dependency here that would stop the > changes landing in different trees. I haven't tried Alexandru's device tree patch without the associated code changes, but I guess I just assumed that it would make a really ugly (non)ideal backlight curve and we'd be better off with what we currently have (AKA no curve specified at all). Hrm, thinking about it, I guess the worst case is a slightly non-ideal backlight curve and it would be all good in the final v5.11 which would have the device tree and code changes, so you're right that both the code and device tree could target v5.11 without anything too bad... > Daniel. > > > > > Signed-off-by: Alexandru Stan <amstan@chromium.org> > > > --- > > > > > > arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 9 +++++++++ > > > 1 file changed, 9 insertions(+) > > > > > > diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi > > > index bf875589d364..ccdabc6c4994 100644 > > > --- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi > > > +++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi > > > @@ -179,6 +179,15 @@ pp3300_fp_tp: pp3300-fp-tp-regulator { > > > backlight: backlight { > > > compatible = "pwm-backlight"; > > > > > > + /* The panels don't seem to like anything below ~ 5% */ > > > + brightness-levels = < > > > + 196 256 324 400 484 576 676 784 900 1024 1156 1296 > > > + 1444 1600 1764 1936 2116 2304 2500 2704 2916 3136 > > > + 3364 3600 3844 4096 > > > + >; > > > + num-interpolated-steps = <64>; > > > + default-brightness-level = <951>; > > > > I haven't done lots of digging here, but this matches what Alexandru > > and Matthias agreed upon for the downstream tree and seems sane. > > Thus: > > > > Reviewed-by: Douglas Anderson <dianders@chromium.org> ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 3/3] arm64: dts: qcom: trogdor: Add brightness-levels 2020-10-14 13:51 ` Doug Anderson @ 2020-10-15 9:15 ` Daniel Thompson 0 siblings, 0 replies; 13+ messages in thread From: Daniel Thompson @ 2020-10-15 9:15 UTC (permalink / raw) To: Doug Anderson Cc: Alexandru Stan, Thierry Reding, Uwe Kleine-König, Lee Jones, Jingoo Han, Bartlomiej Zolnierkiewicz, Heiko Stuebner, Rob Herring, Andy Gross, Bjorn Andersson, Enric Balletbo i Serra, Matthias Kaehlcke, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-arm-msm, LKML On Wed, Oct 14, 2020 at 06:51:19AM -0700, Doug Anderson wrote: > Hi, > > On Wed, Oct 14, 2020 at 4:33 AM Daniel Thompson > <daniel.thompson@linaro.org> wrote: > > > > On Tue, Oct 13, 2020 at 09:28:38AM -0700, Doug Anderson wrote: > > > Hi, > > > > > > On Tue, Oct 13, 2020 at 1:01 AM Alexandru Stan <amstan@chromium.org> wrote: > > > > > > > > Now that we have better interpolation for the backlight > > > > ("backlight: pwm_bl: Fix interpolation"), we can now add the curve to > > > > the trogdor boards, being careful to crop the low end. > > > > > > Just to make it clear, the patch this depends on hasn't landed yet. > > > Presumably it will land in the v5.10 timeframe? That means that > > > without extra coordination this patch can target v5.11. > > > > You're talking about patch 1 from this set? Despite the title I view > > the patch as changing policy (albeit one that does also fix some annoying > > quantization errors at the same time) so it's not necessarily a > > candidate for merging outside the merge window (I've not checked with > > Lee but I think it likely the shutter is already down for features). > > Ugh, I'm off by one. :( Right. New features prepared for v5.10 > should already have been baking in linuxnext and merge requests have > already started flowing towards Linus. After v5.10-rc1 then it'd just > fixes and this doesn't really qualify. So the timing dictates that > patch #1 will land in v5.11, not v5.10. > > > > Moreover I'm not clear why there a dependency here that would stop the > > changes landing in different trees. > > I haven't tried Alexandru's device tree patch without the associated > code changes, but I guess I just assumed that it would make a really > ugly (non)ideal backlight curve and we'd be better off with what we > currently have (AKA no curve specified at all). > > Hrm, thinking about it, I guess the worst case is a slightly non-ideal > backlight curve and it would be all good in the final v5.11 which > would have the device tree and code changes, so you're right that both > the code and device tree could target v5.11 without anything too > bad... Excellent. I'll try to remember this for v3 so I can get my Acked-by versus Reviewed-by tags correct ;-) . Daniel. > > > > Daniel. > > > > > > > > Signed-off-by: Alexandru Stan <amstan@chromium.org> > > > > --- > > > > > > > > arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 9 +++++++++ > > > > 1 file changed, 9 insertions(+) > > > > > > > > diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi > > > > index bf875589d364..ccdabc6c4994 100644 > > > > --- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi > > > > +++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi > > > > @@ -179,6 +179,15 @@ pp3300_fp_tp: pp3300-fp-tp-regulator { > > > > backlight: backlight { > > > > compatible = "pwm-backlight"; > > > > > > > > + /* The panels don't seem to like anything below ~ 5% */ > > > > + brightness-levels = < > > > > + 196 256 324 400 484 576 676 784 900 1024 1156 1296 > > > > + 1444 1600 1764 1936 2116 2304 2500 2704 2916 3136 > > > > + 3364 3600 3844 4096 > > > > + >; > > > > + num-interpolated-steps = <64>; > > > > + default-brightness-level = <951>; > > > > > > I haven't done lots of digging here, but this matches what Alexandru > > > and Matthias agreed upon for the downstream tree and seems sane. > > > Thus: > > > > > > Reviewed-by: Douglas Anderson <dianders@chromium.org> ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2020-10-22 3:51 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-10-13 8:01 [PATCH v2 0/3] PWM backlight interpolation adjustments Alexandru Stan 2020-10-13 8:01 ` [PATCH v2 1/3] backlight: pwm_bl: Fix interpolation Alexandru Stan 2020-10-14 11:26 ` Daniel Thompson 2020-10-15 6:54 ` Geert Uytterhoeven 2020-10-22 3:51 ` Alexandru Stan 2020-10-13 8:01 ` [PATCH v2 2/3] ARM: dts: rockchip: veyron: Remove 0 point from brightness-levels Alexandru Stan 2020-10-14 14:19 ` Daniel Thompson 2020-10-15 21:29 ` Alexandru M Stan 2020-10-13 8:01 ` [PATCH v2 3/3] arm64: dts: qcom: trogdor: Add brightness-levels Alexandru Stan 2020-10-13 16:28 ` Doug Anderson 2020-10-14 11:33 ` Daniel Thompson 2020-10-14 13:51 ` Doug Anderson 2020-10-15 9:15 ` Daniel Thompson
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).