The root of the problem seems to be BURST mode with the bridge, and that the IMX8MP has a fixed root video clock that feeds all the video interfaces, and those video interfaces can only divide up that root clock in a number of ways. LVDS for example - can only divide it by 7 (Display Output, Resolution and Timings (Linux) | Toradex Developer Center). I’m not exactly sure what the limitations are for the pixel clock for DSI, but - when I set up a pixel clock for the panel in the DTS of 25Mhz, the DSI pixel clock seems to actually be slightly under, in other cases it may be slightly over. This mismatch seems to cause issues feeding the bridge fast enough which is trying to drive another display at a fixed timing.
imx8mp.dtsi has a fixed clock for the root clock:
clk-pll14xx.c has a fixed table for configurations for the PLL:
So, I can only assume that what was happening is that the fixed 1039.5MHz couldn’t be divided down accurately enough to make a pixel clock that feeds the 25MHz requirement sufficiently with the clock ranges/timings the bridge driver configures.
But, since commit b09c68dc57c9 (“clk: imx: pll14xx: Support dynamic rates”) - this video PLL can basically arbitrarily be set, and it calculates these constants for you. So, I searched around to find someone who used this and found:
https://lore.kernel.org/linux-arm-kernel/6bc5b8d7-ff10-4860-ac46-1460a7d850da@denx.de/T/
This sets up CLK_SET_PARENT on the imx8mp pixel clocks so that they can reconfigure the video PLL to be ideal.
Now, this commit was later reverted: [v7,2/7] Revert "clk: imx: clk-imx8mp: Allow media_disp pixel clock reconfigure parent rate" - Patchwork
Because both of the two pixel clocks will fight to reconfigure the root video PLL. For a single display use-case, I’m pretty sure this works very well though and I’d recommend folks give it a try if they’re seeing the clock (media_dispN_pix) not divide out well. I’m pretty sure there’s a way to math out what the root video PLL should be to better divide down, but I’ll stick with this for my single display use-case as it will probably result in many DTSses for various pixel clock frequencies working well without needing any kernel changes.
Also, I don’t exactly understand this, but it seems that BURST mode for DSI that the bridge driver sets up causes issues. I’ve seen a few folks make this patch to the sn65dsi83.c driver. Without using sync pulse mode, I see the display do this odd interlacing pattern:
Anyway, I can now see that the pixel clock is exactly the 25MHz I set in the DTS:
This along with the BURST change results in a stable display.