The issue with the panel driver is mostly with probe ordering and timing – the driver gets probed and initialized before the supply voltage regulators are, so the first initialization sequence does exactly nothing. However, if, for example, your desktop environment blanks the screen and resets it when it starts up, or for some reason the display panel module is loaded extremely late, then this might work anyway.
I have no clue why this specific case kept happening on my hardware, but it’s not weird that timing issues behave like that. It could also be a result of not trying to boot into a desktop environment immediately, and thus no blanking and re-initialization (however, manually blanking the framebuffer also didn’t work for me – probably because the code in unprepare is all commented out). I’m also ~50% sure that almost all the panel initialization issues the uConsole has ultimately boil down to this probe timing. This is also why blanking the framebuffer and un-blanking it usually fixes the issue. In fact, all 3 of the old drivers (cm3, cm4, cm5) handled startup timing differently. And the CM4 driver didn’t even have the two voltage regulators defined before.
Here’s a pull request to fix up initialization ordering: drm: panel: cwu50: Fixup for probe ordering and initialization timing by PeterCxy · Pull Request #3 · ak-rex/ClockworkPi-linux · GitHub. I added the iovcc definition for CM4 too so that initialization order is somewhat fixed there as well. But I didn’t add vci because I’m not sure what that regulator maps to on the CM4 and I don’t have a real piece of hardware at hand to test with. My current Arch Kernel build contains the fix already.