Hi,
On Wed, Mar 30, 2022 at 11:02 PM Sankeerth Billakanti (QUIC) quic_sbillaka@quicinc.com wrote:
Hi Dmitry,
On Wed, 30 Mar 2022 at 19:04, Sankeerth Billakanti quic_sbillaka@quicinc.com wrote:
The panel-edp driver modes needs to be validated differently from DP because the link capabilities are not available for EDP by that time.
Signed-off-by: Sankeerth Billakanti quic_sbillaka@quicinc.com
This should not be necessary after https://patchwork.freedesktop.org/patch/479261/?series=101682&rev=1. Could you please check?
The check for DP_MAX_PIXEL_CLK_KHZ is not necessary anymore but we need to return early for eDP because unlike DP, eDP context will not have the information about the number of lanes and link clock.
So, I will modify the patch to return after the DP_MAX_PIXEL_CLK_KHZ check if is_eDP is set.
I haven't walked through all the relevant code but something you said above sounds strange. You say that for eDP we don't have info about the number of lanes? We _should_.
It's certainly possible to have a panel that supports _either_ 1 or 2 lanes but then only physically connect 1 lane to it. ...or you could have a panel that supports 2 or 4 lanes and you only connect 1 lane. See, for instance, ti_sn_bridge_parse_lanes. There we assume 4 lanes but if a "data-lanes" property is present then we can use that to know that fewer lanes are physically connected.
It's also possible to connect more lanes to a panel than it supports. You could connect 2 lanes to it but then it only supports 1. This case needs to be handled as well...
-Doug