Kernel driver for backlight control of ili9488 with PWM pin?

[rcloran]

I've been working on getting a board which includes a display driven by a ili9488 working, and have had pretty good success with Linux 6.11 and the panel_mipi_dbi driver (thanks for your work on this!). One thing I've not been able to figure out properly is "integrated" backlight control.

The board has the PWM pin of the ili9488 driving its backlight. With the correct initialization commands¹, I'm able to set the backlight using the debug command file, eg:

$ echo "51 00" > /sys/kernel/debug/dri/spi0.0/command
$ echo "51 ff" > /sys/kernel/debug/dri/spi0.0/command

However, it seems that with a proper kernel backlight driver, I'd get features further up the stack, such as having DPMS be able to turn the display off. Is that correct?

Is there an existing driver or way to have X/Wayland control the backlight of this board?

I've seen the ili922x and ili9320 drivers in the backlight directory of the kernel tree, but a quick read suggests they're pretty different devices. It's not super clear to me whether they share the use of an SPI device with their related video driver. If I wanted to tackle writing a backlight driver for this chip (looks like it's not a standard MIPI command, please correct me if I'm wrong), might it look something like those?

Footnotes

1. Initialization:

   # Invert backlight PWM
   command 0xC8 0xB1
   # Set up PWM frequency to avoid audible noises
   command 0xCF 0x01
   # Brightness control block on, backlight control on
   command 0x53 0x24
   

   ↩

[notro]

Two kernel drivers can't share one SPI slave device directly. This situation is solved in the kernel using mfd or aux drivers to control the hw and then there are slave devices on this that have their own drivers.
I don't know much about the userspace side of things, but maybe you can listen to DBUS messages and then have some script write to the debugfs files to turn on/off backlight?

[rcloran]

Thanks!

Two kernel drivers can't share one SPI slave device directly.

That makes sense...

This situation is solved in the kernel using mfd or aux drivers to control the hw and then there are slave devices on this that have their own drivers.

Thanks, that might be useful. I haven't found any simple examples yet, but I haven't tried too hard :) I'll continue exploring.

Would it make sense to explore being able to bind (I don't know if that's the right word) drivers to the panel-mipi-dbi-spi driver? It doesn't seem like there would be much use beyond backlights like this, but being able to just call mipi_dbi_command would make at least the common path for a backlight driver like that really simple. It seems like it probably wouldn't be worth the complexity of making the panel driver have some bus-like functionality, though.

I don't know much about the userspace side of things, but maybe you can listen to DBUS messages and then have some script write to the debugfs files to turn on/off backlight?

AFAICT there's no D-Bus interactions in the chain I'm using (Gtk app on Wayland), but it's a reasonable idea that I hadn't thought of. I do have some even higher level options that have me with a system that overall does what I want, but it involves running a web server (because everything should be over http, right...), so I'd still like to work on getting it done "right".

As an aside, where's the right place to discuss possible bugs in the kernel driver? I think that there's a problem with the blanking code -- when I try to "power off" the display using Wayland, about 2/3 of the display is cleared, but not the whole thing. I think it's because not enough bytes are written for the RGB666 format -- 2 bytes/pixel are always written: https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/drm_mipi_dbi.c#L407

[notro]

Would it make sense to explore being able to bind (I don't know if that's the right word) drivers to the panel-mipi-dbi-spi driver? It doesn't seem like there would be much use beyond backlights like this, but being able to just call mipi_dbi_command would make at least the common path for a backlight driver like that really simple. It seems like it probably wouldn't be worth the complexity of making the panel driver have some bus-like functionality, though.

I'm not the maintainer anymore but I think that would be a lot of complexity for little gain.

As an aside, where's the right place to discuss possible bugs in the kernel driver? I think that there's a problem with the blanking code -- when I try to "power off" the display using Wayland, about 2/3 of the display is cleared, but not the whole thing. I think it's because not enough bytes are written for the RGB666 format -- 2 bytes/pixel are always written: https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/drm_mipi_dbi.c#L407

You're right that's a bug. Look in the MAINTAINERS file to find the maintainers email, also cc the dri-devel mailinglist.