@@ -517,50 +517,6 @@ static int cdns_dsi_mode2cfg(struct cdns_dsi *dsi,
return 0;
}
-static int cdns_dsi_adjust_phy_config(struct cdns_dsi *dsi,
- struct cdns_dsi_cfg *dsi_cfg,
- struct phy_configure_opts_mipi_dphy *phy_cfg,
- const struct videomode *vm)
-{
- struct cdns_dsi_output *output = &dsi->output;
- unsigned long long dlane_bps;
- unsigned long adj_dsi_htotal;
- unsigned long dsi_htotal;
- unsigned long dpi_htotal;
- unsigned long dpi_hz;
- unsigned int dsi_hfp_ext;
- unsigned int lanes = output->dev->lanes;
-
- dsi_htotal = dsi_cfg->htotal;
-
- /*
- * Make sure DSI htotal is aligned on a lane boundary when calculating
- * the expected data rate. This is done by extending HFP in case of
- * misalignment.
- */
- adj_dsi_htotal = dsi_htotal;
- if (dsi_htotal % lanes)
- adj_dsi_htotal += lanes - (dsi_htotal % lanes);
-
- dpi_hz = vm->pixelclock;
- dlane_bps = (unsigned long long)dpi_hz * adj_dsi_htotal;
-
- /* data rate in bytes/sec is not an integer, refuse the mode. */
- dpi_htotal = vm->hactive + vm->hfront_porch + vm->hback_porch +
- vm->hsync_len;
- if (do_div(dlane_bps, lanes * dpi_htotal))
- return -EINVAL;
-
- /* data rate was in bytes/sec, convert to bits/sec. */
- phy_cfg->hs_clk_rate = dlane_bps * 8;
-
- dsi_hfp_ext = adj_dsi_htotal - dsi_htotal;
- dsi_cfg->hfp += dsi_hfp_ext;
- dsi_cfg->htotal = dsi_htotal + dsi_hfp_ext;
-
- return 0;
-}
-
static int cdns_dsi_check_conf(struct cdns_dsi *dsi,
const struct videomode *vm,
struct cdns_dsi_cfg *dsi_cfg)
@@ -581,10 +537,6 @@ static int cdns_dsi_check_conf(struct cdns_dsi *dsi,
if (ret)
return ret;
- ret = cdns_dsi_adjust_phy_config(dsi, dsi_cfg, phy_cfg, vm);
- if (ret)
- return ret;
-
req_hs_clk_rate = output->phy_opts.mipi_dphy.hs_clk_rate;
ret = phy_validate(dsi->dphy, PHY_MODE_MIPI_DPHY, 0, &output->phy_opts);
if (ret)
cdns_dsi_adjust_phy_config() is called from cdns_dsi_adjust_phy_config(), which is called from .atomic_check(). It checks the DSI htotal and adjusts it to align on the DSI lane boundary by changing hfp and then recalculating htotal and HS clock rate. This has a few problems. First is the fact that the whole thing is not needed: we do not need to align on the lane boundary. The whole frame is sent in HS mode, and it is fine if the line's last byte clock tick fills, say, only 2 of the 4 lanes. The next line will just continue from there. Assuming the DSI timing values have been calculated to match the incoming DPI stream, and the HS clock is compatible with the DPI pixel clock, the "uneven" DSI lines will even out when multiple lines are being sent. But we could do the align, aligning is not a problem as such. However, adding more bytes to the hfp, as the function currently does, makes the DSI line time longer, so the function then adjusts the HS clock rate. This is where things fail: we don't know what rates we can get from the HS clock, and at least in TI K3 SoC case the rates are quite coarsely grained. Thus small adjustment to hfp will lead to a big change in HS clock rate, and things break down. We could do a loop here, adjusting hfp, adjusting clock, checking clock rate, adjusting hfp again, etc., but considering that the whole adjustment shouldn't be needed at all, it's easier to just remove the function. Something like this function should be added back later, when adding burst mode support, but that's a bigger change and I don't think this function would help that work in any way. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> --- drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 48 -------------------------- 1 file changed, 48 deletions(-)