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 via set_mode from
the controller driver.

The controller part will follow after we conclude the PHY part first.

Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
---
Changes in v2:
- Dropped the dedicated xlate function and added set_mode op instead
- Dropped the eDP PHY type and mode addition
- Added the DP PHY submodes (eDP and DP)
- Removed the device match data storing from the container struct
- Link to v1: https://lore.kernel.org/r/20231219-x1e80100-phy-edp-compatible-refactor-v1-0-f9e77752953d@linaro.org

Initial attepmpt was here:
https://lore.kernel.org/all/20231122-phy-qualcomm-edp-x1e80100-v3-3-576fc4e9559d@linaro.org/
Compared to that version, this one uses the phy-cells method and drops
the X1E80100 support. The X1E80100 support will be a separate patchset.

---
Abel Vesa (2):
      phy: Add Embedded DisplayPort and DisplayPort submodes
      phy: qcom: edp: Add set_mode op for configuring eDP/DP submode

 drivers/phy/qualcomm/phy-qcom-edp.c | 90 ++++++++++++++++++++++++++++---------
 include/linux/phy/phy-dp.h          |  3 ++
 2 files changed, 72 insertions(+), 21 deletions(-)
---
base-commit: 8a9be2a3cb673dba9d22311beb74be261f0b3f15
change-id: 20231219-x1e80100-phy-edp-compatible-refactor-8733eca7ccda

Best regards,
-- 
Abel Vesa <abel.vesa@linaro.org>

On 22.12.2023 14:01, Abel Vesa 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 via set_mode from
> the controller driver.
> 
> The controller part will follow after we conclude the PHY part first.
I got a bit lost between all the propositions, how are we going to
discern the controller modes going forward?

Konrad

On 23-12-22 16:02:56, Konrad Dybcio wrote:
> On 22.12.2023 14:01, Abel Vesa 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 via set_mode from
> > the controller driver.
> > 
> > The controller part will follow after we conclude the PHY part first.
> I got a bit lost between all the propositions, how are we going to
> discern the controller modes going forward?

Have a look here:
https://lore.kernel.org/all/CAA8EJpr8rKMBzcm-=HGu7-C5hPkNMrnG1cA78O00UjgJVT7p6Q@mail.gmail.com/

I currently implemented this locally, using the is-edp property.

Whatever property we will end up using for specifying the mode in the
controller mode, the set_mode op is still needed in the phy driver.

> 
> Konrad