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/[email protected]/
Compared to that version, this one uses the phy-cells method and drops
the X1E80100 support. The X1E80100 support will be a separate patchset.
Signed-off-by: Abel Vesa <[email protected]>
---
Abel Vesa (3):
dt-bindings: phy: Add PHY_TYPE_EDP definition
phy: Add PHY Embedded DisplayPort mode
phy: qcom: edp: Allow PHY mode configuration via devicetree
drivers/phy/qualcomm/phy-qcom-edp.c | 89 ++++++++++++++++++++++++++++---------
include/dt-bindings/phy/phy.h | 1 +
include/linux/phy/phy.h | 3 +-
3 files changed, 70 insertions(+), 23 deletions(-)
---
base-commit: 0e182d9523f6c0af49357fcd812eaa702bd4b403
change-id: 20231219-x1e80100-phy-edp-compatible-refactor-8733eca7ccda
Best regards,
--
Abel Vesa <[email protected]>
Add definition for Embedded DisplayPort (eDP) phy mode.
Signed-off-by: Abel Vesa <[email protected]>
---
include/linux/phy/phy.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index f6d607ef0e80..bea532711906 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -42,7 +42,8 @@ enum phy_mode {
PHY_MODE_MIPI_DPHY,
PHY_MODE_SATA,
PHY_MODE_LVDS,
- PHY_MODE_DP
+ PHY_MODE_DP,
+ PHY_MODE_EDP
};
enum phy_media {
--
2.34.1
Add definition for Embedded DisplayPort (eDP) phy type.
Signed-off-by: Abel Vesa <[email protected]>
---
include/dt-bindings/phy/phy.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/dt-bindings/phy/phy.h b/include/dt-bindings/phy/phy.h
index 6b901b342348..b1a64508d937 100644
--- a/include/dt-bindings/phy/phy.h
+++ b/include/dt-bindings/phy/phy.h
@@ -23,5 +23,6 @@
#define PHY_TYPE_DPHY 10
#define PHY_TYPE_CPHY 11
#define PHY_TYPE_USXGMII 12
+#define PHY_TYPE_EDP 13
#endif /* _DT_BINDINGS_PHY */
--
2.34.1
Future platforms should not use different compatibles to differentiate
between eDP and DP mode. Instead, they should use a single compatible as
the IP block is the same, and use the 'phys' (controller) DT property
to pass the phy mode. Rework the device match config data so that it
only keeps the different knobs rather than swing and pre-emphasis tables.
The existing platforms will remain with separate compatibles for each mode.
Signed-off-by: Abel Vesa <[email protected]>
---
drivers/phy/qualcomm/phy-qcom-edp.c | 89 ++++++++++++++++++++++++++++---------
1 file changed, 67 insertions(+), 22 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c b/drivers/phy/qualcomm/phy-qcom-edp.c
index 8e5078304646..c70e6eae16ba 100644
--- a/drivers/phy/qualcomm/phy-qcom-edp.c
+++ b/drivers/phy/qualcomm/phy-qcom-edp.c
@@ -68,19 +68,22 @@
#define TXn_TRAN_DRVR_EMP_EN 0x0078
-struct qcom_edp_cfg {
- bool is_dp;
-
- /* DP PHY swing and pre_emphasis tables */
+struct qcom_edp_swing_pre_emph_cfg {
const u8 (*swing_hbr_rbr)[4][4];
const u8 (*swing_hbr3_hbr2)[4][4];
const u8 (*pre_emphasis_hbr_rbr)[4][4];
const u8 (*pre_emphasis_hbr3_hbr2)[4][4];
};
+struct qcom_edp_phy_cfg {
+ int type;
+ bool needs_swing_pre_emph_cfg;
+};
+
struct qcom_edp {
struct device *dev;
- const struct qcom_edp_cfg *cfg;
+ const struct qcom_edp_phy_cfg *cfg;
+ const struct qcom_edp_swing_pre_emph_cfg *swing_pre_emph_cfg;
struct phy *phy;
@@ -96,6 +99,8 @@ struct qcom_edp {
struct clk_bulk_data clks[2];
struct regulator_bulk_data supplies[2];
+
+ bool is_dp;
};
static const u8 dp_swing_hbr_rbr[4][4] = {
@@ -126,8 +131,7 @@ static const u8 dp_pre_emp_hbr2_hbr3[4][4] = {
{ 0x04, 0xff, 0xff, 0xff }
};
-static const struct qcom_edp_cfg dp_phy_cfg = {
- .is_dp = true,
+static const struct qcom_edp_swing_pre_emph_cfg dp_phy_swing_pre_emph_cfg = {
.swing_hbr_rbr = &dp_swing_hbr_rbr,
.swing_hbr3_hbr2 = &dp_swing_hbr2_hbr3,
.pre_emphasis_hbr_rbr = &dp_pre_emp_hbr_rbr,
@@ -162,18 +166,30 @@ static const u8 edp_pre_emp_hbr2_hbr3[4][4] = {
{ 0x00, 0xff, 0xff, 0xff }
};
-static const struct qcom_edp_cfg edp_phy_cfg = {
- .is_dp = false,
+static const struct qcom_edp_swing_pre_emph_cfg edp_phy_swing_pre_emph_cfg = {
.swing_hbr_rbr = &edp_swing_hbr_rbr,
.swing_hbr3_hbr2 = &edp_swing_hbr2_hbr3,
.pre_emphasis_hbr_rbr = &edp_pre_emp_hbr_rbr,
.pre_emphasis_hbr3_hbr2 = &edp_pre_emp_hbr2_hbr3,
};
+static struct qcom_edp_phy_cfg sc7280_dp_phy_cfg = {
+ .type = PHY_TYPE_DP,
+};
+
+static struct qcom_edp_phy_cfg sc8280xp_dp_phy_cfg = {
+ .type = PHY_TYPE_DP,
+ .needs_swing_pre_emph_cfg = true,
+};
+
+static struct qcom_edp_phy_cfg sc8280xp_edp_phy_cfg = {
+ .type = PHY_TYPE_EDP,
+ .needs_swing_pre_emph_cfg = true,
+};
+
static int qcom_edp_phy_init(struct phy *phy)
{
struct qcom_edp *edp = phy_get_drvdata(phy);
- const struct qcom_edp_cfg *cfg = edp->cfg;
int ret;
u8 cfg8;
@@ -200,7 +216,7 @@ static int qcom_edp_phy_init(struct phy *phy)
DP_PHY_PD_CTL_PLL_PWRDN | DP_PHY_PD_CTL_DP_CLAMP_EN,
edp->edp + DP_PHY_PD_CTL);
- if (cfg && cfg->is_dp)
+ if (edp->cfg->needs_swing_pre_emph_cfg && edp->is_dp)
cfg8 = 0xb7;
else
cfg8 = 0x37;
@@ -234,7 +250,7 @@ static int qcom_edp_phy_init(struct phy *phy)
static int qcom_edp_set_voltages(struct qcom_edp *edp, const struct phy_configure_opts_dp *dp_opts)
{
- const struct qcom_edp_cfg *cfg = edp->cfg;
+ const struct qcom_edp_swing_pre_emph_cfg *cfg = edp->swing_pre_emph_cfg;
unsigned int v_level = 0;
unsigned int p_level = 0;
u8 ldo_config;
@@ -242,7 +258,7 @@ static int qcom_edp_set_voltages(struct qcom_edp *edp, const struct phy_configur
u8 emph;
int i;
- if (!cfg)
+ if (!edp->cfg->needs_swing_pre_emph_cfg)
return 0;
for (i = 0; i < dp_opts->lanes; i++) {
@@ -261,7 +277,7 @@ static int qcom_edp_set_voltages(struct qcom_edp *edp, const struct phy_configur
if (swing == 0xff || emph == 0xff)
return -EINVAL;
- ldo_config = (cfg && cfg->is_dp) ? 0x1 : 0x0;
+ ldo_config = edp->is_dp ? 0x1 : 0x0;
writel(ldo_config, edp->tx0 + TXn_LDO_CONFIG);
writel(swing, edp->tx0 + TXn_TX_DRV_LVL);
@@ -447,10 +463,9 @@ static int qcom_edp_set_vco_div(const struct qcom_edp *edp, unsigned long *pixel
static int qcom_edp_phy_power_on(struct phy *phy)
{
const struct qcom_edp *edp = phy_get_drvdata(phy);
- const struct qcom_edp_cfg *cfg = edp->cfg;
u32 bias0_en, drvr0_en, bias1_en, drvr1_en;
unsigned long pixel_freq;
- u8 ldo_config;
+ u8 ldo_config = 0x0;
int timeout;
int ret;
u32 val;
@@ -468,7 +483,8 @@ static int qcom_edp_phy_power_on(struct phy *phy)
return timeout;
- ldo_config = (cfg && cfg->is_dp) ? 0x1 : 0x0;
+ if (edp->cfg->needs_swing_pre_emph_cfg && edp->is_dp)
+ ldo_config = 0x1;
writel(ldo_config, edp->tx0 + TXn_LDO_CONFIG);
writel(ldo_config, edp->tx1 + TXn_LDO_CONFIG);
@@ -768,6 +784,33 @@ static int qcom_edp_clks_register(struct qcom_edp *edp, struct device_node *np)
return devm_of_clk_add_hw_provider(edp->dev, of_clk_hw_onecell_get, data);
}
+static struct phy *qcom_edp_phy_xlate(struct device *dev,
+ struct of_phandle_args *args)
+{
+ struct qcom_edp *edp = dev_get_drvdata(dev);
+ int type = edp->cfg->type;
+
+ if (args->args_count == 1)
+ type = args->args[0];
+
+ if (type != PHY_TYPE_DP && type != PHY_TYPE_EDP)
+ return ERR_PTR(-EINVAL);
+
+ if (type == PHY_TYPE_EDP) {
+ edp->phy->attrs.mode = PHY_MODE_EDP;
+ } else {
+ edp->phy->attrs.mode = PHY_MODE_DP;
+ edp->is_dp = true;
+ }
+
+ if (edp->cfg->needs_swing_pre_emph_cfg)
+ edp->swing_pre_emph_cfg = edp->is_dp ?
+ &dp_phy_swing_pre_emph_cfg:
+ &edp_phy_swing_pre_emph_cfg;
+
+ return edp->phy;
+}
+
static int qcom_edp_phy_probe(struct platform_device *pdev)
{
struct phy_provider *phy_provider;
@@ -832,17 +875,19 @@ static int qcom_edp_phy_probe(struct platform_device *pdev)
return PTR_ERR(edp->phy);
}
+ dev_set_drvdata(edp->dev, edp);
phy_set_drvdata(edp->phy, edp);
- phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
+ phy_provider = devm_of_phy_provider_register(dev, qcom_edp_phy_xlate);
+
return PTR_ERR_OR_ZERO(phy_provider);
}
static const struct of_device_id qcom_edp_phy_match_table[] = {
- { .compatible = "qcom,sc7280-edp-phy" },
- { .compatible = "qcom,sc8180x-edp-phy" },
- { .compatible = "qcom,sc8280xp-dp-phy", .data = &dp_phy_cfg },
- { .compatible = "qcom,sc8280xp-edp-phy", .data = &edp_phy_cfg },
+ { .compatible = "qcom,sc7280-edp-phy" , .data = &sc7280_dp_phy_cfg, },
+ { .compatible = "qcom,sc8180x-edp-phy", .data = &sc7280_dp_phy_cfg, },
+ { .compatible = "qcom,sc8280xp-dp-phy", .data = &sc8280xp_dp_phy_cfg, },
+ { .compatible = "qcom,sc8280xp-edp-phy", .data = &sc8280xp_edp_phy_cfg, },
{ }
};
MODULE_DEVICE_TABLE(of, qcom_edp_phy_match_table);
--
2.34.1
On 19/12/2023 21:55, Abel Vesa wrote:
> Add definition for Embedded DisplayPort (eDP) phy type.
>
> Signed-off-by: Abel Vesa <[email protected]>
> ---
> include/dt-bindings/phy/phy.h | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Krzysztof Kozlowski <[email protected]>
Best regards,
Krzysztof
On Tue, 19 Dec 2023 at 22:55, Abel Vesa <[email protected]> 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/[email protected]/
>
> 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?
--
With best wishes
Dmitry
On Tue, 19 Dec 2023 at 22:55, Abel Vesa <[email protected]> wrote:
>
> Add definition for Embedded DisplayPort (eDP) phy mode.
If we leave the DT property aside, is eDP a separate PHY mode, or a
submode? (in terms of phy_set_mode_ext).
> Signed-off-by: Abel Vesa <[email protected]>
> ---
> include/linux/phy/phy.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index f6d607ef0e80..bea532711906 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -42,7 +42,8 @@ enum phy_mode {
> PHY_MODE_MIPI_DPHY,
> PHY_MODE_SATA,
> PHY_MODE_LVDS,
> - PHY_MODE_DP
> + PHY_MODE_DP,
> + PHY_MODE_EDP
> };
--
With best wishes
Dmitry
On 21.12.2023 17:27, Dmitry Baryshkov wrote:
> On Tue, 19 Dec 2023 at 22:55, Abel Vesa <[email protected]> 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/[email protected]/
>>
>> 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?
Konrad
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 <[email protected]> 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/[email protected]/
> >>
> >> 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.
>
> Konrad
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 <[email protected]> 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/[email protected]/
>>>>
>>>> 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