| Message ID | 20190208141629.14323-1-harald@ccbib.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [PATCHv3] arm64: dts: allwinner: a64: teres-i: enable backlight | expand |
Hi Harald, On Fri, Feb 08, 2019 at 02:16:29PM +0000, Harald Geyer wrote: > Enable pwm and add a pretty standard backlight node. > > The regulator is always on, but we include it anyway, because it is > required by the binding document. > > Signed-off-by: Harald Geyer <harald@ccbib.org> > --- > The backlight node got dropped from the initial submission of the > teres-i DT, because PWM support wasn't available in time, and I > kind of forgot to resubmit once PWM was in. Sorry about that. > > While testing this patch I noticed, that sometimes on boot the > brightness is set to max_brightness instead of the default specified > in DT. I couldn't reproduce it reliably, but it seems to be related > to changing the pwm period. I guess the logic trying to detect > the brightness set by the boot loader gets confused in some corner > case if the pwm periods don't match. However unbinding and rebinding > the device to the driver always made it go to the proper default > brightness, so the problem is clearly not in the DT. > > If the theory above is true, then it implies that the version of > u-boot running on my laptop doesn't completely overwrite all pwm > parameters. As this might be specific to my installation, I didn't > mention the issue in the commit message. > > Changes since v2: > * Drop all the other stuff that got merged a year ago. > * Rebased on current sunxi/for-next branch > * Add power-supply property (just to conform to the binding) > * Use slightly different brightness-levels > > Actually I tried omitting brightness-levels completely, as it is now > optional. However automatic calculation gives unreasonable results > (depending on the exact value of pwm period). A report has been sent > to the author of the code. > > > .../arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts > index 7b7b14ba58e6..2a78932d5d3b 100644 > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts > @@ -21,6 +21,15 @@ > serial0 = &uart0; > }; > > + backlight: backlight { > + compatible = "pwm-backlight"; > + pwms = <&pwm 0 50000 0>; > + power-supply = <®_dcdc1>; > + brightness-levels = <0 5 10 15 20 30 40 55 70 85 100>; The backlight perceived brightness should increase lineary with each step, which means that if you have ten steps, each step should increase the perceived brightness by 10%. The eye being what it is, a exponential sequence is usually a much better approximation. It looks good otherwise, thanks! Maxime
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts index 7b7b14ba58e6..2a78932d5d3b 100644 --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts @@ -21,6 +21,15 @@ serial0 = &uart0; }; + backlight: backlight { + compatible = "pwm-backlight"; + pwms = <&pwm 0 50000 0>; + power-supply = <®_dcdc1>; + brightness-levels = <0 5 10 15 20 30 40 55 70 85 100>; + default-brightness-level = <4>; + enable-gpios = <&pio 3 23 GPIO_ACTIVE_HIGH>; /* PD23 */ + }; + chosen { stdout-path = "serial0:115200n8"; @@ -131,6 +140,10 @@ status = "okay"; }; +&pwm { + status = "okay"; +}; + &r_rsb { status = "okay";
Enable pwm and add a pretty standard backlight node. The regulator is always on, but we include it anyway, because it is required by the binding document. Signed-off-by: Harald Geyer <harald@ccbib.org> --- The backlight node got dropped from the initial submission of the teres-i DT, because PWM support wasn't available in time, and I kind of forgot to resubmit once PWM was in. Sorry about that. While testing this patch I noticed, that sometimes on boot the brightness is set to max_brightness instead of the default specified in DT. I couldn't reproduce it reliably, but it seems to be related to changing the pwm period. I guess the logic trying to detect the brightness set by the boot loader gets confused in some corner case if the pwm periods don't match. However unbinding and rebinding the device to the driver always made it go to the proper default brightness, so the problem is clearly not in the DT. If the theory above is true, then it implies that the version of u-boot running on my laptop doesn't completely overwrite all pwm parameters. As this might be specific to my installation, I didn't mention the issue in the commit message. Changes since v2: * Drop all the other stuff that got merged a year ago. * Rebased on current sunxi/for-next branch * Add power-supply property (just to conform to the binding) * Use slightly different brightness-levels Actually I tried omitting brightness-levels completely, as it is now optional. However automatic calculation gives unreasonable results (depending on the exact value of pwm period). A report has been sent to the author of the code. .../arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts | 13 +++++++++++++ 1 file changed, 13 insertions(+)