boards: pinetime: display backlight via GPIO

[caspermeijn]

Is your enhancement proposal related to a problem? Please describe. With the main Zephyr samples, the backlight of the Pinetime board is not enabled, therefore the picture of the display is not visible.

The backlight is enabled via GPIO. There are three GPIO, each with a different resistor, for three brightness levels. But due to the resistor this is not a very efficient way to reduce the brightness. It seems the best way is to use PWM on the pin for highest brightness.

There is currently no way to connect a backlight to a display driver. Some display drivers are able to set the brightness of the display controller. Most drivers will just return -ENOTSUP when changing the brightness. There is no display driver that supports a GPIO pin as backlight.

Describe the solution you'd like Add a led-backlight devicetree binding similar to Linux. Then add a reference to the led-backlight from the st7789v display driver. This way the hardware connection is described in the devicetree.

Then extend the display driver to use the led interface to drive the backlight. In the set_brightness function of the display driver it will call the led_set_brightness of the backlight led.

Describe alternatives you've considered 1) Adding the GPIO binding directly to the display devicetree entry. This seems to be the easiest option, but it is not very extend-able.

Additional context

[ck-telecom]

There is a led_pwm driver in drivers/led/led_pwm.c, whether we could using this driver in display driver, invoke the APIs like invoke SPI bus driver?

[caspermeijn]

There is a led_pwm driver in drivers/led/led_pwm.c, whether we could using this driver in display driver, invoke the APIs like invoke SPI bus driver?

Yes, using led_pwm driver is what I meant with alternative 2. I was not able to prototype this solution before, but now I can and it seems easy. I will change the description to reflect this new insight.

[caspermeijn]

I know again what the problem is with using the led_pwm driver. If you have a DTS phandle to a single led, then you can't retreive the led number. The led number is basically the index of the led in the gpio-leds compatible.

I can't find an example of a DTS reference to a led in the main Zephyr repo. All led related examples loop over all leds in the first gpio-leds compatible.

@ck-telecom Do you know of such example?

[ck-telecom]

@caspermeijn I think it shall looks like this:

pwmleds {
    compatible = "pwm-leds";
    pwm_led0: pwm_led_0 {
        pwms = <&pwm0 13>;
    };
};

&st7789v { pwm-backlight = <&pwm_led0>; }

[caspermeijn]

@ck-telecom Yes, I also think it should be something like that. But how do you use that reference to set the brightness of the pwm-led.

I try to finish my proof of concept code and I can give you a proper example.

[ck-telecom]

This way is a wapper of pwm-leds, you could invoke pwm-les APIs to control brightness, but you should binds the pwm-leds device, can you try to unterstand drivers/led/led-pwm.c, similar to invoke pwm APIs, but in st7789v driver, you should invoke pwm-leds APIs like set_brightness().

[ck-telecom]

I have a look at Linux backlight, it use /sys/class/leds/ to control backlight, the don't combo this in the linux framebuffer drivers, so I am not sure it is a good idea to control pwm based backlight in a display driver, maybe we shall control pwm backlight using pwm-leds driver, that is fine to most applications

[ck-telecom]

DT_NODELABEL(pwn_led0) maybe helpful

[caspermeijn]

@ck-telecom I finished my prove of concept. See TODO at the link below for the problem I had with the reference.

[zephyrbot]

Hi @galak,

This issue, marked as an Enhancement, was opened a while ago and did not get any traction. It was just assigned to you based on the labels. If you don't consider yourself the right person to address this issue, please re-assing it to the right person.

Please take a moment to review if the issue is still relevant to the project. If it is, please provide feedback and direction on how to move forward. If it is not, has already been addressed, is a duplicate, or is no longer relevant, please close it with a short comment explaining the reason.

@caspermeijn you are also encouraged to help moving this issue forward by providing additional information and confirming this request/issue is still relevant to you.

Thanks!