-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DRM: rp1: rp1-dsi: Fix escape clock divider and timeouts. #6120
Conversation
Escape clock divider was fixed at 5, which is correct at 800Mbps/lane but increasingly out of spec for higher rates. Compute it correctly. High speed timeout was fixed at 5*512 == 2560 byte-clocks per lane. Compute it conservatively to be 8/7 times the line period (assuming there will be a transition to LP some time during each scanline?) keeping the old value as a lower bound. Increase LPRX TO to 1024, and BTA TO to 0xb00 (same value as in bridge/synopsys/dw-mipi-dsi). (No change to LP_CMD_TIM. To do: compute this correctly.) Signed-off-by: Nick Hollinghurst <nick.hollinghurst@raspberrypi.com>
I think this fixes wide-scanline DSI flakiness, and perhaps setup issues at high bitrates. Some loose ends remain:
And there's the question of whether we should be using the bridge/synopsys driver instead! I avoided this because it requires a great deal of adaptation / boilerplate (since PHY config-bus, clock and power arrangements can vary so much between chips). |
Seems to work for 2 lane mode. I've added a line to the overlay to allow overriding 4 lane mode is odd.
|
Tell a lie - we get RGB, blanking packet, and then HSync start. Drop to LP, wait a bit, back to HS with a HSync start, back to LP. Then repeat. |
I'll try to reproduce this in the sim. I expect it's unrelated to the timeout(?) but it'd be good to fix it while we're here. |
Ahhh -- I suspect it's another driver silliness and we most likely have never correctly supported 4 lanes. 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. Will have to think about another way to route clocks to synchronize them. I'm not yet completely sure how synchronized they need to be for correct operation in non-burst mode... The DSI PLL has finite precision and doesn't produce exactly the requested frequency. Everything is coming from the same crystal so it should be tractable. |
I'm inclined to push this change and raise a new issue for 4 lanes. We may need to investigate what pixel-clock precision can be achieved while keeping DPI and DSI in effective lock-step; or alternatively what happens when they're not quite aligned (hopefully the worst that will happen is that HFP duration becomes slightly irregular). It's a bit of an odd design that we have these two clock / video timing domains, one of them purely internal. Unlike in 2712 there is no pixel-valve (there is an eDPI flow-control signal, but I think it's only for command-mode displays). |
Absolutely. Feel free to drop the Draft tag from this PR. |
See: raspberrypi/linux#6113 kernel: DRM: rp1: rp1-dsi: Fix escape clock divider and timeouts See: raspberrypi/linux#6120 kernel: vc4/hdmi: Ignore hotplug interrupt with force_hotplug See: raspberrypi/linux#6123 kernel: drivers: media: cfe: Add remap entries for mono formats See: raspberrypi/linux#6122 kernel: dw-axi-dmac-platform: Avoid trampling with zero length buffer See: raspberrypi/linux#6118 kernel: Add a strict_gpiod option See: raspberrypi/linux#6117 kernel: Unicam FS/FE timing GPIO See: raspberrypi/linux#6088
See: raspberrypi/linux#6113 kernel: DRM: rp1: rp1-dsi: Fix escape clock divider and timeouts See: raspberrypi/linux#6120 kernel: vc4/hdmi: Ignore hotplug interrupt with force_hotplug See: raspberrypi/linux#6123 kernel: drivers: media: cfe: Add remap entries for mono formats See: raspberrypi/linux#6122 kernel: dw-axi-dmac-platform: Avoid trampling with zero length buffer See: raspberrypi/linux#6118 kernel: Add a strict_gpiod option See: raspberrypi/linux#6117 kernel: Unicam FS/FE timing GPIO See: raspberrypi/linux#6088
Escape clock divider was fixed at 5, which is correct at 800Mbps/lane but increasingly out of spec for higher rates. Compute it correctly.
High speed timeout was fixed at 5*512 == 2560 byte-clocks per lane. Compute it conservatively to be 8/7 times the line period (assuming there will be a transition to LP some time during each scanline?) keeping the old value as a lower bound. Increase LPRX TO to 1024, and BTA TO to 0xb00 (same value as in bridge/synopsys/dw-mipi-dsi).
(No change to LP_CMD_TIM. To do: compute this correctly.)