Re: [PATCH] arm64: dts: rockchip: Add DSI LCD display on rk3576-evb1

Am Mittwoch, 29. Juli 2026, 18:32:08 Mitteleuropäische Sommerzeit schrieb Alexey Charkov:

On Wed, Jul 29, 2026 at 6:46 PM Heiko Stübner [off-list ref] wrote:

quoted

Am Montag, 20. Oktober 2025, 14:31:12 Mitteleuropäische Sommerzeit schrieb Heiko Stuebner:

quoted

Am Montag, 20. Oktober 2025, 10:50:58 Mitteleuropäische Sommerzeit schrieb Alexey Charkov:

quoted

On Mon, Oct 20, 2025 at 12:31 PM Heiko Stuebner [off-list ref] wrote:

quoted

Am Montag, 20. Oktober 2025, 10:19:51 Mitteleuropäische Sommerzeit schrieb Alexey Charkov:

quoted

On Thu, Sep 25, 2025 at 12:38 AM Alexey Charkov [off-list ref] wrote:

quoted

Add support for the Rockchip W552793DBA-V10 LCD+touchscreen assembly which
comes physically attached to Rockchip RK3576 EVB1 boards.

The display part is driven by the on-chip MIPI DSI controller, and the
touchscreen is connected over I2C.

Signed-off-by: Alexey Charkov <alchark@gmail.com>
---
Note that backlight support is left out for now, as it depends on PWM
support [0] which has not yet been merged.

A workaround is simply `gpioset -c 0 13=1` to set the respective GPIO
pin high and thus to light up the display unconditionally.

[0] https://lore.kernel.org/lkml/20250602-rk3576-pwm-v2-0-a6434b0ce60c@collabora.com/ (local)
---
 arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts | 89 ++++++++++++++++++++++++
 1 file changed, 89 insertions(+)

Hi Heiko,

Any thoughts about this one? Can we perhaps get it merged for -next?

Does the gpio-backlight work on that device?
That would make the gpioset hack unnecessary.

I've got a local patch using pwm-gpio and pwm-backlight as a stop-gap
solution, but I don't think it's worth merging upstream, because the
backlight is supposed to be driven by the hardware PWM on the same pin
(not bit-banging the GPIO line). After all, Nicolas has been working on
adding a proper hardware PWM driver for RK3576.

The display itself works without PWM support, and so does the touchscreen.

Right now, I don't think we have an actual timeline if/when Nicolas will
be able to work on the pwm again. So my idea was if we want to
integrate the baclight as you described below, to have an actual usable
display and then when the new pwm has landed switch over to that one?

With the ELCE around the corner we're nearing the year-mark here ;-)
(And I'm surprised, I remembered this pending patch)

I've been hoping that Nicolas' PWM series gets further along in the meantime :)

quoted

So how about integrating your gpio-pwm backlight for the time being?

Could do that, but I'm worried if it would immediately become set in
stone because DT is ABI, making it hard to switch to a "proper"
hardware-driven PWM once Nicolas' series lands.

The backlight subsystem is using dev_name() to name the sysfs node.
So if you keep the node name to "backlight", the backlight device stays the
same.

I guess the question is if you also consider the brightness levels as
unchangeable, though I would assume any sane system should just read
max_brightness and adjust accordingly.

Also this is an eval-board ... so you won't have any actual real-world
users :-) .

So, personally I don't see the big hickup here, but we'll do what you
think best.


Heiko

quoted

Or alternatively just going with a gpio-backlight, like the Anbernic Vita did:

        /*
         * LEDs and Backlights can be controlled as a PWM, but PWM
         * support is not yet available.
         */
        gpio_backlight: backlight {
                compatible = "gpio-backlight";
                gpios = <&gpio2 RK_PC4 GPIO_ACTIVE_HIGH>;
                pinctrl-0 = <&led_backlight_h>;
                pinctrl-names = "default";
        };

In the case of RK3576 EVB1 enabling it at full power is eye-burning
bright, so some sort of PWM is definitely warranted.

Best regards,
Alexey