Re: [PATCH 0/3] phy: qcom: edp: Add support for DT phy mode configuration

From: Konrad Dybcio
Date: Thu Jan 25 2024 - 11:36:25 EST




On 1/15/24 10:52, Abel Vesa wrote:
On 24-01-03 14:42:49, Konrad Dybcio wrote:
On 21.12.2023 17:27, Dmitry Baryshkov wrote:
On Tue, 19 Dec 2023 at 22:55, Abel Vesa <abel.vesa@xxxxxxxxxx> wrote:

Until now, all platform that supported both eDP and DP had different
compatibles for each mode. Using different compatibles for basically
the same IP block but for a different configuration is bad way all
around. There is a new compute platform from Qualcomm that supports
both eDP and DP with the same PHY. So instead of following the old
method, we should allow the mode to be configured from devicetree.

There has been an off-list discussion on what would be the right way
to pass on the PHY mode information to the driver and it has been
concluded that phy-cells is the way to go. This means that basically
the controller will pass another value (that is, the PHY type) to
its 'phys' DT property.

For this, we need both the bindings value and the PHY mode value to be
added as well.

The controller part will follow shortly. But for now, lets see where
this is going.

There has been another attempt at this here:
https://lore.kernel.org/all/20231122-phy-qualcomm-edp-x1e80100-v3-3-576fc4e9559d@xxxxxxxxxx/

Compared to that version, this one uses the phy-cells method and drops
the X1E80100 support. The X1E80100 support will be a separate patchset.

After several back and forth discussions, I think that this approach
is not correct and not that easy to extend. Instead I'd like to
suggest adding a property to the DP controller, which enables eDP
behaviour (and thus makes DP driver call phy_set_mode()). Something
like this:
dp: displayport-controller@ae0000 {
compatible = "qcom,sm8000-dp";
/* reg, interrupts, etc */
edp-interface;
/* or simpler */
is-edp;
};

What do you think?

Please excuse my alzheimer, but why did we not go with phy-type after
the last discussion?

phy-type would be a property of the phy. That way we would need pass
the mode to the controller. So it was concluded that passing that
information from the controller via phy_set_mode is more straightforward.

Eeh, reluctantly, I'm gonna say yes. It's not the prettiest solution,
but none of the ones I can think of seem much better.

Konrad