RP1 (Pi 5) DSI issue with 4 lanes

[njhollinghurst]

Describe the bug

Currently we make the DPI clock by dividing down the DSI byte clock. That is not going to work in cases where bpp < 8*lanes.

With the current driver it can result in DPI running too slowly, causing dropped scanlines and other misbehaviour of MIPI DSI.

If they must be clocked via different PLL and divider architectures, we may need to investigate what pixel-rate precision can be achieved while keeping DPI and DSI in effective lock-step; or to understand what happens when they're not quite synchronized (hopefully the worst that will happen is that HFP duration becomes slightly irregular)? In either case, some driver changes will be needed.

(leftover from PR 6120)

Steps to reproduce the behaviour

Using dtoverlay=vc4-kms-dsi-generic, configure DSI output with four lanes and 24bpp. kmstest --flip will show that the display is running at a lower frame rate than expected. A DSI analyser may show other woes.

Device (s)

Raspberry Pi 5

System

rpi-6.6.y

Logs

No response

Additional context

cc @6by9

[njhollinghurst]

Been doing some experiments with the 7" display (even though it uses only 1 lane)...

When DPI rate is imprecisely derived from the 200MHz core clock: the screen works but flickers, with a horizontal jitter.

DSI Host has the option to inhibit returning to LP mode during HBP, which may guarantee that the offset between HSYNC and data will be a fixed number of MIPI clocks. Unfortunately that doesn't cure the jitter!*

There is a limited palette of pixel rates for which we can derive DPI rate from the core clock and DSI from the MIPI PLL, in an exact ratio. With one lane at 24bpp, 28.571Mpix/s is one such rate, and it displays perfectly.** With 4 lanes there would be about 25 such rates in the range 13.333Mpix/s to 160Mpix/s.

-- *I guess the bridge chip expects the line period to be uniform, or perhaps an exact multiple of its own re-generated (divided) DPI clock. Let's hope other displays are less fussy.

**it doesn't bear too much thinking about how this displays without jitter, since the phase relationship between the two clocks is undefined.

[njhollinghurst]

#6157 should fix this by allowing DPI clock to be derived from PLL_SYS where necessary.

Still no attempt has been made to force the pixel-rate to a more auspicious one to reduce jitter, since we have not tested with a 4-lane panel that would seem to need it.

[njhollinghurst]

There are still questions about "burst mode", namely:

• how to interpret the DRM flag that requests it;
• whether we can exploit it to lock the DPI and DSI clock rates and avoid jitter altogether;
• how to drive the HW flag of the same name (which changes a FIFO threshold, but may be detrimental to reliability by preventing DSI host from re-synchronizing to DPI?)

But I think this issue is dealt with now.