@@ -966,6 +966,28 @@ static u32 *cdns_dsi_bridge_get_input_bus_fmts(struct drm_bridge *bridge,
return input_fmts;
}
+static long cdns_dsi_round_pclk(struct cdns_dsi *dsi, unsigned long pclk)
+{
+ struct cdns_dsi_output *output = &dsi->output;
+ unsigned int nlanes = output->dev->lanes;
+ union phy_configure_opts phy_opts = { 0 };
+ u32 bitspp;
+ int ret;
+
+ bitspp = mipi_dsi_pixel_format_to_bpp(output->dev->format);
+
+ ret = phy_mipi_dphy_get_default_config(pclk, bitspp, nlanes,
+ &phy_opts.mipi_dphy);
+ if (ret)
+ return ret;
+
+ ret = phy_validate(dsi->dphy, PHY_MODE_MIPI_DPHY, 0, &phy_opts);
+ if (ret)
+ return ret;
+
+ return div64_u64((u64)phy_opts.mipi_dphy.hs_clk_rate * nlanes, bitspp);
+}
+
static int cdns_dsi_bridge_atomic_check(struct drm_bridge *bridge,
struct drm_bridge_state *bridge_state,
struct drm_crtc_state *crtc_state,
@@ -978,12 +1000,27 @@ static int cdns_dsi_bridge_atomic_check(struct drm_bridge *bridge,
struct cdns_dsi_cfg *dsi_cfg = &dsi_state->dsi_cfg;
struct drm_display_mode *adjusted_crtc_mode = &crtc_state->adjusted_mode;
struct videomode vm;
+ long pclk;
/* cdns-dsi requires negative syncs */
adjusted_crtc_mode->flags &= ~(DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
adjusted_crtc_mode->flags |= DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC;
- drm_display_mode_to_videomode(mode, &vm);
+ /*
+ * The DPHY PLL has quite a coarsely grained clock rate options. See
+ * what hsclk rate we can achieve based on the pixel clock, convert it
+ * back to pixel clock, set that to the adjusted_mode->clock. This is
+ * all in hopes that the CRTC will be able to provide us the requested
+ * clock, as otherwise the DPI and DSI clocks will be out of sync.
+ */
+
+ pclk = cdns_dsi_round_pclk(dsi, mode->clock * 1000);
+ if (pclk < 0)
+ return (int)pclk;
+
+ adjusted_crtc_mode->clock = pclk / 1000;
+
+ drm_display_mode_to_videomode(adjusted_crtc_mode, &vm);
return cdns_dsi_check_conf(dsi, &vm, dsi_cfg);
}
The driver currently expects the pixel clock and the HS clock to be compatible, but the DPHY PLL doesn't give very finely grained rates. This often leads to the situation where the pipeline just fails, as the resulting HS clock is just too off. We could change the driver to do a better job on adjusting the DSI blanking values, hopefully getting a working pipeline even if the pclk and HS clocks are not exactly compatible. But that is a bigger work. What we can do easily is to see in .atomic_check() what HS clock rate we can get, based on the pixel clock rate, and then convert the HS clock rate back to pixel clock rate and ask that rate from the crtc. If the crtc has a good PLL (which is the case for TI K3 SoCs), this will fix any issues wrt. the clock rates. If the crtc cannot provide the requested clock, well, we're no worse off with this patch than what we have at the moment. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> --- drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 39 +++++++++++++++++++++++++- 1 file changed, 38 insertions(+), 1 deletion(-)