raspberrypi
DSI0 not reliable (Compute Modules only)
Describe the bug
Tracking work raised by https://forums.raspberrypi.com/viewtopic.php?t=331474
DSI0 (only exposed on Compute Modules) seems to have issues when used with vc4-kms-v3d such as the colour channels getting swapped when stopping and restarting.
This has been confirmed with a DSI analyser, so it is something within the SoC, not just one display.
Steps to reproduce the behaviour
Configure a DSI display on DSI0 and then use xrandr to disable and reenable the display. Observe occasional colour shift (eg RGB to GBR to BRG)
Device (s)
Raspberry Pi CM1, Raspberry Pi CM3, Raspberry Pi CM3 Lite, Raspberry Pi CM3+, Raspberry Pi CM3+ Lite, Raspberry Pi CM4, Raspberry Pi CM4 Lite
System
5.15 kernel.
Logs
No response
Additional context
No response
Possibly hopeful progress on this one.
DSI appears to want the PV stopped before the DSI block, and KMS was doing it the other way around. Unfortunately this is inherent in the structure of KMS that:
- the bridge chain (includes DSI) gets disabled
- the encoder (dummy in this case) gets disabled
- the bridge chain gets post_disabled
- then the PV gets disabled right at the end.
The DSI bridge disable can get to the PV functions and call atomic_disable, but it's pretty ugly. I'll ask our tame DRM expert if there's a nice way to do it.
FWIW https://github.com/6by9/linux/tree/rpi-5.15.y-dsi has my changes in it, plus some debug stuff. Testing has been on a CM3, but the same thing was observed on both CM3 and CM4 before.
Some progress made. If the display is producing incorrect colours, running sudo memtool mw 0xfe209000 0x2841 (Pi4 only - address differs for CM1&3) whilst the display is active appears to clear it. The issue is that it can also make the colours go wrong when they were correct.
I still need to find an appropriate point to hit that reset within the drivers.
(sudo apt install memtool if not already installed).
PR #6094 has got the Pi 7" panel and several others working on both DSI ports of CM3 and CM4.
Pi5 has always had a 1 pixel offset both up and left (wants a timing of 800/59/2/47/- 480/100/2/23/-, not the current 800/59/2/45/- 480/7/2/22/-), but is otherwise also working.
@aBUGSworstnightmare-rpi if you fancied testing this it would be most appreciated, but we'll probably look at merging it next week anyway.
Hi, sorry, but can't offer support any more on topics related to the official Pi 7" panel as I don't have one in my possession any more.
Will do some tests with DSI83 on DSI0 though!
It was more your wider testing of DSI devices on DSI0 that I was hoping for. The DSI0 fix should be generic.
The fixes for the Pi panel are more that I've finally had time to sit down and test out all the combinations, and fiddling to determine the quirks. I really don't understand what that Toshiba bridge chip is doing under some circumstances, and why it wants a totally different timing when connected to DSI0 is baffling. The other panels have all just taken the DSI output, and the analyser doesn't show anything obviously different between DSI0 and DSI1.
I will pull your rpi-6.6.y-dsi0 repro, compile a custom kernel (as I need to have 3 modules which are not part of the def_config) and then report back.
running the Nexus7 panel on 2-lane DSI0 (CM4+CM4IO) with no issues found so far. Blanks and resumes from blanking with no issues seen so far. Forcing it on/off seems fine so far as well
WAYLAND_DISPLAY="wayland-1" wlr-randr --output LVDS-1 --off
WAYLAND_DISPLAY="wayland-1" wlr-randr --output LVDS-1 --on