[BUG] rp1-pio initializes after rp1-dpi probe on Pi 5, breaking DPI interlace VSync

[alexbaldwin]

Describe the bug

On LibreELEC 12.2.1 for Raspberry Pi 5, the rp1-pio driver initializes ~40ms after the drm-rp1-dpi driver's pio_open() call during boot. This causes interlaced DPI modes to fail at setting up PIO-generated VSync, which is required for properly-phased interlaced output per https://www.raspberrypi.com/news/how-we-added-interlaced-video-to-raspberry-pi-5/

The DPI block still emits interlaced fields, but without PIO managing VSync phase, fields are misaligned on the display — manifesting as "slow interlace" / double-image flicker on CRTs. This appears to be the same root cause as the ws2812-pio-rp1 issue (see Forum Thread below), where another driver that depends on rp1-pio being initialized also fails at probe time.

Manual workaround that proves the fix path: after boot completes and PIO is ready, triggering a DPI mode re-set (e.g. systemctl restart kodi) succeeds and produces [drm] Using PIO to generate VSync on GPIO2. Happy to test kernel patches.

How to reproduce

Steps to reproduce the behavior:

1. Install LibreELEC 12.2.1 on a Raspberry Pi 5 with a VGA666 HAT (or any DPI-capable HAT) connected to a display that accepts 480i or 576i
2. Append to config.txt:

   dtoverlay=vc4-kms-dpi-generic
   dtparam=clock-frequency=13500000
   dtparam=hactive=720,hfp=16,hsync=62,hbp=60
   dtparam=vactive=480,vfp=9,vsync=6,vbp=30
   dtparam=hsync-invert,vsync-invert
   dtparam=interlaced
   

3. Set cmdline.txt video param to video=DPI-1:720x480i@60
4. Boot and observe dmesg — drm-rp1-dpi emits *ERROR* Could not open PIO, then rp1-pio is created ~40ms later
5. On the display: interlaced output is present but fields are not properly phased

Information

• LibreELEC Version: 12.2.1 (RPi5.aarch64), kernel 6.12.56
• Hardware Platform: RPi5 (2GB) + VGA666 HAT → sync combiner → Sony PVM-20L5
• Forum Thread: (none opened by me — related ws2812 thread referenced below, same root cause)

Log file

Relevant dmesg excerpt showing the race:

[    0.485659] drm-rp1-dpi 1f00148000.dpi: rp1dpi_platform_probe
[    0.485835] [drm] Initialized drm-rp1-dpi 1.0.0 for 1f00148000.dpi on minor 2
[    0.486677] drm-rp1-dpi 1f00148000.dpi: rp1dpi_pipe_enable
[    0.489643] drm-rp1-dpi 1f00148000.dpi: mode=720x480 total=858x525i 13500kHz
[    0.489653] drm-rp1-dpi 1f00148000.dpi: [drm] *ERROR* Could not open PIO
[    0.526101] drm-rp1-dpi 1f00148000.dpi: [drm] fb0: drm-rp1-dpidrmf frame buffer device
[    0.526737] rp1-pio 1f00178000.pio: Created instance as pio0

After manual Kodi restart (proving the fix path works):

drm-rp1-dpi 1f00148000.dpi: rp1dpi_pipe_disable
drm-rp1-dpi 1f00148000.dpi: rp1dpi_pipe_enable
drm-rp1-dpi 1f00148000.dpi: [drm] Using PIO to generate VSync on GPIO2

Can provide a full pastekodi URL on request.

Context

The RP1 DPI driver's interlaced mode requires PIO to synthesize properly-phased VSync pulses — see https://www.raspberrypi.com/news/how-we-added-interlaced-video-to-raspberry-pi-5/ and the driver source at https://github.com/raspberrypi/linux/blob/rpi-6.12.y/drivers/gpu/drm/rp1/rp1-dpi/rp1_dpi_pio.c

Two possible fixes:

1. Return -EPROBE_DEFER from rp1dpi_pio_start() when pio_open() fails, so rp1-dpi re-probes after rp1-pio is ready
2. Adjust device tree or initcall ordering so rp1-pio probes before rp1-dpi

Option (1) is more robust and would also resolve the related ws2812-pio-rp1 initialization issue discussed here: https://forum.libreelec.tv/thread/30075-ws2812-pio-rp1-kernel-driver-seems-not-functional-on-rpi5/

Currently working around this with a user /storage/.config/autostart.sh that waits for /dev/pio0 + active kodi.service then restarts Kodi, costing ~15-20s of boot time and causing a visible "Kodi starts → restarts" transition. Willing to test kernel patches on this hardware.

[HiassofT]

Please test with the latest LE13 nightly https://test.libreelec.tv/13.0/RPi/RPi5/ - LE12 won't get any further updates

If the issue still occurs in LE13 post a full pastekodi log

[alexbaldwin]

Tested on LibreELEC-RPi5.aarch64-13.0-devel (latest nightly as of today).

Result: bug still present.

Same failure mode as LE12. drm-rp1-dpi probes, calls pio_open(), fails with *ERROR* Could not open PIO, and ~17ms later rp1-pio creates its instance. The gap is shorter on LE13 but the init ordering is unchanged.

Relevant dmesg:
[ 0.505867] drm-rp1-dpi 1f00148000.dpi: rp1dpi_platform_probe
[ 0.508547] [drm] Initialized drm-rp1-dpi 1.0.0 for 1f00148000.dpi on minor 2
[ 0.508988] drm-rp1-dpi 1f00148000.dpi: rp1dpi_pipe_enable
[ 0.509033] drm-rp1-dpi 1f00148000.dpi: [drm] in_fmt='XR24' bus_fmt=0x1009 mode=720x480 total=858x525i 13500kHz -H-V+DE+CK
[ 0.509039] drm-rp1-dpi 1f00148000.dpi: [drm] ERROR Could not open PIO
[ 0.525413] drm-rp1-dpi 1f00148000.dpi: [drm] fb0: drm-rp1-dpidrmf frame buffer device
[ 0.525905] rp1-pio 1f00178000.pio: Created instance as pio0

Manual systemctl restart kodi after boot still succeeds in bringing up PIO correctly and outputs [drm] Using PIO to generate VSync on GPIO2 — confirming the -EPROBE_DEFER path from rp1dpi_pio_start() would resolve this.

Full pastekodi: https://paste.libreelec.tv/topical-rabbit.log

Happy to test patches or nightlies with specific fixes applied.

[HiassofT]

Thanks for the new log, this indeed seems to be an issue in the drm-rp1-dpi driver.

Please create an issue about that on the RPi linux repo https://github.com/raspberrypi/linux, and best mention that we build vc4, pio etc drivers directly into the kernel, not as modules as the RPi defconfigs does.