From manivannan.sadhasivam at linaro.org  Thu Aug  1 00:00:26 2024
From: manivannan.sadhasivam at linaro.org (Manivannan Sadhasivam)
Date: Thu, 1 Aug 2024 12:30:26 +0530
Subject: [PATCH v3] phy: qcom: qmp: Add debug prints for register writes
In-Reply-To: <172249532035.256913.2685367794999812971.b4-ty@kernel.org>
References: <20240731152548.102987-1-manivannan.sadhasivam@linaro.org>
 <172249532035.256913.2685367794999812971.b4-ty@kernel.org>
Message-ID: <20240801070026.GB3705@thinkpad>

On Thu, Aug 01, 2024 at 12:25:20PM +0530, Vinod Koul wrote:
> 
> On Wed, 31 Jul 2024 20:55:48 +0530, Manivannan Sadhasivam wrote:
> > These register prints are useful to validate the init sequence against the
> > Qcom internal documentation and also to share with the Qcom hw engineers to
> > debug issues related to PHY.
> > 
> > Sample debug prints:
> > 
> > qcom-qmp-pcie-phy 1c0e000.phy: Writing Reg: QSERDES_V5_COM_SYSCLK_EN_SEL Offset: 0x0094 Val: 0xd9
> > qcom-qmp-pcie-phy 1c0e000.phy: Writing Reg: QSERDES_V5_COM_HSCLK_SEL Offset: 0x0158 Val: 0x11
> > 
> > [...]
> 
> Applied, thanks!
> 
> [1/1] phy: qcom: qmp: Add debug prints for register writes
>       commit: 4e92d504475ea5841716ad775f412342520a3d26
> 

Thanks! Bjorn spotted that it is worth making 'char *name' a const. Can you
please ammend the commit?

- Mani

-- 
????????? ????????


From alexander.stein at ew.tq-group.com  Thu Aug  1 01:35:15 2024
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Thu, 01 Aug 2024 10:35:15 +0200
Subject: [PATCH] phy: fsl-imx8mq-usb: fix tuning parameter name
In-Reply-To: <20240801065716.3819399-1-xu.yang_2@nxp.com>
References: <20240801065716.3819399-1-xu.yang_2@nxp.com>
Message-ID: <5802707.GXAFRqVoOG@steina-w>

Am Donnerstag, 1. August 2024, 08:57:16 CEST schrieb Xu Yang:
> According to fsl,imx8mq-usb-phy.yaml, this tuning parameter should be
> fsl,phy-pcs-tx-deemph-3p5db-attenuation-db.

Should this include a Fixes tag?

Best regards,
Alexander

> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> ---
>  drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> index 0b9a59d5b8f0..adc6394626ce 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> @@ -176,7 +176,7 @@ static void imx8m_get_phy_tuning_data(struct imx8mq_usb_phy *imx_phy)
>  		imx_phy->comp_dis_tune =
>  			phy_comp_dis_tune_from_property(imx_phy->comp_dis_tune);
>  
> -	if (device_property_read_u32(dev, "fsl,pcs-tx-deemph-3p5db-attenuation-db",
> +	if (device_property_read_u32(dev, "fsl,phy-pcs-tx-deemph-3p5db-attenuation-db",
>  				     &imx_phy->pcs_tx_deemph_3p5db))
>  		imx_phy->pcs_tx_deemph_3p5db = PHY_TUNE_DEFAULT;
>  	else
> 


-- 
TQ-Systems GmbH | M?hlstra?e 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht M?nchen, HRB 105018
Gesch?ftsf?hrer: Detlef Schneider, R?diger Stahl, Stefan Schneider
http://www.tq-group.com/




From Markus.Elfring at web.de  Thu Aug  1 02:50:48 2024
From: Markus.Elfring at web.de (Markus Elfring)
Date: Thu, 1 Aug 2024 11:50:48 +0200
Subject: [PATCH v3 2/2] phy: nuvoton: add new driver for the Nuvoton MA35
 SoC USB 2.0 PHY
In-Reply-To: <20240801053744.807884-3-hpchen0nvt@gmail.com>
References: <20240801053744.807884-3-hpchen0nvt@gmail.com>
Message-ID: <9cca717a-c7e9-4bf7-8cde-3a90fcfb1df5@web.de>

?
> +++ b/drivers/phy/nuvoton/phy-ma35d1-usb2.c
> @@ -0,0 +1,146 @@
?
> +MODULE_DESCRIPTION("Nuvoton ma35d1 USB2.0 PHY driver");
> +MODULE_AUTHOR("hpchen0nvt at gmail.com");
?

How do you think about to add a personal name to such an email address?

Regards,
Markus


From abel.vesa at linaro.org  Thu Aug  1 03:33:36 2024
From: abel.vesa at linaro.org (Abel Vesa)
Date: Thu, 1 Aug 2024 13:33:36 +0300
Subject: [PATCH] phy: qcom-qmp-pcie: Fix X1E80100 PCIe Gen4 PHY
 initialisation
In-Reply-To: <ZqOysDk0LqwxG4OF@hovoldconsulting.com>
References: <20240726-x1e80100-phy-qmp-pcie-fix-config-v1-1-b569f03c0c48@linaro.org>
 <ZqOysDk0LqwxG4OF@hovoldconsulting.com>
Message-ID: <ZqtkgPf+JOP+im1s@linaro.org>

On 24-07-26 16:29:04, Johan Hovold wrote:
> On Fri, Jul 26, 2024 at 10:16:56AM +0300, Abel Vesa wrote:
> > Update the PCIe Gen4 PHY init sequence with the latest based on internal
> > Qualcomm documentation.
> 
> Any hints about what these updates imply?

Usually, there is an updated variant of the same document.
I've been told that this values are fine-tuned over time.
I'm assuming these updates should help with link stability, but it's
just a guess.

> 
> > Fixes: 606060ce8fd0 ("phy: qcom-qmp-pcie: Add support for X1E80100 g3x2 and g4x2 PCIE")
> > Signed-off-by: Abel Vesa <abel.vesa at linaro.org>
> > ---
> >  drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 23 ++++++++++++++++-------
> >  1 file changed, 16 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
> > index 5b36cc7ac78b..8b624afbf014 100644
> > --- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
> > +++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
> 
> >  static const struct qmp_phy_init_tbl x1e80100_qmp_gen4x2_pcie_tx_tbl[] = {
> > @@ -1286,12 +1287,15 @@ static const struct qmp_phy_init_tbl x1e80100_qmp_gen4x2_pcie_rx_tbl[] = {
> >  	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_DFE_1, 0x01),
> >  	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_DFE_2, 0x01),
> >  	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_DFE_3, 0x45),
> > -	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_VGA_CAL_MAN_VAL, 0x0b),
> > +	QMP_PHY_INIT_CFG_LANE(QSERDES_V6_20_RX_VGA_CAL_MAN_VAL, 0x0A, 1),
> > +	QMP_PHY_INIT_CFG_LANE(QSERDES_V6_20_RX_VGA_CAL_MAN_VAL, 0x0B, 2),
> 
> Please use lower-case hex consistently.

Sure. Will fix in v2.

> 
> > +	QMP_PHY_INIT_CFG(QSERDES_V6_20_VGA_CAL_CNTRL1, 0x00),
> >  	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_GM_CAL, 0x0d),
> >  	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_EQU_ADAPTOR_CNTRL4, 0x0b),
> >  	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_SIGDET_ENABLES, 0x1c),
> >  	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_PHPRE_CTRL, 0x20),
> > -	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_DFE_CTLE_POST_CAL_OFFSET, 0x38),
> > +	QMP_PHY_INIT_CFG_LANE(QSERDES_V6_20_RX_DFE_CTLE_POST_CAL_OFFSET, 0x3A, 1),
> > +	QMP_PHY_INIT_CFG_LANE(QSERDES_V6_20_RX_DFE_CTLE_POST_CAL_OFFSET, 0x38, 2),
> 
> Ditto.
> 
> Johan


From abel.vesa at linaro.org  Thu Aug  1 03:40:24 2024
From: abel.vesa at linaro.org (Abel Vesa)
Date: Thu, 01 Aug 2024 13:40:24 +0300
Subject: [PATCH v2] phy: qcom: qmp-pcie: Fix X1E80100 PCIe Gen4 PHY
 initialisation
Message-ID: <20240801-x1e80100-phy-qmp-pcie-fix-config-v2-1-cdc0f22b4169@linaro.org>

Update the PCIe Gen4 PHY init sequence with the latest based on internal
Qualcomm documentation.

Fixes: 606060ce8fd0 ("phy: qcom-qmp-pcie: Add support for X1E80100 g3x2 and g4x2 PCIE")
Signed-off-by: Abel Vesa <abel.vesa at linaro.org>
---
Changes in v2:
- Changed subject line as requested by Vinod (on a ML, different patch).
- Changed to lower case hex all new values.
- Link to v1: https://lore.kernel.org/r/20240726-x1e80100-phy-qmp-pcie-fix-config-v1-1-b569f03c0c48 at linaro.org
---
 drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 23 ++++++++++++++++-------
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
index 5b36cc7ac78b..06cd9787e700 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
@@ -1245,8 +1245,8 @@ static const struct qmp_phy_init_tbl x1e80100_qmp_gen4x2_pcie_serdes_tbl[] = {
 static const struct qmp_phy_init_tbl x1e80100_qmp_gen4x2_pcie_ln_shrd_tbl[] = {
 	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RXCLK_DIV2_CTRL, 0x01),
 	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_DFE_DAC_ENABLE1, 0x88),
-	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_TX_ADAPT_POST_THRESH1, 0x00),
-	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_TX_ADAPT_POST_THRESH2, 0x1f),
+	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_TX_ADAPT_POST_THRESH1, 0x02),
+	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_TX_ADAPT_POST_THRESH2, 0x0d),
 	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MODE_RATE_0_1_B0, 0xd4),
 	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MODE_RATE_0_1_B1, 0x12),
 	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MODE_RATE_0_1_B2, 0xdb),
@@ -1263,6 +1263,7 @@ static const struct qmp_phy_init_tbl x1e80100_qmp_gen4x2_pcie_ln_shrd_tbl[] = {
 	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MARG_COARSE_THRESH4_RATE3, 0x1f),
 	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MARG_COARSE_THRESH5_RATE3, 0x1f),
 	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MARG_COARSE_THRESH6_RATE3, 0x1f),
+	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_SUMMER_CAL_SPD_MODE, 0x5b),
 };
 
 static const struct qmp_phy_init_tbl x1e80100_qmp_gen4x2_pcie_tx_tbl[] = {
@@ -1286,12 +1287,15 @@ static const struct qmp_phy_init_tbl x1e80100_qmp_gen4x2_pcie_rx_tbl[] = {
 	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_DFE_1, 0x01),
 	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_DFE_2, 0x01),
 	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_DFE_3, 0x45),
-	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_VGA_CAL_MAN_VAL, 0x0b),
+	QMP_PHY_INIT_CFG_LANE(QSERDES_V6_20_RX_VGA_CAL_MAN_VAL, 0x0a, 1),
+	QMP_PHY_INIT_CFG_LANE(QSERDES_V6_20_RX_VGA_CAL_MAN_VAL, 0x0b, 2),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_VGA_CAL_CNTRL1, 0x00),
 	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_GM_CAL, 0x0d),
 	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_EQU_ADAPTOR_CNTRL4, 0x0b),
 	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_SIGDET_ENABLES, 0x1c),
 	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_PHPRE_CTRL, 0x20),
-	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_DFE_CTLE_POST_CAL_OFFSET, 0x38),
+	QMP_PHY_INIT_CFG_LANE(QSERDES_V6_20_RX_DFE_CTLE_POST_CAL_OFFSET, 0x3a, 1),
+	QMP_PHY_INIT_CFG_LANE(QSERDES_V6_20_RX_DFE_CTLE_POST_CAL_OFFSET, 0x38, 2),
 	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_Q_PI_INTRINSIC_BIAS_RATE32, 0x39),
 	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_MODE_RATE2_B0, 0x14),
 	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_MODE_RATE2_B1, 0xb3),
@@ -1307,6 +1311,7 @@ static const struct qmp_phy_init_tbl x1e80100_qmp_gen4x2_pcie_rx_tbl[] = {
 	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_MODE_RATE3_B4, 0x4b),
 	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_MODE_RATE3_B5, 0x76),
 	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_MODE_RATE3_B6, 0xff),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_TX_ADPT_CTRL, 0x10),
 };
 
 static const struct qmp_phy_init_tbl x1e80100_qmp_gen4x2_pcie_pcs_tbl[] = {
@@ -1314,6 +1319,8 @@ static const struct qmp_phy_init_tbl x1e80100_qmp_gen4x2_pcie_pcs_tbl[] = {
 	QMP_PHY_INIT_CFG(QPHY_V6_20_PCS_RX_SIGDET_LVL, 0xcc),
 	QMP_PHY_INIT_CFG(QPHY_V6_20_PCS_EQ_CONFIG4, 0x00),
 	QMP_PHY_INIT_CFG(QPHY_V6_20_PCS_EQ_CONFIG5, 0x22),
+	QMP_PHY_INIT_CFG(QPHY_V6_20_PCS_TX_RX_CONFIG1, 0x04),
+	QMP_PHY_INIT_CFG(QPHY_V6_20_PCS_TX_RX_CONFIG2, 0x02),
 };
 
 static const struct qmp_phy_init_tbl x1e80100_qmp_gen4x2_pcie_pcs_misc_tbl[] = {
@@ -1324,11 +1331,13 @@ static const struct qmp_phy_init_tbl x1e80100_qmp_gen4x2_pcie_pcs_misc_tbl[] = {
 	QMP_PHY_INIT_CFG(QPHY_PCIE_V6_20_PCS_G4_PRE_GAIN, 0x2e),
 	QMP_PHY_INIT_CFG(QPHY_PCIE_V6_20_PCS_RX_MARGINING_CONFIG1, 0x03),
 	QMP_PHY_INIT_CFG(QPHY_PCIE_V6_20_PCS_RX_MARGINING_CONFIG3, 0x28),
+	QMP_PHY_INIT_CFG(QPHY_PCIE_V6_20_PCS_G3_RXEQEVAL_TIME, 0x27),
+	QMP_PHY_INIT_CFG(QPHY_PCIE_V6_20_PCS_G4_RXEQEVAL_TIME, 0x27),
 	QMP_PHY_INIT_CFG(QPHY_PCIE_V6_20_PCS_TX_RX_CONFIG, 0xc0),
 	QMP_PHY_INIT_CFG(QPHY_PCIE_V6_20_PCS_POWER_STATE_CONFIG2, 0x1d),
-	QMP_PHY_INIT_CFG(QPHY_PCIE_V6_20_PCS_RX_MARGINING_CONFIG5, 0x0f),
-	QMP_PHY_INIT_CFG(QPHY_PCIE_V6_20_PCS_G3_FOM_EQ_CONFIG5, 0xf2),
-	QMP_PHY_INIT_CFG(QPHY_PCIE_V6_20_PCS_G4_FOM_EQ_CONFIG5, 0xf2),
+	QMP_PHY_INIT_CFG(QPHY_PCIE_V6_20_PCS_RX_MARGINING_CONFIG5, 0x18),
+	QMP_PHY_INIT_CFG(QPHY_PCIE_V6_20_PCS_G3_FOM_EQ_CONFIG5, 0x7a),
+	QMP_PHY_INIT_CFG(QPHY_PCIE_V6_20_PCS_G4_FOM_EQ_CONFIG5, 0x8a),
 };
 
 static const struct qmp_phy_init_tbl sm8250_qmp_pcie_serdes_tbl[] = {

---
base-commit: 8400291e289ee6b2bf9779ff1c83a291501f017b
change-id: 20240725-x1e80100-phy-qmp-pcie-fix-config-a9bdc75fd9fe

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



From xu.yang_2 at nxp.com  Thu Aug  1 03:55:38 2024
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Thu, 1 Aug 2024 18:55:38 +0800
Subject: [PATCH] phy: fsl-imx8mq-usb: fix tuning parameter name
In-Reply-To: <5802707.GXAFRqVoOG@steina-w>
References: <20240801065716.3819399-1-xu.yang_2@nxp.com>
 <5802707.GXAFRqVoOG@steina-w>
Message-ID: <20240801105538.aieqm6qliiw6z2su@hippo>

On Thu, Aug 01, 2024 at 10:35:15AM +0200, Alexander Stein wrote:
> Am Donnerstag, 1. August 2024, 08:57:16 CEST schrieb Xu Yang:
> > According to fsl,imx8mq-usb-phy.yaml, this tuning parameter should be
> > fsl,phy-pcs-tx-deemph-3p5db-attenuation-db.
> 
> Should this include a Fixes tag?

Sure. I forget this tag. Will add it.

Thanks,
Xu Yang

> 
> Best regards,
> Alexander
> 
> > Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> > ---
> >  drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> > index 0b9a59d5b8f0..adc6394626ce 100644
> > --- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> > +++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> > @@ -176,7 +176,7 @@ static void imx8m_get_phy_tuning_data(struct imx8mq_usb_phy *imx_phy)
> >  		imx_phy->comp_dis_tune =
> >  			phy_comp_dis_tune_from_property(imx_phy->comp_dis_tune);
> >  
> > -	if (device_property_read_u32(dev, "fsl,pcs-tx-deemph-3p5db-attenuation-db",
> > +	if (device_property_read_u32(dev, "fsl,phy-pcs-tx-deemph-3p5db-attenuation-db",
> >  				     &imx_phy->pcs_tx_deemph_3p5db))
> >  		imx_phy->pcs_tx_deemph_3p5db = PHY_TUNE_DEFAULT;
> >  	else
> > 
> 
> 
> -- 
> TQ-Systems GmbH | M?hlstra?e 2, Gut Delling | 82229 Seefeld, Germany
> Amtsgericht M?nchen, HRB 105018
> Gesch?ftsf?hrer: Detlef Schneider, R?diger Stahl, Stefan Schneider
> http://www.tq-group.com/
> 
> 


From xu.yang_2 at nxp.com  Thu Aug  1 04:01:36 2024
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Thu,  1 Aug 2024 19:01:36 +0800
Subject: [PATCH v2] phy: fsl-imx8mq-usb: fix tuning parameter name
Message-ID: <20240801110136.1031689-1-xu.yang_2@nxp.com>

According to fsl,imx8mq-usb-phy.yaml, this tuning parameter should be
fsl,phy-pcs-tx-deemph-3p5db-attenuation-db.

Fixes: c971874a89e1 ("phy: fsl-imx8mq-usb: fix tuning parameter name")
Cc: stable at vger.kernel.org
Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>

---
Changes in v2:
 - add fixes
---
 drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
index 0b9a59d5b8f0..adc6394626ce 100644
--- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
+++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
@@ -176,7 +176,7 @@ static void imx8m_get_phy_tuning_data(struct imx8mq_usb_phy *imx_phy)
 		imx_phy->comp_dis_tune =
 			phy_comp_dis_tune_from_property(imx_phy->comp_dis_tune);
 
-	if (device_property_read_u32(dev, "fsl,pcs-tx-deemph-3p5db-attenuation-db",
+	if (device_property_read_u32(dev, "fsl,phy-pcs-tx-deemph-3p5db-attenuation-db",
 				     &imx_phy->pcs_tx_deemph_3p5db))
 		imx_phy->pcs_tx_deemph_3p5db = PHY_TUNE_DEFAULT;
 	else
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Thu Aug  1 05:24:15 2024
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Thu, 01 Aug 2024 14:24:15 +0200
Subject: [PATCH v2] phy: fsl-imx8mq-usb: fix tuning parameter name
In-Reply-To: <20240801110136.1031689-1-xu.yang_2@nxp.com>
References: <20240801110136.1031689-1-xu.yang_2@nxp.com>
Message-ID: <14458406.uLZWGnKmhe@steina-w>

Hi,

Am Donnerstag, 1. August 2024, 13:01:36 CEST schrieb Xu Yang:
> According to fsl,imx8mq-usb-phy.yaml, this tuning parameter should be
> fsl,phy-pcs-tx-deemph-3p5db-attenuation-db.
> 
> Fixes: c971874a89e1 ("phy: fsl-imx8mq-usb: fix tuning parameter name")

Maybe you accidently selected the wrong commit here. I think this should be
Fixes: 63c85ad0cd811 ("phy: fsl-imx8mp-usb: add support for phy tuning")

Best regards,
Alexander

> Cc: stable at vger.kernel.org
> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> 
> ---
> Changes in v2:
>  - add fixes
> ---
>  drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> index 0b9a59d5b8f0..adc6394626ce 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> @@ -176,7 +176,7 @@ static void imx8m_get_phy_tuning_data(struct imx8mq_usb_phy *imx_phy)
>  		imx_phy->comp_dis_tune =
>  			phy_comp_dis_tune_from_property(imx_phy->comp_dis_tune);
>  
> -	if (device_property_read_u32(dev, "fsl,pcs-tx-deemph-3p5db-attenuation-db",
> +	if (device_property_read_u32(dev, "fsl,phy-pcs-tx-deemph-3p5db-attenuation-db",
>  				     &imx_phy->pcs_tx_deemph_3p5db))
>  		imx_phy->pcs_tx_deemph_3p5db = PHY_TUNE_DEFAULT;
>  	else
> 


-- 
TQ-Systems GmbH | M?hlstra?e 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht M?nchen, HRB 105018
Gesch?ftsf?hrer: Detlef Schneider, R?diger Stahl, Stefan Schneider
http://www.tq-group.com/




From xu.yang_2 at nxp.com  Thu Aug  1 05:42:54 2024
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Thu, 1 Aug 2024 20:42:54 +0800
Subject: [PATCH v2] phy: fsl-imx8mq-usb: fix tuning parameter name
In-Reply-To: <14458406.uLZWGnKmhe@steina-w>
References: <20240801110136.1031689-1-xu.yang_2@nxp.com>
 <14458406.uLZWGnKmhe@steina-w>
Message-ID: <20240801124254.36sabvfg33kb4f2e@hippo>

On Thu, Aug 01, 2024 at 02:24:15PM +0200, Alexander Stein wrote:
> Hi,
> 
> Am Donnerstag, 1. August 2024, 13:01:36 CEST schrieb Xu Yang:
> > According to fsl,imx8mq-usb-phy.yaml, this tuning parameter should be
> > fsl,phy-pcs-tx-deemph-3p5db-attenuation-db.
> > 
> > Fixes: c971874a89e1 ("phy: fsl-imx8mq-usb: fix tuning parameter name")
> 
> Maybe you accidently selected the wrong commit here. I think this should be
> Fixes: 63c85ad0cd811 ("phy: fsl-imx8mp-usb: add support for phy tuning")

Thank you! I find the commit but wrongly paste another one.

Best Regards,
Xu Yang


> 
> Best regards,
> Alexander
> 
> > Cc: stable at vger.kernel.org
> > Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> > 
> > ---
> > Changes in v2:
> >  - add fixes
> > ---
> >  drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> > index 0b9a59d5b8f0..adc6394626ce 100644
> > --- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> > +++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> > @@ -176,7 +176,7 @@ static void imx8m_get_phy_tuning_data(struct imx8mq_usb_phy *imx_phy)
> >  		imx_phy->comp_dis_tune =
> >  			phy_comp_dis_tune_from_property(imx_phy->comp_dis_tune);
> >  
> > -	if (device_property_read_u32(dev, "fsl,pcs-tx-deemph-3p5db-attenuation-db",
> > +	if (device_property_read_u32(dev, "fsl,phy-pcs-tx-deemph-3p5db-attenuation-db",
> >  				     &imx_phy->pcs_tx_deemph_3p5db))
> >  		imx_phy->pcs_tx_deemph_3p5db = PHY_TUNE_DEFAULT;
> >  	else
> > 
> 
> 
> -- 
> TQ-Systems GmbH | M?hlstra?e 2, Gut Delling | 82229 Seefeld, Germany
> Amtsgericht M?nchen, HRB 105018
> Gesch?ftsf?hrer: Detlef Schneider, R?diger Stahl, Stefan Schneider
> http://www.tq-group.com/
> 
> 


From xu.yang_2 at nxp.com  Thu Aug  1 05:46:42 2024
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Thu,  1 Aug 2024 20:46:42 +0800
Subject: [PATCH v3] phy: fsl-imx8mq-usb: fix tuning parameter name
Message-ID: <20240801124642.1152838-1-xu.yang_2@nxp.com>

According to fsl,imx8mq-usb-phy.yaml, this tuning parameter should be
fsl,phy-pcs-tx-deemph-3p5db-attenuation-db.

Fixes: 63c85ad0cd81 ("phy: fsl-imx8mp-usb: add support for phy tuning")
Cc: stable at vger.kernel.org
Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>

---
Changes in v2:
 - add fixes
Changes in v3:
 - correct fixes commit
---
 drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
index 0b9a59d5b8f0..adc6394626ce 100644
--- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
+++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
@@ -176,7 +176,7 @@ static void imx8m_get_phy_tuning_data(struct imx8mq_usb_phy *imx_phy)
 		imx_phy->comp_dis_tune =
 			phy_comp_dis_tune_from_property(imx_phy->comp_dis_tune);
 
-	if (device_property_read_u32(dev, "fsl,pcs-tx-deemph-3p5db-attenuation-db",
+	if (device_property_read_u32(dev, "fsl,phy-pcs-tx-deemph-3p5db-attenuation-db",
 				     &imx_phy->pcs_tx_deemph_3p5db))
 		imx_phy->pcs_tx_deemph_3p5db = PHY_TUNE_DEFAULT;
 	else
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Thu Aug  1 05:53:36 2024
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Thu, 01 Aug 2024 14:53:36 +0200
Subject: [PATCH v3] phy: fsl-imx8mq-usb: fix tuning parameter name
In-Reply-To: <20240801124642.1152838-1-xu.yang_2@nxp.com>
References: <20240801124642.1152838-1-xu.yang_2@nxp.com>
Message-ID: <4195136.aeNJFYEL58@steina-w>

Hi,

Am Donnerstag, 1. August 2024, 14:46:42 CEST schrieb Xu Yang:
> According to fsl,imx8mq-usb-phy.yaml, this tuning parameter should be
> fsl,phy-pcs-tx-deemph-3p5db-attenuation-db.
> 
> Fixes: 63c85ad0cd81 ("phy: fsl-imx8mp-usb: add support for phy tuning")
> Cc: stable at vger.kernel.org
> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>

Look good to me:
Reviewed-by: Alexander Stein <alexander.stein at ew.tq-group.com>

> ---
> Changes in v2:
>  - add fixes
> Changes in v3:
>  - correct fixes commit
> ---
>  drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> index 0b9a59d5b8f0..adc6394626ce 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> @@ -176,7 +176,7 @@ static void imx8m_get_phy_tuning_data(struct imx8mq_usb_phy *imx_phy)
>  		imx_phy->comp_dis_tune =
>  			phy_comp_dis_tune_from_property(imx_phy->comp_dis_tune);
>  
> -	if (device_property_read_u32(dev, "fsl,pcs-tx-deemph-3p5db-attenuation-db",
> +	if (device_property_read_u32(dev, "fsl,phy-pcs-tx-deemph-3p5db-attenuation-db",
>  				     &imx_phy->pcs_tx_deemph_3p5db))
>  		imx_phy->pcs_tx_deemph_3p5db = PHY_TUNE_DEFAULT;
>  	else
> 


-- 
TQ-Systems GmbH | M?hlstra?e 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht M?nchen, HRB 105018
Gesch?ftsf?hrer: Detlef Schneider, R?diger Stahl, Stefan Schneider
http://www.tq-group.com/




From krzk at kernel.org  Thu Aug  1 07:40:06 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Thu, 1 Aug 2024 16:40:06 +0200
Subject: [PATCH v3 1/2] dt-bindings: phy: nuvoton,ma35-usb2-phy: add new
 bindings
In-Reply-To: <20240801053744.807884-2-hpchen0nvt@gmail.com>
References: <20240801053744.807884-1-hpchen0nvt@gmail.com>
 <20240801053744.807884-2-hpchen0nvt@gmail.com>
Message-ID: <31b72731-277c-4e57-9cc0-d646f154845b@kernel.org>

On 01/08/2024 07:37, Hui-Ping Chen wrote:
> Add dt-bindings for USB2 PHY found on the Nuvoton MA35 SoC.
> 
> Signed-off-by: Hui-Ping Chen <hpchen0nvt at gmail.com>
> ---

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From krzk at kernel.org  Thu Aug  1 07:42:47 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Thu, 1 Aug 2024 16:42:47 +0200
Subject: [PATCH v2 2/2] phy: nuvoton: add new driver for the Nuvoton MA35
 SoC USB 2.0 PHY
In-Reply-To: <20240731014313.113417-3-hpchen0nvt@gmail.com>
References: <20240731014313.113417-1-hpchen0nvt@gmail.com>
 <20240731014313.113417-3-hpchen0nvt@gmail.com>
Message-ID: <b738737e-ff71-434e-a27d-2f7056416c74@kernel.org>

On 31/07/2024 03:43, Hui-Ping Chen wrote:
> Nuvoton MA35 SoCs support DWC2 USB controller.
> Add the driver to drive the USB 2.0 PHY transceivers.
> 
> Signed-off-by: Hui-Ping Chen <hpchen0nvt at gmail.com>


> +struct ma35_usb_phy {
> +	struct clk *clk;
> +	struct device *dev;
> +	struct regmap *sysreg;
> +};
> +
> +static int ma35_usb_phy_power_on(struct phy *phy)
> +{
> +	struct ma35_usb_phy *p_phy = phy_get_drvdata(phy);
> +	unsigned int val;
> +	int ret;
> +
> +	ret = clk_prepare_enable(p_phy->clk);
> +	if (ret < 0) {
> +		dev_err(p_phy->dev, "Failed to enable PHY clock: %d\n", ret);
> +		return ret;
> +	}
> +
> +	regmap_read(p_phy->sysreg, MA35_SYS_REG_USBPMISCR, &val);
> +	if (val & PHY0SUSPEND) {
> +		/*
> +		 * USB PHY0 is in operation mode already
> +		 * make sure USB PHY 60 MHz UTMI Interface Clock ready
> +		 */
> +		ret = readl_poll_timeout((void __iomem *)p_phy->sysreg + MA35_SYS_REG_USBPMISCR,

sysreg is a regmap, not io address. How could it possibly work and be
tested?!? This cannot work. Test your code *before* sending it.

> +					 val, val & PHY0DEVCKSTB, 1, 100);
> +		if (ret == -ETIMEDOUT) {
> +			dev_err(p_phy->dev, "1.Check PHY clock, Timeout: %d\n", val);
> +			return ret;
> +		}
> +		return 0;
> +	}
> +
> +	/*
> +	 * reset USB PHY0.
> +	 * wait until USB PHY0 60 MHz UTMI Interface Clock ready
> +	 */
> +	regmap_update_bits(p_phy->sysreg, MA35_SYS_REG_USBPMISCR, 0x7, (PHY0POR | PHY0SUSPEND));
> +	udelay(10);
> +
> +	/* make USB PHY0 enter operation mode */
> +	regmap_update_bits(p_phy->sysreg, MA35_SYS_REG_USBPMISCR, 0x7, PHY0SUSPEND);
> +
> +	/* make sure USB PHY 60 MHz UTMI Interface Clock ready */
> +	ret = readl_poll_timeout((void __iomem *)p_phy->sysreg + MA35_SYS_REG_USBPMISCR,

Same problem.


Best regards,
Krzysztof



From krzk at kernel.org  Thu Aug  1 07:43:56 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Thu, 1 Aug 2024 16:43:56 +0200
Subject: [PATCH v3 2/2] phy: nuvoton: add new driver for the Nuvoton MA35
 SoC USB 2.0 PHY
In-Reply-To: <20240801053744.807884-3-hpchen0nvt@gmail.com>
References: <20240801053744.807884-1-hpchen0nvt@gmail.com>
 <20240801053744.807884-3-hpchen0nvt@gmail.com>
Message-ID: <85bd5da2-312e-4d25-a4e9-afae4fedbd50@kernel.org>

On 01/08/2024 07:37, Hui-Ping Chen wrote:
> +	struct regmap *sysreg;

Look here - iomem? No.

> +};
> +
> +static int ma35_usb_phy_power_on(struct phy *phy)
> +{
> +	struct ma35_usb_phy *p_phy = phy_get_drvdata(phy);
> +	unsigned int val;
> +	int ret;
> +
> +	ret = clk_prepare_enable(p_phy->clk);
> +	if (ret < 0) {
> +		dev_err(p_phy->dev, "Failed to enable PHY clock: %d\n", ret);
> +		return ret;
> +	}
> +
> +	regmap_read(p_phy->sysreg, MA35_SYS_REG_USBPMISCR, &val);
> +	if (val & PHY0SUSPEND) {
> +		/*
> +		 * USB PHY0 is in operation mode already
> +		 * make sure USB PHY 60 MHz UTMI Interface Clock ready
> +		 */
> +		ret = readl_poll_timeout((void __iomem *)p_phy->sysreg + MA35_SYS_REG_USBPMISCR,

Eh, I responded to v2, not here, so repeating:

sysreg is a regmap, not io address. How could it possibly work and be
tested?!? This cannot work. Test your code *before* sending it.


Best regards,
Krzysztof



From conor at kernel.org  Thu Aug  1 08:12:54 2024
From: conor at kernel.org (Conor Dooley)
Date: Thu, 1 Aug 2024 16:12:54 +0100
Subject: [PATCH 1/2] dt-bindings: phy: ti,tcan104x-can: Document
 Microchip ATA6561
In-Reply-To: <CAMuHMdUf=McxMLqb1hgu_-4QkSFJkdWrdtbwiwn9yJoMSi3YWA@mail.gmail.com>
References: <20240718210322.37492-1-ilordash02@gmail.com>
 <20240718210322.37492-2-ilordash02@gmail.com>
 <20240719-ahead-kiwi-995e52bf3e74@spud>
 <CAGCz5HkF_WNZBVpY2SWVf071Pi896BvKFk0jnfNAYX5AKx2Zcw@mail.gmail.com>
 <20240723-dinginess-john-608d0b28293b@spud>
 <CAGCz5H=Gncw+Tr0XaQQhhGWQER5Rs1BcxbkPaJwx9jJ-8j7LGQ@mail.gmail.com>
 <20240723-municipal-snowy-136b08b6db90@spud>
 <CAGCz5HnJKjNj7A0YD2fw20m-NrEs3MoCLwox86mC11Kudq8xbg@mail.gmail.com>
 <CAMuHMdUf=McxMLqb1hgu_-4QkSFJkdWrdtbwiwn9yJoMSi3YWA@mail.gmail.com>
Message-ID: <20240801-disarray-gesture-ebad121272b0@spud>

On Mon, Jul 29, 2024 at 10:51:50AM +0200, Geert Uytterhoeven wrote:
> Hi Ilya,
> 
> On Sun, Jul 28, 2024 at 10:52?AM Ilya Orazov <ilordash02 at gmail.com> wrote:
> > On Tue, 23 Jul 2024 at 23:14, Conor Dooley <conor at kernel.org> wrote:
> > > On Tue, Jul 23, 2024 at 10:55:17PM +0300, Ilya Orazov wrote:
> > > > On Tue, 23 Jul 2024 at 21:50, Conor Dooley <conor at kernel.org> wrote:
> > > > > On Tue, Jul 23, 2024 at 08:20:04PM +0300, IlorDash wrote:
> > > > > > On Fri, 19 Jul 2024 at 18:07, Conor Dooley <conor at kernel.org> wrote:
> > > > > > >
> > > > > > > On Fri, Jul 19, 2024 at 12:03:21AM +0300, Ilya Orazov wrote:
> > > > > > > > Microchip ATA6561 is High-Speed CAN Transceiver with Standby Mode.
> > > > > > > > It is pin-compatible with TI TCAN1042.
> > > > > > > >
> > > > > > > > Signed-off-by: Ilya Orazov <ilordash02 at gmail.com>
> > > > > > > > ---
> > > > > > > >  Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml | 1 +
> > > > > > > >  1 file changed, 1 insertion(+)
> > > > > > > >
> > > > > > > > diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> > > > > > > > index 79dad3e89aa6..03de361849d2 100644
> > > > > > > > --- a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> > > > > > > > +++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> > > > > > > > @@ -18,6 +18,7 @@ properties:
> > > > > > > >        - nxp,tjr1443
> > > > > > > >        - ti,tcan1042
> > > > > > > >        - ti,tcan1043
> > > > > > > > +      - microchip,ata6561
> > > > > > >
> > > > > > > Given that your driver patch has
> > > > > > > | diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
> > > > > > > | index ee4ce4249698..dbcd99213ba1 100644
> > > > > > > | --- a/drivers/phy/phy-can-transceiver.c
> > > > > > > | +++ b/drivers/phy/phy-can-transceiver.c
> > > > > > > | @@ -89,6 +89,10 @@ static const struct of_device_id can_transceiver_phy_ids[] = {
> > > > > > > |                 .compatible = "nxp,tjr1443",
> > > > > > > |                 .data = &tcan1043_drvdata
> > > > > > > |         },
> > > > > > > | +       {
> > > > > > > | +               .compatible = "microchip,ata6561",
> > > > > > > | +               .data = &tcan1042_drvdata
> > > > > > > | +       },
> > > > > > > |         { }
> > > > > > > |  };
> > > > > > >
> > > > > > > the driver patch is actually not needed at all, and you just need to
> > > > > > > allow ti,tcan1042 as fallback compatible in the binding, so something
> > > > > > > like:
> > > > > > >
> > > > > > >   compatible:
> > > > > > >     oneOf:
> > > > > > >       - enum:
> > > > > > >           - nxp,tjr1443
> > > > > > >           - ti,tcan1042
> > > > > > >           - ti,tcan1043
> > > > > > >       - items:
> > > > > > >           - const: microchip,ata6561
> > > > > > >           - const: ti,tcan1042
> > > > > > >
> > > > > > >    '#phy-cells':
> > > > > > >      const: 0
> > > > > >
> > > > > > I tested the build with fallback compatible:
> > > > > >
> > > > > > compatible:
> > > > > >   oneOf:
> > > > > >     - items:
> > > > > >       - enum:
> > > > > >         - microchip,ata6561
> > > > > >       - const: ti,tcan1042
> > > > > >     - items:
> > > > > >       - enum:
> > > > > >         - nxp,tjr1443
> > > > > >       - const: ti,tcan1043
> > > > > >
> > > > > > and modified compatible property in DTS:
> > > > > >
> > > > > > compatible = "microchip,ata6561", "ti,tcan1042";
> > > > > >
> > > > > > Build succeeded, phy-can-transceiver driver was used. So I would like
> > > > > > to add a fallback compatible for both "microchip,ata6561" and
> > > > > > "nxp,tjr1443" in this binding and modify other DTS files with
> > > > > > compatible = "nxp,tjr1443". What do you think?
> > > > >
> > > > > This is wrong on two counts. Firstly, were what you have correct, you
> > > > > should
> > > > > squash the two:
> > > > >      - items:
> > > > >          - enum:
> > > > >            - nxp,tjr1443
> > > > >            - microchip,ata6561
> > > > >          - const: ti,tcan1042
> > > > >
> > > > > However, that does not allow the TI compatibles in isolation, so you
> > > > > still need to allow that for the actual TI devices, so you need:
> > > > >
> > > > >    oneOf:
> > > > >      - items:
> > > > >          - enum:
> > > > >            - microchip,ata6561
> > > > >            - nxp,tjr1443
> > > > >            - ti,tcan1043
> > > > >          - const: ti,tcan1042
> > > > >      - const: ti,tcan1042
> > > > >
> > > > > There's probably some devicetrees that would need to be fixed up. I'm
> > > > > just not convinced that this is worth retrofitting however.
> > > >
> > > > But nxp,tjr1443 is pin compatible with ti,tcan1043, so it should
> > > > fallback only to ti,tcan1043 and not ti,tcan1042. That's why I decided
> > > > to split them into different enums.
> > >
> > > Ah, sorry I missed that. I misread the match data. Then you need:
> > >   compatible:
> > >     oneOf:
> > >       - items:
> > >         - enum:
> > >           - microchip,ata6561
> > >         - const: ti,tcan1042
> > >       - items:
> > >         - enum:
> > >           - nxp,tjr1443
> > >         - const: ti,tcan1043
> > >       - enum:
> > >           const: ti,tcan1042
> > >           const: ti,tcan1043
> > >
> > > because the TI devices exist and we still need to be able to
> > > differentiate the TI and NXP devices. If you have
> > >   compatible = "nxp,tjr1443", "ti,tcan1042";
> > > that means the device is an nxp,tjr1443. If you have
> > >   compatible = "ti,tcan1042";
> > > then that's a tcan1042.
> > >
> > > > I made my patch according to a similar one that adds support for
> > > > nxp,tjr1443. You can find it's conversation on
> > > > https://lore.kernel.org/all/6ee5e2ce00019bd3f77d6a702b38bab1a45f3bb0.1674037830.git.geert+renesas at glider.be/t/#u.
> > >
> > > > I thought we want to hold all PHY chip names in one compatible enum
> > > > and each in its own of_device_id struct in driver and extend them
> > > > where appropriate.
> > >
> > > Nah, fallbacks are preferred when the programming model is either
> > > identical or a "compatible superset" of an existing device. New
> > > of_device_id structs should only be used where we need to account for
> > > differences in the programming model.
> >
> > However, I am curious as to why the NXP CAN PHY transceiver was not
> > included as fallback compatible. Geert, could you please share your
> > thoughts on this matter?
> 
> The TJR1443 looked sufficiently similar to the TCAN1043 to use the
> same driver configuration (which is limited to having standby and/or
> enable signals or not).  However, I'm not sure it behaves exactly
> the same, e.g. in case of reporting an error condition (which is not
> yet supported by the driver). The part numbers are also different,
> so this is not a simple case of SN74HCxx vs. CD74HCxx.
> 
> Summary: I don't know if they are identical, or if TJR1443 is a
> compatible superset of TCAN1043, or vice versa. Hence I went for the
> safest way....

If we don't know for sure what the craic is with compatibility, then we
should leave the existing tjr1443 compatible as-is I think.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-phy/attachments/20240801/7c254206/attachment.sig>

From abel.vesa at linaro.org  Thu Aug  1 08:54:53 2024
From: abel.vesa at linaro.org (Abel Vesa)
Date: Thu, 01 Aug 2024 18:54:53 +0300
Subject: [PATCH v2] phy: qcom: qmp-pcie: Configure all tables on port B PHY
Message-ID: <20240801-phy-qcom-qmp-pcie-write-all-tbls-second-port-v2-1-6e53c701e87e@linaro.org>

From: Qiang Yu <quic_qianyu at quicinc.com>

Currently, only the RX and TX tables are written to the second PHY
(port B) when the 4-lanes mode is configured, but according to Qualcomm
internal documentation, the pcs, pcs_misc, serdes and ln_shrd tables need
to be written as well.

Signed-off-by: Qiang Yu <quic_qianyu at quicinc.com>
Signed-off-by: Abel Vesa <abel.vesa at linaro.org>
---
Changes in v2:
- Reordered tables as Johan has suggested
- Link to v1: https://lore.kernel.org/r/20240726-phy-qcom-qmp-pcie-write-all-tbls-second-port-v1-1-751b9ee01184 at linaro.org
---
 drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
index 5b36cc7ac78b..c0f4bc6b8ebc 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
@@ -3660,18 +3660,30 @@ static void qmp_pcie_init_port_b(struct qmp_pcie *qmp, const struct qmp_phy_cfg_
 {
 	const struct qmp_phy_cfg *cfg = qmp->cfg;
 	const struct qmp_pcie_offsets *offs = cfg->offsets;
-	void __iomem *tx3, *rx3, *tx4, *rx4;
+	void __iomem *serdes, *tx3, *rx3, *tx4, *rx4, *pcs, *pcs_misc, *ln_shrd;
 
+	serdes = qmp->port_b + offs->serdes;
 	tx3 = qmp->port_b + offs->tx;
 	rx3 = qmp->port_b + offs->rx;
 	tx4 = qmp->port_b + offs->tx2;
 	rx4 = qmp->port_b + offs->rx2;
+	pcs = qmp->port_b + offs->pcs;
+	pcs_misc = qmp->port_b + offs->pcs_misc;
+	ln_shrd = qmp->port_b + offs->ln_shrd;
+
+	qmp_configure(serdes, tbls->serdes, tbls->serdes_num);
+	qmp_configure(serdes, cfg->serdes_4ln_tbl, cfg->serdes_4ln_num);
 
 	qmp_configure_lane(tx3, tbls->tx, tbls->tx_num, 1);
 	qmp_configure_lane(rx3, tbls->rx, tbls->rx_num, 1);
 
 	qmp_configure_lane(tx4, tbls->tx, tbls->tx_num, 2);
 	qmp_configure_lane(rx4, tbls->rx, tbls->rx_num, 2);
+
+	qmp_configure(pcs, tbls->pcs, tbls->pcs_num);
+	qmp_configure(pcs_misc, tbls->pcs_misc, tbls->pcs_misc_num);
+
+	qmp_configure(ln_shrd, tbls->ln_shrd, tbls->ln_shrd_num);
 }
 
 static void qmp_pcie_init_registers(struct qmp_pcie *qmp, const struct qmp_phy_cfg_tbls *tbls)

---
base-commit: 8400291e289ee6b2bf9779ff1c83a291501f017b
change-id: 20240725-phy-qcom-qmp-pcie-write-all-tbls-second-port-8efeced876bf

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



From dmitry.baryshkov at linaro.org  Thu Aug  1 12:27:06 2024
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Thu, 1 Aug 2024 22:27:06 +0300
Subject: [PATCH v2] phy: qcom: qmp-pcie: Configure all tables on port B
 PHY
In-Reply-To: <20240801-phy-qcom-qmp-pcie-write-all-tbls-second-port-v2-1-6e53c701e87e@linaro.org>
References: <20240801-phy-qcom-qmp-pcie-write-all-tbls-second-port-v2-1-6e53c701e87e@linaro.org>
Message-ID: <37id2c7h33sj7p3vlo3tiv35qta7utee6aswieyy2b64get4bk@eqjjakr743fx>

On Thu, Aug 01, 2024 at 06:54:53PM GMT, Abel Vesa wrote:
> From: Qiang Yu <quic_qianyu at quicinc.com>
> 
> Currently, only the RX and TX tables are written to the second PHY
> (port B) when the 4-lanes mode is configured, but according to Qualcomm
> internal documentation, the pcs, pcs_misc, serdes and ln_shrd tables need
> to be written as well.
> 
> Signed-off-by: Qiang Yu <quic_qianyu at quicinc.com>
> Signed-off-by: Abel Vesa <abel.vesa at linaro.org>
> ---
> Changes in v2:
> - Reordered tables as Johan has suggested
> - Link to v1: https://lore.kernel.org/r/20240726-phy-qcom-qmp-pcie-write-all-tbls-second-port-v1-1-751b9ee01184 at linaro.org
> ---
>  drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>


-- 
With best wishes
Dmitry


From hpchen0nvt at gmail.com  Thu Aug  1 21:57:40 2024
From: hpchen0nvt at gmail.com (Hui-Ping Chen)
Date: Fri, 2 Aug 2024 12:57:40 +0800
Subject: [PATCH v3 2/2] phy: nuvoton: add new driver for the Nuvoton MA35
 SoC USB 2.0 PHY
In-Reply-To: <9cca717a-c7e9-4bf7-8cde-3a90fcfb1df5@web.de>
References: <20240801053744.807884-3-hpchen0nvt@gmail.com>
 <9cca717a-c7e9-4bf7-8cde-3a90fcfb1df5@web.de>
Message-ID: <d1e08364-8f87-4282-9392-31db3330eae9@gmail.com>

Dear Markus,

Thank you for your reply.



On 2024/8/1 ?? 05:50, Markus Elfring wrote:
> ?
>> +++ b/drivers/phy/nuvoton/phy-ma35d1-usb2.c
>> @@ -0,0 +1,146 @@
> ?
>> +MODULE_DESCRIPTION("Nuvoton ma35d1 USB2.0 PHY driver");
>> +MODULE_AUTHOR("hpchen0nvt at gmail.com");
> ?
>
> How do you think about to add a personal name to such an email address?

I'm sorry. I forgot to put my name here. I'll make it up.


> Regards,
> Markus


Best regards,

Hui-Ping Chen




From hpchen0nvt at gmail.com  Thu Aug  1 22:01:08 2024
From: hpchen0nvt at gmail.com (Hui-Ping Chen)
Date: Fri, 2 Aug 2024 13:01:08 +0800
Subject: [PATCH v3 2/2] phy: nuvoton: add new driver for the Nuvoton MA35
 SoC USB 2.0 PHY
In-Reply-To: <85bd5da2-312e-4d25-a4e9-afae4fedbd50@kernel.org>
References: <20240801053744.807884-1-hpchen0nvt@gmail.com>
 <20240801053744.807884-3-hpchen0nvt@gmail.com>
 <85bd5da2-312e-4d25-a4e9-afae4fedbd50@kernel.org>
Message-ID: <ea046ad5-ee78-44a5-803c-a09669cb8a82@gmail.com>

Dear Krzysztof,

Thank you for your reply.



On 2024/8/1 ?? 10:43, Krzysztof Kozlowski wrote:
> On 01/08/2024 07:37, Hui-Ping Chen wrote:
>> +	struct regmap *sysreg;
> Look here - iomem? No.

Yes, this is my mistake.



>> +};
>> +
>> +static int ma35_usb_phy_power_on(struct phy *phy)
>> +{
>> +	struct ma35_usb_phy *p_phy = phy_get_drvdata(phy);
>> +	unsigned int val;
>> +	int ret;
>> +
>> +	ret = clk_prepare_enable(p_phy->clk);
>> +	if (ret < 0) {
>> +		dev_err(p_phy->dev, "Failed to enable PHY clock: %d\n", ret);
>> +		return ret;
>> +	}
>> +
>> +	regmap_read(p_phy->sysreg, MA35_SYS_REG_USBPMISCR, &val);
>> +	if (val & PHY0SUSPEND) {
>> +		/*
>> +		 * USB PHY0 is in operation mode already
>> +		 * make sure USB PHY 60 MHz UTMI Interface Clock ready
>> +		 */
>> +		ret = readl_poll_timeout((void __iomem *)p_phy->sysreg + MA35_SYS_REG_USBPMISCR,
> Eh, I responded to v2, not here, so repeating:
>
> sysreg is a regmap, not io address. How could it possibly work and be
> tested?!? This cannot work. Test your code *before* sending it.
>
Yes, this is my mistake. I won't reply to v2. I will reply here.


I would change 'readl_poll_timeout' to 'regmap_read_poll_timeout'.

And it has been tested OK on our platform.



> Best regards,
> Krzysztof


Best regards,

Hui-Ping Chen




From xu.yang_2 at nxp.com  Fri Aug  2 02:16:58 2024
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Fri,  2 Aug 2024 17:16:58 +0800
Subject: [PATCH 1/5] dt-bindings: phy: imx8mq-usb: add compatible "fsl,imx95-usb-phy"
Message-ID: <20240802091702.2057294-1-xu.yang_2@nxp.com>

The usb phy in i.MX95 is compatible with i.MX8MP's, this will add a
compatible "fsl,imx95-usb-phy" for i.MX95. Also change reg maxItems
to 2 since i.MX95 needs another regmap to control Type-C Assist (TCA)
block. Since i.MX95 usb phy is able to switch SS lanes, this will also
add orientation-switch and port property to the file.

Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
---
 .../bindings/phy/fsl,imx8mq-usb-phy.yaml      | 40 +++++++++++++++++--
 1 file changed, 36 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
index dc3a3f709fea..b0a614a9556d 100644
--- a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
@@ -11,12 +11,17 @@ maintainers:
 
 properties:
   compatible:
-    enum:
-      - fsl,imx8mq-usb-phy
-      - fsl,imx8mp-usb-phy
+    oneOf:
+      - enum:
+          - fsl,imx8mq-usb-phy
+          - fsl,imx8mp-usb-phy
+      - items:
+          - const: fsl,imx95-usb-phy
+          - const: fsl,imx8mp-usb-phy
 
   reg:
-    maxItems: 1
+    minItems: 1
+    maxItems: 2
 
   "#phy-cells":
     const: 0
@@ -28,6 +33,17 @@ properties:
     items:
       - const: phy
 
+  orientation-switch:
+    description:
+      Flag the PHY as possible handler of USB Type-C orientation switching
+    type: boolean
+
+  port:
+    $ref: /schemas/graph.yaml#/properties/port
+    description:
+      A port node to link the PHY to a TypeC controller for the purpose of
+      handling orientation switching.
+
   power-domains:
     maxItems: 1
 
@@ -89,6 +105,22 @@ required:
   - clocks
   - clock-names
 
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - fsl,imx95-usb-phy
+    then:
+      properties:
+        reg:
+          minItems: 2
+    else:
+      properties:
+        reg:
+          maxItems: 1
+
 additionalProperties: false
 
 examples:
-- 
2.34.1



From xu.yang_2 at nxp.com  Fri Aug  2 02:16:59 2024
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Fri,  2 Aug 2024 17:16:59 +0800
Subject: [PATCH 2/5] dt-bindings: usb: dwc3-imx8mp: add compatible string for imx95
In-Reply-To: <20240802091702.2057294-1-xu.yang_2@nxp.com>
References: <20240802091702.2057294-1-xu.yang_2@nxp.com>
Message-ID: <20240802091702.2057294-2-xu.yang_2@nxp.com>

The i.MX95 is compatible with i.MX8MP's usb controller. This will add a
compatible string "fsl,imx95-dwc3" for i.MX95.

Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
---
 Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml b/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml
index 9ea1e4cd0709..baf130669c38 100644
--- a/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml
@@ -12,7 +12,11 @@ maintainers:
 
 properties:
   compatible:
-    const: fsl,imx8mp-dwc3
+    oneOf:
+      - items:
+          - const: fsl,imx95-dwc3
+          - const: fsl,imx8mp-dwc3
+      - const: fsl,imx8mp-dwc3
 
   reg:
     items:
-- 
2.34.1



From xu.yang_2 at nxp.com  Fri Aug  2 02:17:00 2024
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Fri,  2 Aug 2024 17:17:00 +0800
Subject: [PATCH 3/5] phy: fsl-imx8mq-usb: add tca function driver for imx95
In-Reply-To: <20240802091702.2057294-1-xu.yang_2@nxp.com>
References: <20240802091702.2057294-1-xu.yang_2@nxp.com>
Message-ID: <20240802091702.2057294-3-xu.yang_2@nxp.com>

The i.MX95 USB3 phy has a Type-C Assist block (TCA). This block consists
two functional blocks (XBar assist and VBus assist) and one system
access interface using APB.

The primary functionality of XBar assist is:
 - switching lane for flip
 - moving unused lanes into lower power states.

This info can be get from:
i.MX95 RM Chapter 163.3.8 Type-C assist (TCA) block.

This will add support for TCA block to achieve lane switching and tca
lower power functionality.

Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
Reviewed-by: Jun Li <jun.li at nxp.com>
---
 drivers/phy/freescale/Kconfig              |   1 +
 drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 238 +++++++++++++++++++++
 2 files changed, 239 insertions(+)

diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
index dcd9acff6d01..81f53564ee15 100644
--- a/drivers/phy/freescale/Kconfig
+++ b/drivers/phy/freescale/Kconfig
@@ -5,6 +5,7 @@ if (ARCH_MXC && ARM64) || COMPILE_TEST
 config PHY_FSL_IMX8MQ_USB
 	tristate "Freescale i.MX8M USB3 PHY"
 	depends on OF && HAS_IOMEM
+	depends on TYPEC || TYPEC=n
 	select GENERIC_PHY
 	default ARCH_MXC && ARM64
 
diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
index adc6394626ce..18d00cec0665 100644
--- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
+++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
@@ -10,6 +10,7 @@
 #include <linux/phy/phy.h>
 #include <linux/platform_device.h>
 #include <linux/regulator/consumer.h>
+#include <linux/usb/typec_mux.h>
 
 #define PHY_CTRL0			0x0
 #define PHY_CTRL0_REF_SSP_EN		BIT(2)
@@ -50,11 +51,66 @@
 
 #define PHY_TUNE_DEFAULT		0xffffffff
 
+#define TCA_CLK_RST			0x00
+#define TCA_CLK_RST_SW			BIT(9)
+#define TCA_CLK_RST_REF_CLK_EN		BIT(1)
+#define TCA_CLK_RST_SUSPEND_CLK_EN	BIT(0)
+
+#define TCA_INTR_EN			0x04
+#define TCA_INTR_STS			0x08
+
+#define TCA_GCFG			0x10
+#define TCA_GCFG_ROLE_HSTDEV		BIT(4)
+#define TCA_GCFG_OP_MODE		GENMASK(1, 0)
+#define TCA_GCFG_OP_MODE_SYSMODE	0
+#define TCA_GCFG_OP_MODE_SYNCMODE	1
+
+#define TCA_TCPC			0x14
+#define TCA_TCPC_VALID			BIT(4)
+#define TCA_TCPC_LOW_POWER_EN		BIT(3)
+#define TCA_TCPC_ORIENTATION_NORMAL	BIT(2)
+#define TCA_TCPC_MUX_CONTRL		GENMASK(1, 0)
+#define TCA_TCPC_MUX_CONTRL_NO_CONN	0
+#define TCA_TCPC_MUX_CONTRL_USB_CONN	1
+
+#define TCA_SYSMODE_CFG			0x18
+#define TCA_SYSMODE_TCPC_DISABLE	BIT(3)
+#define TCA_SYSMODE_TCPC_FLIP		BIT(2)
+
+#define TCA_CTRLSYNCMODE_CFG0		0x20
+#define TCA_CTRLSYNCMODE_CFG1           0x20
+
+#define TCA_PSTATE			0x30
+#define TCA_PSTATE_CM_STS		BIT(4)
+#define TCA_PSTATE_TX_STS		BIT(3)
+#define TCA_PSTATE_RX_PLL_STS		BIT(2)
+#define TCA_PSTATE_PIPE0_POWER_DOWN	GENMASK(1, 0)
+
+#define TCA_GEN_STATUS			0x34
+#define TCA_GEN_DEV_POR			BIT(12)
+#define TCA_GEN_REF_CLK_SEL		BIT(8)
+#define TCA_GEN_TYPEC_FLIP_INVERT	BIT(4)
+#define TCA_GEN_PHY_TYPEC_DISABLE	BIT(3)
+#define TCA_GEN_PHY_TYPEC_FLIP		BIT(2)
+
+#define TCA_VBUS_CTRL			0x40
+#define TCA_VBUS_STATUS			0x44
+
+#define TCA_INFO			0xFC
+
+struct tca_blk {
+	struct typec_switch_dev *sw;
+	void __iomem *base;
+	struct mutex mutex;
+	enum typec_orientation orientation;
+};
+
 struct imx8mq_usb_phy {
 	struct phy *phy;
 	struct clk *clk;
 	void __iomem *base;
 	struct regulator *vbus;
+	struct tca_blk *tca;
 	u32 pcs_tx_swing_full;
 	u32 pcs_tx_deemph_3p5db;
 	u32 tx_vref_tune;
@@ -64,6 +120,171 @@ struct imx8mq_usb_phy {
 	u32 comp_dis_tune;
 };
 
+
+static void tca_blk_orientation_set(struct tca_blk *tca,
+				enum typec_orientation orientation);
+
+#ifdef CONFIG_TYPEC
+
+static int tca_blk_typec_switch_set(struct typec_switch_dev *sw,
+				enum typec_orientation orientation)
+{
+	struct imx8mq_usb_phy *imx_phy = typec_switch_get_drvdata(sw);
+	struct tca_blk *tca = imx_phy->tca;
+	int ret;
+
+	if (tca->orientation == orientation)
+		return 0;
+
+	ret = clk_prepare_enable(imx_phy->clk);
+	if (ret)
+		return ret;
+
+	tca_blk_orientation_set(tca, orientation);
+	clk_disable_unprepare(imx_phy->clk);
+
+	return 0;
+}
+
+static struct typec_switch_dev *tca_blk_get_typec_switch(struct platform_device *pdev,
+					struct imx8mq_usb_phy *imx_phy)
+{
+	struct device *dev = &pdev->dev;
+	struct typec_switch_dev *sw;
+	struct typec_switch_desc sw_desc = { };
+
+	sw_desc.drvdata = imx_phy;
+	sw_desc.fwnode = dev->fwnode;
+	sw_desc.set = tca_blk_typec_switch_set;
+	sw_desc.name = NULL;
+
+	sw = typec_switch_register(dev, &sw_desc);
+	if (IS_ERR(sw)) {
+		dev_err(dev, "Error register tca orientation switch: %ld",
+				PTR_ERR(sw));
+		return NULL;
+	}
+
+	return sw;
+}
+
+static void tca_blk_put_typec_switch(struct typec_switch_dev *sw)
+{
+	typec_switch_unregister(sw);
+}
+
+#else
+
+static struct typec_switch_dev *tca_blk_get_typec_switch(struct platform_device *pdev,
+			struct imx8mq_usb_phy *imx_phy)
+{
+	return NULL;
+}
+
+static void tca_blk_put_typec_switch(struct typec_switch_dev *sw) {}
+
+#endif /* CONFIG_TYPEC */
+
+static void tca_blk_orientation_set(struct tca_blk *tca,
+				enum typec_orientation orientation)
+{
+	u32 val;
+
+	mutex_lock(&tca->mutex);
+
+	if (orientation == TYPEC_ORIENTATION_NONE) {
+		/*
+		 * use Controller Synced Mode for TCA low power enable and
+		 * put PHY to USB safe state.
+		 */
+		val = readl(tca->base + TCA_GCFG);
+		val = FIELD_PREP(TCA_GCFG_OP_MODE, TCA_GCFG_OP_MODE_SYNCMODE);
+		writel(val, tca->base + TCA_GCFG);
+
+		val = readl(tca->base + TCA_TCPC);
+		val = TCA_TCPC_VALID | TCA_TCPC_LOW_POWER_EN;
+		writel(val, tca->base + TCA_TCPC);
+
+		goto out;
+	}
+
+	/* use System Configuration Mode for TCA mux control. */
+	val = readl(tca->base + TCA_GCFG);
+	val = FIELD_PREP(TCA_GCFG_OP_MODE, TCA_GCFG_OP_MODE_SYSMODE);
+	writel(val, tca->base + TCA_GCFG);
+
+	/* Disable TCA module */
+	val = readl(tca->base + TCA_SYSMODE_CFG);
+	val |= TCA_SYSMODE_TCPC_DISABLE;
+	writel(val, tca->base + TCA_SYSMODE_CFG);
+
+	if (orientation == TYPEC_ORIENTATION_REVERSE)
+		val |= TCA_SYSMODE_TCPC_FLIP;
+	else if (orientation == TYPEC_ORIENTATION_NORMAL)
+		val &= ~TCA_SYSMODE_TCPC_FLIP;
+
+	writel(val, tca->base + TCA_SYSMODE_CFG);
+
+	/* Enable TCA module */
+	val &= ~TCA_SYSMODE_TCPC_DISABLE;
+	writel(val, tca->base + TCA_SYSMODE_CFG);
+
+out:
+	tca->orientation = orientation;
+	mutex_unlock(&tca->mutex);
+}
+
+static void tca_blk_init(struct tca_blk *tca)
+{
+	u32 val;
+
+	/* reset XBar block */
+	val = readl(tca->base + TCA_CLK_RST);
+	val &= ~TCA_CLK_RST_SW;
+	writel(val, tca->base + TCA_CLK_RST);
+
+	udelay(100);
+
+	/* clear reset */
+	val |= TCA_CLK_RST_SW;
+	writel(val, tca->base + TCA_CLK_RST);
+
+	tca_blk_orientation_set(tca, tca->orientation);
+}
+
+static int imx95_usb_phy_get_tca(struct platform_device *pdev,
+				struct imx8mq_usb_phy *imx_phy)
+{
+	struct device *dev = &pdev->dev;
+	struct tca_blk *tca;
+
+	tca = devm_kzalloc(dev, sizeof(*tca), GFP_KERNEL);
+	if (!tca)
+		return -ENOMEM;
+
+	tca->base = devm_platform_ioremap_resource(pdev, 1);
+	if (IS_ERR(tca->base))
+		return PTR_ERR(tca->base);
+
+	mutex_init(&tca->mutex);
+
+	tca->orientation = TYPEC_ORIENTATION_NORMAL;
+	tca->sw = tca_blk_get_typec_switch(pdev, imx_phy);
+	imx_phy->tca = tca;
+
+	return 0;
+}
+
+static void imx95_usb_phy_put_tca(struct imx8mq_usb_phy *imx_phy)
+{
+	struct tca_blk *tca = imx_phy->tca;
+
+	if (!tca)
+		return;
+
+	tca_blk_put_typec_switch(tca->sw);
+}
+
 static u32 phy_tx_vref_tune_from_property(u32 percent)
 {
 	percent = clamp(percent, 94U, 124U);
@@ -315,6 +536,9 @@ static int imx8mp_usb_phy_init(struct phy *phy)
 
 	imx8m_phy_tune(imx_phy);
 
+	if (imx_phy->tca)
+		tca_blk_init(imx_phy->tca);
+
 	return 0;
 }
 
@@ -359,6 +583,8 @@ static const struct of_device_id imx8mq_usb_phy_of_match[] = {
 	 .data = &imx8mq_usb_phy_ops,},
 	{.compatible = "fsl,imx8mp-usb-phy",
 	 .data = &imx8mp_usb_phy_ops,},
+	{.compatible = "fsl,imx95-usb-phy",
+	 .data = &imx8mp_usb_phy_ops,},
 	{ }
 };
 MODULE_DEVICE_TABLE(of, imx8mq_usb_phy_of_match);
@@ -398,6 +624,10 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
 
 	phy_set_drvdata(imx_phy->phy, imx_phy);
 
+	if (device_is_compatible(dev, "fsl,imx95-usb-phy") &&
+			imx95_usb_phy_get_tca(pdev, imx_phy) < 0)
+		return dev_err_probe(dev, -ENODEV, "failed to get tca\n");
+
 	imx8m_get_phy_tuning_data(imx_phy);
 
 	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
@@ -405,8 +635,16 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
 	return PTR_ERR_OR_ZERO(phy_provider);
 }
 
+static void imx8mq_usb_phy_remove(struct platform_device *pdev)
+{
+	struct imx8mq_usb_phy *imx_phy = platform_get_drvdata(pdev);
+
+	imx95_usb_phy_put_tca(imx_phy);
+}
+
 static struct platform_driver imx8mq_usb_phy_driver = {
 	.probe	= imx8mq_usb_phy_probe,
+	.remove = imx8mq_usb_phy_remove,
 	.driver = {
 		.name	= "imx8mq-usb-phy",
 		.of_match_table	= imx8mq_usb_phy_of_match,
-- 
2.34.1



From xu.yang_2 at nxp.com  Fri Aug  2 02:17:01 2024
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Fri,  2 Aug 2024 17:17:01 +0800
Subject: [PATCH 4/5] arm64: dts: imx95: add usb3 related nodes
In-Reply-To: <20240802091702.2057294-1-xu.yang_2@nxp.com>
References: <20240802091702.2057294-1-xu.yang_2@nxp.com>
Message-ID: <20240802091702.2057294-4-xu.yang_2@nxp.com>

Add usb3 phy and controller nodes for imx95.

Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
---
 arch/arm64/boot/dts/freescale/imx95.dtsi | 43 ++++++++++++++++++++++++
 1 file changed, 43 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
index 1bbf9a0468f6..06a7c2f1e211 100644
--- a/arch/arm64/boot/dts/freescale/imx95.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
@@ -1188,5 +1188,48 @@ pcie1_ep: pcie-ep at 4c380000 {
 			power-domains = <&scmi_devpd IMX95_PD_HSIO_TOP>;
 			status = "disabled";
 		};
+
+		usb3_phy: phy at 4c1f0040 {
+			compatible = "fsl,imx95-usb-phy", "fsl,imx8mp-usb-phy";
+			reg = <0x0 0x4c1f0040 0x0 0x40>,
+			      <0x0 0x4c1fc000 0x0 0x100>;
+			clocks = <&scmi_clk IMX95_CLK_HSIO>;
+			clock-names = "phy";
+			#phy-cells = <0>;
+			power-domains = <&scmi_devpd IMX95_PD_HSIO_TOP>;
+			orientation-switch;
+			status = "disabled";
+		};
+
+		usb3: usb at 4c010010 {
+			compatible = "fsl,imx95-dwc3", "fsl,imx8mp-dwc3";
+			reg = <0x0 0x4c010010 0x0 0x04>,
+			      <0x0 0x4c1f0000 0x0 0x20>;
+			clocks = <&scmi_clk IMX95_CLK_HSIO>,
+				 <&scmi_clk IMX95_CLK_32K>;
+			clock-names = "hsio", "suspend";
+			interrupts = <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>;
+			#address-cells = <2>;
+			#size-cells = <2>;
+			ranges;
+			power-domains = <&scmi_devpd IMX95_PD_HSIO_TOP>;
+			dma-ranges = <0x0 0x0 0x0 0x0 0x10 0x0>;
+			status = "disabled";
+
+			usb3_dwc3: usb at 4c100000 {
+				compatible = "snps,dwc3";
+				reg = <0x0 0x4c100000 0x0 0x10000>;
+				clocks = <&scmi_clk IMX95_CLK_HSIO>,
+					 <&scmi_clk IMX95_CLK_24M>,
+					 <&scmi_clk IMX95_CLK_32K>;
+				clock-names = "bus_early", "ref", "suspend";
+				interrupts = <GIC_SPI 175 IRQ_TYPE_LEVEL_HIGH>;
+				phys = <&usb3_phy>, <&usb3_phy>;
+				phy-names = "usb2-phy", "usb3-phy";
+				snps,gfladj-refclk-lpm-sel-quirk;
+				snps,parkmode-disable-ss-quirk;
+				iommus = <&smmu 0xe>;
+			};
+		};
 	};
 };
-- 
2.34.1



From xu.yang_2 at nxp.com  Fri Aug  2 02:17:02 2024
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Fri,  2 Aug 2024 17:17:02 +0800
Subject: [PATCH 5/5] arm64: dts: imx95-19x19-evk: add typec nodes and enable usb3 node
In-Reply-To: <20240802091702.2057294-1-xu.yang_2@nxp.com>
References: <20240802091702.2057294-1-xu.yang_2@nxp.com>
Message-ID: <20240802091702.2057294-5-xu.yang_2@nxp.com>

This board has one Type-C port which has USB3 capability. This will
add typec nodes and enable usb3 node.

Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
---
 .../boot/dts/freescale/imx95-19x19-evk.dts    | 81 +++++++++++++++++++
 1 file changed, 81 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
index d14a54ab4fd4..46a9cd3d4403 100644
--- a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
@@ -5,6 +5,7 @@
 
 /dts-v1/;
 
+#include <dt-bindings/usb/pd.h>
 #include "imx95.dtsi"
 
 / {
@@ -99,6 +100,48 @@ i2c7_pcal6524: i2c7-gpio at 22 {
 		interrupt-parent = <&gpio5>;
 		interrupts = <16 IRQ_TYPE_LEVEL_LOW>;
 	};
+
+	ptn5110: tcpc at 50 {
+		compatible = "nxp,ptn5110", "tcpci";
+		reg = <0x50>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_typec>;
+		interrupt-parent = <&gpio5>;
+		interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
+
+		typec_con: connector {
+			compatible = "usb-c-connector";
+			label = "USB-C";
+			power-role = "dual";
+			data-role = "dual";
+			try-power-role = "sink";
+			source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+			sink-pdos = <PDO_FIXED(5000, 0, PDO_FIXED_USB_COMM)>;
+			op-sink-microwatt = <0>;
+			self-powered;
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				port at 0 {
+					reg = <0>;
+
+					typec_con_hs: endpoint {
+						remote-endpoint = <&usb3_data_hs>;
+					};
+				};
+
+				port at 1 {
+					reg = <1>;
+
+					typec_con_ss: endpoint {
+						remote-endpoint = <&usb3_data_ss>;
+					};
+				};
+			};
+		};
+	};
 };
 
 &lpuart1 {
@@ -128,6 +171,38 @@ &pcie1 {
 	status = "okay";
 };
 
+&usb3 {
+	status = "okay";
+};
+
+&usb3_phy {
+	status = "okay";
+
+	port {
+		usb3_data_ss: endpoint {
+			remote-endpoint = <&typec_con_ss>;
+		};
+	};
+};
+
+&usb3_dwc3 {
+	dr_mode = "otg";
+	hnp-disable;
+	srp-disable;
+	adp-disable;
+	usb-role-switch;
+	role-switch-default-mode = "peripheral";
+	snps,dis-u1-entry-quirk;
+	snps,dis-u2-entry-quirk;
+	status = "okay";
+
+	port {
+		usb3_data_hs: endpoint {
+			remote-endpoint = <&typec_con_hs>;
+		};
+	};
+};
+
 &usdhc1 {
 	pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
 	pinctrl-0 = <&pinctrl_usdhc1>;
@@ -245,6 +320,12 @@ IMX95_PAD_SD2_RESET_B__GPIO3_IO_BIT7		0x31e
 		>;
 	};
 
+	pinctrl_typec: typecgrp {
+		fsl,pins = <
+			IMX95_PAD_GPIO_IO34__GPIO5_IO_BIT14			0x31e
+		>;
+	};
+
 	pinctrl_usdhc2_gpio: usdhc2gpiogrp {
 		fsl,pins = <
 			IMX95_PAD_SD2_CD_B__GPIO3_IO_BIT0		0x31e
-- 
2.34.1



From minda.chen at starfivetech.com  Fri Aug  2 03:45:26 2024
From: minda.chen at starfivetech.com (Minda Chen)
Date: Fri, 2 Aug 2024 10:45:26 +0000
Subject: [PATCH 3/3] phy: starfive: jh7110-usb: Fix link configuration to
 controller
In-Reply-To: <cd7b125c8c797f9d63440944df7121f9db0a49ad.1722457123.git.jan.kiszka@siemens.com>
References: <cover.1722457123.git.jan.kiszka@siemens.com>
 <cd7b125c8c797f9d63440944df7121f9db0a49ad.1722457123.git.jan.kiszka@siemens.com>
Message-ID: <SHXPR01MB086373887A29C696747FB365E6B32@SHXPR01MB0863.CHNPR01.prod.partner.outlook.cn>



> 
> From: Jan Kiszka <jan.kiszka at siemens.com>
> 
> In order to connect the USB 2.0 PHY to its controller, we also need to set
> "u0_pdrstn_split_sw_usbpipe_plugen" [1]. Some downstream U-Boot versions
> did that, but upstream firmware does not, and the kernel must not rely on such
> behavior anyway. Failing to set this left the USB gadget port invisible to
> connected hosts behind.
> 
> Link:
> https://doc-en.rvspace.org/JH7110/TRM/JH7110_TRM/sys_syscon.html#sys_sys
> con__section_b3l_fqs_wsb [1]
> Fixes: 16d3a71c20cf ("phy: starfive: Add JH7110 USB 2.0 PHY driver")
> Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com>
> ---
>  drivers/phy/starfive/phy-jh7110-usb.c | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/drivers/phy/starfive/phy-jh7110-usb.c
> b/drivers/phy/starfive/phy-jh7110-usb.c
> index 633912f8a05d..67882bc4cebc 100644
> --- a/drivers/phy/starfive/phy-jh7110-usb.c
> +++ b/drivers/phy/starfive/phy-jh7110-usb.c
> @@ -10,18 +10,24 @@
>  #include <linux/clk.h>
>  #include <linux/err.h>
>  #include <linux/io.h>
> +#include <linux/mfd/syscon.h>
>  #include <linux/module.h>
>  #include <linux/phy/phy.h>
>  #include <linux/platform_device.h>
> +#include <linux/regmap.h>
>  #include <linux/usb/of.h>
> 
>  #define USB_125M_CLK_RATE		125000000
>  #define USB_LS_KEEPALIVE_OFF		0x4
>  #define USB_LS_KEEPALIVE_ENABLE		BIT(4)
> 
> +#define USB_PDRSTN_SPLIT		BIT(17)
> +
>  struct jh7110_usb2_phy {
>  	struct phy *phy;
>  	void __iomem *regs;
> +	struct regmap *sys_syscon;
> +	u32 sys_phy_connect;
>  	struct clk *usb_125m_clk;
>  	struct clk *app_125m;
>  	enum phy_mode mode;
> @@ -61,6 +67,10 @@ static int usb2_phy_set_mode(struct phy *_phy,
>  		usb2_set_ls_keepalive(phy, (mode != PHY_MODE_USB_DEVICE));
>  	}
> 
> +	/* Connect usb 2.0 phy mode */
> +	regmap_update_bits(phy->sys_syscon, phy->sys_phy_connect,
> +			   USB_PDRSTN_SPLIT, USB_PDRSTN_SPLIT);
> +
>  	return 0;
>  }
> 
> @@ -101,6 +111,7 @@ static int jh7110_usb_phy_probe(struct
> platform_device *pdev)
>  	struct jh7110_usb2_phy *phy;
>  	struct device *dev = &pdev->dev;
>  	struct phy_provider *phy_provider;
> +	u32 args[1];
> 
>  	phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
>  	if (!phy)
> @@ -129,6 +140,15 @@ static int jh7110_usb_phy_probe(struct
> platform_device *pdev)
>  	phy_set_drvdata(phy->phy, phy);
>  	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
> 
> +	phy->sys_syscon =
> +		syscon_regmap_lookup_by_phandle_args(pdev->dev.of_node,
> +						     "starfive,sys-syscon",
> +						     1, args);
> +	if (IS_ERR(phy->sys_syscon))
> +		return dev_err_probe(dev, PTR_ERR(phy->phy),
> +			"Failed to get sys-syscon\n");
> +	phy->sys_phy_connect = args[0];
> +
>  	return PTR_ERR_OR_ZERO(phy_provider);
>  }
> 
Reviewed-by: Minda Chen <minda.chen at starfivetech.com>



From dmitry.baryshkov at linaro.org  Fri Aug  2 06:52:06 2024
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Fri, 2 Aug 2024 16:52:06 +0300
Subject: [PATCH 3/5] phy: fsl-imx8mq-usb: add tca function driver for
 imx95
In-Reply-To: <20240802091702.2057294-3-xu.yang_2@nxp.com>
References: <20240802091702.2057294-1-xu.yang_2@nxp.com>
 <20240802091702.2057294-3-xu.yang_2@nxp.com>
Message-ID: <i2o5pk7jnni4bgc6txktus26dtnd6quivxkslgqkelmyb334k6@s5waxd5ep75f>

On Fri, Aug 02, 2024 at 05:17:00PM GMT, Xu Yang wrote:
> The i.MX95 USB3 phy has a Type-C Assist block (TCA). This block consists
> two functional blocks (XBar assist and VBus assist) and one system
> access interface using APB.
> 
> The primary functionality of XBar assist is:
>  - switching lane for flip
>  - moving unused lanes into lower power states.
> 
> This info can be get from:
> i.MX95 RM Chapter 163.3.8 Type-C assist (TCA) block.
> 
> This will add support for TCA block to achieve lane switching and tca
> lower power functionality.
> 
> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> Reviewed-by: Jun Li <jun.li at nxp.com>
> ---
>  drivers/phy/freescale/Kconfig              |   1 +
>  drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 238 +++++++++++++++++++++
>  2 files changed, 239 insertions(+)
> 

[..]

> @@ -398,6 +624,10 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
>  
>  	phy_set_drvdata(imx_phy->phy, imx_phy);
>  
> +	if (device_is_compatible(dev, "fsl,imx95-usb-phy") &&
> +			imx95_usb_phy_get_tca(pdev, imx_phy) < 0)
> +		return dev_err_probe(dev, -ENODEV, "failed to get tca\n");

Pleas propagate error returned by imx95_usb_phy_get_tca() instead of
always returning -ENODEV.

> +
>  	imx8m_get_phy_tuning_data(imx_phy);
>  
>  	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
> @@ -405,8 +635,16 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
>  	return PTR_ERR_OR_ZERO(phy_provider);
>  }
>  
> +static void imx8mq_usb_phy_remove(struct platform_device *pdev)
> +{
> +	struct imx8mq_usb_phy *imx_phy = platform_get_drvdata(pdev);
> +
> +	imx95_usb_phy_put_tca(imx_phy);
> +}
> +
>  static struct platform_driver imx8mq_usb_phy_driver = {
>  	.probe	= imx8mq_usb_phy_probe,
> +	.remove = imx8mq_usb_phy_remove,
>  	.driver = {
>  		.name	= "imx8mq-usb-phy",
>  		.of_match_table	= imx8mq_usb_phy_of_match,
> -- 
> 2.34.1
> 

-- 
With best wishes
Dmitry


From vkoul at kernel.org  Fri Aug  2 07:10:27 2024
From: vkoul at kernel.org (Vinod Koul)
Date: Fri, 2 Aug 2024 19:40:27 +0530
Subject: [PATCH] phy: qcom: com-qmp-combo: fix swing and pre-emphasis
 table for sm8350
In-Reply-To: <20240725220608.131426-1-quic_abhinavk@quicinc.com>
References: <20240725220608.131426-1-quic_abhinavk@quicinc.com>
Message-ID: <Zqzo08Siy5liaPAd@matsya>

On 25-07-24, 15:06, Abhinav Kumar wrote:
> Fix the voltage swing and pre-emphasis tables for sm8350 as the current
> one do not match the hardware docs.
> 
> Fixes: ef14aff107bd ("phy: qcom: com-qmp-combo: add SM8350 & SM8450 support")
> Signed-off-by: Abhinav Kumar <quic_abhinavk at quicinc.com>
> ---
>  drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> index 31e43638a649..c15b01aa5a48 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> @@ -1946,8 +1946,8 @@ static const struct qmp_phy_cfg sm8350_usb3dpphy_cfg = {
>  
>  	.swing_hbr_rbr		= &qmp_dp_v4_voltage_swing_hbr_rbr,
>  	.pre_emphasis_hbr_rbr	= &qmp_dp_v4_pre_emphasis_hbr_rbr,
> -	.swing_hbr3_hbr2	= &qmp_dp_v3_voltage_swing_hbr3_hbr2,
> -	.pre_emphasis_hbr3_hbr2 = &qmp_dp_v4_pre_emphasis_hbr3_hbr2,
> +	.swing_hbr3_hbr2	= &qmp_dp_v5_voltage_swing_hbr3_hbr2,
> +	.pre_emphasis_hbr3_hbr2 = &qmp_dp_v5_pre_emphasis_hbr3_hbr2,

This is fine but you need to drop the unused qmp_dp_v4_pre_emphasis_hbr3_hbr2 table...

It adds a warning, defined but unused!

-- 
~Vinod


From ilordash02 at gmail.com  Sat Aug  3 05:31:52 2024
From: ilordash02 at gmail.com (Ilya Orazov)
Date: Sat, 3 Aug 2024 15:31:52 +0300
Subject: [PATCH 1/2] dt-bindings: phy: ti,tcan104x-can: Document Microchip ATA6561
In-Reply-To: <20240801-disarray-gesture-ebad121272b0@spud>
References: <20240718210322.37492-1-ilordash02@gmail.com> <20240718210322.37492-2-ilordash02@gmail.com>
 <20240719-ahead-kiwi-995e52bf3e74@spud> <CAGCz5HkF_WNZBVpY2SWVf071Pi896BvKFk0jnfNAYX5AKx2Zcw@mail.gmail.com>
 <20240723-dinginess-john-608d0b28293b@spud> <CAGCz5H=Gncw+Tr0XaQQhhGWQER5Rs1BcxbkPaJwx9jJ-8j7LGQ@mail.gmail.com>
 <20240723-municipal-snowy-136b08b6db90@spud> <CAGCz5HnJKjNj7A0YD2fw20m-NrEs3MoCLwox86mC11Kudq8xbg@mail.gmail.com>
 <CAMuHMdUf=McxMLqb1hgu_-4QkSFJkdWrdtbwiwn9yJoMSi3YWA@mail.gmail.com> <20240801-disarray-gesture-ebad121272b0@spud>
Message-ID: <CAGCz5H=gDfJpfAhH-QbxN5VSDyVtwGU6Zt16z7=sqpTdjkeGqA@mail.gmail.com>

On Thu, 1 Aug 2024 at 18:12, Conor Dooley <conor at kernel.org> wrote:
>
> On Mon, Jul 29, 2024 at 10:51:50AM +0200, Geert Uytterhoeven wrote:
> > Hi Ilya,
> >
> > On Sun, Jul 28, 2024 at 10:52?AM Ilya Orazov <ilordash02 at gmail.com> wrote:
> > > On Tue, 23 Jul 2024 at 23:14, Conor Dooley <conor at kernel.org> wrote:
> > > > On Tue, Jul 23, 2024 at 10:55:17PM +0300, Ilya Orazov wrote:
> > > > > On Tue, 23 Jul 2024 at 21:50, Conor Dooley <conor at kernel.org> wrote:
> > > > > > On Tue, Jul 23, 2024 at 08:20:04PM +0300, IlorDash wrote:
> > > > > > > On Fri, 19 Jul 2024 at 18:07, Conor Dooley <conor at kernel.org> wrote:
> > > > > > > >
> > > > > > > > On Fri, Jul 19, 2024 at 12:03:21AM +0300, Ilya Orazov wrote:
> > > > > > > > > Microchip ATA6561 is High-Speed CAN Transceiver with Standby Mode.
> > > > > > > > > It is pin-compatible with TI TCAN1042.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Ilya Orazov <ilordash02 at gmail.com>
> > > > > > > > > ---
> > > > > > > > >  Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml | 1 +
> > > > > > > > >  1 file changed, 1 insertion(+)
> > > > > > > > >
> > > > > > > > > diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> > > > > > > > > index 79dad3e89aa6..03de361849d2 100644
> > > > > > > > > --- a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> > > > > > > > > +++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> > > > > > > > > @@ -18,6 +18,7 @@ properties:
> > > > > > > > >        - nxp,tjr1443
> > > > > > > > >        - ti,tcan1042
> > > > > > > > >        - ti,tcan1043
> > > > > > > > > +      - microchip,ata6561
> > > > > > > >
> > > > > > > > Given that your driver patch has
> > > > > > > > | diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
> > > > > > > > | index ee4ce4249698..dbcd99213ba1 100644
> > > > > > > > | --- a/drivers/phy/phy-can-transceiver.c
> > > > > > > > | +++ b/drivers/phy/phy-can-transceiver.c
> > > > > > > > | @@ -89,6 +89,10 @@ static const struct of_device_id can_transceiver_phy_ids[] = {
> > > > > > > > |                 .compatible = "nxp,tjr1443",
> > > > > > > > |                 .data = &tcan1043_drvdata
> > > > > > > > |         },
> > > > > > > > | +       {
> > > > > > > > | +               .compatible = "microchip,ata6561",
> > > > > > > > | +               .data = &tcan1042_drvdata
> > > > > > > > | +       },
> > > > > > > > |         { }
> > > > > > > > |  };
> > > > > > > >
> > > > > > > > the driver patch is actually not needed at all, and you just need to
> > > > > > > > allow ti,tcan1042 as fallback compatible in the binding, so something
> > > > > > > > like:
> > > > > > > >
> > > > > > > >   compatible:
> > > > > > > >     oneOf:
> > > > > > > >       - enum:
> > > > > > > >           - nxp,tjr1443
> > > > > > > >           - ti,tcan1042
> > > > > > > >           - ti,tcan1043
> > > > > > > >       - items:
> > > > > > > >           - const: microchip,ata6561
> > > > > > > >           - const: ti,tcan1042
> > > > > > > >
> > > > > > > >    '#phy-cells':
> > > > > > > >      const: 0
> > > > > > >
> > > > > > > I tested the build with fallback compatible:
> > > > > > >
> > > > > > > compatible:
> > > > > > >   oneOf:
> > > > > > >     - items:
> > > > > > >       - enum:
> > > > > > >         - microchip,ata6561
> > > > > > >       - const: ti,tcan1042
> > > > > > >     - items:
> > > > > > >       - enum:
> > > > > > >         - nxp,tjr1443
> > > > > > >       - const: ti,tcan1043
> > > > > > >
> > > > > > > and modified compatible property in DTS:
> > > > > > >
> > > > > > > compatible = "microchip,ata6561", "ti,tcan1042";
> > > > > > >
> > > > > > > Build succeeded, phy-can-transceiver driver was used. So I would like
> > > > > > > to add a fallback compatible for both "microchip,ata6561" and
> > > > > > > "nxp,tjr1443" in this binding and modify other DTS files with
> > > > > > > compatible = "nxp,tjr1443". What do you think?
> > > > > >
> > > > > > This is wrong on two counts. Firstly, were what you have correct, you
> > > > > > should
> > > > > > squash the two:
> > > > > >      - items:
> > > > > >          - enum:
> > > > > >            - nxp,tjr1443
> > > > > >            - microchip,ata6561
> > > > > >          - const: ti,tcan1042
> > > > > >
> > > > > > However, that does not allow the TI compatibles in isolation, so you
> > > > > > still need to allow that for the actual TI devices, so you need:
> > > > > >
> > > > > >    oneOf:
> > > > > >      - items:
> > > > > >          - enum:
> > > > > >            - microchip,ata6561
> > > > > >            - nxp,tjr1443
> > > > > >            - ti,tcan1043
> > > > > >          - const: ti,tcan1042
> > > > > >      - const: ti,tcan1042
> > > > > >
> > > > > > There's probably some devicetrees that would need to be fixed up. I'm
> > > > > > just not convinced that this is worth retrofitting however.
> > > > >
> > > > > But nxp,tjr1443 is pin compatible with ti,tcan1043, so it should
> > > > > fallback only to ti,tcan1043 and not ti,tcan1042. That's why I decided
> > > > > to split them into different enums.
> > > >
> > > > Ah, sorry I missed that. I misread the match data. Then you need:
> > > >   compatible:
> > > >     oneOf:
> > > >       - items:
> > > >         - enum:
> > > >           - microchip,ata6561
> > > >         - const: ti,tcan1042
> > > >       - items:
> > > >         - enum:
> > > >           - nxp,tjr1443
> > > >         - const: ti,tcan1043
> > > >       - enum:
> > > >           const: ti,tcan1042
> > > >           const: ti,tcan1043
> > > >
> > > > because the TI devices exist and we still need to be able to
> > > > differentiate the TI and NXP devices. If you have
> > > >   compatible = "nxp,tjr1443", "ti,tcan1042";
> > > > that means the device is an nxp,tjr1443. If you have
> > > >   compatible = "ti,tcan1042";
> > > > then that's a tcan1042.
> > > >
> > > > > I made my patch according to a similar one that adds support for
> > > > > nxp,tjr1443. You can find it's conversation on
> > > > > https://lore.kernel.org/all/6ee5e2ce00019bd3f77d6a702b38bab1a45f3bb0.1674037830.git.geert+renesas at glider.be/t/#u.
> > > >
> > > > > I thought we want to hold all PHY chip names in one compatible enum
> > > > > and each in its own of_device_id struct in driver and extend them
> > > > > where appropriate.
> > > >
> > > > Nah, fallbacks are preferred when the programming model is either
> > > > identical or a "compatible superset" of an existing device. New
> > > > of_device_id structs should only be used where we need to account for
> > > > differences in the programming model.
> > >
> > > However, I am curious as to why the NXP CAN PHY transceiver was not
> > > included as fallback compatible. Geert, could you please share your
> > > thoughts on this matter?
> >
> > The TJR1443 looked sufficiently similar to the TCAN1043 to use the
> > same driver configuration (which is limited to having standby and/or
> > enable signals or not).  However, I'm not sure it behaves exactly
> > the same, e.g. in case of reporting an error condition (which is not
> > yet supported by the driver). The part numbers are also different,
> > so this is not a simple case of SN74HCxx vs. CD74HCxx.
> >
> > Summary: I don't know if they are identical, or if TJR1443 is a
> > compatible superset of TCAN1043, or vice versa. Hence I went for the
> > safest way....
>
> If we don't know for sure what the craic is with compatibility, then we
> should leave the existing tjr1443 compatible as-is I think.

If I understood the kernel documentation correctly, we use fallback
compatibles when devices are similar or there is an iterative
relationship between them. In my case, the TCAN1042 and ATA6561 are
from different manufacturers, and I'm not sure about their fully
identical functionality.

Therefore, I'll go back to the original idea where I shouldn't use a
fallback compatible here and must leave it as another compatible
property with its own of_device_id struct.

What do you think about it? In my opinion, this is not a case for
fallback compatibility.

-- 
Best regards,
Ilya Orazov


From krzk at kernel.org  Sun Aug  4 07:16:34 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Sun, 4 Aug 2024 16:16:34 +0200
Subject: [PATCH 1/5] dt-bindings: phy: imx8mq-usb: add compatible
 "fsl,imx95-usb-phy"
In-Reply-To: <20240802091702.2057294-1-xu.yang_2@nxp.com>
References: <20240802091702.2057294-1-xu.yang_2@nxp.com>
Message-ID: <21557eac-44f0-451d-a194-c5d545cacbee@kernel.org>

On 02/08/2024 11:16, Xu Yang wrote:
> The usb phy in i.MX95 is compatible with i.MX8MP's, this will add a
> compatible "fsl,imx95-usb-phy" for i.MX95. Also change reg maxItems
> to 2 since i.MX95 needs another regmap to control Type-C Assist (TCA)
> block. Since i.MX95 usb phy is able to switch SS lanes, this will also
> add orientation-switch and port property to the file.
> 
> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> ---
>  .../bindings/phy/fsl,imx8mq-usb-phy.yaml      | 40 +++++++++++++++++--
>  1 file changed, 36 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
> index dc3a3f709fea..b0a614a9556d 100644
> --- a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
> @@ -11,12 +11,17 @@ maintainers:
>  
>  properties:
>    compatible:
> -    enum:
> -      - fsl,imx8mq-usb-phy
> -      - fsl,imx8mp-usb-phy
> +    oneOf:
> +      - enum:
> +          - fsl,imx8mq-usb-phy
> +          - fsl,imx8mp-usb-phy
> +      - items:
> +          - const: fsl,imx95-usb-phy
> +          - const: fsl,imx8mp-usb-phy
>  
>    reg:
> -    maxItems: 1
> +    minItems: 1
> +    maxItems: 2
>  
>    "#phy-cells":
>      const: 0
> @@ -28,6 +33,17 @@ properties:
>      items:
>        - const: phy
>  
> +  orientation-switch:
> +    description:
> +      Flag the PHY as possible handler of USB Type-C orientation switching

No need to duplicate definitions of properties.

> +    type: boolean
> +
> +  port:
> +    $ref: /schemas/graph.yaml#/properties/port
> +    description:
> +      A port node to link the PHY to a TypeC controller for the purpose of
> +      handling orientation switching.

Same here. You probably miss reference to usb-switch.

> +
>    power-domains:
>      maxItems: 1
>  
> @@ -89,6 +105,22 @@ required:
>    - clocks
>    - clock-names
>  
> +allOf:
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - fsl,imx95-usb-phy
> +    then:
> +      properties:
> +        reg:
> +          minItems: 2

list and describe the items here, instead.


Krzysztof



From krzk at kernel.org  Sun Aug  4 07:17:08 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Sun, 4 Aug 2024 16:17:08 +0200
Subject: [PATCH 2/5] dt-bindings: usb: dwc3-imx8mp: add compatible string
 for imx95
In-Reply-To: <20240802091702.2057294-2-xu.yang_2@nxp.com>
References: <20240802091702.2057294-1-xu.yang_2@nxp.com>
 <20240802091702.2057294-2-xu.yang_2@nxp.com>
Message-ID: <a7ba4577-40e8-46d5-bde2-442e7100dc9b@kernel.org>

On 02/08/2024 11:16, Xu Yang wrote:
> The i.MX95 is compatible with i.MX8MP's usb controller. This will add a
> compatible string "fsl,imx95-dwc3" for i.MX95.
> 
> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> ---


Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From vkoul at kernel.org  Sun Aug  4 09:36:11 2024
From: vkoul at kernel.org (Vinod Koul)
Date: Sun, 4 Aug 2024 22:06:11 +0530
Subject: [PATCH v2] phy: qcom: qmp-pcie: Configure all tables on port B
 PHY
In-Reply-To: <20240801-phy-qcom-qmp-pcie-write-all-tbls-second-port-v2-1-6e53c701e87e@linaro.org>
References: <20240801-phy-qcom-qmp-pcie-write-all-tbls-second-port-v2-1-6e53c701e87e@linaro.org>
Message-ID: <Zq-t-1jfSg3RmLKW@matsya>

On 01-08-24, 18:54, Abel Vesa wrote:
> From: Qiang Yu <quic_qianyu at quicinc.com>
> 
> Currently, only the RX and TX tables are written to the second PHY
> (port B) when the 4-lanes mode is configured, but according to Qualcomm
> internal documentation, the pcs, pcs_misc, serdes and ln_shrd tables need
> to be written as well.

Sorry this does not apply on phy/next please rebase and resend

-- 
~Vinod


From vkoul at kernel.org  Sun Aug  4 09:39:09 2024
From: vkoul at kernel.org (Vinod Koul)
Date: Sun, 4 Aug 2024 22:09:09 +0530
Subject: [PATCH v3] phy: qcom: qmp: Add debug prints for register writes
In-Reply-To: <20240801070026.GB3705@thinkpad>
References: <20240731152548.102987-1-manivannan.sadhasivam@linaro.org>
 <172249532035.256913.2685367794999812971.b4-ty@kernel.org>
 <20240801070026.GB3705@thinkpad>
Message-ID: <Zq-ura3oYbhb8C9a@matsya>

On 01-08-24, 12:30, Manivannan Sadhasivam wrote:
> On Thu, Aug 01, 2024 at 12:25:20PM +0530, Vinod Koul wrote:
> > 
> > On Wed, 31 Jul 2024 20:55:48 +0530, Manivannan Sadhasivam wrote:
> > > These register prints are useful to validate the init sequence against the
> > > Qcom internal documentation and also to share with the Qcom hw engineers to
> > > debug issues related to PHY.
> > > 
> > > Sample debug prints:
> > > 
> > > qcom-qmp-pcie-phy 1c0e000.phy: Writing Reg: QSERDES_V5_COM_SYSCLK_EN_SEL Offset: 0x0094 Val: 0xd9
> > > qcom-qmp-pcie-phy 1c0e000.phy: Writing Reg: QSERDES_V5_COM_HSCLK_SEL Offset: 0x0158 Val: 0x11
> > > 
> > > [...]
> > 
> > Applied, thanks!
> > 
> > [1/1] phy: qcom: qmp: Add debug prints for register writes
> >       commit: 4e92d504475ea5841716ad775f412342520a3d26
> > 
> 
> Thanks! Bjorn spotted that it is worth making 'char *name' a const. Can you
> please ammend the commit?

Send a patch please, I dont like to rebase

-- 
~Vinod


From vkoul at kernel.org  Sun Aug  4 10:09:59 2024
From: vkoul at kernel.org (Vinod Koul)
Date: Sun, 4 Aug 2024 22:39:59 +0530
Subject: [PATCH v3] phy: cadence-torrent: add support for three or more
 links using 2 protocols
In-Reply-To: <20240716102442.1605280-1-s-vadapalli@ti.com>
References: <20240716102442.1605280-1-s-vadapalli@ti.com>
Message-ID: <Zq-15_enK919eUg_@matsya>

On 16-07-24, 15:54, Siddharth Vadapalli wrote:
> The Torrent SERDES can support at most two different protocols (PHY types).
> This only mandates that the device-tree sub-nodes used to represent the
> configuration should describe links with at-most two different protocols.
> 
> The existing implementation however imposes an artificial constraint that
> allows only two links (device-tree sub-nodes). As long as at-most two
> protocols are chosen, using more than two links to describe them in an
> alternating configuration is still a valid configuration of the Torrent
> SERDES.
> 
> A 3-Link 2-Protocol configuration of the 4-Lane SERDES can be:
> Lane 0 => Protocol 1 => Link 1
> Lane 1 => Protocol 1 => Link 1
> Lane 2 => Protocol 2 => Link 2
> Lane 3 => Protocol 1 => Link 3
> 
> A 4-Link 2-Protocol configuration of the 4-Lane SERDES can be:
> Lane 0 => Protocol 1 => Link 1
> Lane 1 => Protocol 2 => Link 2
> Lane 2 => Protocol 1 => Link 3
> Lane 3 => Protocol 2 => Link 4
> 
> Signed-off-by: Siddharth Vadapalli <s-vadapalli at ti.com>
> ---
> 
> Hello,
> 
> This patch is based on linux-next tagged next-20240715.

Sorry this does not apply for me on phy/next, can you rebase..?

-- 
~Vinod


From vkoul at kernel.org  Sun Aug  4 10:20:52 2024
From: vkoul at kernel.org (Vinod Koul)
Date: Sun, 4 Aug 2024 22:50:52 +0530
Subject: [PATCH] phy: xilinx: phy-zynqmp: Fix SGMII linkup failure on
 resume
In-Reply-To: <1721155263-2913528-1-git-send-email-radhey.shyam.pandey@amd.com>
References: <1721155263-2913528-1-git-send-email-radhey.shyam.pandey@amd.com>
Message-ID: <Zq-4dH2dXzGXebYv@matsya>

On 17-07-24, 00:11, Radhey Shyam Pandey wrote:
> From: Piyush Mehta <piyush.mehta at amd.com>
> 
> On a few Kria KR260 Robotics Starter Kit the PS-GEM SGMII linkup is not
> happening after the resume. This is because serdes registers are reset
> when FPD is off (in suspend state) and needs to be reprogrammed in the
> resume path with the same default initialization as done in the first
> stage bootloader psu_init routine.
> 
> To address the failure introduce a set of serdes registers to be saved in
> the suspend path and then restore it on resume.
> 
> Signed-off-by: Piyush Mehta <piyush.mehta at amd.com>
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey at amd.com>
> ---
>  drivers/phy/xilinx/phy-zynqmp.c | 56 +++++++++++++++++++++++++++++++++
>  1 file changed, 56 insertions(+)
> 
> diff --git a/drivers/phy/xilinx/phy-zynqmp.c b/drivers/phy/xilinx/phy-zynqmp.c
> index dc8319bda43d..bdcc8d7c3dfa 100644
> --- a/drivers/phy/xilinx/phy-zynqmp.c
> +++ b/drivers/phy/xilinx/phy-zynqmp.c
> @@ -165,6 +165,24 @@
>  /* Timeout values */
>  #define TIMEOUT_US			1000
>  
> +/* Lane 0/1/2/3 offset */
> +#define DIG_8(n)		((0x4000 * (n)) + 0x1074)
> +#define ILL13(n)		((0x4000 * (n)) + 0x1994)
> +#define DIG_10(n)		((0x4000 * (n)) + 0x107C)
> +#define RST_DLY(n)		((0x4000 * (n)) + 0x19A4)
> +#define BYP_15(n)		((0x4000 * (n)) + 0x1038)
> +#define BYP_12(n)		((0x4000 * (n)) + 0x102C)
> +#define MISC3(n)		((0x4000 * (n)) + 0x19AC)
> +#define EQ11(n)			((0x4000 * (n)) + 0x1978)

Lower case hex value please

> +
> +static u32 save_reg_address[] = {
> +	/* Lane 0/1/2/3 Register */
> +	DIG_8(0), ILL13(0), DIG_10(0), RST_DLY(0), BYP_15(0), BYP_12(0), MISC3(0), EQ11(0),
> +	DIG_8(1), ILL13(1), DIG_10(1), RST_DLY(1), BYP_15(1), BYP_12(1), MISC3(1), EQ11(1),
> +	DIG_8(2), ILL13(2), DIG_10(2), RST_DLY(2), BYP_15(2), BYP_12(2), MISC3(2), EQ11(2),
> +	DIG_8(3), ILL13(3), DIG_10(3), RST_DLY(3), BYP_15(3), BYP_12(3), MISC3(3), EQ11(3),
> +};
> +
>  struct xpsgtr_dev;
>  
>  /**
> @@ -213,6 +231,7 @@ struct xpsgtr_phy {
>   * @tx_term_fix: fix for GT issue
>   * @saved_icm_cfg0: stored value of ICM CFG0 register
>   * @saved_icm_cfg1: stored value of ICM CFG1 register
> + * @saved_regs: registers to be saved/restored during suspend/resume
>   */
>  struct xpsgtr_dev {
>  	struct device *dev;
> @@ -225,6 +244,7 @@ struct xpsgtr_dev {
>  	bool tx_term_fix;
>  	unsigned int saved_icm_cfg0;
>  	unsigned int saved_icm_cfg1;
> +	u32 *saved_regs;
>  };
>  
>  /*
> @@ -298,6 +318,32 @@ static inline void xpsgtr_clr_set_phy(struct xpsgtr_phy *gtr_phy,
>  	writel((readl(addr) & ~clr) | set, addr);
>  }
>  
> +/**
> + * xpsgtr_save_lane_regs - Saves registers on suspend
> + * @gtr_dev: pointer to phy controller context structure
> + */
> +static void xpsgtr_save_lane_regs(struct xpsgtr_dev *gtr_dev)
> +{
> +	int i;
> +
> +	for (i = 0; i < ARRAY_SIZE(save_reg_address); i++)
> +		gtr_dev->saved_regs[i] = xpsgtr_read(gtr_dev,
> +						     save_reg_address[i]);
> +}
> +
> +/**
> + * xpsgtr_restore_lane_regs - Restores registers on resume
> + * @gtr_dev: pointer to phy controller context structure
> + */
> +static void xpsgtr_restore_lane_regs(struct xpsgtr_dev *gtr_dev)
> +{
> +	int i;
> +
> +	for (i = 0; i < ARRAY_SIZE(save_reg_address); i++)
> +		xpsgtr_write(gtr_dev, save_reg_address[i],
> +			     gtr_dev->saved_regs[i]);
> +}
> +
>  /*
>   * Hardware Configuration
>   */
> @@ -837,6 +883,8 @@ static int xpsgtr_runtime_suspend(struct device *dev)
>  	gtr_dev->saved_icm_cfg0 = xpsgtr_read(gtr_dev, ICM_CFG0);
>  	gtr_dev->saved_icm_cfg1 = xpsgtr_read(gtr_dev, ICM_CFG1);
>  
> +	xpsgtr_save_lane_regs(gtr_dev);
> +
>  	return 0;
>  }
>  
> @@ -847,6 +895,8 @@ static int xpsgtr_runtime_resume(struct device *dev)
>  	unsigned int i;
>  	bool skip_phy_init;
>  
> +	xpsgtr_restore_lane_regs(gtr_dev);
> +
>  	icm_cfg0 = xpsgtr_read(gtr_dev, ICM_CFG0);
>  	icm_cfg1 = xpsgtr_read(gtr_dev, ICM_CFG1);
>  
> @@ -992,6 +1042,12 @@ static int xpsgtr_probe(struct platform_device *pdev)
>  		return ret;
>  	}
>  
> +	gtr_dev->saved_regs = devm_kmalloc(gtr_dev->dev,
> +					   sizeof(save_reg_address),
> +					   GFP_KERNEL);
> +	if (!gtr_dev->saved_regs)
> +		return -ENOMEM;
> +
>  	return 0;
>  }
>  
> 
> base-commit: d67978318827d06f1c0fa4c31343a279e9df6fde
> -- 
> 2.34.1

-- 
~Vinod


From vkoul at kernel.org  Sun Aug  4 10:31:25 2024
From: vkoul at kernel.org (Vinod Koul)
Date: Sun, 4 Aug 2024 23:01:25 +0530
Subject: [PATCH] phy: airoha: adjust initialization delay in
 airoha_pcie_phy_init()
In-Reply-To: <82e50875deba44e34f49bd92578b4dc24f121b01.1720508349.git.lorenzo@kernel.org>
References: <82e50875deba44e34f49bd92578b4dc24f121b01.1720508349.git.lorenzo@kernel.org>
Message-ID: <Zq-67ZnlmMLh_Ssz@matsya>

On 09-07-24, 09:03, Lorenzo Bianconi wrote:
> Align phy-pcie initialization delay to the vendor sdk in
> airoha_pcie_phy_init routine and allow the hw to complete required
> configuration before proceeding
> 
> Signed-off-by: Lorenzo Bianconi <lorenzo at kernel.org>
> ---
>  drivers/phy/phy-airoha-pcie.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/phy/phy-airoha-pcie.c b/drivers/phy/phy-airoha-pcie.c
> index bd3edaa986c8..445bacfdaaf4 100644
> --- a/drivers/phy/phy-airoha-pcie.c
> +++ b/drivers/phy/phy-airoha-pcie.c
> @@ -18,6 +18,9 @@
>  #define LEQ_LEN_CTRL_MAX_VAL	7
>  #define FREQ_LOCK_MAX_ATTEMPT	10
>  
> +/* PCIe-PHY initialization time in ms needed by the hw to complete */
> +#define PHY_HW_INIT_TIME_MS	30
> +
>  enum airoha_pcie_port_gen {
>  	PCIE_PORT_GEN1 = 1,
>  	PCIE_PORT_GEN2,
> @@ -1180,8 +1183,11 @@ static int airoha_pcie_phy_init(struct phy *phy)
>  				 PCIE_DA_XPON_CDR_PR_PWDB);
>  	airoha_phy_pma1_set_bits(pcie_phy, REG_PCIE_PMA_SS_DA_XPON_PWDB0,
>  				 PCIE_DA_XPON_CDR_PR_PWDB);
> -
> -	usleep_range(100, 200);
> +	/*
> +	 * Wait for the time in ms needed by the hw to complete the PCIe-PHY
> +	 * initialization
> +	 */
> +	mdelay(PHY_HW_INIT_TIME_MS);

Why not use msleep()...?

-- 
~Vinod


From vkoul at kernel.org  Sun Aug  4 10:48:45 2024
From: vkoul at kernel.org (Vinod Koul)
Date: Sun, 4 Aug 2024 23:18:45 +0530
Subject: [PATCH] phy: mvebu-cp110-utmi: support swapping d+/d- lanes by
 dts property
In-Reply-To: <20240704-mvebu-utmi-phy-v1-1-9d3c8eea46e5@solid-run.com>
References: <20240704-mvebu-utmi-phy-v1-1-9d3c8eea46e5@solid-run.com>
Message-ID: <Zq--_WIgaPXPiYRQ@matsya>

On 04-07-24, 16:57, Josua Mayer wrote:
> CP11x UTMI PHY supports swapping D+/D- signals via digital control
> register 1.
> 
> Add support for the "swap-dx-lanes" device-tree property, which lists
> the port-ids that should swap D+ and D-.
> The property is evaluated in probe and applied before power-on
> during mvebu_cp110_utmi_port_setup.

It fails my build tests

drivers/phy/marvell/phy-mvebu-cp110-utmi.c:
In function ?mvebu_cp110_utmi_phy_probe?:
drivers/phy/marvell/phy-mvebu-cp110-utmi.c:361:89:
error: macro "of_property_for_each_u32" passed 5 arguments, but takes
just 3
  361 |                 of_property_for_each_u32(dev->of_node,
"swap-dx-lanes", prop, p, swap_dx)
      |
^
In file included from
drivers/phy/marvell/phy-mvebu-cp110-utmi.c:15:
include/linux/of.h:1432: note:
macro "of_property_for_each_u32" defined here
 1432 | #define of_property_for_each_u32(np, propname, u)
\
      | 
drivers/phy/marvell/phy-mvebu-cp110-utmi.c:361:17:
error: ?of_property_for_each_u32? undeclared (first use in this
function); did you mean ?of_property_read_u32??
  361 |                 of_property_for_each_u32(dev->of_node,
"swap-dx-lanes", prop, p, swap_dx)
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~
      |                 of_property_read_u32
drivers/phy/marvell/phy-mvebu-cp110-utmi.c:361:17:
note: each undeclared identifier is reported only once for each function
it appears in
drivers/phy/marvell/phy-mvebu-cp110-utmi.c:361:41:
error: expected ?;? before ?if?
  361 |                 of_property_for_each_u32(dev->of_node,
"swap-dx-lanes", prop, p, swap_dx)
      |                                         ^
      |                                         ;
  362 |                         if (swap_dx == port_id)
      |                         ~~               
drivers/phy/marvell/phy-mvebu-cp110-utmi.c:301:13:
error: unused variable ?swap_dx? [-Werror=unused-variable]
  301 |         u32 swap_dx = 0;
      |             ^~~~~~~
drivers/phy/marvell/phy-mvebu-cp110-utmi.c:299:23:
error: unused variable ?p? [-Werror=unused-variable]
  299 |         const __be32 *p;
      |                       ^
drivers/phy/marvell/phy-mvebu-cp110-utmi.c:298:26:
error: unused variable ?prop? [-Werror=unused-variable]
  298 |         struct property *prop;
      |                          ^~~~
cc1: all warnings being treated as errors


> 
> Signed-off-by: Josua Mayer <josua at solid-run.com>
> ---
>  drivers/phy/marvell/phy-mvebu-cp110-utmi.c | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/drivers/phy/marvell/phy-mvebu-cp110-utmi.c b/drivers/phy/marvell/phy-mvebu-cp110-utmi.c
> index 4922a5f3327d..5e403f842e9a 100644
> --- a/drivers/phy/marvell/phy-mvebu-cp110-utmi.c
> +++ b/drivers/phy/marvell/phy-mvebu-cp110-utmi.c
> @@ -62,6 +62,8 @@
>  #define   SQ_AMP_CAL_MASK			GENMASK(2, 0)
>  #define   SQ_AMP_CAL_VAL			1
>  #define   SQ_AMP_CAL_EN				BIT(3)
> +#define UTMI_DIG_CTRL1_REG			0x20
> +#define   SWAP_DPDM				BIT(15)
>  #define UTMI_CTRL_STATUS0_REG			0x24
>  #define   SUSPENDM				BIT(22)
>  #define   TEST_SEL				BIT(25)
> @@ -104,6 +106,7 @@ struct mvebu_cp110_utmi_port {
>  	struct mvebu_cp110_utmi *priv;
>  	u32 id;
>  	enum usb_dr_mode dr_mode;
> +	bool swap_dx;
>  };
>  
>  static void mvebu_cp110_utmi_port_setup(struct mvebu_cp110_utmi_port *port)
> @@ -159,6 +162,13 @@ static void mvebu_cp110_utmi_port_setup(struct mvebu_cp110_utmi_port *port)
>  	reg &= ~(VDAT_MASK | VSRC_MASK);
>  	reg |= (VDAT_VAL << VDAT_OFFSET) | (VSRC_VAL << VSRC_OFFSET);
>  	writel(reg, PORT_REGS(port) + UTMI_CHGDTC_CTRL_REG);
> +
> +	/* Swap D+/D- */
> +	reg = readl(PORT_REGS(port) + UTMI_DIG_CTRL1_REG);
> +	reg &= ~(SWAP_DPDM);
> +	if (port->swap_dx)
> +		reg |= SWAP_DPDM;
> +	writel(reg, PORT_REGS(port) + UTMI_DIG_CTRL1_REG);
>  }
>  
>  static int mvebu_cp110_utmi_phy_power_off(struct phy *phy)
> @@ -285,7 +295,10 @@ static int mvebu_cp110_utmi_phy_probe(struct platform_device *pdev)
>  	struct mvebu_cp110_utmi *utmi;
>  	struct phy_provider *provider;
>  	struct device_node *child;
> +	struct property *prop;
> +	const __be32 *p;
>  	u32 usb_devices = 0;
> +	u32 swap_dx = 0;
>  
>  	utmi = devm_kzalloc(dev, sizeof(*utmi), GFP_KERNEL);
>  	if (!utmi)
> @@ -345,6 +358,10 @@ static int mvebu_cp110_utmi_phy_probe(struct platform_device *pdev)
>  			}
>  		}
>  
> +		of_property_for_each_u32(dev->of_node, "swap-dx-lanes", prop, p, swap_dx)
> +			if (swap_dx == port_id)
> +				port->swap_dx = 1;
> +
>  		/* Retrieve PHY capabilities */
>  		utmi->ops = &mvebu_cp110_utmi_phy_ops;
>  
> 
> ---
> base-commit: 4de480264948cbf2b08a72c39ee122a9f9761e03
> change-id: 20240704-mvebu-utmi-phy-84aa3bf3957d
> 
> Sincerely,
> -- 
> Josua Mayer <josua at solid-run.com>

-- 
~Vinod


From vkoul at kernel.org  Sun Aug  4 10:51:41 2024
From: vkoul at kernel.org (Vinod Koul)
Date: Sun, 04 Aug 2024 23:21:41 +0530
Subject: [PATCH v1] phy: marvell: phy-mvebu-cp110-comphy: improve
 eth_port1 on comphy4
In-Reply-To: <20240711131612.98952-1-eichest@gmail.com>
References: <20240711131612.98952-1-eichest@gmail.com>
Message-ID: <172279390156.406109.13116235675996046154.b4-ty@kernel.org>


On Thu, 11 Jul 2024 15:12:47 +0200, Stefan Eichenberger wrote:
> According to the CN9100_MPP_information document, CP_SRD4 (comphy 4)
> supports 2500 BASE-X and 5000 BASE-R for ETH_PORT1. I was able to test
> that 2500 BASE-X is indeed supported. Unfortunately, our HW does not
> support 5000 BASE-R, but I assume from the document that it does, so I
> set the muxing there too to 0x1.
> 
> 
> [...]

Applied, thanks!

[1/1] phy: marvell: phy-mvebu-cp110-comphy: improve eth_port1 on comphy4
      commit: 8c9f085ae3384c5dfc0bc5f2f785b7adbf7d756b

Best regards,
-- 
Vinod Koul <vkoul at kernel.org>



From vkoul at kernel.org  Sun Aug  4 10:51:44 2024
From: vkoul at kernel.org (Vinod Koul)
Date: Sun, 04 Aug 2024 23:21:44 +0530
Subject: [PATCH] phy: ti: phy-j721e-wiz: convert comma to semicolon
In-Reply-To: <20240710031626.2003110-1-nichen@iscas.ac.cn>
References: <20240710031626.2003110-1-nichen@iscas.ac.cn>
Message-ID: <172279390484.406109.8757122625415415901.b4-ty@kernel.org>


On Wed, 10 Jul 2024 11:16:26 +0800, Chen Ni wrote:
> Replace a comma between expression statements by a semicolon.
> 
> 

Applied, thanks!

[1/1] phy: ti: phy-j721e-wiz: convert comma to semicolon
      commit: 0f20e326e723075f98456bacf8de475421f68be6

Best regards,
-- 
Vinod Koul <vkoul at kernel.org>



From vkoul at kernel.org  Sun Aug  4 10:51:47 2024
From: vkoul at kernel.org (Vinod Koul)
Date: Sun, 04 Aug 2024 23:21:47 +0530
Subject: [PATCH] dt-bindings: phy: hisilicon,hi3798cv200-combphy:
 Convert to DT schema
In-Reply-To: <20240703215905.2031038-1-robh@kernel.org>
References: <20240703215905.2031038-1-robh@kernel.org>
Message-ID: <172279390783.406109.10208814683830391737.b4-ty@kernel.org>


On Wed, 03 Jul 2024 15:59:04 -0600, Rob Herring (Arm) wrote:
> Convert the hisilicon,hi3798cv200-combphy binding to DT schema format.
> 
> Drop the example as arm/hisilicon/controller/hi3798cv200-perictrl.yaml
> already contains an example of this binding.
> 
> 

Applied, thanks!

[1/1] dt-bindings: phy: hisilicon,hi3798cv200-combphy: Convert to DT schema
      commit: dd1051f9329880a0749954e601a5ece9a07f8685

Best regards,
-- 
Vinod Koul <vkoul at kernel.org>



From vkoul at kernel.org  Sun Aug  4 10:51:58 2024
From: vkoul at kernel.org (Vinod Koul)
Date: Sun, 04 Aug 2024 23:21:58 +0530
Subject: [PATCH v2] phy: qcom: qmp-pcie: Fix X1E80100 PCIe Gen4 PHY
 initialisation
In-Reply-To: <20240801-x1e80100-phy-qmp-pcie-fix-config-v2-1-cdc0f22b4169@linaro.org>
References: <20240801-x1e80100-phy-qmp-pcie-fix-config-v2-1-cdc0f22b4169@linaro.org>
Message-ID: <172279391895.406224.15086845328782715859.b4-ty@kernel.org>


On Thu, 01 Aug 2024 13:40:24 +0300, Abel Vesa wrote:
> Update the PCIe Gen4 PHY init sequence with the latest based on internal
> Qualcomm documentation.
> 
> 

Applied, thanks!

[1/1] phy: qcom: qmp-pcie: Fix X1E80100 PCIe Gen4 PHY initialisation
      commit: 0e8a0504da59041e775a95db3ebc1a6211423593

Best regards,
-- 
Vinod Koul <vkoul at kernel.org>



From vkoul at kernel.org  Sun Aug  4 10:52:01 2024
From: vkoul at kernel.org (Vinod Koul)
Date: Sun, 04 Aug 2024 23:22:01 +0530
Subject: [PATCH v3] phy: fsl-imx8mq-usb: fix tuning parameter name
In-Reply-To: <20240801124642.1152838-1-xu.yang_2@nxp.com>
References: <20240801124642.1152838-1-xu.yang_2@nxp.com>
Message-ID: <172279392198.406224.16617087876410546053.b4-ty@kernel.org>


On Thu, 01 Aug 2024 20:46:42 +0800, Xu Yang wrote:
> According to fsl,imx8mq-usb-phy.yaml, this tuning parameter should be
> fsl,phy-pcs-tx-deemph-3p5db-attenuation-db.
> 
> 

Applied, thanks!

[1/1] phy: fsl-imx8mq-usb: fix tuning parameter name
      commit: ce52c2532299c7ccfd34a52db8d071e890a78c59

Best regards,
-- 
Vinod Koul <vkoul at kernel.org>



From vkoul at kernel.org  Sun Aug  4 10:52:06 2024
From: vkoul at kernel.org (Vinod Koul)
Date: Sun, 04 Aug 2024 23:22:06 +0530
Subject: [PATCH] phy: exynos5-usbdrd: fix error code in probe()
In-Reply-To: <a956a3e2-c6ce-4f07-ad80-ec8a96e00d16@stanley.mountain>
References: <a956a3e2-c6ce-4f07-ad80-ec8a96e00d16@stanley.mountain>
Message-ID: <172279392602.406224.4966447752583319349.b4-ty@kernel.org>


On Mon, 08 Jul 2024 12:04:33 -0500, Dan Carpenter wrote:
> Return negative -ENOMEM instead of positive ENOMEM.
> 
> 

Applied, thanks!

[1/1] phy: exynos5-usbdrd: fix error code in probe()
      commit: 3a07703a523045cbdb0a5fa5e0902a9145ee43e9

Best regards,
-- 
Vinod Koul <vkoul at kernel.org>



From virag.david003 at gmail.com  Sun Aug  4 14:53:45 2024
From: virag.david003 at gmail.com (David Virag)
Date: Sun,  4 Aug 2024 23:53:45 +0200
Subject: [PATCH 00/13] Add USB support to Exynos7885
Message-ID: <20240804215458.404085-1-virag.david003@gmail.com>

This set of patches adds support for USB on the Exynos7885 SoC.

The Exynos7885 has a DWC3 compatible USB controller and an Exynos USB
PHY that theoretically supports USB3 SuperSpeed, but is not implemented
in any known device. The vendor kernel also stubs out USB3 functions, so
we do not support it.

While at it, since we need some new clocks implemented, also fix some
issues with the existing clock driver/bindings.

p.s.: Not realizing the USB PLL has a MUX on it made me waste I don't
even want to know how much time on troubleshooting why it's not
working...

David Virag (13):
  dt-bindings: clock: exynos7885: Fix duplicated binding
  dt-bindings: clock: exynos7885: Add CMU_TOP PLL MUX indices
  dt-bindings: clock: exynos7885: Add indices for USB clocks
  dt-bindings: phy: samsung,usb3-drd-phy: Add Exynos7885 support
  dt-bindings: usb: samsung,exynos-dwc3: Add Exynos7885 support
  clk: samsung: exynos7885: Update CLKS_NR_FSYS after bindings fix
  clk: samsung: exynos7885: Add missing MUX clocks from PLLs in CMU_TOP
  clk: samsung: clk-pll: Add support for pll_1418x
  clk: samsung: exynos7885: Add USB related clocks to CMU_FSYS
  usb: dwc3: exynos: Add support for Exynos7885
  phy: exynos5-usbdrd: support Exynos7885 USB PHY
  arm64: dts: exynos: Enable USB in Exynos7885
  arm64: dts: exynos: exynos7885-jackpotlte: Enable USB support

 .../bindings/phy/samsung,usb3-drd-phy.yaml    |  2 +
 .../bindings/usb/samsung,exynos-dwc3.yaml     |  5 +-
 .../boot/dts/exynos/exynos7885-jackpotlte.dts | 20 ++++
 arch/arm64/boot/dts/exynos/exynos7885.dtsi    | 35 +++++++
 drivers/clk/samsung/clk-exynos7885.c          | 95 +++++++++++++++----
 drivers/clk/samsung/clk-pll.c                 | 20 +++-
 drivers/clk/samsung/clk-pll.h                 |  1 +
 drivers/phy/samsung/phy-exynos5-usbdrd.c      | 21 ++++
 drivers/usb/dwc3/dwc3-exynos.c                |  3 +
 include/dt-bindings/clock/exynos7885.h        | 32 ++++---
 include/linux/soc/samsung/exynos-regs-pmu.h   |  3 +
 11 files changed, 201 insertions(+), 36 deletions(-)

-- 
2.46.0



From virag.david003 at gmail.com  Sun Aug  4 14:53:46 2024
From: virag.david003 at gmail.com (David Virag)
Date: Sun,  4 Aug 2024 23:53:46 +0200
Subject: [PATCH 01/13] dt-bindings: clock: exynos7885: Fix duplicated binding
In-Reply-To: <20240804215458.404085-1-virag.david003@gmail.com>
References: <20240804215458.404085-1-virag.david003@gmail.com>
Message-ID: <20240804215458.404085-2-virag.david003@gmail.com>

The numbering in Exynos7885's FSYS CMU bindings has 4 duplicated by
accident, with the rest of the bindings continuing with 5.

Fix this by moving CLK_MOUT_FSYS_USB30DRD_USER to the end as 11.

Since CLK_MOUT_FSYS_USB30DRD_USER is not used in any device tree as of
now, and there are no other clocks affected (maybe apart from
CLK_MOUT_FSYS_MMC_SDIO_USER which the number was shared with, also not
used in a device tree), this is the least impactful way to solve this
problem.

Fixes: cd268e309c29 ("dt-bindings: clock: Add bindings for Exynos7885 CMU_FSYS")
Signed-off-by: David Virag <virag.david003 at gmail.com>
---
 include/dt-bindings/clock/exynos7885.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/dt-bindings/clock/exynos7885.h b/include/dt-bindings/clock/exynos7885.h
index 255e3aa94323..54cfccff8508 100644
--- a/include/dt-bindings/clock/exynos7885.h
+++ b/include/dt-bindings/clock/exynos7885.h
@@ -136,12 +136,12 @@
 #define CLK_MOUT_FSYS_MMC_CARD_USER	2
 #define CLK_MOUT_FSYS_MMC_EMBD_USER	3
 #define CLK_MOUT_FSYS_MMC_SDIO_USER	4
-#define CLK_MOUT_FSYS_USB30DRD_USER	4
 #define CLK_GOUT_MMC_CARD_ACLK		5
 #define CLK_GOUT_MMC_CARD_SDCLKIN	6
 #define CLK_GOUT_MMC_EMBD_ACLK		7
 #define CLK_GOUT_MMC_EMBD_SDCLKIN	8
 #define CLK_GOUT_MMC_SDIO_ACLK		9
 #define CLK_GOUT_MMC_SDIO_SDCLKIN	10
+#define CLK_MOUT_FSYS_USB30DRD_USER	11
 
 #endif /* _DT_BINDINGS_CLOCK_EXYNOS_7885_H */
-- 
2.46.0



From virag.david003 at gmail.com  Sun Aug  4 14:53:47 2024
From: virag.david003 at gmail.com (David Virag)
Date: Sun,  4 Aug 2024 23:53:47 +0200
Subject: [PATCH 02/13] dt-bindings: clock: exynos7885: Add CMU_TOP PLL MUX indices
In-Reply-To: <20240804215458.404085-1-virag.david003@gmail.com>
References: <20240804215458.404085-1-virag.david003@gmail.com>
Message-ID: <20240804215458.404085-3-virag.david003@gmail.com>

Add indices for missing MUX clocks from PLLs in CMU_TOP.

Signed-off-by: David Virag <virag.david003 at gmail.com>
---
 include/dt-bindings/clock/exynos7885.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/dt-bindings/clock/exynos7885.h b/include/dt-bindings/clock/exynos7885.h
index 54cfccff8508..4ce86810b10d 100644
--- a/include/dt-bindings/clock/exynos7885.h
+++ b/include/dt-bindings/clock/exynos7885.h
@@ -69,6 +69,8 @@
 #define CLK_GOUT_FSYS_MMC_EMBD		58
 #define CLK_GOUT_FSYS_MMC_SDIO		59
 #define CLK_GOUT_FSYS_USB30DRD		60
+#define CLK_MOUT_SHARED0_PLL		61
+#define CLK_MOUT_SHARED1_PLL		62
 
 /* CMU_CORE */
 #define CLK_MOUT_CORE_BUS_USER			1
-- 
2.46.0



From virag.david003 at gmail.com  Sun Aug  4 14:53:48 2024
From: virag.david003 at gmail.com (David Virag)
Date: Sun,  4 Aug 2024 23:53:48 +0200
Subject: [PATCH 03/13] dt-bindings: clock: exynos7885: Add indices for USB clocks
In-Reply-To: <20240804215458.404085-1-virag.david003@gmail.com>
References: <20240804215458.404085-1-virag.david003@gmail.com>
Message-ID: <20240804215458.404085-4-virag.david003@gmail.com>

Exynos7885 SoC has a DWC3 USB Controller with Exynos USB PHY which in
theory supports USB3 SuperSpeed, but is only used as USB2 in all known
devices.

These, of course, need some clocks.
Add indices for these clocks.

Signed-off-by: David Virag <virag.david003 at gmail.com>
---
 include/dt-bindings/clock/exynos7885.h | 30 ++++++++++++++++----------
 1 file changed, 19 insertions(+), 11 deletions(-)

diff --git a/include/dt-bindings/clock/exynos7885.h b/include/dt-bindings/clock/exynos7885.h
index 4ce86810b10d..cfede84b46b9 100644
--- a/include/dt-bindings/clock/exynos7885.h
+++ b/include/dt-bindings/clock/exynos7885.h
@@ -134,16 +134,24 @@
 #define CLK_GOUT_WDT1_PCLK		43
 
 /* CMU_FSYS */
-#define CLK_MOUT_FSYS_BUS_USER		1
-#define CLK_MOUT_FSYS_MMC_CARD_USER	2
-#define CLK_MOUT_FSYS_MMC_EMBD_USER	3
-#define CLK_MOUT_FSYS_MMC_SDIO_USER	4
-#define CLK_GOUT_MMC_CARD_ACLK		5
-#define CLK_GOUT_MMC_CARD_SDCLKIN	6
-#define CLK_GOUT_MMC_EMBD_ACLK		7
-#define CLK_GOUT_MMC_EMBD_SDCLKIN	8
-#define CLK_GOUT_MMC_SDIO_ACLK		9
-#define CLK_GOUT_MMC_SDIO_SDCLKIN	10
-#define CLK_MOUT_FSYS_USB30DRD_USER	11
+#define CLK_MOUT_FSYS_BUS_USER			1
+#define CLK_MOUT_FSYS_MMC_CARD_USER		2
+#define CLK_MOUT_FSYS_MMC_EMBD_USER		3
+#define CLK_MOUT_FSYS_MMC_SDIO_USER		4
+#define CLK_GOUT_MMC_CARD_ACLK			5
+#define CLK_GOUT_MMC_CARD_SDCLKIN		6
+#define CLK_GOUT_MMC_EMBD_ACLK			7
+#define CLK_GOUT_MMC_EMBD_SDCLKIN		8
+#define CLK_GOUT_MMC_SDIO_ACLK			9
+#define CLK_GOUT_MMC_SDIO_SDCLKIN		10
+#define CLK_MOUT_FSYS_USB30DRD_USER		11
+#define CLK_MOUT_USB_PLL			12
+#define CLK_FOUT_USB_PLL			13
+#define CLK_FSYS_USB20PHY_CLKCORE		14
+#define CLK_FSYS_USB30DRD_ACLK_20PHYCTRL	15
+#define CLK_FSYS_USB30DRD_ACLK_30PHYCTRL_0	16
+#define CLK_FSYS_USB30DRD_ACLK_30PHYCTRL_1	17
+#define CLK_FSYS_USB30DRD_BUS_CLK_EARLY		18
+#define CLK_FSYS_USB30DRD_REF_CLK		19
 
 #endif /* _DT_BINDINGS_CLOCK_EXYNOS_7885_H */
-- 
2.46.0



From virag.david003 at gmail.com  Sun Aug  4 14:53:49 2024
From: virag.david003 at gmail.com (David Virag)
Date: Sun,  4 Aug 2024 23:53:49 +0200
Subject: [PATCH 04/13] dt-bindings: phy: samsung,usb3-drd-phy: Add Exynos7885 support
In-Reply-To: <20240804215458.404085-1-virag.david003@gmail.com>
References: <20240804215458.404085-1-virag.david003@gmail.com>
Message-ID: <20240804215458.404085-5-virag.david003@gmail.com>

Document Exynos7885 compatible.
Exynos7885 USB PHY has two clocks (ref and phy) like Exynos850, which
are already described in bindings.

Signed-off-by: David Virag <virag.david003 at gmail.com>
---
 Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml
index 16321cdd4919..bf993d738bce 100644
--- a/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml
@@ -30,6 +30,7 @@ properties:
       - samsung,exynos5420-usbdrd-phy
       - samsung,exynos5433-usbdrd-phy
       - samsung,exynos7-usbdrd-phy
+      - samsung,exynos7885-usbdrd-phy
       - samsung,exynos850-usbdrd-phy
 
   clocks:
@@ -168,6 +169,7 @@ allOf:
             enum:
               - samsung,exynos5250-usbdrd-phy
               - samsung,exynos5420-usbdrd-phy
+              - samsung,exynos7885-usbdrd-phy
               - samsung,exynos850-usbdrd-phy
     then:
       properties:
-- 
2.46.0



From virag.david003 at gmail.com  Sun Aug  4 14:53:50 2024
From: virag.david003 at gmail.com (David Virag)
Date: Sun,  4 Aug 2024 23:53:50 +0200
Subject: [PATCH 05/13] dt-bindings: usb: samsung,exynos-dwc3: Add Exynos7885 support
In-Reply-To: <20240804215458.404085-1-virag.david003@gmail.com>
References: <20240804215458.404085-1-virag.david003@gmail.com>
Message-ID: <20240804215458.404085-6-virag.david003@gmail.com>

Exynos7885 SoC has a DWC3 compatible USB controller, so it can reuse the
existing Exynos glue layer. Clocks are the same as on Exynos850.
Document Exynos7885 compatible.

Signed-off-by: David Virag <virag.david003 at gmail.com>
---
 .../devicetree/bindings/usb/samsung,exynos-dwc3.yaml         | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml b/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml
index 2b3430cebe99..3ec849ef4bdb 100644
--- a/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml
@@ -16,6 +16,7 @@ properties:
       - samsung,exynos5250-dwusb3
       - samsung,exynos5433-dwusb3
       - samsung,exynos7-dwusb3
+      - samsung,exynos7885-dwusb3
       - samsung,exynos850-dwusb3
 
   '#address-cells':
@@ -124,7 +125,9 @@ allOf:
       properties:
         compatible:
           contains:
-            const: samsung,exynos850-dwusb3
+            enum:
+              - samsung,exynos7885-dwusb3
+              - samsung,exynos850-dwusb3
     then:
       properties:
         clocks:
-- 
2.46.0



From virag.david003 at gmail.com  Sun Aug  4 14:53:51 2024
From: virag.david003 at gmail.com (David Virag)
Date: Sun,  4 Aug 2024 23:53:51 +0200
Subject: [PATCH 06/13] clk: samsung: exynos7885: Update CLKS_NR_FSYS after bindings fix
In-Reply-To: <20240804215458.404085-1-virag.david003@gmail.com>
References: <20240804215458.404085-1-virag.david003@gmail.com>
Message-ID: <20240804215458.404085-7-virag.david003@gmail.com>

Update CLKS_NR_FSYS to the proper value after a fix in DT bindings.
This should always be the last clock in a CMU + 1.

Signed-off-by: David Virag <virag.david003 at gmail.com>
---
 drivers/clk/samsung/clk-exynos7885.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/samsung/clk-exynos7885.c b/drivers/clk/samsung/clk-exynos7885.c
index f7d7427a558b..87387d4cbf48 100644
--- a/drivers/clk/samsung/clk-exynos7885.c
+++ b/drivers/clk/samsung/clk-exynos7885.c
@@ -20,7 +20,7 @@
 #define CLKS_NR_TOP			(CLK_GOUT_FSYS_USB30DRD + 1)
 #define CLKS_NR_CORE			(CLK_GOUT_TREX_P_CORE_PCLK_P_CORE + 1)
 #define CLKS_NR_PERI			(CLK_GOUT_WDT1_PCLK + 1)
-#define CLKS_NR_FSYS			(CLK_GOUT_MMC_SDIO_SDCLKIN + 1)
+#define CLKS_NR_FSYS			(CLK_MOUT_FSYS_USB30DRD_USER + 1)
 
 /* ---- CMU_TOP ------------------------------------------------------------- */
 
-- 
2.46.0



From virag.david003 at gmail.com  Sun Aug  4 14:53:52 2024
From: virag.david003 at gmail.com (David Virag)
Date: Sun,  4 Aug 2024 23:53:52 +0200
Subject: [PATCH 07/13] clk: samsung: exynos7885: Add missing MUX clocks from PLLs in CMU_TOP
In-Reply-To: <20240804215458.404085-1-virag.david003@gmail.com>
References: <20240804215458.404085-1-virag.david003@gmail.com>
Message-ID: <20240804215458.404085-8-virag.david003@gmail.com>

In Exynos7885 (and seemingly all modern Exynos SoCs) all PLLs have a MUX
attached to them controlled by bit 4 in the PLL's CON0 register.

These MUXes can select between OSCCLK or the PLL's output, essentially
making the PLL bypassable.

These weren't modeled in the driver because the vendor provided drivers
didn't model it properly, instead setting them when updating the PMS
values.

Not having them modeled didn't cause any problems in this case, since
these MUXes were set to the PLL's output by default, but this is not the
case everywhere in this SoC.

Signed-off-by: David Virag <virag.david003 at gmail.com>
---
 drivers/clk/samsung/clk-exynos7885.c | 22 ++++++++++++++++------
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos7885.c b/drivers/clk/samsung/clk-exynos7885.c
index 87387d4cbf48..a0c9b7cc6942 100644
--- a/drivers/clk/samsung/clk-exynos7885.c
+++ b/drivers/clk/samsung/clk-exynos7885.c
@@ -17,7 +17,7 @@
 #include "clk-exynos-arm64.h"
 
 /* NOTE: Must be equal to the last clock ID increased by one */
-#define CLKS_NR_TOP			(CLK_GOUT_FSYS_USB30DRD + 1)
+#define CLKS_NR_TOP			(CLK_MOUT_SHARED1_PLL + 1)
 #define CLKS_NR_CORE			(CLK_GOUT_TREX_P_CORE_PCLK_P_CORE + 1)
 #define CLKS_NR_PERI			(CLK_GOUT_WDT1_PCLK + 1)
 #define CLKS_NR_FSYS			(CLK_MOUT_FSYS_USB30DRD_USER + 1)
@@ -162,6 +162,10 @@ static const struct samsung_pll_clock top_pll_clks[] __initconst = {
 	    NULL),
 };
 
+/* List of parent clocks for Muxes in CMU_TOP */
+PNAME(mout_shared0_pll_p)	= { "oscclk", "fout_shared0_pll" };
+PNAME(mout_shared1_pll_p)	= { "oscclk", "fout_shared1_pll" };
+
 /* List of parent clocks for Muxes in CMU_TOP: for CMU_CORE */
 PNAME(mout_core_bus_p)		= { "dout_shared0_div2", "dout_shared1_div2",
 				    "dout_shared0_div3", "dout_shared0_div3" };
@@ -189,6 +193,12 @@ PNAME(mout_fsys_mmc_sdio_p)	= { "dout_shared0_div2", "dout_shared1_div2" };
 PNAME(mout_fsys_usb30drd_p)	= { "dout_shared0_div4", "dout_shared1_div4" };
 
 static const struct samsung_mux_clock top_mux_clks[] __initconst = {
+	/* TOP */
+	MUX(CLK_MOUT_SHARED0_PLL, "mout_shared0_pll", mout_shared0_pll_p,
+	    PLL_CON0_PLL_SHARED0, 4, 1),
+	MUX(CLK_MOUT_SHARED1_PLL, "mout_shared1_pll", mout_shared1_pll_p,
+	    PLL_CON0_PLL_SHARED1, 4, 1),
+
 	/* CORE */
 	MUX(CLK_MOUT_CORE_BUS, "mout_core_bus", mout_core_bus_p,
 	    CLK_CON_MUX_MUX_CLKCMU_CORE_BUS, 0, 2),
@@ -232,17 +242,17 @@ static const struct samsung_mux_clock top_mux_clks[] __initconst = {
 
 static const struct samsung_div_clock top_div_clks[] __initconst = {
 	/* TOP */
-	DIV(CLK_DOUT_SHARED0_DIV2, "dout_shared0_div2", "fout_shared0_pll",
+	DIV(CLK_DOUT_SHARED0_DIV2, "dout_shared0_div2", "mout_shared0_pll",
 	    CLK_CON_DIV_PLL_SHARED0_DIV2, 0, 1),
-	DIV(CLK_DOUT_SHARED0_DIV3, "dout_shared0_div3", "fout_shared0_pll",
+	DIV(CLK_DOUT_SHARED0_DIV3, "dout_shared0_div3", "mout_shared0_pll",
 	    CLK_CON_DIV_PLL_SHARED0_DIV3, 0, 2),
 	DIV(CLK_DOUT_SHARED0_DIV4, "dout_shared0_div4", "dout_shared0_div2",
 	    CLK_CON_DIV_PLL_SHARED0_DIV4, 0, 1),
-	DIV(CLK_DOUT_SHARED0_DIV5, "dout_shared0_div5", "fout_shared0_pll",
+	DIV(CLK_DOUT_SHARED0_DIV5, "dout_shared0_div5", "mout_shared0_pll",
 	    CLK_CON_DIV_PLL_SHARED0_DIV5, 0, 3),
-	DIV(CLK_DOUT_SHARED1_DIV2, "dout_shared1_div2", "fout_shared1_pll",
+	DIV(CLK_DOUT_SHARED1_DIV2, "dout_shared1_div2", "mout_shared1_pll",
 	    CLK_CON_DIV_PLL_SHARED1_DIV2, 0, 1),
-	DIV(CLK_DOUT_SHARED1_DIV3, "dout_shared1_div3", "fout_shared1_pll",
+	DIV(CLK_DOUT_SHARED1_DIV3, "dout_shared1_div3", "mout_shared1_pll",
 	    CLK_CON_DIV_PLL_SHARED1_DIV3, 0, 2),
 	DIV(CLK_DOUT_SHARED1_DIV4, "dout_shared1_div4", "dout_shared1_div2",
 	    CLK_CON_DIV_PLL_SHARED1_DIV4, 0, 1),
-- 
2.46.0



From virag.david003 at gmail.com  Sun Aug  4 14:53:53 2024
From: virag.david003 at gmail.com (David Virag)
Date: Sun,  4 Aug 2024 23:53:53 +0200
Subject: [PATCH 08/13] clk: samsung: clk-pll: Add support for pll_1418x
In-Reply-To: <20240804215458.404085-1-virag.david003@gmail.com>
References: <20240804215458.404085-1-virag.david003@gmail.com>
Message-ID: <20240804215458.404085-9-virag.david003@gmail.com>

pll1418x is used in Exynos7885 SoC for USB PHY clock.
Operation-wise it is very similar to pll0822x, except that MDIV is only
9 bits wide instead of 10, and we use the CON1 register in the PLL
macro's "con" parameter instead of CON3 like this:

	PLL(pll_1418x, CLK_FOUT_USB_PLL, "fout_usb_pll", "oscclk",
	    PLL_LOCKTIME_PLL_USB, PLL_CON0_PLL_USB,
	    pll_usb_rate_table),

Technically the PLL should work fine with pll0822x code if the PLL
tables are correct, but it's more "correct" to actually update the mask.

Signed-off-by: David Virag <virag.david003 at gmail.com>
---
 drivers/clk/samsung/clk-pll.c | 20 ++++++++++++++++----
 drivers/clk/samsung/clk-pll.h |  1 +
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
index 4be879ab917e..c61a2810737c 100644
--- a/drivers/clk/samsung/clk-pll.c
+++ b/drivers/clk/samsung/clk-pll.c
@@ -430,6 +430,9 @@ static const struct clk_ops samsung_pll36xx_clk_min_ops = {
 #define PLL0822X_LOCK_STAT_SHIFT	(29)
 #define PLL0822X_ENABLE_SHIFT		(31)
 
+/* PLL1418x is similar to PLL0822x, except that MDIV is one bit smaller */
+#define PLL1418X_MDIV_MASK		(0x1FF)
+
 static unsigned long samsung_pll0822x_recalc_rate(struct clk_hw *hw,
 						  unsigned long parent_rate)
 {
@@ -438,7 +441,10 @@ static unsigned long samsung_pll0822x_recalc_rate(struct clk_hw *hw,
 	u64 fvco = parent_rate;
 
 	pll_con3 = readl_relaxed(pll->con_reg);
-	mdiv = (pll_con3 >> PLL0822X_MDIV_SHIFT) & PLL0822X_MDIV_MASK;
+	if (pll->type != pll_1418x)
+		mdiv = (pll_con3 >> PLL0822X_MDIV_SHIFT) & PLL0822X_MDIV_MASK;
+	else
+		mdiv = (pll_con3 >> PLL0822X_MDIV_SHIFT) & PLL1418X_MDIV_MASK;
 	pdiv = (pll_con3 >> PLL0822X_PDIV_SHIFT) & PLL0822X_PDIV_MASK;
 	sdiv = (pll_con3 >> PLL0822X_SDIV_SHIFT) & PLL0822X_SDIV_MASK;
 
@@ -468,9 +474,14 @@ static int samsung_pll0822x_set_rate(struct clk_hw *hw, unsigned long drate,
 
 	/* Change PLL PMS values */
 	pll_con3 = readl_relaxed(pll->con_reg);
-	pll_con3 &= ~((PLL0822X_MDIV_MASK << PLL0822X_MDIV_SHIFT) |
-			(PLL0822X_PDIV_MASK << PLL0822X_PDIV_SHIFT) |
-			(PLL0822X_SDIV_MASK << PLL0822X_SDIV_SHIFT));
+	if (pll->type != pll_1418x)
+		pll_con3 &= ~((PLL0822X_MDIV_MASK << PLL0822X_MDIV_SHIFT) |
+				(PLL0822X_PDIV_MASK << PLL0822X_PDIV_SHIFT) |
+				(PLL0822X_SDIV_MASK << PLL0822X_SDIV_SHIFT));
+	else
+		pll_con3 &= ~((PLL1418X_MDIV_MASK << PLL0822X_MDIV_SHIFT) |
+				(PLL0822X_PDIV_MASK << PLL0822X_PDIV_SHIFT) |
+				(PLL0822X_SDIV_MASK << PLL0822X_SDIV_SHIFT));
 	pll_con3 |= (rate->mdiv << PLL0822X_MDIV_SHIFT) |
 			(rate->pdiv << PLL0822X_PDIV_SHIFT) |
 			(rate->sdiv << PLL0822X_SDIV_SHIFT);
@@ -1317,6 +1328,7 @@ static void __init _samsung_clk_register_pll(struct samsung_clk_provider *ctx,
 			init.ops = &samsung_pll35xx_clk_ops;
 		break;
 	case pll_1417x:
+	case pll_1418x:
 	case pll_0818x:
 	case pll_0822x:
 	case pll_0516x:
diff --git a/drivers/clk/samsung/clk-pll.h b/drivers/clk/samsung/clk-pll.h
index ffd3d52c0dec..1efbe4c446d0 100644
--- a/drivers/clk/samsung/clk-pll.h
+++ b/drivers/clk/samsung/clk-pll.h
@@ -30,6 +30,7 @@ enum samsung_pll_type {
 	pll_2650x,
 	pll_2650xx,
 	pll_1417x,
+	pll_1418x,
 	pll_1450x,
 	pll_1451x,
 	pll_1452x,
-- 
2.46.0



From virag.david003 at gmail.com  Sun Aug  4 14:53:54 2024
From: virag.david003 at gmail.com (David Virag)
Date: Sun,  4 Aug 2024 23:53:54 +0200
Subject: [PATCH 09/13] clk: samsung: exynos7885: Add USB related clocks to CMU_FSYS
In-Reply-To: <20240804215458.404085-1-virag.david003@gmail.com>
References: <20240804215458.404085-1-virag.david003@gmail.com>
Message-ID: <20240804215458.404085-10-virag.david003@gmail.com>

Exynos7885 SoC has a DWC3 USB Controller with Exynos USB PHY which in
theory supports USB3 SuperSpeed, but is only used as USB2 in all known
devices.

These clocks are needed for everything related to USB.

While at it, also remove the CLK_SET_RATE_PARENT capability of
CLK_MOUT_FSYS_USB30DRD_USER, since it's not actually needed.

Signed-off-by: David Virag <virag.david003 at gmail.com>
---
 drivers/clk/samsung/clk-exynos7885.c | 73 ++++++++++++++++++++++------
 1 file changed, 59 insertions(+), 14 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos7885.c b/drivers/clk/samsung/clk-exynos7885.c
index a0c9b7cc6942..637257a6f10e 100644
--- a/drivers/clk/samsung/clk-exynos7885.c
+++ b/drivers/clk/samsung/clk-exynos7885.c
@@ -20,7 +20,7 @@
 #define CLKS_NR_TOP			(CLK_MOUT_SHARED1_PLL + 1)
 #define CLKS_NR_CORE			(CLK_GOUT_TREX_P_CORE_PCLK_P_CORE + 1)
 #define CLKS_NR_PERI			(CLK_GOUT_WDT1_PCLK + 1)
-#define CLKS_NR_FSYS			(CLK_MOUT_FSYS_USB30DRD_USER + 1)
+#define CLKS_NR_FSYS			(CLK_FSYS_USB30DRD_REF_CLK + 1)
 
 /* ---- CMU_TOP ------------------------------------------------------------- */
 
@@ -686,38 +686,66 @@ static const struct samsung_cmu_info core_cmu_info __initconst = {
 /* ---- CMU_FSYS ------------------------------------------------------------ */
 
 /* Register Offset definitions for CMU_FSYS (0x13400000) */
-#define PLL_CON0_MUX_CLKCMU_FSYS_BUS_USER	0x0100
-#define PLL_CON0_MUX_CLKCMU_FSYS_MMC_CARD_USER	0x0120
-#define PLL_CON0_MUX_CLKCMU_FSYS_MMC_EMBD_USER	0x0140
-#define PLL_CON0_MUX_CLKCMU_FSYS_MMC_SDIO_USER	0x0160
-#define PLL_CON0_MUX_CLKCMU_FSYS_USB30DRD_USER	0x0180
-#define CLK_CON_GAT_GOUT_FSYS_MMC_CARD_I_ACLK	0x2030
-#define CLK_CON_GAT_GOUT_FSYS_MMC_CARD_SDCLKIN	0x2034
-#define CLK_CON_GAT_GOUT_FSYS_MMC_EMBD_I_ACLK	0x2038
-#define CLK_CON_GAT_GOUT_FSYS_MMC_EMBD_SDCLKIN	0x203c
-#define CLK_CON_GAT_GOUT_FSYS_MMC_SDIO_I_ACLK	0x2040
-#define CLK_CON_GAT_GOUT_FSYS_MMC_SDIO_SDCLKIN	0x2044
+#define PLL_LOCKTIME_PLL_USB				0x0000
+#define PLL_CON0_MUX_CLKCMU_FSYS_BUS_USER		0x0100
+#define PLL_CON0_MUX_CLKCMU_FSYS_MMC_CARD_USER		0x0120
+#define PLL_CON0_MUX_CLKCMU_FSYS_MMC_EMBD_USER		0x0140
+#define PLL_CON0_MUX_CLKCMU_FSYS_MMC_SDIO_USER		0x0160
+#define PLL_CON0_MUX_CLKCMU_FSYS_USB30DRD_USER		0x0180
+#define PLL_CON0_PLL_USB				0x01a0
+#define CLK_CON_GAT_CLK_FSYS_USB20PHY_CLKCORE		0x200c
+#define CLK_CON_GAT_GOUT_FSYS_MMC_CARD_I_ACLK		0x2030
+#define CLK_CON_GAT_GOUT_FSYS_MMC_CARD_SDCLKIN		0x2034
+#define CLK_CON_GAT_GOUT_FSYS_MMC_EMBD_I_ACLK		0x2038
+#define CLK_CON_GAT_GOUT_FSYS_MMC_EMBD_SDCLKIN		0x203c
+#define CLK_CON_GAT_GOUT_FSYS_MMC_SDIO_I_ACLK		0x2040
+#define CLK_CON_GAT_GOUT_FSYS_MMC_SDIO_SDCLKIN		0x2044
+#define CLK_CON_GAT_GOUT_FSYS_USB30DRD_ACLK_20PHYCTRL	0x2068
+#define CLK_CON_GAT_GOUT_FSYS_USB30DRD_ACLK_30PHYCTRL_0	0x206c
+#define CLK_CON_GAT_GOUT_FSYS_USB30DRD_ACLK_30PHYCTRL_1	0x2070
+#define CLK_CON_GAT_GOUT_FSYS_USB30DRD_BUS_CLK_EARLY	0x2074
+#define CLK_CON_GAT_GOUT_FSYS_USB30DRD_REF_CLK		0x2078
 
 static const unsigned long fsys_clk_regs[] __initconst = {
+	PLL_LOCKTIME_PLL_USB,
 	PLL_CON0_MUX_CLKCMU_FSYS_BUS_USER,
 	PLL_CON0_MUX_CLKCMU_FSYS_MMC_CARD_USER,
 	PLL_CON0_MUX_CLKCMU_FSYS_MMC_EMBD_USER,
 	PLL_CON0_MUX_CLKCMU_FSYS_MMC_SDIO_USER,
 	PLL_CON0_MUX_CLKCMU_FSYS_USB30DRD_USER,
+	PLL_CON0_PLL_USB,
+	CLK_CON_GAT_CLK_FSYS_USB20PHY_CLKCORE,
 	CLK_CON_GAT_GOUT_FSYS_MMC_CARD_I_ACLK,
 	CLK_CON_GAT_GOUT_FSYS_MMC_CARD_SDCLKIN,
 	CLK_CON_GAT_GOUT_FSYS_MMC_EMBD_I_ACLK,
 	CLK_CON_GAT_GOUT_FSYS_MMC_EMBD_SDCLKIN,
 	CLK_CON_GAT_GOUT_FSYS_MMC_SDIO_I_ACLK,
 	CLK_CON_GAT_GOUT_FSYS_MMC_SDIO_SDCLKIN,
+	CLK_CON_GAT_GOUT_FSYS_USB30DRD_ACLK_20PHYCTRL,
+	CLK_CON_GAT_GOUT_FSYS_USB30DRD_ACLK_30PHYCTRL_0,
+	CLK_CON_GAT_GOUT_FSYS_USB30DRD_ACLK_30PHYCTRL_1,
+	CLK_CON_GAT_GOUT_FSYS_USB30DRD_BUS_CLK_EARLY,
+	CLK_CON_GAT_GOUT_FSYS_USB30DRD_REF_CLK,
 };
 
+static const struct samsung_pll_rate_table pll_usb_rate_table[] __initconst = {
+	PLL_35XX_RATE(26 * MHZ, 50000000U, 400, 13, 4),
+};
+
+static const struct samsung_pll_clock fsys_pll_clks[] __initconst = {
+	PLL(pll_1418x, CLK_FOUT_USB_PLL, "fout_usb_pll", "oscclk",
+	    PLL_LOCKTIME_PLL_USB, PLL_CON0_PLL_USB,
+	    pll_usb_rate_table),
+};
+
+
 /* List of parent clocks for Muxes in CMU_FSYS */
 PNAME(mout_fsys_bus_user_p)		= { "oscclk", "dout_fsys_bus" };
 PNAME(mout_fsys_mmc_card_user_p)	= { "oscclk", "dout_fsys_mmc_card" };
 PNAME(mout_fsys_mmc_embd_user_p)	= { "oscclk", "dout_fsys_mmc_embd" };
 PNAME(mout_fsys_mmc_sdio_user_p)	= { "oscclk", "dout_fsys_mmc_sdio" };
 PNAME(mout_fsys_usb30drd_user_p)	= { "oscclk", "dout_fsys_usb30drd" };
+PNAME(mout_usb_pll_p)			= { "oscclk", "fout_usb_pll" };
 
 static const struct samsung_mux_clock fsys_mux_clks[] __initconst = {
 	MUX(CLK_MOUT_FSYS_BUS_USER, "mout_fsys_bus_user", mout_fsys_bus_user_p,
@@ -731,12 +759,16 @@ static const struct samsung_mux_clock fsys_mux_clks[] __initconst = {
 	MUX_F(CLK_MOUT_FSYS_MMC_SDIO_USER, "mout_fsys_mmc_sdio_user",
 	      mout_fsys_mmc_sdio_user_p, PLL_CON0_MUX_CLKCMU_FSYS_MMC_SDIO_USER,
 	      4, 1, CLK_SET_RATE_PARENT, 0),
-	MUX_F(CLK_MOUT_FSYS_USB30DRD_USER, "mout_fsys_usb30drd_user",
+	MUX(CLK_MOUT_FSYS_USB30DRD_USER, "mout_fsys_usb30drd_user",
 	      mout_fsys_usb30drd_user_p, PLL_CON0_MUX_CLKCMU_FSYS_USB30DRD_USER,
-	      4, 1, CLK_SET_RATE_PARENT, 0),
+	      4, 1),
+	nMUX_F(CLK_MOUT_USB_PLL, "mout_usb_pll", mout_usb_pll_p,
+	    PLL_CON0_PLL_USB, 4, 1, CLK_SET_RATE_PARENT, 0),
 };
 
 static const struct samsung_gate_clock fsys_gate_clks[] __initconst = {
+	GATE(CLK_FSYS_USB20PHY_CLKCORE, "clk_fsys_usb20phy_clkcore", "mout_usb_pll",
+	     CLK_CON_GAT_CLK_FSYS_USB20PHY_CLKCORE, 21, CLK_SET_RATE_PARENT, 0),
 	GATE(CLK_GOUT_MMC_CARD_ACLK, "gout_mmc_card_aclk", "mout_fsys_bus_user",
 	     CLK_CON_GAT_GOUT_FSYS_MMC_CARD_I_ACLK, 21, 0, 0),
 	GATE(CLK_GOUT_MMC_CARD_SDCLKIN, "gout_mmc_card_sdclkin",
@@ -752,9 +784,22 @@ static const struct samsung_gate_clock fsys_gate_clks[] __initconst = {
 	GATE(CLK_GOUT_MMC_SDIO_SDCLKIN, "gout_mmc_sdio_sdclkin",
 	     "mout_fsys_mmc_sdio_user", CLK_CON_GAT_GOUT_FSYS_MMC_SDIO_SDCLKIN,
 	     21, CLK_SET_RATE_PARENT, 0),
+	GATE(CLK_FSYS_USB30DRD_ACLK_20PHYCTRL, "clk_fsys_usb30drd_aclk_20phyctrl",
+	     "mout_fsys_bus_user", CLK_CON_GAT_GOUT_FSYS_USB30DRD_ACLK_20PHYCTRL, 21, 0, 0),
+	GATE(CLK_FSYS_USB30DRD_ACLK_30PHYCTRL_0, "clk_fsys_usb30drd_aclk_30phyctrl_0",
+	     "mout_fsys_bus_user", CLK_CON_GAT_GOUT_FSYS_USB30DRD_ACLK_30PHYCTRL_0, 21, 0, 0),
+	GATE(CLK_FSYS_USB30DRD_ACLK_30PHYCTRL_1, "clk_fsys_usb30drd_aclk_30phyctrl_1",
+	     "mout_fsys_bus_user", CLK_CON_GAT_GOUT_FSYS_USB30DRD_ACLK_30PHYCTRL_1, 21, 0, 0),
+	GATE(CLK_FSYS_USB30DRD_BUS_CLK_EARLY, "clk_fsys_usb30drd_bus_clk_early",
+	     "mout_fsys_bus_user", CLK_CON_GAT_GOUT_FSYS_USB30DRD_BUS_CLK_EARLY, 21, 0, 0),
+	GATE(CLK_FSYS_USB30DRD_REF_CLK, "clk_fsys_usb30drd_ref_clk", "mout_fsys_usb30drd_user",
+	     CLK_CON_GAT_GOUT_FSYS_USB30DRD_REF_CLK, 21, 0, 0),
+
 };
 
 static const struct samsung_cmu_info fsys_cmu_info __initconst = {
+	.pll_clks		= fsys_pll_clks,
+	.nr_pll_clks		= ARRAY_SIZE(fsys_pll_clks),
 	.mux_clks		= fsys_mux_clks,
 	.nr_mux_clks		= ARRAY_SIZE(fsys_mux_clks),
 	.gate_clks		= fsys_gate_clks,
-- 
2.46.0



From virag.david003 at gmail.com  Sun Aug  4 14:53:55 2024
From: virag.david003 at gmail.com (David Virag)
Date: Sun,  4 Aug 2024 23:53:55 +0200
Subject: [PATCH 10/13] usb: dwc3: exynos: Add support for Exynos7885
In-Reply-To: <20240804215458.404085-1-virag.david003@gmail.com>
References: <20240804215458.404085-1-virag.david003@gmail.com>
Message-ID: <20240804215458.404085-11-virag.david003@gmail.com>

Add Exynos7885 compatible string. As 7885 has the same clocks as 850, it
can reuse the data for Exynos850.

Signed-off-by: David Virag <virag.david003 at gmail.com>
---
 drivers/usb/dwc3/dwc3-exynos.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index 9a6e988d165a..5cd4dc2e0a67 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -185,6 +185,9 @@ static const struct of_device_id exynos_dwc3_match[] = {
 	}, {
 		.compatible = "samsung,exynos7-dwusb3",
 		.data = &exynos7_drvdata,
+	}, {
+		.compatible = "samsung,exynos7885-dwusb3",
+		.data = &exynos850_drvdata,
 	}, {
 		.compatible = "samsung,exynos850-dwusb3",
 		.data = &exynos850_drvdata,
-- 
2.46.0



From virag.david003 at gmail.com  Sun Aug  4 14:53:56 2024
From: virag.david003 at gmail.com (David Virag)
Date: Sun,  4 Aug 2024 23:53:56 +0200
Subject: [PATCH 11/13] phy: exynos5-usbdrd: support Exynos7885 USB PHY
In-Reply-To: <20240804215458.404085-1-virag.david003@gmail.com>
References: <20240804215458.404085-1-virag.david003@gmail.com>
Message-ID: <20240804215458.404085-12-virag.david003@gmail.com>

The Exynos7885 SoC has an Exynos USB PHY that theoretically supports
USB3 SuperSpeed, but all known devices using it only have USB2 and the
vendor driver has USB3 function stubbed out, so we'll only support USB2.

Apart from this mysterius USB3 capability, it's the closest to Exynos850
out of those supported. Unlike other SoCs though, this one doesn't set
the reference clock by default, so we have to set it manually.
For this, create a set_ref_clk_rate property in drvdata that can be set
to a predefined value to set the clockrate to.

Signed-off-by: David Virag <virag.david003 at gmail.com>
---
 drivers/phy/samsung/phy-exynos5-usbdrd.c    | 21 +++++++++++++++++++++
 include/linux/soc/samsung/exynos-regs-pmu.h |  3 +++
 2 files changed, 24 insertions(+)

diff --git a/drivers/phy/samsung/phy-exynos5-usbdrd.c b/drivers/phy/samsung/phy-exynos5-usbdrd.c
index df52b78a120b..466c72d8a93c 100644
--- a/drivers/phy/samsung/phy-exynos5-usbdrd.c
+++ b/drivers/phy/samsung/phy-exynos5-usbdrd.c
@@ -367,6 +367,7 @@ struct exynos5_usbdrd_phy_drvdata {
 	int n_clks;
 	const char * const *core_clk_names;
 	int n_core_clks;
+	u32 set_ref_clk_rate;
 	const char * const *regulator_names;
 	int n_regulators;
 	u32 pmu_offset_usbdrd0_phy;
@@ -1361,6 +1362,10 @@ static int exynos5_usbdrd_phy_clk_handle(struct exynos5_usbdrd_phy *phy_drd)
 		return dev_err_probe(phy_drd->dev, -ENODEV,
 				     "failed to find phy reference clock\n");
 
+	/* Exynos7885 SoC has reference clock unset by default */
+	if (phy_drd->drv_data->set_ref_clk_rate)
+		clk_set_rate(ref_clk, phy_drd->drv_data->set_ref_clk_rate);
+
 	ref_rate = clk_get_rate(ref_clk);
 	ret = exynos5_rate_to_clk(ref_rate, &phy_drd->extrefclk);
 	if (ret)
@@ -1460,6 +1465,19 @@ static const struct exynos5_usbdrd_phy_drvdata exynos7_usbdrd_phy = {
 	.n_regulators		= ARRAY_SIZE(exynos5_regulator_names),
 };
 
+static const struct exynos5_usbdrd_phy_drvdata exynos7885_usbdrd_phy = {
+	.phy_cfg                = phy_cfg_exynos850,
+	.phy_ops                = &exynos850_usbdrd_phy_ops,
+	.pmu_offset_usbdrd0_phy = EXYNOS7885_PHY_CTRL_USB20,
+	.clk_names		= exynos5_clk_names,
+	.n_clks			= ARRAY_SIZE(exynos5_clk_names),
+	.core_clk_names		= exynos5_core_clk_names,
+	.n_core_clks		= ARRAY_SIZE(exynos5_core_clk_names),
+	.regulator_names	= exynos5_regulator_names,
+	.n_regulators		= ARRAY_SIZE(exynos5_regulator_names),
+	.set_ref_clk_rate       = 50 * MHZ,
+};
+
 static const struct exynos5_usbdrd_phy_drvdata exynos850_usbdrd_phy = {
 	.phy_cfg		= phy_cfg_exynos850,
 	.phy_ops		= &exynos850_usbdrd_phy_ops,
@@ -1663,6 +1681,9 @@ static const struct of_device_id exynos5_usbdrd_phy_of_match[] = {
 	}, {
 		.compatible = "samsung,exynos7-usbdrd-phy",
 		.data = &exynos7_usbdrd_phy
+	}, {
+		.compatible = "samsung,exynos7885-usbdrd-phy",
+		.data = &exynos7885_usbdrd_phy
 	}, {
 		.compatible = "samsung,exynos850-usbdrd-phy",
 		.data = &exynos850_usbdrd_phy
diff --git a/include/linux/soc/samsung/exynos-regs-pmu.h b/include/linux/soc/samsung/exynos-regs-pmu.h
index ce1a3790d6fb..04ef93625eab 100644
--- a/include/linux/soc/samsung/exynos-regs-pmu.h
+++ b/include/linux/soc/samsung/exynos-regs-pmu.h
@@ -657,6 +657,9 @@
 #define EXYNOS5433_PAD_RETENTION_UFS_OPTION			(0x3268)
 #define EXYNOS5433_PAD_RETENTION_FSYSGENIO_OPTION		(0x32A8)
 
+/* For Exynos7885 */
+#define EXYNOS7885_PHY_CTRL_USB20				(0x674)
+
 /* For Tensor GS101 */
 #define GS101_SYSIP_DAT0					(0x810)
 #define GS101_SYSTEM_CONFIGURATION				(0x3A00)
-- 
2.46.0



From virag.david003 at gmail.com  Sun Aug  4 14:53:57 2024
From: virag.david003 at gmail.com (David Virag)
Date: Sun,  4 Aug 2024 23:53:57 +0200
Subject: [PATCH 12/13] arm64: dts: exynos: Enable USB in Exynos7885
In-Reply-To: <20240804215458.404085-1-virag.david003@gmail.com>
References: <20240804215458.404085-1-virag.david003@gmail.com>
Message-ID: <20240804215458.404085-13-virag.david003@gmail.com>

Add USB controller and USB PHY controller nodes to Exynos7885 SoC DTSI

The SoC theoretically supports USB3 SuperSpeed, but is not implemented
in any known device. The vendor kernel also stubs out USB3 functions, so
we do not support it.

It is though, perfectly capable of USB 2.0 high-speed mode, both as host
and device.

Signed-off-by: David Virag <virag.david003 at gmail.com>
---
 arch/arm64/boot/dts/exynos/exynos7885.dtsi | 35 ++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos7885.dtsi b/arch/arm64/boot/dts/exynos/exynos7885.dtsi
index 008228fb319a..1352c64d132e 100644
--- a/arch/arm64/boot/dts/exynos/exynos7885.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7885.dtsi
@@ -463,6 +463,41 @@ i2c_7: i2c at 11cd0000 {
 			clock-names = "i2c";
 			status = "disabled";
 		};
+
+		usbdrd: usb at 13600000 {
+			compatible = "samsung,exynos7885-dwusb3";
+			ranges = <0x0 0x13600000 0x10000>;
+			clocks = <&cmu_fsys CLK_FSYS_USB30DRD_BUS_CLK_EARLY>,
+				 <&cmu_fsys CLK_FSYS_USB30DRD_REF_CLK>;
+			clock-names = "bus_early", "ref";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			status = "disabled";
+
+			usbdrd_dwc3: usb at 0 {
+				compatible = "snps,dwc3";
+				reg = <0x0 0x10000>;
+				interrupts = <GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH>;
+				phys = <&usbdrd_phy 0>;
+				phy-names = "usb2-phy";
+				/*
+				 * SoC in theory supports SS but no device has it.
+				 * Actual capabilities unknown.
+				 */
+				maximum-speed = "high-speed";
+			};
+		};
+
+		usbdrd_phy: phy at 135d0000 {
+			compatible = "samsung,exynos7885-usbdrd-phy";
+			reg = <0x135d0000 0x100>;
+			clocks = <&cmu_fsys CLK_FSYS_USB30DRD_ACLK_20PHYCTRL>,
+				 <&cmu_fsys CLK_FSYS_USB20PHY_CLKCORE>;
+			clock-names = "phy", "ref";
+			samsung,pmu-syscon = <&pmu_system_controller>;
+			#phy-cells = <1>;
+			status = "disabled";
+		};
 	};
 };
 
-- 
2.46.0



From virag.david003 at gmail.com  Sun Aug  4 14:53:58 2024
From: virag.david003 at gmail.com (David Virag)
Date: Sun,  4 Aug 2024 23:53:58 +0200
Subject: [PATCH 13/13] arm64: dts: exynos: exynos7885-jackpotlte: Enable USB support
In-Reply-To: <20240804215458.404085-1-virag.david003@gmail.com>
References: <20240804215458.404085-1-virag.david003@gmail.com>
Message-ID: <20240804215458.404085-14-virag.david003@gmail.com>

The Samsung Galaxy A8 (2018) has an USB-C port capable of USB 2.0
speeds, used both as host and device, and is used for charging the
phone.

The physical port is directly connected to an S2MU004 IC, but until we
have support for it, we can still use the USB device funtionality.

Signed-off-by: David Virag <virag.david003 at gmail.com>
---
 .../boot/dts/exynos/exynos7885-jackpotlte.dts | 20 +++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos7885-jackpotlte.dts b/arch/arm64/boot/dts/exynos/exynos7885-jackpotlte.dts
index 47a389d9ff7d..c1902d2f57cf 100644
--- a/arch/arm64/boot/dts/exynos/exynos7885-jackpotlte.dts
+++ b/arch/arm64/boot/dts/exynos/exynos7885-jackpotlte.dts
@@ -59,6 +59,12 @@ power-key {
 			wakeup-source;
 		};
 	};
+
+	/* TODO: Remove this once PMIC is implemented  */
+	reg_dummy: regulator-0 {
+		compatible = "regulator-fixed";
+		regulator-name = "dummy_reg";
+	};
 };
 
 &mmc_0 {
@@ -111,3 +117,17 @@ key_power: key-power-pins {
 &serial_2 {
 	status = "okay";
 };
+
+&usbdrd {
+	status = "okay";
+	vdd10-supply = <&reg_dummy>;
+	vdd33-supply = <&reg_dummy>;
+};
+
+&usbdrd_dwc3 {
+	dr_mode = "peripheral"; /* Force to peripheral until we have Type-C working */
+};
+
+&usbdrd_phy {
+	status = "okay";
+};
-- 
2.46.0



From hpchen0nvt at gmail.com  Sun Aug  4 20:03:54 2024
From: hpchen0nvt at gmail.com (Hui-Ping Chen)
Date: Mon,  5 Aug 2024 03:03:54 +0000
Subject: [PATCH v4 0/2] Add support for nuvoton ma35 usb2 phy
Message-ID: <20240805030356.14565-1-hpchen0nvt@gmail.com>

This patch series adds the usb2 phy driver for the nuvoton ma35 ARMv8 SoC.
It includes DT binding documentation and the ma35 usb2 phy driver.

v4:
  - Update ma35d1 usb2 phy driver
    - Update the 'readl_poll_timeout' to 'regmap_read_poll_timeout'.
    - Update MODULE_AUTHOR name.


v3:
  - Update nuvoton,ma35d1-usb2-phy.yaml
    - Update the syscon usage description.


v2:
  - Update nuvoton,ma35d1-usb2-phy.yaml
    - Update the 'nuvoton,ma35-usb2-phy' to 'nuvoton,ma35d1-usb2-phy'.
    - Remove unnecessary descriptions. 
    - Add explanations related to SYS.
  - Update ma35d1 usb2 phy driver
    - Update the 'nuvoton,ma35-usb2-phy' to 'nuvoton,ma35d1-usb2-phy'.
    - Use readl_poll_timeout() to make the system more efficient and the 
      code more streamlined.
    - Use the same variable name. Update the 'p_phy->dev' to 'pdev->dev'.



Hui-Ping Chen (2):
  dt-bindings: phy: nuvoton,ma35-usb2-phy: add new bindings
  phy: nuvoton: add new driver for the Nuvoton MA35 SoC USB 2.0 PHY

 .../bindings/phy/nuvoton,ma35d1-usb2-phy.yaml |  45 ++++++
 drivers/phy/Kconfig                           |   1 +
 drivers/phy/Makefile                          |   1 +
 drivers/phy/nuvoton/Kconfig                   |  13 ++
 drivers/phy/nuvoton/Makefile                  |   3 +
 drivers/phy/nuvoton/phy-ma35d1-usb2.c         | 143 ++++++++++++++++++
 6 files changed, 206 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.yaml
 create mode 100644 drivers/phy/nuvoton/Kconfig
 create mode 100644 drivers/phy/nuvoton/Makefile
 create mode 100644 drivers/phy/nuvoton/phy-ma35d1-usb2.c

-- 
2.25.1



From hpchen0nvt at gmail.com  Sun Aug  4 20:03:55 2024
From: hpchen0nvt at gmail.com (Hui-Ping Chen)
Date: Mon,  5 Aug 2024 03:03:55 +0000
Subject: [PATCH v4 1/2] dt-bindings: phy: nuvoton,ma35-usb2-phy: add new bindings
In-Reply-To: <20240805030356.14565-1-hpchen0nvt@gmail.com>
References: <20240805030356.14565-1-hpchen0nvt@gmail.com>
Message-ID: <20240805030356.14565-2-hpchen0nvt@gmail.com>

Add dt-bindings for USB2 PHY found on the Nuvoton MA35 SoC.

Signed-off-by: Hui-Ping Chen <hpchen0nvt at gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 .../bindings/phy/nuvoton,ma35d1-usb2-phy.yaml | 45 +++++++++++++++++++
 1 file changed, 45 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.yaml

diff --git a/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.yaml
new file mode 100644
index 000000000000..fff858c909a0
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/nuvoton,ma35d1-usb2-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton MA35D1 USB2 phy
+
+maintainers:
+  - Hui-Ping Chen <hpchen0nvt at gmail.com>
+
+properties:
+  compatible:
+    enum:
+      - nuvoton,ma35d1-usb2-phy
+
+  "#phy-cells":
+    const: 0
+
+  clocks:
+    maxItems: 1
+
+  nuvoton,sys:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description:
+      phandle to syscon for checking the PHY clock status.
+
+required:
+  - compatible
+  - "#phy-cells"
+  - clocks
+  - nuvoton,sys
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/nuvoton,ma35d1-clk.h>
+
+    usb_phy: usb-phy {
+        compatible = "nuvoton,ma35d1-usb2-phy";
+        clocks = <&clk USBD_GATE>;
+        nuvoton,sys = <&sys>;
+        #phy-cells = <0>;
+    };
-- 
2.25.1



From hpchen0nvt at gmail.com  Sun Aug  4 20:03:56 2024
From: hpchen0nvt at gmail.com (Hui-Ping Chen)
Date: Mon,  5 Aug 2024 03:03:56 +0000
Subject: [PATCH v4 2/2] phy: nuvoton: add new driver for the Nuvoton MA35 SoC USB 2.0 PHY
In-Reply-To: <20240805030356.14565-1-hpchen0nvt@gmail.com>
References: <20240805030356.14565-1-hpchen0nvt@gmail.com>
Message-ID: <20240805030356.14565-3-hpchen0nvt@gmail.com>

Nuvoton MA35 SoCs support DWC2 USB controller.
Add the driver to drive the USB 2.0 PHY transceivers.

Signed-off-by: Hui-Ping Chen <hpchen0nvt at gmail.com>
---
 drivers/phy/Kconfig                   |   1 +
 drivers/phy/Makefile                  |   1 +
 drivers/phy/nuvoton/Kconfig           |  13 +++
 drivers/phy/nuvoton/Makefile          |   3 +
 drivers/phy/nuvoton/phy-ma35d1-usb2.c | 143 ++++++++++++++++++++++++++
 5 files changed, 161 insertions(+)
 create mode 100644 drivers/phy/nuvoton/Kconfig
 create mode 100644 drivers/phy/nuvoton/Makefile
 create mode 100644 drivers/phy/nuvoton/phy-ma35d1-usb2.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index dfab1c66b3e5..f73abff416be 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -95,6 +95,7 @@ source "drivers/phy/mediatek/Kconfig"
 source "drivers/phy/microchip/Kconfig"
 source "drivers/phy/motorola/Kconfig"
 source "drivers/phy/mscc/Kconfig"
+source "drivers/phy/nuvoton/Kconfig"
 source "drivers/phy/qualcomm/Kconfig"
 source "drivers/phy/ralink/Kconfig"
 source "drivers/phy/realtek/Kconfig"
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 5fcbce5f9ab1..ebc399560da4 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -25,6 +25,7 @@ obj-y					+= allwinner/	\
 					   microchip/	\
 					   motorola/	\
 					   mscc/	\
+					   nuvoton/	\
 					   qualcomm/	\
 					   ralink/	\
 					   realtek/	\
diff --git a/drivers/phy/nuvoton/Kconfig b/drivers/phy/nuvoton/Kconfig
new file mode 100644
index 000000000000..270ee2943287
--- /dev/null
+++ b/drivers/phy/nuvoton/Kconfig
@@ -0,0 +1,13 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# PHY drivers for Nuvoton MA35 platforms
+#
+config PHY_MA35_USB
+	tristate "Nuvoton MA35 USB2.0 PHY driver"
+	depends on ARCH_MA35 || COMPILE_TEST
+	depends on OF
+	select GENERIC_PHY
+	help
+	  Enable this to support the USB2.0 PHY on the Nuvoton MA35
+	  series SoCs.
+
diff --git a/drivers/phy/nuvoton/Makefile b/drivers/phy/nuvoton/Makefile
new file mode 100644
index 000000000000..2937e3921898
--- /dev/null
+++ b/drivers/phy/nuvoton/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+
+obj-$(CONFIG_PHY_MA35_USB)		+= phy-ma35d1-usb2.o
diff --git a/drivers/phy/nuvoton/phy-ma35d1-usb2.c b/drivers/phy/nuvoton/phy-ma35d1-usb2.c
new file mode 100644
index 000000000000..9a459b700ed4
--- /dev/null
+++ b/drivers/phy/nuvoton/phy-ma35d1-usb2.c
@@ -0,0 +1,143 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2024 Nuvoton Technology Corp.
+ */
+#include <linux/bitfield.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+
+/* USB PHY Miscellaneous Control Register */
+#define MA35_SYS_REG_USBPMISCR	0x60
+#define PHY0POR			BIT(0)  /* PHY Power-On Reset Control Bit */
+#define PHY0SUSPEND			BIT(1)  /* PHY Suspend; 0: suspend, 1: operaion */
+#define PHY0COMN			BIT(2)  /* PHY Common Block Power-Down Control */
+#define PHY0DEVCKSTB			BIT(10) /* PHY 60 MHz UTMI clock stable bit */
+
+struct ma35_usb_phy {
+	struct clk *clk;
+	struct device *dev;
+	struct regmap *sysreg;
+};
+
+static int ma35_usb_phy_power_on(struct phy *phy)
+{
+	struct ma35_usb_phy *p_phy = phy_get_drvdata(phy);
+	unsigned int val;
+	int ret;
+
+	ret = clk_prepare_enable(p_phy->clk);
+	if (ret < 0) {
+		dev_err(p_phy->dev, "Failed to enable PHY clock: %d\n", ret);
+		return ret;
+	}
+
+	regmap_read(p_phy->sysreg, MA35_SYS_REG_USBPMISCR, &val);
+	if (val & PHY0SUSPEND) {
+		/*
+		 * USB PHY0 is in operation mode already
+		 * make sure USB PHY 60 MHz UTMI Interface Clock ready
+		 */
+		ret = regmap_read_poll_timeout(p_phy->sysreg, MA35_SYS_REG_USBPMISCR, val,
+						val & PHY0DEVCKSTB, 10, 1000);
+		if (ret == 0)
+			return 0;
+	}
+
+	/*
+	 * reset USB PHY0.
+	 * wait until USB PHY0 60 MHz UTMI Interface Clock ready
+	 */
+	regmap_update_bits(p_phy->sysreg, MA35_SYS_REG_USBPMISCR, 0x7, (PHY0POR | PHY0SUSPEND));
+	udelay(20);
+
+	/* make USB PHY0 enter operation mode */
+	regmap_update_bits(p_phy->sysreg, MA35_SYS_REG_USBPMISCR, 0x7, PHY0SUSPEND);
+
+	/* make sure USB PHY 60 MHz UTMI Interface Clock ready */
+	ret = regmap_read_poll_timeout(p_phy->sysreg, MA35_SYS_REG_USBPMISCR, val,
+					val & PHY0DEVCKSTB, 10, 1000);
+	if (ret == -ETIMEDOUT) {
+		dev_err(p_phy->dev, "Check PHY clock, Timeout: %d\n", ret);
+		clk_disable_unprepare(p_phy->clk);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int ma35_usb_phy_power_off(struct phy *phy)
+{
+	struct ma35_usb_phy *p_phy = phy_get_drvdata(phy);
+
+	clk_disable_unprepare(p_phy->clk);
+	return 0;
+}
+
+static const struct phy_ops ma35_usb_phy_ops = {
+	.power_on = ma35_usb_phy_power_on,
+	.power_off = ma35_usb_phy_power_off,
+	.owner = THIS_MODULE,
+};
+
+static int ma35_usb_phy_probe(struct platform_device *pdev)
+{
+	struct phy_provider *provider;
+	struct ma35_usb_phy *p_phy;
+	struct phy *phy;
+
+	p_phy = devm_kzalloc(&pdev->dev, sizeof(*p_phy), GFP_KERNEL);
+	if (!p_phy)
+		return -ENOMEM;
+
+	p_phy->dev = &pdev->dev;
+	platform_set_drvdata(pdev, p_phy);
+
+	p_phy->sysreg = syscon_regmap_lookup_by_phandle(pdev->dev.of_node, "nuvoton,sys");
+	if (IS_ERR(p_phy->sysreg))
+		return dev_err_probe(&pdev->dev, PTR_ERR(p_phy->sysreg),
+				     "Failed to get SYS registers\n");
+
+	p_phy->clk = of_clk_get(pdev->dev.of_node, 0);
+	if (IS_ERR(p_phy->clk))
+		return dev_err_probe(&pdev->dev, PTR_ERR(p_phy->clk),
+				     "failed to find usb_phy clock\n");
+
+	phy = devm_phy_create(&pdev->dev, NULL, &ma35_usb_phy_ops);
+	if (IS_ERR(phy))
+		return dev_err_probe(&pdev->dev, PTR_ERR(phy), "Failed to create PHY\n");
+
+	phy_set_drvdata(phy, p_phy);
+
+	provider = devm_of_phy_provider_register(&pdev->dev, of_phy_simple_xlate);
+	if (IS_ERR(provider))
+		return dev_err_probe(&pdev->dev, PTR_ERR(provider),
+				     "Failed to register PHY provider\n");
+	return 0;
+}
+
+static const struct of_device_id ma35_usb_phy_of_match[] = {
+	{ .compatible = "nuvoton,ma35d1-usb2-phy", },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, ma35_usb_phy_of_match);
+
+static struct platform_driver ma35_usb_phy_driver = {
+	.probe		= ma35_usb_phy_probe,
+	.driver	= {
+		.name	= "ma35d1-usb2-phy",
+		.of_match_table = ma35_usb_phy_of_match,
+	},
+};
+module_platform_driver(ma35_usb_phy_driver);
+
+MODULE_DESCRIPTION("Nuvoton ma35d1 USB2.0 PHY driver");
+MODULE_AUTHOR("Hui-Ping Chen <hpchen0nvt at gmail.com>");
+MODULE_LICENSE("GPL");
-- 
2.25.1



From victor.liu at nxp.com  Sun Aug  4 20:23:59 2024
From: victor.liu at nxp.com (Liu Ying)
Date: Mon, 5 Aug 2024 11:23:59 +0800
Subject: [PATCH v2 06/16] drm/imx: Add i.MX8qxp Display Controller display
 engine
In-Reply-To: <vlnpy7abizzzh7sj5zrgakwyams3w6k7ee4kaagiw646atmnjf@xkimtr43d4hr>
References: <20240712093243.2108456-1-victor.liu@nxp.com>
 <20240712093243.2108456-7-victor.liu@nxp.com>
 <ib6brwxeai3wkgzglihfbqx7jakjslnftydbzo32xthijkd4u6@y4ebhgk5o3ec>
 <8071fdf8-6813-4707-8a9c-ad24f8b6a32f@nxp.com>
 <vlnpy7abizzzh7sj5zrgakwyams3w6k7ee4kaagiw646atmnjf@xkimtr43d4hr>
Message-ID: <677a5492-8f88-4ad6-8652-278d24b1b8a1@nxp.com>

On 07/31/2024, Dmitry Baryshkov wrote:
> On Tue, Jul 30, 2024 at 02:25:41PM GMT, Liu Ying wrote:
>> On 07/28/2024, Dmitry Baryshkov wrote:
>>> On Fri, Jul 12, 2024 at 05:32:33PM GMT, Liu Ying wrote:
>>>> i.MX8qxp Display Controller display engine consists of all processing
>>>> units that operate in a display clock domain.  Add minimal feature
>>>> support with FrameGen and TCon so that the engine can output display
>>>> timings.  The display engine driver as a master binds FrameGen and
>>>> TCon drivers as components.  While at it, the display engine driver
>>>> is a component to be bound with the upcoming DRM driver.
>>>
>>> Generic question: why do you need so many small subdrivers? Are they
>>
>> As we model processing units, interrupt controller, display engine
>> and pixel engine as devices, relevant drivers are created to bind
>> them.
>>
>> Maxime insisted on splitting the main display controller(the overall
>> IP) into separate devices.  Also, Rob asked me to document every
>> processing units and the other sub-devices in v2.  So, splitting the
>> controller is kinda accepted from both DT PoV and DRM PoV.
> 
> I went back to the previous series, where Maxime commented on the
> "multiple devices glued together". With the split architecture it
> becomes even more strange, because now you have a separate IRQ
> controller which enumerates interrupts for all subdevices and then glues
> them back.
> 
> If it was an actually split device, I'd have expected that each of
> subdevices has interrupts going to the external controller, without the
> glue controller. Or that the glue controller has a limited set of the
> externally-generated interrupts that it further splits into per-block
> IRQs.

People may have different opinions on whether the main display controller
should be split into sub-devices or not, or even how it should be split,
which looks quite subjective.  Given this situation, I tend to follow
the kind of agreement reached by Rob and Maxime that it should be split
entirely and each processing unit should have a dt-binding doc.

> 
> Could you please point out the patches that describe and implement the
> <&dc0_irqsteer> device?

drivers/irqchip/irq-imx-irqsteer.c
Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml

You may find an irqsteer DT node in patch 13/16 in v2.

> 
>>
>>> used to represent the flexibility of the pipeline? Can you instantiate
>>
>> No. They are just used to bind the devices created from DT.
>>
>>> these units directly from the de(?) driver and reference created
>>> structures without the need to create subdevices?
>>
>> Given the separated devices created from DT, I can't.
> 
> I'd allow Maxime to override me here, but I think that subblocks should
> not be described in DT, unless that is required to describe
> possible versatility in the display pipeline.
> 
>>>>
>>>> Signed-off-by: Liu Ying <victor.liu at nxp.com>
>>>> ---
>>>> v2:
>>>> * Use OF alias id to get instance id.
>>>> * Add dev member to struct dc_tc.
>>>>
>>>>  drivers/gpu/drm/imx/Kconfig     |   1 +
>>>>  drivers/gpu/drm/imx/Makefile    |   1 +
>>>>  drivers/gpu/drm/imx/dc/Kconfig  |   5 +
>>>>  drivers/gpu/drm/imx/dc/Makefile |   5 +
>>>>  drivers/gpu/drm/imx/dc/dc-de.c  | 151 +++++++++++++
>>>>  drivers/gpu/drm/imx/dc/dc-de.h  |  62 ++++++
>>>>  drivers/gpu/drm/imx/dc/dc-drv.c |  32 +++
>>>>  drivers/gpu/drm/imx/dc/dc-drv.h |  24 +++
>>>>  drivers/gpu/drm/imx/dc/dc-fg.c  | 366 ++++++++++++++++++++++++++++++++
>>>>  drivers/gpu/drm/imx/dc/dc-tc.c  | 137 ++++++++++++
>>>>  10 files changed, 784 insertions(+)
>>>>  create mode 100644 drivers/gpu/drm/imx/dc/Kconfig
>>>>  create mode 100644 drivers/gpu/drm/imx/dc/Makefile
>>>>  create mode 100644 drivers/gpu/drm/imx/dc/dc-de.c
>>>>  create mode 100644 drivers/gpu/drm/imx/dc/dc-de.h
>>>>  create mode 100644 drivers/gpu/drm/imx/dc/dc-drv.c
>>>>  create mode 100644 drivers/gpu/drm/imx/dc/dc-drv.h
>>>>  create mode 100644 drivers/gpu/drm/imx/dc/dc-fg.c
>>>>  create mode 100644 drivers/gpu/drm/imx/dc/dc-tc.c
>>>>
>>>> diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig
>>>> index 03535a15dd8f..3e8c6edbc17c 100644
>>>> --- a/drivers/gpu/drm/imx/Kconfig
>>>> +++ b/drivers/gpu/drm/imx/Kconfig
>>>> @@ -1,5 +1,6 @@
>>>>  # SPDX-License-Identifier: GPL-2.0-only
>>>>  
>>>> +source "drivers/gpu/drm/imx/dc/Kconfig"
>>>>  source "drivers/gpu/drm/imx/dcss/Kconfig"
>>>>  source "drivers/gpu/drm/imx/ipuv3/Kconfig"
>>>>  source "drivers/gpu/drm/imx/lcdc/Kconfig"
>>>> diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile
>>>> index 86f38e7c7422..c7b317640d71 100644
>>>> --- a/drivers/gpu/drm/imx/Makefile
>>>> +++ b/drivers/gpu/drm/imx/Makefile
>>>> @@ -1,5 +1,6 @@
>>>>  # SPDX-License-Identifier: GPL-2.0
>>>>  
>>>> +obj-$(CONFIG_DRM_IMX8_DC) += dc/
>>>>  obj-$(CONFIG_DRM_IMX_DCSS) += dcss/
>>>>  obj-$(CONFIG_DRM_IMX) += ipuv3/
>>>>  obj-$(CONFIG_DRM_IMX_LCDC) += lcdc/
>>>> diff --git a/drivers/gpu/drm/imx/dc/Kconfig b/drivers/gpu/drm/imx/dc/Kconfig
>>>> new file mode 100644
>>>> index 000000000000..32d7471c49d0
>>>> --- /dev/null
>>>> +++ b/drivers/gpu/drm/imx/dc/Kconfig
>>>> @@ -0,0 +1,5 @@
>>>> +config DRM_IMX8_DC
>>>> +	tristate "Freescale i.MX8 Display Controller Graphics"
>>>> +	depends on DRM && COMMON_CLK && OF && (ARCH_MXC || COMPILE_TEST)
>>>> +	help
>>>> +	  enable Freescale i.MX8 Display Controller(DC) graphics support
>>>> diff --git a/drivers/gpu/drm/imx/dc/Makefile b/drivers/gpu/drm/imx/dc/Makefile
>>>> new file mode 100644
>>>> index 000000000000..56de82d53d4d
>>>> --- /dev/null
>>>> +++ b/drivers/gpu/drm/imx/dc/Makefile
>>>> @@ -0,0 +1,5 @@
>>>> +# SPDX-License-Identifier: GPL-2.0
>>>> +
>>>> +imx8-dc-drm-objs := dc-de.o dc-drv.o dc-fg.o dc-tc.o
>>>> +
>>>> +obj-$(CONFIG_DRM_IMX8_DC) += imx8-dc-drm.o
>>>> diff --git a/drivers/gpu/drm/imx/dc/dc-de.c b/drivers/gpu/drm/imx/dc/dc-de.c
>>>> new file mode 100644
>>>> index 000000000000..2c8268b76b08
>>>> --- /dev/null
>>>> +++ b/drivers/gpu/drm/imx/dc/dc-de.c
>>>> @@ -0,0 +1,151 @@
>>>> +// SPDX-License-Identifier: GPL-2.0+
>>>> +/*
>>>> + * Copyright 2024 NXP
>>>> + */
>>>> +
>>>> +#include <linux/component.h>
>>>> +#include <linux/container_of.h>
>>>> +#include <linux/io.h>
>>>> +#include <linux/mod_devicetable.h>
>>>> +#include <linux/module.h>
>>>> +#include <linux/of.h>
>>>> +#include <linux/of_platform.h>
>>>> +#include <linux/platform_device.h>
>>>> +#include <linux/pm.h>
>>>> +#include <linux/pm_runtime.h>
>>>> +
>>>> +#include <drm/drm_managed.h>
>>>> +
>>>> +#include "dc-de.h"
>>>> +#include "dc-drv.h"
>>>> +
>>>> +#define POLARITYCTRL		0xc
>>>> +#define  POLEN_HIGH		BIT(2)
>>>> +
>>>> +struct dc_de_priv {
>>>> +	struct dc_de engine;
>>>> +	void __iomem *reg_top;
>>>> +};
>>>> +
>>>> +static inline struct dc_de_priv *to_de_priv(struct dc_de *de)
>>>> +{
>>>> +	return container_of(de, struct dc_de_priv, engine);
>>>> +}
>>>> +
>>>> +static inline void
>>>> +dc_dec_write(struct dc_de *de, unsigned int offset, u32 value)
>>>> +{
>>>> +	struct dc_de_priv *priv = to_de_priv(de);
>>>> +
>>>> +	writel(value, priv->reg_top + offset);
>>>
>>> Is there a point in this wrapper? Can you call writel directly? This
>>
>> At least, it helps finding read/write ops upon interested devices through
>> 'git grep'.
> 
> git grep writel also works.

I said "interested devices".  For example, write ops upon LayerBlend can
be easily found by 'git grep dc_lb_write'.  'git grep writel' is not enough
to tell interested device.

> 
>>
>> Also, since we have dc_*_write_mask() helpers, it doesn't look too bad to
>> have dc_*_read/write() helpers.
> 
> Please use regmap_update_bits instead of dc_*_write_mask.

Then, you are suggesting to use both regmap_update_bits and writel.
This doesn't look very consistent.  Why not use regmap_write and
regmap_update_bits?

Anyway, this is a bit bike-shedding.  If you don't have too strong opinion
on this, I'd hope to keep the read/write ops as-is.

> 
>>
>>> question generally applies to the driver. I see a lot of small functions
>>> which can be inlined without losing the clarity.
>>
>> Can you please point out typical ones?
> 
> dc_fg_enable_shden(), dc_fg_syncmode(), dc_dec_init()

I'll inline them and some others.

> 
> To provide an example, this is the code from dc_crtc_atomic_enable().
> 
> 	dc_fg_displaymode(dc_crtc->fg, FG_DM_SEC_ON_TOP);
> 	dc_fg_panic_displaymode(dc_crtc->fg, FG_DM_CONSTCOL);
> 	dc_fg_cfg_videomode(dc_crtc->fg, adj);
> 
> the FG parameters are fixed here. I'd expect a single call from dc_dcrtc
> to dc_fg, which internally does all the settings. This removes a need to
> export low-level details to other modules.

The display modes set by dc_fg_displaymode() and dc_fg_panic_displaymode()
are kinda key settings for KMS.  IMHO, setting them in ->atomic_enable()
makes maintenance and code reading a bit easier though with trivial and
neglectable performance penalty since they are done for each mode setting.

Anyway, since you asked, I'll move the two to dc_fg_init() and move
some others where apply.

> 
>>
>>>
>>>> +}
>>>> +
>>>> +static void dc_dec_init(struct dc_de *de)
>>>> +{
>>>> +	dc_dec_write(de, POLARITYCTRL, POLEN_HIGH);
>>>> +}
>>>> +
>>>> +static int dc_de_bind(struct device *dev, struct device *master, void *data)
>>>> +{
>>>> +	struct platform_device *pdev = to_platform_device(dev);
>>>> +	struct dc_drm_device *dc_drm = data;
>>>> +	struct dc_de_priv *priv;
>>>> +	int ret;
>>>> +
>>>> +	priv = drmm_kzalloc(&dc_drm->base, sizeof(*priv), GFP_KERNEL);
>>>> +	if (!priv)
>>>> +		return -ENOMEM;
>>>> +
>>>> +	priv->reg_top = devm_platform_ioremap_resource_byname(pdev, "top");
>>>> +	if (IS_ERR(priv->reg_top))
>>>> +		return PTR_ERR(priv->reg_top);
>>>> +
>>>> +	priv->engine.irq_shdld = platform_get_irq_byname(pdev, "shdload");
>>>> +	if (priv->engine.irq_shdld < 0)
>>>> +		return priv->engine.irq_shdld;
>>>> +
>>>> +	priv->engine.irq_framecomplete =
>>>> +				platform_get_irq_byname(pdev, "framecomplete");
>>>> +	if (priv->engine.irq_framecomplete < 0)
>>>> +		return priv->engine.irq_framecomplete;
>>>> +
>>>> +	priv->engine.irq_seqcomplete =
>>>> +				platform_get_irq_byname(pdev, "seqcomplete");
>>>> +	if (priv->engine.irq_seqcomplete < 0)
>>>> +		return priv->engine.irq_seqcomplete;
>>>> +
>>>> +	priv->engine.id = of_alias_get_id(dev->of_node, "dc0-display-engine");
>>>
>>> Is this alias documented somewhere? Is it Acked by DT maintainers?
>>
>> I see aliases nodes in about 10 .yaml files as examples.
>> If needed, I can add them to examples.
>>
>> Rob said "Ideally, no" to use alias in v1. However, IMHO, it is the only
>> appropriate way to get instance id. In v1 review cycles, we've seen kinda
>> 4 ways:
>>
>> 1) fsl,dc-*-id DT property
>>    Rejected by Krzystof.
>>
>> 2) OF alias
>>
>> 3) OF graph ports (Rob)
>>    This doesn't directly get instance id but just tell the connections.
>>    Since there are too many input/output options between some processing
>>    units, I hope we don't end up using this approach, as I mentioned in v1.
>>    It seems be difficult for display driver to handle those ports.   
>>
>>    VC4 Hardware Video Scaler(HVS) is not using OF graph ports to tell the
>>    connections to display controllers, either. See brcm,bcm2835-hvs.yaml.
>>  
>> 4) fsl,imx8qxp-dc-*{id} DT compatible string
>>    It doesn't seem necessary to add the id information to compatible string.
> 
> For the similar issue we ended up hardcoding IO address / masks into the
> driver. This is far from being optimal (and I'd like to get away from

I thought about using IO address to tell instance id in driver before v1,
and chose not to do that since it's not straightforward and kinda abusing IO
address.

> it). If we were designing drm/msm from scratch now, we'd probably have used OF
> graph port IDs.

Don't know drm/msm and it's backing HW(s), so not sure how OF graph ports
can bring benefits for it.  For i.MX8 DC, it will be too complex for DT and
display driver to use OF graph ports. 

> 
>>
>>>
>>>> +	if (priv->engine.id < 0) {
>>>> +		dev_err(dev, "failed to get alias id: %d\n", priv->engine.id);
>>>> +		return priv->engine.id;
>>>> +	}
>>>> +
>>>> +	priv->engine.dev = dev;
>>>> +
>>>> +	dev_set_drvdata(dev, priv);
>>>> +
>>>> +	ret = devm_pm_runtime_enable(dev);
>>>> +	if (ret)
>>>> +		return ret;
>>>> +
>>>> +	dc_drm->de[priv->engine.id] = &priv->engine;
>>>> +
>>>> +	return 0;
>>>> +}
>>>> +
>>>
>>
>> -- 
>> Regards,
>> Liu Ying
>>
> 

-- 
Regards,
Liu Ying



From xu.yang_2 at nxp.com  Sun Aug  4 20:27:29 2024
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Mon, 5 Aug 2024 11:27:29 +0800
Subject: [PATCH 3/5] phy: fsl-imx8mq-usb: add tca function driver for
 imx95
In-Reply-To: <i2o5pk7jnni4bgc6txktus26dtnd6quivxkslgqkelmyb334k6@s5waxd5ep75f>
References: <20240802091702.2057294-1-xu.yang_2@nxp.com>
 <20240802091702.2057294-3-xu.yang_2@nxp.com>
 <i2o5pk7jnni4bgc6txktus26dtnd6quivxkslgqkelmyb334k6@s5waxd5ep75f>
Message-ID: <20240805032729.awuai5v67lmzq5mm@hippo>

On Fri, Aug 02, 2024 at 04:52:06PM +0300, Dmitry Baryshkov wrote:
> On Fri, Aug 02, 2024 at 05:17:00PM GMT, Xu Yang wrote:
> > The i.MX95 USB3 phy has a Type-C Assist block (TCA). This block consists
> > two functional blocks (XBar assist and VBus assist) and one system
> > access interface using APB.
> > 
> > The primary functionality of XBar assist is:
> >  - switching lane for flip
> >  - moving unused lanes into lower power states.
> > 
> > This info can be get from:
> > i.MX95 RM Chapter 163.3.8 Type-C assist (TCA) block.
> > 
> > This will add support for TCA block to achieve lane switching and tca
> > lower power functionality.
> > 
> > Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> > Reviewed-by: Jun Li <jun.li at nxp.com>
> > ---
> >  drivers/phy/freescale/Kconfig              |   1 +
> >  drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 238 +++++++++++++++++++++
> >  2 files changed, 239 insertions(+)
> > 
> 
> [..]
> 
> > @@ -398,6 +624,10 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
> >  
> >  	phy_set_drvdata(imx_phy->phy, imx_phy);
> >  
> > +	if (device_is_compatible(dev, "fsl,imx95-usb-phy") &&
> > +			imx95_usb_phy_get_tca(pdev, imx_phy) < 0)
> > +		return dev_err_probe(dev, -ENODEV, "failed to get tca\n");
> 
> Pleas propagate error returned by imx95_usb_phy_get_tca() instead of
> always returning -ENODEV.

Okay.

Thanks,
Xu Yang

> 
> > +
> >  	imx8m_get_phy_tuning_data(imx_phy);
> >  
> >  	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
> > @@ -405,8 +635,16 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
> >  	return PTR_ERR_OR_ZERO(phy_provider);
> >  }
> >  
> > +static void imx8mq_usb_phy_remove(struct platform_device *pdev)
> > +{
> > +	struct imx8mq_usb_phy *imx_phy = platform_get_drvdata(pdev);
> > +
> > +	imx95_usb_phy_put_tca(imx_phy);
> > +}
> > +
> >  static struct platform_driver imx8mq_usb_phy_driver = {
> >  	.probe	= imx8mq_usb_phy_probe,
> > +	.remove = imx8mq_usb_phy_remove,
> >  	.driver = {
> >  		.name	= "imx8mq-usb-phy",
> >  		.of_match_table	= imx8mq_usb_phy_of_match,
> > -- 
> > 2.34.1
> > 
> 
> -- 
> With best wishes
> Dmitry


From xu.yang_2 at nxp.com  Sun Aug  4 20:36:58 2024
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Mon, 5 Aug 2024 11:36:58 +0800
Subject: [PATCH 1/5] dt-bindings: phy: imx8mq-usb: add compatible
 "fsl,imx95-usb-phy"
In-Reply-To: <21557eac-44f0-451d-a194-c5d545cacbee@kernel.org>
References: <20240802091702.2057294-1-xu.yang_2@nxp.com>
 <21557eac-44f0-451d-a194-c5d545cacbee@kernel.org>
Message-ID: <20240805033658.s36ouzjienvf72p2@hippo>

On Sun, Aug 04, 2024 at 04:16:34PM +0200, Krzysztof Kozlowski wrote:
> On 02/08/2024 11:16, Xu Yang wrote:
> > The usb phy in i.MX95 is compatible with i.MX8MP's, this will add a
> > compatible "fsl,imx95-usb-phy" for i.MX95. Also change reg maxItems
> > to 2 since i.MX95 needs another regmap to control Type-C Assist (TCA)
> > block. Since i.MX95 usb phy is able to switch SS lanes, this will also
> > add orientation-switch and port property to the file.
> > 
> > Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> > ---
> >  .../bindings/phy/fsl,imx8mq-usb-phy.yaml      | 40 +++++++++++++++++--
> >  1 file changed, 36 insertions(+), 4 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
> > index dc3a3f709fea..b0a614a9556d 100644
> > --- a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
> > +++ b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
> > @@ -11,12 +11,17 @@ maintainers:
> >  
> >  properties:
> >    compatible:
> > -    enum:
> > -      - fsl,imx8mq-usb-phy
> > -      - fsl,imx8mp-usb-phy
> > +    oneOf:
> > +      - enum:
> > +          - fsl,imx8mq-usb-phy
> > +          - fsl,imx8mp-usb-phy
> > +      - items:
> > +          - const: fsl,imx95-usb-phy
> > +          - const: fsl,imx8mp-usb-phy
> >  
> >    reg:
> > -    maxItems: 1
> > +    minItems: 1
> > +    maxItems: 2
> >  
> >    "#phy-cells":
> >      const: 0
> > @@ -28,6 +33,17 @@ properties:
> >      items:
> >        - const: phy
> >  
> > +  orientation-switch:
> > +    description:
> > +      Flag the PHY as possible handler of USB Type-C orientation switching
> 
> No need to duplicate definitions of properties.

Okay. I need to use usb-switch.

> 
> > +    type: boolean
> > +
> > +  port:
> > +    $ref: /schemas/graph.yaml#/properties/port
> > +    description:
> > +      A port node to link the PHY to a TypeC controller for the purpose of
> > +      handling orientation switching.
> 
> Same here. You probably miss reference to usb-switch.

Okay.

> 
> > +
> >    power-domains:
> >      maxItems: 1
> >  
> > @@ -89,6 +105,22 @@ required:
> >    - clocks
> >    - clock-names
> >  
> > +allOf:
> > +  - if:
> > +      properties:
> > +        compatible:
> > +          contains:
> > +            enum:
> > +              - fsl,imx95-usb-phy
> > +    then:
> > +      properties:
> > +        reg:
> > +          minItems: 2
> 
> list and describe the items here, instead.

Okay.

Thanks,
Xu Yang

> 
> 
> Krzysztof
> 


From victor.liu at nxp.com  Sun Aug  4 22:01:25 2024
From: victor.liu at nxp.com (Liu Ying)
Date: Mon, 5 Aug 2024 13:01:25 +0800
Subject: [PATCH v2 09/16] drm/imx: Add i.MX8qxp Display Controller KMS
In-Reply-To: <3qmhbkx63hhncn3dl35tkhqcdo5bh2jypsfck656ylqrzfy4va@6xkgo32eg5du>
References: <20240712093243.2108456-1-victor.liu@nxp.com>
 <20240712093243.2108456-10-victor.liu@nxp.com>
 <reuwtcszfrh5vtkuckkng5zejbj3nh7ahgf2igy2kpyskxrgox@oigld6uy55aw>
 <93485a85-65d6-4c49-9869-19248efefae7@nxp.com>
 <3qmhbkx63hhncn3dl35tkhqcdo5bh2jypsfck656ylqrzfy4va@6xkgo32eg5du>
Message-ID: <722ea510-3d69-4c75-99a5-62f52c86082a@nxp.com>

On 07/31/2024, Dmitry Baryshkov wrote:
> On Tue, Jul 30, 2024 at 04:31:35PM GMT, Liu Ying wrote:
>> On 07/28/2024, Dmitry Baryshkov wrote:
>>> On Fri, Jul 12, 2024 at 05:32:36PM GMT, Liu Ying wrote:
>>>> i.MX8qxp Display Controller(DC) is comprised of three main components that
>>>> include a blit engine for 2D graphics accelerations, display controller for
>>>> display output processing, as well as a command sequencer.  Add kernel
>>>> mode setting support for the display controller part with two CRTCs and
>>>> two primary planes(backed by FetchLayer and FetchWarp respectively).  The
>>>> registers of the display controller are accessed without command sequencer
>>>> involved, instead just by using CPU.  The command sequencer is supposed to
>>>> be used by the blit engine.
>>>
>>> Generic comment: please consider moving dc_plane / dc_crtc defines to
>>> the source files and dropping the headers.
>>
>> struct dc_crtc is referenced from dc-drv.h and dc-kms.c.
>> struct dc_plane is referenced from dc-crtc.c and dc-drv.h.
>>
>> If no objections, I may drop dc-crtc.h and dc-plane.h,
>> and move necessary stuff to dc-kms.h.
>>
>>>
>>>>
>>>> Signed-off-by: Liu Ying <victor.liu at nxp.com>
>>>> ---
>>>> v2:
>>>> * Find next bridge from TCon's port.
>>>> * Drop drm/drm_module.h include from dc-drv.c.
>>>>
>>>>  drivers/gpu/drm/imx/dc/Kconfig    |   2 +
>>>>  drivers/gpu/drm/imx/dc/Makefile   |   5 +-
>>>>  drivers/gpu/drm/imx/dc/dc-crtc.c  | 578 ++++++++++++++++++++++++++++++
>>>>  drivers/gpu/drm/imx/dc/dc-crtc.h  |  67 ++++
>>>>  drivers/gpu/drm/imx/dc/dc-de.h    |   3 +
>>>>  drivers/gpu/drm/imx/dc/dc-drv.c   | 236 ++++++++++++
>>>>  drivers/gpu/drm/imx/dc/dc-drv.h   |  21 ++
>>>>  drivers/gpu/drm/imx/dc/dc-kms.c   | 143 ++++++++
>>>>  drivers/gpu/drm/imx/dc/dc-kms.h   |  15 +
>>>>  drivers/gpu/drm/imx/dc/dc-plane.c | 227 ++++++++++++
>>>>  drivers/gpu/drm/imx/dc/dc-plane.h |  37 ++
>>>>  11 files changed, 1332 insertions(+), 2 deletions(-)
>>>>  create mode 100644 drivers/gpu/drm/imx/dc/dc-crtc.c
>>>>  create mode 100644 drivers/gpu/drm/imx/dc/dc-crtc.h
>>>>  create mode 100644 drivers/gpu/drm/imx/dc/dc-kms.c
>>>>  create mode 100644 drivers/gpu/drm/imx/dc/dc-kms.h
>>>>  create mode 100644 drivers/gpu/drm/imx/dc/dc-plane.c
>>>>  create mode 100644 drivers/gpu/drm/imx/dc/dc-plane.h
>>>>
>>>> diff --git a/drivers/gpu/drm/imx/dc/Kconfig b/drivers/gpu/drm/imx/dc/Kconfig
>>>> index b66b815fbdf1..dac0de009273 100644
>>>> --- a/drivers/gpu/drm/imx/dc/Kconfig
>>>> +++ b/drivers/gpu/drm/imx/dc/Kconfig
>>>> @@ -1,6 +1,8 @@
>>>>  config DRM_IMX8_DC
>>>>  	tristate "Freescale i.MX8 Display Controller Graphics"
>>>>  	depends on DRM && COMMON_CLK && OF && (ARCH_MXC || COMPILE_TEST)
>>>> +	select DRM_GEM_DMA_HELPER
>>>> +	select DRM_KMS_HELPER
>>>>  	select GENERIC_IRQ_CHIP
>>>>  	help
>>>>  	  enable Freescale i.MX8 Display Controller(DC) graphics support
>>>> diff --git a/drivers/gpu/drm/imx/dc/Makefile b/drivers/gpu/drm/imx/dc/Makefile
>>>> index 1ce3e8a8db22..b9d33c074984 100644
>>>> --- a/drivers/gpu/drm/imx/dc/Makefile
>>>> +++ b/drivers/gpu/drm/imx/dc/Makefile
>>>> @@ -1,6 +1,7 @@
>>>>  # SPDX-License-Identifier: GPL-2.0
>>>>  
>>>> -imx8-dc-drm-objs := dc-cf.o dc-de.o dc-drv.o dc-ed.o dc-fg.o dc-fl.o dc-fu.o \
>>>> -		    dc-fw.o dc-ic.o dc-lb.o dc-pe.o dc-tc.o
>>>> +imx8-dc-drm-objs := dc-cf.o dc-crtc.o dc-de.o dc-drv.o dc-ed.o dc-fg.o dc-fl.o \
>>>> +		    dc-fu.o dc-fw.o dc-ic.o dc-kms.o dc-lb.o dc-pe.o \
>>>> +		    dc-plane.o dc-tc.o
>>>>  
>>>>  obj-$(CONFIG_DRM_IMX8_DC) += imx8-dc-drm.o
>>>> diff --git a/drivers/gpu/drm/imx/dc/dc-crtc.c b/drivers/gpu/drm/imx/dc/dc-crtc.c
>>>> new file mode 100644
>>>> index 000000000000..e151e14a6677
>>>> --- /dev/null
>>>> +++ b/drivers/gpu/drm/imx/dc/dc-crtc.c
>>>> @@ -0,0 +1,578 @@
>>>> +// SPDX-License-Identifier: GPL-2.0+
>>>> +/*
>>>> + * Copyright 2024 NXP
>>>> + */
>>>> +
>>>> +#include <linux/completion.h>
>>>> +#include <linux/interrupt.h>
>>>> +#include <linux/irqreturn.h>
>>>> +#include <linux/pm_runtime.h>
>>>> +#include <linux/spinlock.h>
>>>> +
>>>> +#include <drm/drm_atomic.h>
>>>> +#include <drm/drm_atomic_helper.h>
>>>> +#include <drm/drm_atomic_state_helper.h>
>>>> +#include <drm/drm_crtc.h>
>>>> +#include <drm/drm_device.h>
>>>> +#include <drm/drm_drv.h>
>>>> +#include <drm/drm_managed.h>
>>>> +#include <drm/drm_modes.h>
>>>> +#include <drm/drm_modeset_helper_vtables.h>
>>>> +#include <drm/drm_plane.h>
>>>> +#include <drm/drm_vblank.h>
>>>> +
>>>> +#include "dc-crtc.h"
>>>> +#include "dc-de.h"
>>>> +#include "dc-drv.h"
>>>> +#include "dc-pe.h"
>>>> +#include "dc-plane.h"
>>>> +
>>>> +#define DC_CRTC_WAIT_FOR_COMPLETION_TIMEOUT(c)				\
>>>> +do {									\
>>>> +	unsigned long ret;						\
>>>> +	ret = wait_for_completion_timeout(&dc_crtc->c, HZ);		\
>>>> +	if (ret == 0)							\
>>>> +		dc_crtc_err(crtc, "%s: wait for " #c " timeout\n",	\
>>>> +							__func__);	\
>>>> +} while (0)
>>>> +
>>>> +#define DC_CRTC_CHECK_FRAMEGEN_FIFO(fg)					\
>>>> +do {									\
>>>> +	typeof(fg) _fg = (fg);						\
>>>> +	if (dc_fg_secondary_requests_to_read_empty_fifo(_fg)) {		\
>>>> +		dc_fg_secondary_clear_channel_status(_fg);		\
>>>> +		dc_crtc_err(crtc, "%s: FrameGen FIFO empty\n",		\
>>>> +							__func__);	\
>>>> +	}								\
>>>> +} while (0)
>>>> +
>>>> +#define DC_CRTC_WAIT_FOR_FRAMEGEN_SECONDARY_SYNCUP(fg)			\
>>>> +do {									\
>>>> +	if (dc_fg_wait_for_secondary_syncup(fg))			\
>>>> +		dc_crtc_err(crtc,					\
>>>> +			"%s: FrameGen secondary channel isn't syncup\n",\
>>>> +							__func__);	\
>>>> +} while (0)
>>>> +
>>>> +static u32 dc_crtc_get_vblank_counter(struct drm_crtc *crtc)
>>>> +{
>>>> +	struct dc_crtc *dc_crtc = to_dc_crtc(crtc);
>>>> +
>>>> +	return dc_fg_get_frame_index(dc_crtc->fg);
>>>> +}
>>>> +
>>>> +static int dc_crtc_enable_vblank(struct drm_crtc *crtc)
>>>> +{
>>>> +	struct dc_crtc *dc_crtc = to_dc_crtc(crtc);
>>>> +
>>>> +	enable_irq(dc_crtc->irq_dec_framecomplete);
>>>> +
>>>> +	return 0;
>>>> +}
>>>> +
>>>> +static void dc_crtc_disable_vblank(struct drm_crtc *crtc)
>>>> +{
>>>> +	struct dc_crtc *dc_crtc = to_dc_crtc(crtc);
>>>> +
>>>> +	disable_irq_nosync(dc_crtc->irq_dec_framecomplete);
>>>> +}
>>>> +
>>>> +static irqreturn_t
>>>> +dc_crtc_dec_framecomplete_irq_handler(int irq, void *dev_id)
>>>> +{
>>>> +	struct dc_crtc *dc_crtc = dev_id;
>>>> +	struct drm_crtc *crtc = &dc_crtc->base;
>>>> +	unsigned long flags;
>>>> +
>>>> +	drm_crtc_handle_vblank(crtc);
>>>> +
>>>> +	spin_lock_irqsave(&crtc->dev->event_lock, flags);
>>>> +	if (dc_crtc->event) {
>>>> +		drm_crtc_send_vblank_event(crtc, dc_crtc->event);
>>>> +		dc_crtc->event = NULL;
>>>> +		drm_crtc_vblank_put(crtc);
>>>> +	}
>>>> +	spin_unlock_irqrestore(&crtc->dev->event_lock, flags);
>>>> +
>>>> +	return IRQ_HANDLED;
>>>> +}
>>>> +
>>>> +static irqreturn_t dc_crtc_common_irq_handler(int irq, void *dev_id)
>>>> +{
>>>> +	struct dc_crtc *dc_crtc = dev_id;
>>>> +	struct drm_crtc *crtc = &dc_crtc->base;
>>>> +
>>>> +	if (irq == dc_crtc->irq_dec_seqcomplete) {
>>>> +		complete(&dc_crtc->dec_seqcomplete_done);
>>>> +	} else if (irq == dc_crtc->irq_dec_shdld) {
>>>> +		complete(&dc_crtc->dec_shdld_done);
>>>> +	} else if (irq == dc_crtc->irq_ed_cont_shdld) {
>>>> +		complete(&dc_crtc->ed_cont_shdld_done);
>>>> +	} else if (irq == dc_crtc->irq_ed_safe_shdld) {
>>>> +		complete(&dc_crtc->ed_safe_shdld_done);
>>>> +	} else {
>>>> +		dc_crtc_err(crtc, "invalid CRTC irq(%u)\n", irq);
>>>> +		return IRQ_NONE;
>>>
>>> And this is a counter-example to my previous questions. If you had 4
>>> separate handlers, there would have been no need for the futile "invalid
>>> CRTC" error, because it would not be possible at all.
>>
>> Ok, will drop the else clause.  Thanks.
>>
>>>
>>>> +	}
>>>> +
>>>> +	return IRQ_HANDLED;
>>>> +}
>>>> +
>>>> +static const struct drm_crtc_funcs dc_crtc_funcs = {
>>>> +	.reset			= drm_atomic_helper_crtc_reset,
>>>> +	.destroy		= drm_crtc_cleanup,
>>>> +	.set_config		= drm_atomic_helper_set_config,
>>>> +	.page_flip		= drm_atomic_helper_page_flip,
>>>> +	.atomic_duplicate_state	= drm_atomic_helper_crtc_duplicate_state,
>>>> +	.atomic_destroy_state	= drm_atomic_helper_crtc_destroy_state,
>>>> +	.get_vblank_counter	= dc_crtc_get_vblank_counter,
>>>> +	.enable_vblank		= dc_crtc_enable_vblank,
>>>> +	.disable_vblank		= dc_crtc_disable_vblank,
>>>> +	.get_vblank_timestamp	= drm_crtc_vblank_helper_get_vblank_timestamp,
>>>> +};
>>>> +
>>>> +static void dc_crtc_queue_state_event(struct drm_crtc_state *crtc_state)
>>>> +{
>>>> +	struct drm_crtc *crtc = crtc_state->crtc;
>>>> +	struct dc_crtc *dc_crtc = to_dc_crtc(crtc);
>>>> +
>>>> +	spin_lock_irq(&crtc->dev->event_lock);
>>>> +	if (crtc_state->event) {
>>>> +		WARN_ON(drm_crtc_vblank_get(crtc));
>>>> +		WARN_ON(dc_crtc->event);
>>>> +		dc_crtc->event = crtc_state->event;
>>>> +		crtc_state->event = NULL;
>>>> +	}
>>>> +	spin_unlock_irq(&crtc->dev->event_lock);
>>>> +}
>>>> +
>>>> +static enum drm_mode_status
>>>> +dc_crtc_check_clock(struct dc_crtc *dc_crtc, int clk_khz)
>>>> +{
>>>> +	return dc_fg_check_clock(dc_crtc->fg, clk_khz);
>>>> +}
>>>> +
>>>> +static enum drm_mode_status
>>>> +dc_crtc_mode_valid(struct drm_crtc *crtc, const struct drm_display_mode *mode)
>>>> +{
>>>> +	struct dc_crtc *dc_crtc = to_dc_crtc(crtc);
>>>> +	enum drm_mode_status status;
>>>> +
>>>> +	status = dc_crtc_check_clock(dc_crtc, mode->clock);
>>>> +	if (status != MODE_OK)
>>>> +		return status;
>>>> +
>>>> +	if (mode->crtc_clock > DC_FRAMEGEN_MAX_CLOCK_KHZ)
>>>> +		return MODE_CLOCK_HIGH;
>>>> +
>>>> +	return MODE_OK;
>>>> +}
>>>> +
>>>> +static int
>>>> +dc_crtc_atomic_check(struct drm_crtc *crtc, struct drm_atomic_state *state)
>>>> +{
>>>> +	struct drm_crtc_state *new_crtc_state =
>>>> +				drm_atomic_get_new_crtc_state(state, crtc);
>>>> +	struct drm_display_mode *adj = &new_crtc_state->adjusted_mode;
>>>> +	struct dc_crtc *dc_crtc = to_dc_crtc(crtc);
>>>> +	enum drm_mode_status status;
>>>> +
>>>> +	status = dc_crtc_check_clock(dc_crtc, adj->clock);
>>>> +	if (status != MODE_OK)
>>>> +		return -EINVAL;
>>>> +
>>>> +	return 0;
>>>> +}
>>>> +
>>>> +static void
>>>> +dc_crtc_atomic_begin(struct drm_crtc *crtc, struct drm_atomic_state *state)
>>>> +{
>>>> +	struct drm_crtc_state *new_crtc_state =
>>>> +				drm_atomic_get_new_crtc_state(state, crtc);
>>>> +	struct dc_drm_device *dc_drm = to_dc_drm_device(crtc->dev);
>>>> +	struct dc_crtc *dc_crtc = to_dc_crtc(crtc);
>>>> +	int idx, ret;
>>>> +
>>>> +	if (!drm_atomic_crtc_needs_modeset(new_crtc_state) ||
>>>> +	    !new_crtc_state->active)
>>>> +		return;
>>>
>>> Why? Can it be called under such conditions?
>>
>> This is needed to make sure the balance of calling
>> pm_runtime_resume_and_get(dc_crtc->pe->dev)
>> from dc_crtc_atomic_begin() and calling
>> pm_runtime_put(dc_crtc->pe->dev)
>> from dc_crtc_atomic_disable().
>>
>> pm_runtime_resume_and_get(dc_crtc->pe->dev) is called
>> only when the CRTC is to be enabled with a modeset
>> commit.
>>
>>>
>>>> +
>>>> +	if (!drm_dev_enter(crtc->dev, &idx))
>>>> +		return;
>>>
>>> Can you please give an example of a driver using drm_dev_enter()/_exit()
>>> in DRM callbacks?
>>
>> vc4.
>>
>> BTW, this is required by Maxime, as noted in cover letter.
>>
>>>
>>>> +
>>>> +	/* request pixel engine power-on when CRTC starts to be active */
>>>> +	ret = pm_runtime_resume_and_get(dc_crtc->pe->dev);
>>>
>>> This function doesn't return an error. So if pm_runtime_resume_and_get()
>>
>> Kerneldoc of pm_runtime_resume_and_get() mentions error code.
>> '
>> or a negative error code otherwise
>> '
>> So, it may return an error.
>>
>>> didn't increment the counter, corresponding pm_runtime_put() might cause
>>> an underflow. Instead void functions should use pm_runtime_get_sync()
>>
>> pm_runtime_resume_and_get() is called from dc_crtc_atomic_begin(), which
>> is atomic considering the general DRM atomic KMS idea.  So, if the call
>> returns an error, the best we can do is to print the error out like
>> this driver does IMO.  The call should not fail in the first place due
>> to the "atomic" sense, though it can fail in theory.
>>
>> pm_runtime_get_sync() may also return an error. And it's Kerneldoc kinda
>> says pm_runtime_resume_and_get() is better.
>> '
>> Consider using pm_runtime_resume_and_get() instead of it, especially
>> if its return value is checked by the caller, as this is likely to result
>> in cleaner code.
>> '
>>
>>>
>>> Also can any of the code running afterwards result in the unclocked
>>> exception if resume fails?
>>
>> Yes.  But, it's all atomic anyway...
>>
>>>
>>>> +	if (ret)
>>>> +		dc_crtc_err(crtc, "failed to get DC pixel engine RPM: %d\n",
>>>> +			    ret);
>>>> +
>>>> +	atomic_inc(&dc_drm->pe_rpm_count);
>>>
>>> Why do you need a separate RPM count? RPM code already has one.
>>
>> If no objections, I will drop the count and call
>> pm_runtime_active(dc_crtc->pe->dev) from dc_crtc_disable_at_unbind().
> 
> Why do you need the disable_at_unbind() thing? Doesn't shutdown take
> care of disabling it for you?

It is used to balance PM runtime usage counter, because shutdown is
called after drm_dev_unplug() which means pm_runtime_put() function
calls in ->atomic_disable() are skipped due to drm_dev_enter().

> 
>>
>> Thanks.
>>
>>>
>>>> +
>>>> +	drm_dev_exit(idx);
>>>> +}
>>>> +
>>>
>>>
>>> [...]
>>>
>>>> +
>>>> +static int
>>>> +dc_crtc_request_irq(struct dc_crtc *dc_crtc, struct device *dev,
>>>> +		    unsigned int irq,
>>>> +		    irqreturn_t (*irq_handler)(int irq, void *dev_id))
>>>> +{
>>>> +	int ret;
>>>> +
>>>> +	ret = request_irq(irq, irq_handler, IRQF_NO_AUTOEN, dev_name(dev),
>>>> +			  dc_crtc);
>>>> +	if (ret < 0)
>>>> +		dev_err(dev, "failed to request irq(%u): %d\n", irq, ret);
>>>> +
>>>> +	return ret;
>>>> +}
>>>> +
>>>> +static int dc_crtc_request_irqs(struct drm_device *drm, struct dc_crtc *dc_crtc)
>>>> +{
>>>> +	struct {
>>>> +		struct device *dev;
>>>> +		unsigned int irq;
>>>> +		irqreturn_t (*irq_handler)(int irq, void *dev_id);
>>>> +	} irqs[] = {
>>>> +		{
>>>> +			dc_crtc->de->dev,
>>>> +			dc_crtc->irq_dec_framecomplete,
>>>> +			dc_crtc_dec_framecomplete_irq_handler,
>>>> +		}, {
>>>> +			dc_crtc->de->dev,
>>>> +			dc_crtc->irq_dec_seqcomplete,
>>>> +			dc_crtc_common_irq_handler,
>>>> +		}, {
>>>> +			dc_crtc->de->dev,
>>>> +			dc_crtc->irq_dec_shdld,
>>>> +			dc_crtc_common_irq_handler,
>>>> +		}, {
>>>> +			dc_crtc->ed_cont->dev,
>>>> +			dc_crtc->irq_ed_cont_shdld,
>>>> +			dc_crtc_common_irq_handler,
>>>> +		}, {
>>>> +			dc_crtc->ed_safe->dev,
>>>> +			dc_crtc->irq_ed_safe_shdld,
>>>> +			dc_crtc_common_irq_handler,
>>>> +		},
>>>> +	};
>>>> +	struct drm_crtc *crtc = &dc_crtc->base;
>>>> +	int i, ret;
>>>> +
>>>> +	dc_crtc->irqs = drmm_kcalloc(drm, ARRAY_SIZE(irqs),
>>>> +				     sizeof(*dc_crtc->irqs), GFP_KERNEL);
>>>
>>> Using array would remove the necessity to call drmm_kcalloc here().
>>
>> Ok, I may use a macro to define the array size instead.
>>
>> #define DC_CRTC_IRQS    5
> 
> Just embed the array into dc_crtc, no need for extra defines.

The array sizes of dc_crtc->irqs[] and the local irqs[] are the same.
Wouldn't it be straightforward to use macro DC_CRTC_IRQS to make
sure they are the same?

> 
>>
>>
>>>
>>>> +	if (!dc_crtc->irqs) {
>>>> +		dev_err(drm->dev, "failed to allocate CRTC%u irqs\n",
>>>> +			crtc->index);
>>>> +		return -ENOMEM;
>>>> +	}
>>>> +
>>>> +	for (i = 0; i < ARRAY_SIZE(irqs); i++) {
>>>> +		struct dc_crtc_irq *irq = &dc_crtc->irqs[i];
>>>> +
>>>> +		ret = dc_crtc_request_irq(dc_crtc, irqs[i].dev, irqs[i].irq,
>>>> +					  irqs[i].irq_handler);
>>>> +		if (ret)
>>>> +			return ret;
>>>> +
>>>> +		irq->dc_crtc = dc_crtc;
>>>> +		irq->irq = irqs[i].irq;
>>>> +
>>>> +		ret = drmm_add_action_or_reset(drm, dc_crtc_free_irq, irq);
>>>
>>> Can you use devm_request_irq() instead?
>>
>> No.
>>
>> The requested irqs would be freed too late as devm_of_platform_populate()
>> is called early from dc_probe().  They would be freed later than the time
>> point where irq domain is removed from dc_ic_unbind().  That would cause
>> a kernel Oops as I tried.
> 
> Ohh, you are using drmm here. Please don't use drmm for IRQ domains.

Can you please tell the reason?

Are you talking about the drmm_kzalloc() and drmm_kcalloc() function calls
in dc_ic_bind()?

> 
>>
>>>
>>>> +		if (ret)
>>>> +			return ret;
>>>> +	}
>>>> +
>>>> +	return 0;
>>>> +}
>>>> +
>>>
>>> [...]
>>>
>>>> +
>>>> +static int dc_kms_init_encoder_per_crtc(struct dc_drm_device *dc_drm,
>>>> +					int crtc_index)
>>>> +{
>>>> +	struct dc_crtc *dc_crtc = &dc_drm->dc_crtc[crtc_index];
>>>> +	struct drm_device *drm = &dc_drm->base;
>>>> +	struct drm_crtc *crtc = &dc_crtc->base;
>>>> +	struct drm_connector *connector;
>>>> +	struct device *dev = drm->dev;
>>>> +	struct drm_encoder *encoder;
>>>> +	struct device_node *remote;
>>>> +	struct drm_bridge *bridge;
>>>> +	int ret = 0;
>>>> +
>>>> +	remote = of_graph_get_remote_node(dc_crtc->de->tc->dev->of_node, 0, -1);
>>>> +	if (!of_device_is_available(remote))
>>>> +		goto out;
>>>> +
>>>> +	bridge = of_drm_find_bridge(remote);
>>>
>>> drm_of_find_panel_or_bridge() instead.
>>
>> Nope.
>>
>> The first bridge is always pixel combiner according to SoC design.
>> It can't be a panel.
> 
> So pass NULL as a panel pointer. At least it saves you from calling
> of_graph_get_remote_node() manually.

Kerneldoc of drm_of_find_panel_or_bridge() says it's deprecated and should
not be used in new drivers.  I'll use devm_drm_of_get_bridge().

> 
>>>> +	if (!bridge) {
>>>> +		ret = -EPROBE_DEFER;
>>>> +		dev_err_probe(dev, ret, "failed to find bridge for CRTC%u\n",
>>>> +			      crtc->index);
>>>> +		goto out;
>>>> +	}
>>>> +
>>>> +	encoder = &dc_drm->encoder[crtc_index];
>>>> +	ret = drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_NONE);
>>>> +	if (ret) {
>>>> +		dev_err(dev, "failed to initialize encoder for CRTC%u: %d\n",
>>>> +			crtc->index, ret);
>>>> +		goto out;
>>>> +	}
>>>> +
>>>> +	encoder->possible_crtcs = drm_crtc_mask(crtc);
>>>> +
>>>> +	ret = drm_bridge_attach(encoder, bridge, NULL,
>>>> +				DRM_BRIDGE_ATTACH_NO_CONNECTOR);
>>>> +	if (ret) {
>>>> +		dev_err(dev,
>>>> +			"failed to attach bridge to encoder for CRTC%u: %d\n",
>>>> +			crtc->index, ret);
>>>> +		goto out;
>>>> +	}
>>>> +
>>>> +	connector = drm_bridge_connector_init(drm, encoder);
>>>> +	if (IS_ERR(connector)) {
>>>> +		ret = PTR_ERR(connector);
>>>> +		dev_err(dev, "failed to init bridge connector for CRTC%u: %d\n",
>>>> +			crtc->index, ret);
>>>> +		goto out;
>>>> +	}
>>>> +
>>>> +	ret = drm_connector_attach_encoder(connector, encoder);
>>>> +	if (ret)
>>>> +		dev_err(dev,
>>>> +			"failed to attach encoder to connector for CRTC%u: %d\n",
>>>> +			crtc->index, ret);
>>>> +
>>>> +out:
>>>> +	of_node_put(remote);
>>>> +	return ret;
>>>> +}
>>>> +
>>>> +int dc_kms_init(struct dc_drm_device *dc_drm)
>>>> +{
>>>> +	struct drm_device *drm = &dc_drm->base;
>>>> +	int ret, i;
>>>> +
>>>> +	ret = drmm_mode_config_init(drm);
>>>> +	if (ret)
>>>> +		return ret;
>>>> +
>>>> +	atomic_set(&dc_drm->pe_rpm_count, 0);
>>>> +
>>>> +	drm->mode_config.min_width = 60;
>>>> +	drm->mode_config.min_height = 60;
>>>> +	drm->mode_config.max_width = 8192;
>>>> +	drm->mode_config.max_height = 8192;
>>>> +	drm->mode_config.funcs = &dc_drm_mode_config_funcs;
>>>> +
>>>> +	drm->vblank_disable_immediate = true;
>>>> +	drm->max_vblank_count = DC_FRAMEGEN_MAX_FRAME_INDEX;
>>>> +
>>>> +	for (i = 0; i < DC_CRTCS; i++) {
>>>> +		ret = dc_crtc_init(dc_drm, i);
>>>> +		if (ret)
>>>> +			return ret;
>>>> +
>>>> +		ret = dc_kms_init_encoder_per_crtc(dc_drm, i);
>>>> +		if (ret)
>>>> +			return ret;
>>>> +	}
>>>> +
>>>> +	ret = drm_vblank_init(drm, DC_CRTCS);
>>>> +	if (ret) {
>>>> +		dev_err(drm->dev, "failed to init vblank support: %d\n", ret);
>>>> +		return ret;
>>>> +	}
>>>> +
>>>> +	drm_mode_config_reset(drm);
>>>> +
>>>> +	drm_kms_helper_poll_init(drm);
>>>> +
>>>> +	return 0;
>>>> +}
>>>> +
>>>> +void dc_kms_uninit(struct dc_drm_device *dc_drm)
>>>> +{
>>>> +	drm_kms_helper_poll_fini(&dc_drm->base);
>>>> +}
>>>> diff --git a/drivers/gpu/drm/imx/dc/dc-kms.h b/drivers/gpu/drm/imx/dc/dc-kms.h
>>>> new file mode 100644
>>>> index 000000000000..4f66b11c106a
>>>> --- /dev/null
>>>> +++ b/drivers/gpu/drm/imx/dc/dc-kms.h
>>>> @@ -0,0 +1,15 @@
>>>> +/* SPDX-License-Identifier: GPL-2.0+ */
>>>> +/*
>>>> + * Copyright 2024 NXP
>>>> + */
>>>> +
>>>> +#ifndef __DC_KMS_H__
>>>> +#define __DC_KMS_H__
>>>> +
>>>> +#include "dc-de.h"
>>>> +
>>>> +#define DC_CRTCS	DC_DISPLAYS
>>>> +#define DC_ENCODERS	DC_DISPLAYS
>>>> +#define DC_PRIMARYS	DC_DISPLAYS
>>>
>>> If they are all equal, why do you need separate defines?
>>
>> Hmm, just for meaningful macro names to make code easy to read.
> 
> From my POV it makes code harder to read, as the reviewer has to keep in
> mind that those values are all the same.

Will only use DC_DISPLAYS and drop the rest.

> 
>>
>>>
>>>> +
>>>> +#endif /* __DC_KMS_H__ */
>>>> diff --git a/drivers/gpu/drm/imx/dc/dc-plane.c b/drivers/gpu/drm/imx/dc/dc-plane.c
>>>> new file mode 100644
>>>> index 000000000000..a49b043ca167
>>>> --- /dev/null
>>>> +++ b/drivers/gpu/drm/imx/dc/dc-plane.c
>>>> @@ -0,0 +1,227 @@
>>>> +// SPDX-License-Identifier: GPL-2.0+
>>>> +/*
>>>> + * Copyright 2024 NXP
>>>> + */
>>>> +
>>>> +#include <drm/drm_atomic.h>
>>>> +#include <drm/drm_atomic_helper.h>
>>>> +#include <drm/drm_atomic_state_helper.h>
>>>> +#include <drm/drm_crtc.h>
>>>> +#include <drm/drm_drv.h>
>>>> +#include <drm/drm_fb_dma_helper.h>
>>>> +#include <drm/drm_fourcc.h>
>>>> +#include <drm/drm_framebuffer.h>
>>>> +#include <drm/drm_gem_atomic_helper.h>
>>>> +#include <drm/drm_plane_helper.h>
>>>> +
>>>> +#include "dc-drv.h"
>>>> +#include "dc-fu.h"
>>>> +#include "dc-plane.h"
>>>> +
>>>> +#define DC_PLANE_MAX_PITCH	0x10000
>>>> +#define DC_PLANE_MAX_PIX_CNT	8192
>>>> +
>>>> +static const uint32_t dc_plane_formats[] = {
>>>> +	DRM_FORMAT_XRGB8888,
>>>> +};
>>>> +
>>>> +static const struct drm_plane_funcs dc_plane_funcs = {
>>>> +	.update_plane		= drm_atomic_helper_update_plane,
>>>> +	.disable_plane		= drm_atomic_helper_disable_plane,
>>>> +	.destroy		= drm_plane_cleanup,
>>>> +	.reset			= drm_atomic_helper_plane_reset,
>>>> +	.atomic_duplicate_state	= drm_atomic_helper_plane_duplicate_state,
>>>> +	.atomic_destroy_state	= drm_atomic_helper_plane_destroy_state,
>>>> +};
>>>> +
>>>> +static int dc_plane_check_no_off_screen(struct drm_plane_state *state,
>>>> +					struct drm_crtc_state *crtc_state)
>>>> +{
>>>> +	if (state->dst.x1 < 0 || state->dst.y1 < 0 ||
>>>> +	    state->dst.x2 > crtc_state->adjusted_mode.hdisplay ||
>>>> +	    state->dst.y2 > crtc_state->adjusted_mode.vdisplay) {
>>>> +		dc_plane_dbg(state->plane, "no off screen\n");
>>>> +		return -EINVAL;
>>>> +	}
>>>> +
>>>> +	return 0;
>>>> +}
>>>> +
>>>> +static int dc_plane_check_max_source_resolution(struct drm_plane_state *state)
>>>> +{
>>>> +	int src_h = drm_rect_height(&state->src) >> 16;
>>>> +	int src_w = drm_rect_width(&state->src) >> 16;
>>>> +
>>>> +	if (src_w > DC_PLANE_MAX_PIX_CNT || src_h > DC_PLANE_MAX_PIX_CNT) {
>>>> +		dc_plane_dbg(state->plane, "invalid source resolution\n");
>>>> +		return -EINVAL;
>>>> +	}
>>>> +
>>>> +	return 0;
>>>> +}
>>>> +
>>>> +static int dc_plane_check_fb(struct drm_plane_state *state)
>>>> +{
>>>> +	struct drm_framebuffer *fb = state->fb;
>>>> +	dma_addr_t baseaddr = drm_fb_dma_get_gem_addr(fb, state, 0);
>>>> +
>>>> +	/* base address alignment */
>>>> +	if (baseaddr & 0x3) {
>>>> +		dc_plane_dbg(state->plane, "fb bad baddr alignment\n");
>>>> +		return -EINVAL;
>>>> +	}
>>>> +
>>>> +	/* pitches[0] range */
>>>> +	if (fb->pitches[0] > DC_PLANE_MAX_PITCH) {
>>>> +		dc_plane_dbg(state->plane, "fb pitches[0] is out of range\n");
>>>> +		return -EINVAL;
>>>> +	}
>>>> +
>>>> +	/* pitches[0] alignment */
>>>> +	if (fb->pitches[0] & 0x3) {
>>>> +		dc_plane_dbg(state->plane, "fb bad pitches[0] alignment\n");
>>>> +		return -EINVAL;
>>>> +	}
>>>> +
>>>> +	return 0;
>>>> +}
>>>> +
>>>> +static int
>>>> +dc_plane_atomic_check(struct drm_plane *plane, struct drm_atomic_state *state)
>>>> +{
>>>> +	struct drm_plane_state *plane_state =
>>>> +				drm_atomic_get_new_plane_state(state, plane);
>>>> +	struct drm_crtc_state *crtc_state;
>>>> +	int ret;
>>>> +
>>>> +	/* ok to disable */
>>>> +	if (!plane_state->fb)
>>>> +		return 0;
>>>> +
>>>> +	if (!plane_state->crtc) {
>>>> +		dc_plane_dbg(plane, "no CRTC in plane state\n");
>>>> +		return -EINVAL;
>>>> +	}
>>>> +
>>>> +	crtc_state =
>>>> +		drm_atomic_get_existing_crtc_state(state, plane_state->crtc);
>>>> +	if (WARN_ON(!crtc_state))
>>>> +		return -EINVAL;
>>>> +
>>>> +	ret = drm_atomic_helper_check_plane_state(plane_state, crtc_state,
>>>> +						  DRM_PLANE_NO_SCALING,
>>>> +						  DRM_PLANE_NO_SCALING,
>>>> +						  true, false);
>>>> +	if (ret) {
>>>> +		dc_plane_dbg(plane, "failed to check plane state: %d\n", ret);
>>>> +		return ret;
>>>> +	}
>>>> +
>>>> +	ret = dc_plane_check_no_off_screen(plane_state, crtc_state);
>>>> +	if (ret)
>>>> +		return ret;
>>>> +
>>>> +	ret = dc_plane_check_max_source_resolution(plane_state);
>>>> +	if (ret)
>>>> +		return ret;
>>>> +
>>>> +	return dc_plane_check_fb(plane_state);
>>>> +}
>>>> +
>>>> +static void
>>>> +dc_plane_atomic_update(struct drm_plane *plane, struct drm_atomic_state *state)
>>>> +{
>>>> +	struct drm_plane_state *new_state =
>>>> +				drm_atomic_get_new_plane_state(state, plane);
>>>> +	struct dc_plane *dplane = to_dc_plane(plane);
>>>> +	struct drm_framebuffer *fb = new_state->fb;
>>>> +	const struct dc_fu_ops *fu_ops;
>>>> +	struct dc_lb *lb = dplane->lb;
>>>> +	struct dc_fu *fu = dplane->fu;
>>>> +	dma_addr_t baseaddr;
>>>> +	int src_w, src_h;
>>>> +	int idx;
>>>> +
>>>> +	if (!drm_dev_enter(plane->dev, &idx))
>>>> +		return;
>>>> +
>>>> +	src_w = drm_rect_width(&new_state->src) >> 16;
>>>> +	src_h = drm_rect_height(&new_state->src) >> 16;
>>>> +
>>>> +	baseaddr = drm_fb_dma_get_gem_addr(fb, new_state, 0);
>>>> +
>>>> +	fu_ops = dc_fu_get_ops(dplane->fu);
>>>> +
>>>> +	fu_ops->set_layerblend(fu, lb);
>>>> +	fu_ops->set_burstlength(fu, baseaddr);
>>>> +	fu_ops->set_src_stride(fu, fb->pitches[0]);
>>>> +	fu_ops->set_src_buf_dimensions(fu, src_w, src_h);
>>>> +	fu_ops->set_fmt(fu, fb->format);
>>>> +	fu_ops->set_framedimensions(fu, src_w, src_h);
>>>> +	fu_ops->set_baseaddress(fu, baseaddr);
>>>> +	fu_ops->enable_src_buf(fu);
>>>
>>> Are you expecting that these ops might change? Can you call the function
>>> directly?
>>
>> Looking at struct dc_fl and struct dc_fw, you may find struct dc_fu
>> is the base class.  These function calls take struct dc_fu as
>> arguments so that derived instances may specify their implementations.
>>
>> So, I can't call their implementation functions directly.
> 
> Ack.

Thanks.

> 
>>
>>>
>>>> +
>>>> +	dc_plane_dbg(plane, "uses %s\n", fu_ops->get_name(fu));
>>>> +
>>>> +	dc_lb_pec_dynamic_prim_sel(lb, dc_cf_get_link_id(dplane->cf));
>>>> +	dc_lb_pec_dynamic_sec_sel(lb, fu_ops->get_link_id(fu));
>>>> +	dc_lb_mode(lb, LB_BLEND);
>>>> +	dc_lb_blendcontrol(lb);
>>>> +	dc_lb_position(lb, new_state->dst.x1, new_state->dst.y1);
>>>> +	dc_lb_pec_clken(lb, CLKEN_AUTOMATIC);
>>>> +
>>>> +	dc_plane_dbg(plane, "uses LayerBlend%u\n", dc_lb_get_id(lb));
>>>> +
>>>> +	/* set ExtDst's source to LayerBlend */
>>>> +	dc_ed_pec_src_sel(dplane->ed, dc_lb_get_link_id(lb));
>>>> +
>>>> +	drm_dev_exit(idx);
>>>> +}
>>>> +
>>>> +static void dc_plane_atomic_disable(struct drm_plane *plane,
>>>> +				    struct drm_atomic_state *state)
>>>> +{
>>>> +	struct dc_plane *dplane = to_dc_plane(plane);
>>>> +	const struct dc_fu_ops *fu_ops;
>>>> +	int idx;
>>>> +
>>>> +	if (!drm_dev_enter(plane->dev, &idx))
>>>> +		return;
>>>> +
>>>> +	/* disable fetchunit in shadow */
>>>> +	fu_ops = dc_fu_get_ops(dplane->fu);
>>>> +	fu_ops->disable_src_buf(dplane->fu);
>>>> +
>>>> +	/* set ExtDst's source to ConstFrame */
>>>> +	dc_ed_pec_src_sel(dplane->ed, dc_cf_get_link_id(dplane->cf));
>>>> +
>>>> +	drm_dev_exit(idx);
>>>> +}
>>>> +
>>>> +static const struct drm_plane_helper_funcs dc_plane_helper_funcs = {
>>>> +	.atomic_check = dc_plane_atomic_check,
>>>> +	.atomic_update = dc_plane_atomic_update,
>>>> +	.atomic_disable = dc_plane_atomic_disable,
>>>> +};
>>>> +
>>>> +int dc_plane_init(struct dc_drm_device *dc_drm, struct dc_plane *dc_plane)
>>>> +{
>>>> +	struct drm_plane *plane = &dc_plane->base;
>>>> +	int ret;
>>>> +
>>>> +	ret = drm_universal_plane_init(&dc_drm->base, plane, 0, &dc_plane_funcs,
>>>> +				       dc_plane_formats,
>>>> +				       ARRAY_SIZE(dc_plane_formats),
>>>> +				       NULL, DRM_PLANE_TYPE_PRIMARY, NULL);
>>>> +	if (ret)
>>>> +		return ret;
>>>> +
>>>> +	drm_plane_helper_add(plane, &dc_plane_helper_funcs);
>>>> +
>>>> +	dc_plane->fu = dc_drm->pe->fu_disp[plane->index];
>>>> +	dc_plane->cf = dc_drm->pe->cf_cont[plane->index];
>>>> +	dc_plane->lb = dc_drm->pe->lb[plane->index];
>>>> +	dc_plane->ed = dc_drm->pe->ed_cont[plane->index];
>>>> +
>>>> +	return 0;
>>>> +}
>>>> diff --git a/drivers/gpu/drm/imx/dc/dc-plane.h b/drivers/gpu/drm/imx/dc/dc-plane.h
>>>> new file mode 100644
>>>> index 000000000000..e72c3a7cb66f
>>>> --- /dev/null
>>>> +++ b/drivers/gpu/drm/imx/dc/dc-plane.h
>>>> @@ -0,0 +1,37 @@
>>>> +/* SPDX-License-Identifier: GPL-2.0+ */
>>>> +/*
>>>> + * Copyright 2024 NXP
>>>> + */
>>>> +
>>>> +#ifndef __DC_PLANE_H__
>>>> +#define __DC_PLANE_H__
>>>> +
>>>> +#include <linux/container_of.h>
>>>> +
>>>> +#include <drm/drm_plane.h>
>>>> +#include <drm/drm_print.h>
>>>> +
>>>> +#include "dc-fu.h"
>>>> +#include "dc-pe.h"
>>>> +
>>>> +#define dc_plane_dbg(plane, fmt, ...)					\
>>>> +do {									\
>>>> +	typeof(plane) _plane = (plane);					\
>>>> +	drm_dbg_kms(_plane->dev, "[PLANE:%d:%s] " fmt,			\
>>>> +		    _plane->base.id, _plane->name, ##__VA_ARGS__);	\
>>>> +} while (0)
>>>> +
>>>> +struct dc_plane {
>>>> +	struct drm_plane base;
>>>> +	struct dc_fu *fu;
>>>> +	struct dc_cf *cf;
>>>> +	struct dc_lb *lb;
>>>> +	struct dc_ed *ed;
>>>> +};
>>>> +
>>>> +static inline struct dc_plane *to_dc_plane(struct drm_plane *plane)
>>>> +{
>>>> +	return container_of(plane, struct dc_plane, base);
>>>> +}
>>>> +
>>>> +#endif /* __DC_PLANE_H__ */
>>>> -- 
>>>> 2.34.1
>>>>
>>>
>>
>> -- 
>> Regards,
>> Liu Ying
>>
> 

-- 
Regards,
Liu Ying



From krzk at kernel.org  Sun Aug  4 22:45:09 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Mon, 5 Aug 2024 07:45:09 +0200
Subject: [PATCH 00/13] Add USB support to Exynos7885
In-Reply-To: <20240804215458.404085-1-virag.david003@gmail.com>
References: <20240804215458.404085-1-virag.david003@gmail.com>
Message-ID: <229538e5-f9db-4f2f-a0ac-13ecb7d3f7ba@kernel.org>

On 04/08/2024 23:53, David Virag wrote:
> This set of patches adds support for USB on the Exynos7885 SoC.
> 
> The Exynos7885 has a DWC3 compatible USB controller and an Exynos USB
> PHY that theoretically supports USB3 SuperSpeed, but is not implemented
> in any known device. The vendor kernel also stubs out USB3 functions, so
> we do not support it.
> 
> While at it, since we need some new clocks implemented, also fix some
> issues with the existing clock driver/bindings.
> 
> p.s.: Not realizing the USB PLL has a MUX on it made me waste I don't
> even want to know how much time on troubleshooting why it's not
> working...

If there is going to be any new version, please split between subsystems
into: clock+DTS, phy and usb.

Best regards,
Krzysztof



From krzk at kernel.org  Sun Aug  4 22:46:02 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Mon, 5 Aug 2024 07:46:02 +0200
Subject: [PATCH 04/13] dt-bindings: phy: samsung,usb3-drd-phy: Add
 Exynos7885 support
In-Reply-To: <20240804215458.404085-5-virag.david003@gmail.com>
References: <20240804215458.404085-1-virag.david003@gmail.com>
 <20240804215458.404085-5-virag.david003@gmail.com>
Message-ID: <f928633d-072f-4b76-a22b-634e635a17c0@kernel.org>

On 04/08/2024 23:53, David Virag wrote:
> Document Exynos7885 compatible.
> Exynos7885 USB PHY has two clocks (ref and phy) like Exynos850, which
> are already described in bindings.
> 
> Signed-off-by: David Virag <virag.david003 at gmail.com>

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From krzk at kernel.org  Sun Aug  4 22:47:12 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Mon, 5 Aug 2024 07:47:12 +0200
Subject: [PATCH 05/13] dt-bindings: usb: samsung,exynos-dwc3: Add
 Exynos7885 support
In-Reply-To: <20240804215458.404085-6-virag.david003@gmail.com>
References: <20240804215458.404085-1-virag.david003@gmail.com>
 <20240804215458.404085-6-virag.david003@gmail.com>
Message-ID: <3cbd3c49-e164-4bab-9a05-fdcbc01ee08b@kernel.org>

On 04/08/2024 23:53, David Virag wrote:
> Exynos7885 SoC has a DWC3 compatible USB controller, so it can reuse the
> existing Exynos glue layer. Clocks are the same as on Exynos850.
> Document Exynos7885 compatible.
> 
> Signed-off-by: David Virag <virag.david003 at gmail.com>
> ---
>  .../devicetree/bindings/usb/samsung,exynos-dwc3.yaml         | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml b/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml
> index 2b3430cebe99..3ec849ef4bdb 100644
> --- a/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml
> +++ b/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml
> @@ -16,6 +16,7 @@ properties:
>        - samsung,exynos5250-dwusb3
>        - samsung,exynos5433-dwusb3
>        - samsung,exynos7-dwusb3
> +      - samsung,exynos7885-dwusb3
>        - samsung,exynos850-dwusb3

This should be compatible with exynos850, so you need oneOf: adding
items with two compatibles.

Best regards,
Krzysztof



From krzk at kernel.org  Sun Aug  4 22:49:05 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Mon, 5 Aug 2024 07:49:05 +0200
Subject: [PATCH 06/13] clk: samsung: exynos7885: Update CLKS_NR_FSYS after
 bindings fix
In-Reply-To: <20240804215458.404085-7-virag.david003@gmail.com>
References: <20240804215458.404085-1-virag.david003@gmail.com>
 <20240804215458.404085-7-virag.david003@gmail.com>
Message-ID: <bd7c76a6-b7a5-4f8d-8081-95b6cdb39186@kernel.org>

On 04/08/2024 23:53, David Virag wrote:
> Update CLKS_NR_FSYS to the proper value after a fix in DT bindings.
> This should always be the last clock in a CMU + 1.
> 
> Signed-off-by: David Virag <virag.david003 at gmail.com>
> ---
>  drivers/clk/samsung/clk-exynos7885.c | 2 +-

This needs fixes and Cc-stable tag, same as the binding.

Best regards,
Krzysztof



From krzk at kernel.org  Sun Aug  4 22:50:48 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Mon, 5 Aug 2024 07:50:48 +0200
Subject: [PATCH 09/13] clk: samsung: exynos7885: Add USB related clocks to
 CMU_FSYS
In-Reply-To: <20240804215458.404085-10-virag.david003@gmail.com>
References: <20240804215458.404085-1-virag.david003@gmail.com>
 <20240804215458.404085-10-virag.david003@gmail.com>
Message-ID: <3dcba527-05ff-4942-93c1-9f3d35619a56@kernel.org>

On 04/08/2024 23:53, David Virag wrote:
> Exynos7885 SoC has a DWC3 USB Controller with Exynos USB PHY which in
> theory supports USB3 SuperSpeed, but is only used as USB2 in all known
> devices.
> 
> These clocks are needed for everything related to USB.
> 
> While at it, also remove the CLK_SET_RATE_PARENT capability of
> CLK_MOUT_FSYS_USB30DRD_USER, since it's not actually needed.
> 
> Signed-off-by: David Virag <virag.david003 at gmail.com>
> ---
>  drivers/clk/samsung/clk-exynos7885.c | 73 ++++++++++++++++++++++------
>  1 file changed, 59 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/clk/samsung/clk-exynos7885.c b/drivers/clk/samsung/clk-exynos7885.c
> index a0c9b7cc6942..637257a6f10e 100644
> --- a/drivers/clk/samsung/clk-exynos7885.c
> +++ b/drivers/clk/samsung/clk-exynos7885.c
> @@ -20,7 +20,7 @@
>  #define CLKS_NR_TOP			(CLK_MOUT_SHARED1_PLL + 1)
>  #define CLKS_NR_CORE			(CLK_GOUT_TREX_P_CORE_PCLK_P_CORE + 1)
>  #define CLKS_NR_PERI			(CLK_GOUT_WDT1_PCLK + 1)
> -#define CLKS_NR_FSYS			(CLK_MOUT_FSYS_USB30DRD_USER + 1)
> +#define CLKS_NR_FSYS			(CLK_FSYS_USB30DRD_REF_CLK + 1)
>  
>  /* ---- CMU_TOP ------------------------------------------------------------- */
>  
> @@ -686,38 +686,66 @@ static const struct samsung_cmu_info core_cmu_info __initconst = {
>  /* ---- CMU_FSYS ------------------------------------------------------------ */
>  
>  /* Register Offset definitions for CMU_FSYS (0x13400000) */
> -#define PLL_CON0_MUX_CLKCMU_FSYS_BUS_USER	0x0100
> -#define PLL_CON0_MUX_CLKCMU_FSYS_MMC_CARD_USER	0x0120
> -#define PLL_CON0_MUX_CLKCMU_FSYS_MMC_EMBD_USER	0x0140
> -#define PLL_CON0_MUX_CLKCMU_FSYS_MMC_SDIO_USER	0x0160
> -#define PLL_CON0_MUX_CLKCMU_FSYS_USB30DRD_USER	0x0180
> -#define CLK_CON_GAT_GOUT_FSYS_MMC_CARD_I_ACLK	0x2030
> -#define CLK_CON_GAT_GOUT_FSYS_MMC_CARD_SDCLKIN	0x2034
> -#define CLK_CON_GAT_GOUT_FSYS_MMC_EMBD_I_ACLK	0x2038
> -#define CLK_CON_GAT_GOUT_FSYS_MMC_EMBD_SDCLKIN	0x203c
> -#define CLK_CON_GAT_GOUT_FSYS_MMC_SDIO_I_ACLK	0x2040
> -#define CLK_CON_GAT_GOUT_FSYS_MMC_SDIO_SDCLKIN	0x2044
> +#define PLL_LOCKTIME_PLL_USB				0x0000
> +#define PLL_CON0_MUX_CLKCMU_FSYS_BUS_USER		0x0100
> +#define PLL_CON0_MUX_CLKCMU_FSYS_MMC_CARD_USER		0x0120
> +#define PLL_CON0_MUX_CLKCMU_FSYS_MMC_EMBD_USER		0x0140
> +#define PLL_CON0_MUX_CLKCMU_FSYS_MMC_SDIO_USER		0x0160
> +#define PLL_CON0_MUX_CLKCMU_FSYS_USB30DRD_USER		0x0180
> +#define PLL_CON0_PLL_USB				0x01a0
> +#define CLK_CON_GAT_CLK_FSYS_USB20PHY_CLKCORE		0x200c
> +#define CLK_CON_GAT_GOUT_FSYS_MMC_CARD_I_ACLK		0x2030
> +#define CLK_CON_GAT_GOUT_FSYS_MMC_CARD_SDCLKIN		0x2034
> +#define CLK_CON_GAT_GOUT_FSYS_MMC_EMBD_I_ACLK		0x2038
> +#define CLK_CON_GAT_GOUT_FSYS_MMC_EMBD_SDCLKIN		0x203c
> +#define CLK_CON_GAT_GOUT_FSYS_MMC_SDIO_I_ACLK		0x2040
> +#define CLK_CON_GAT_GOUT_FSYS_MMC_SDIO_SDCLKIN		0x2044
> +#define CLK_CON_GAT_GOUT_FSYS_USB30DRD_ACLK_20PHYCTRL	0x2068
> +#define CLK_CON_GAT_GOUT_FSYS_USB30DRD_ACLK_30PHYCTRL_0	0x206c
> +#define CLK_CON_GAT_GOUT_FSYS_USB30DRD_ACLK_30PHYCTRL_1	0x2070
> +#define CLK_CON_GAT_GOUT_FSYS_USB30DRD_BUS_CLK_EARLY	0x2074
> +#define CLK_CON_GAT_GOUT_FSYS_USB30DRD_REF_CLK		0x2078
>  
>  static const unsigned long fsys_clk_regs[] __initconst = {
> +	PLL_LOCKTIME_PLL_USB,
>  	PLL_CON0_MUX_CLKCMU_FSYS_BUS_USER,
>  	PLL_CON0_MUX_CLKCMU_FSYS_MMC_CARD_USER,
>  	PLL_CON0_MUX_CLKCMU_FSYS_MMC_EMBD_USER,
>  	PLL_CON0_MUX_CLKCMU_FSYS_MMC_SDIO_USER,
>  	PLL_CON0_MUX_CLKCMU_FSYS_USB30DRD_USER,
> +	PLL_CON0_PLL_USB,
> +	CLK_CON_GAT_CLK_FSYS_USB20PHY_CLKCORE,
>  	CLK_CON_GAT_GOUT_FSYS_MMC_CARD_I_ACLK,
>  	CLK_CON_GAT_GOUT_FSYS_MMC_CARD_SDCLKIN,
>  	CLK_CON_GAT_GOUT_FSYS_MMC_EMBD_I_ACLK,
>  	CLK_CON_GAT_GOUT_FSYS_MMC_EMBD_SDCLKIN,
>  	CLK_CON_GAT_GOUT_FSYS_MMC_SDIO_I_ACLK,
>  	CLK_CON_GAT_GOUT_FSYS_MMC_SDIO_SDCLKIN,
> +	CLK_CON_GAT_GOUT_FSYS_USB30DRD_ACLK_20PHYCTRL,
> +	CLK_CON_GAT_GOUT_FSYS_USB30DRD_ACLK_30PHYCTRL_0,
> +	CLK_CON_GAT_GOUT_FSYS_USB30DRD_ACLK_30PHYCTRL_1,
> +	CLK_CON_GAT_GOUT_FSYS_USB30DRD_BUS_CLK_EARLY,
> +	CLK_CON_GAT_GOUT_FSYS_USB30DRD_REF_CLK,
>  };
>  
> +static const struct samsung_pll_rate_table pll_usb_rate_table[] __initconst = {
> +	PLL_35XX_RATE(26 * MHZ, 50000000U, 400, 13, 4),
> +};
> +
> +static const struct samsung_pll_clock fsys_pll_clks[] __initconst = {
> +	PLL(pll_1418x, CLK_FOUT_USB_PLL, "fout_usb_pll", "oscclk",
> +	    PLL_LOCKTIME_PLL_USB, PLL_CON0_PLL_USB,
> +	    pll_usb_rate_table),
> +};
> +
> +

Just one blank line.

>  /* List of parent clocks for Muxes in CMU_FSYS */
>  PNAME(mout_fsys_bus_user_p)		= { "oscclk", "dout_fsys_bus" };
>  PNAME(mout_fsys_mmc_card_user_p)	= { "oscclk", "dout_fsys_mmc_card" };
>  PNAME(mout_fsys_mmc_embd_user_p)	= { "oscclk", "dout_fsys_mmc_embd" };
>  PNAME(mout_fsys_mmc_sdio_user_p)	= { "oscclk", "dout_fsys_mmc_sdio" };
>  PNAME(mout_fsys_usb30drd_user_p)	= { "oscclk", "dout_fsys_usb30drd" };
> +PNAME(mout_usb_pll_p)			= { "oscclk", "fout_usb_pll" };
>  
>  static const struct samsung_mux_clock fsys_mux_clks[] __initconst = {
>  	MUX(CLK_MOUT_FSYS_BUS_USER, "mout_fsys_bus_user", mout_fsys_bus_user_p,
> @@ -731,12 +759,16 @@ static const struct samsung_mux_clock fsys_mux_clks[] __initconst = {
>  	MUX_F(CLK_MOUT_FSYS_MMC_SDIO_USER, "mout_fsys_mmc_sdio_user",
>  	      mout_fsys_mmc_sdio_user_p, PLL_CON0_MUX_CLKCMU_FSYS_MMC_SDIO_USER,
>  	      4, 1, CLK_SET_RATE_PARENT, 0),
> -	MUX_F(CLK_MOUT_FSYS_USB30DRD_USER, "mout_fsys_usb30drd_user",
> +	MUX(CLK_MOUT_FSYS_USB30DRD_USER, "mout_fsys_usb30drd_user",
>  	      mout_fsys_usb30drd_user_p, PLL_CON0_MUX_CLKCMU_FSYS_USB30DRD_USER,
> -	      4, 1, CLK_SET_RATE_PARENT, 0),
> +	      4, 1),
> +	nMUX_F(CLK_MOUT_USB_PLL, "mout_usb_pll", mout_usb_pll_p,
> +	    PLL_CON0_PLL_USB, 4, 1, CLK_SET_RATE_PARENT, 0),
>  };
>  
>  static const struct samsung_gate_clock fsys_gate_clks[] __initconst = {
> +	GATE(CLK_FSYS_USB20PHY_CLKCORE, "clk_fsys_usb20phy_clkcore", "mout_usb_pll",
> +	     CLK_CON_GAT_CLK_FSYS_USB20PHY_CLKCORE, 21, CLK_SET_RATE_PARENT, 0),
>  	GATE(CLK_GOUT_MMC_CARD_ACLK, "gout_mmc_card_aclk", "mout_fsys_bus_user",
>  	     CLK_CON_GAT_GOUT_FSYS_MMC_CARD_I_ACLK, 21, 0, 0),
>  	GATE(CLK_GOUT_MMC_CARD_SDCLKIN, "gout_mmc_card_sdclkin",
> @@ -752,9 +784,22 @@ static const struct samsung_gate_clock fsys_gate_clks[] __initconst = {
>  	GATE(CLK_GOUT_MMC_SDIO_SDCLKIN, "gout_mmc_sdio_sdclkin",
>  	     "mout_fsys_mmc_sdio_user", CLK_CON_GAT_GOUT_FSYS_MMC_SDIO_SDCLKIN,
>  	     21, CLK_SET_RATE_PARENT, 0),
> +	GATE(CLK_FSYS_USB30DRD_ACLK_20PHYCTRL, "clk_fsys_usb30drd_aclk_20phyctrl",
> +	     "mout_fsys_bus_user", CLK_CON_GAT_GOUT_FSYS_USB30DRD_ACLK_20PHYCTRL, 21, 0, 0),
> +	GATE(CLK_FSYS_USB30DRD_ACLK_30PHYCTRL_0, "clk_fsys_usb30drd_aclk_30phyctrl_0",
> +	     "mout_fsys_bus_user", CLK_CON_GAT_GOUT_FSYS_USB30DRD_ACLK_30PHYCTRL_0, 21, 0, 0),
> +	GATE(CLK_FSYS_USB30DRD_ACLK_30PHYCTRL_1, "clk_fsys_usb30drd_aclk_30phyctrl_1",
> +	     "mout_fsys_bus_user", CLK_CON_GAT_GOUT_FSYS_USB30DRD_ACLK_30PHYCTRL_1, 21, 0, 0),
> +	GATE(CLK_FSYS_USB30DRD_BUS_CLK_EARLY, "clk_fsys_usb30drd_bus_clk_early",
> +	     "mout_fsys_bus_user", CLK_CON_GAT_GOUT_FSYS_USB30DRD_BUS_CLK_EARLY, 21, 0, 0),
> +	GATE(CLK_FSYS_USB30DRD_REF_CLK, "clk_fsys_usb30drd_ref_clk", "mout_fsys_usb30drd_user",
> +	     CLK_CON_GAT_GOUT_FSYS_USB30DRD_REF_CLK, 21, 0, 0),
> +

Drop blank line


Best regards,
Krzysztof



From krzk at kernel.org  Sun Aug  4 22:52:19 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Mon, 5 Aug 2024 07:52:19 +0200
Subject: [PATCH 11/13] phy: exynos5-usbdrd: support Exynos7885 USB PHY
In-Reply-To: <20240804215458.404085-12-virag.david003@gmail.com>
References: <20240804215458.404085-1-virag.david003@gmail.com>
 <20240804215458.404085-12-virag.david003@gmail.com>
Message-ID: <07907c20-b9f8-4721-9899-39083fea672a@kernel.org>

On 04/08/2024 23:53, David Virag wrote:
> The Exynos7885 SoC has an Exynos USB PHY that theoretically supports
> USB3 SuperSpeed, but all known devices using it only have USB2 and the
> vendor driver has USB3 function stubbed out, so we'll only support USB2.
> 
> Apart from this mysterius USB3 capability, it's the closest to Exynos850
> out of those supported. Unlike other SoCs though, this one doesn't set
> the reference clock by default, so we have to set it manually.
> For this, create a set_ref_clk_rate property in drvdata that can be set
> to a predefined value to set the clockrate to.
> 
> Signed-off-by: David Virag <virag.david003 at gmail.com>
> ---
>  drivers/phy/samsung/phy-exynos5-usbdrd.c    | 21 +++++++++++++++++++++
>  include/linux/soc/samsung/exynos-regs-pmu.h |  3 +++
>  2 files changed, 24 insertions(+)
> 
> diff --git a/drivers/phy/samsung/phy-exynos5-usbdrd.c b/drivers/phy/samsung/phy-exynos5-usbdrd.c
> index df52b78a120b..466c72d8a93c 100644
> --- a/drivers/phy/samsung/phy-exynos5-usbdrd.c
> +++ b/drivers/phy/samsung/phy-exynos5-usbdrd.c
> @@ -367,6 +367,7 @@ struct exynos5_usbdrd_phy_drvdata {
>  	int n_clks;
>  	const char * const *core_clk_names;
>  	int n_core_clks;
> +	u32 set_ref_clk_rate;

Rate is in unsigned long.



Best regards,
Krzysztof



From krzk at kernel.org  Sun Aug  4 22:52:58 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Mon, 5 Aug 2024 07:52:58 +0200
Subject: [PATCH 12/13] arm64: dts: exynos: Enable USB in Exynos7885
In-Reply-To: <20240804215458.404085-13-virag.david003@gmail.com>
References: <20240804215458.404085-1-virag.david003@gmail.com>
 <20240804215458.404085-13-virag.david003@gmail.com>
Message-ID: <fe9931ac-4b20-4fe8-aa91-9d9cca7e9770@kernel.org>

On 04/08/2024 23:53, David Virag wrote:
> Add USB controller and USB PHY controller nodes to Exynos7885 SoC DTSI
> 
> The SoC theoretically supports USB3 SuperSpeed, but is not implemented
> in any known device. The vendor kernel also stubs out USB3 functions, so
> we do not support it.
> 
> It is though, perfectly capable of USB 2.0 high-speed mode, both as host
> and device.
> 
> Signed-off-by: David Virag <virag.david003 at gmail.com>
> ---
>  arch/arm64/boot/dts/exynos/exynos7885.dtsi | 35 ++++++++++++++++++++++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/exynos/exynos7885.dtsi b/arch/arm64/boot/dts/exynos/exynos7885.dtsi
> index 008228fb319a..1352c64d132e 100644
> --- a/arch/arm64/boot/dts/exynos/exynos7885.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos7885.dtsi
> @@ -463,6 +463,41 @@ i2c_7: i2c at 11cd0000 {
>  			clock-names = "i2c";
>  			status = "disabled";
>  		};
> +
> +		usbdrd: usb at 13600000 {
> +			compatible = "samsung,exynos7885-dwusb3";
> +			ranges = <0x0 0x13600000 0x10000>;
> +			clocks = <&cmu_fsys CLK_FSYS_USB30DRD_BUS_CLK_EARLY>,
> +				 <&cmu_fsys CLK_FSYS_USB30DRD_REF_CLK>;
> +			clock-names = "bus_early", "ref";
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +			status = "disabled";
> +
> +			usbdrd_dwc3: usb at 0 {
> +				compatible = "snps,dwc3";
> +				reg = <0x0 0x10000>;
> +				interrupts = <GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH>;
> +				phys = <&usbdrd_phy 0>;
> +				phy-names = "usb2-phy";
> +				/*
> +				 * SoC in theory supports SS but no device has it.
> +				 * Actual capabilities unknown.
> +				 */
> +				maximum-speed = "high-speed";
> +			};
> +		};
> +
> +		usbdrd_phy: phy at 135d0000 {

Keep the nodes ordered by unit address.

Best regards,
Krzysztof



From radhey.shyam.pandey at amd.com  Sun Aug  4 22:59:07 2024
From: radhey.shyam.pandey at amd.com (Radhey Shyam Pandey)
Date: Mon, 5 Aug 2024 11:29:07 +0530
Subject: [PATCH v2] phy: xilinx: phy-zynqmp: Fix SGMII linkup failure on resume
Message-ID: <1722837547-2578381-1-git-send-email-radhey.shyam.pandey@amd.com>

From: Piyush Mehta <piyush.mehta at amd.com>

On a few Kria KR260 Robotics Starter Kit the PS-GEM SGMII linkup is not
happening after the resume. This is because serdes registers are reset
when FPD is off (in suspend state) and needs to be reprogrammed in the
resume path with the same default initialization as done in the first
stage bootloader psu_init routine.

To address the failure introduce a set of serdes registers to be saved in
the suspend path and then restore it on resume.

Fixes: 4a33bea00314 ("phy: zynqmp: Add PHY driver for the Xilinx ZynqMP Gigabit Transceiver")
Signed-off-by: Piyush Mehta <piyush.mehta at amd.com>
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey at amd.com>
---
Changes for v2:
- Use lower case for hex values.
- Add Fixes tag.
---
 drivers/phy/xilinx/phy-zynqmp.c | 56 +++++++++++++++++++++++++++++++++
 1 file changed, 56 insertions(+)

diff --git a/drivers/phy/xilinx/phy-zynqmp.c b/drivers/phy/xilinx/phy-zynqmp.c
index cb15041371c9..e6579002f114 100644
--- a/drivers/phy/xilinx/phy-zynqmp.c
+++ b/drivers/phy/xilinx/phy-zynqmp.c
@@ -160,6 +160,24 @@ static const char *const xpsgtr_icm_str[] = {
 /* Timeout values */
 #define TIMEOUT_US			1000
 
+/* Lane 0/1/2/3 offset */
+#define DIG_8(n)		((0x4000 * (n)) + 0x1074)
+#define ILL13(n)		((0x4000 * (n)) + 0x1994)
+#define DIG_10(n)		((0x4000 * (n)) + 0x107c)
+#define RST_DLY(n)		((0x4000 * (n)) + 0x19a4)
+#define BYP_15(n)		((0x4000 * (n)) + 0x1038)
+#define BYP_12(n)		((0x4000 * (n)) + 0x102c)
+#define MISC3(n)		((0x4000 * (n)) + 0x19ac)
+#define EQ11(n)			((0x4000 * (n)) + 0x1978)
+
+static u32 save_reg_address[] = {
+	/* Lane 0/1/2/3 Register */
+	DIG_8(0), ILL13(0), DIG_10(0), RST_DLY(0), BYP_15(0), BYP_12(0), MISC3(0), EQ11(0),
+	DIG_8(1), ILL13(1), DIG_10(1), RST_DLY(1), BYP_15(1), BYP_12(1), MISC3(1), EQ11(1),
+	DIG_8(2), ILL13(2), DIG_10(2), RST_DLY(2), BYP_15(2), BYP_12(2), MISC3(2), EQ11(2),
+	DIG_8(3), ILL13(3), DIG_10(3), RST_DLY(3), BYP_15(3), BYP_12(3), MISC3(3), EQ11(3),
+};
+
 struct xpsgtr_dev;
 
 /**
@@ -209,6 +227,7 @@ struct xpsgtr_phy {
  * @tx_term_fix: fix for GT issue
  * @saved_icm_cfg0: stored value of ICM CFG0 register
  * @saved_icm_cfg1: stored value of ICM CFG1 register
+ * @saved_regs: registers to be saved/restored during suspend/resume
  */
 struct xpsgtr_dev {
 	struct device *dev;
@@ -221,6 +240,7 @@ struct xpsgtr_dev {
 	bool tx_term_fix;
 	unsigned int saved_icm_cfg0;
 	unsigned int saved_icm_cfg1;
+	u32 *saved_regs;
 };
 
 /*
@@ -294,6 +314,32 @@ static inline void xpsgtr_clr_set_phy(struct xpsgtr_phy *gtr_phy,
 	writel((readl(addr) & ~clr) | set, addr);
 }
 
+/**
+ * xpsgtr_save_lane_regs - Saves registers on suspend
+ * @gtr_dev: pointer to phy controller context structure
+ */
+static void xpsgtr_save_lane_regs(struct xpsgtr_dev *gtr_dev)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(save_reg_address); i++)
+		gtr_dev->saved_regs[i] = xpsgtr_read(gtr_dev,
+						     save_reg_address[i]);
+}
+
+/**
+ * xpsgtr_restore_lane_regs - Restores registers on resume
+ * @gtr_dev: pointer to phy controller context structure
+ */
+static void xpsgtr_restore_lane_regs(struct xpsgtr_dev *gtr_dev)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(save_reg_address); i++)
+		xpsgtr_write(gtr_dev, save_reg_address[i],
+			     gtr_dev->saved_regs[i]);
+}
+
 /*
  * Hardware Configuration
  */
@@ -837,6 +883,8 @@ static int xpsgtr_runtime_suspend(struct device *dev)
 	gtr_dev->saved_icm_cfg0 = xpsgtr_read(gtr_dev, ICM_CFG0);
 	gtr_dev->saved_icm_cfg1 = xpsgtr_read(gtr_dev, ICM_CFG1);
 
+	xpsgtr_save_lane_regs(gtr_dev);
+
 	return 0;
 }
 
@@ -847,6 +895,8 @@ static int xpsgtr_runtime_resume(struct device *dev)
 	unsigned int i;
 	bool skip_phy_init;
 
+	xpsgtr_restore_lane_regs(gtr_dev);
+
 	icm_cfg0 = xpsgtr_read(gtr_dev, ICM_CFG0);
 	icm_cfg1 = xpsgtr_read(gtr_dev, ICM_CFG1);
 
@@ -994,6 +1044,12 @@ static int xpsgtr_probe(struct platform_device *pdev)
 		return ret;
 	}
 
+	gtr_dev->saved_regs = devm_kmalloc(gtr_dev->dev,
+					   sizeof(save_reg_address),
+					   GFP_KERNEL);
+	if (!gtr_dev->saved_regs)
+		return -ENOMEM;
+
 	return 0;
 }
 

base-commit: de9c2c66ad8e787abec7c9d7eff4f8c3cdd28aed
-- 
2.34.1



From xu.yang_2 at nxp.com  Mon Aug  5 00:04:29 2024
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Mon, 5 Aug 2024 15:04:29 +0800
Subject: [PATCH 1/5] dt-bindings: phy: imx8mq-usb: add compatible
 "fsl,imx95-usb-phy"
In-Reply-To: <21557eac-44f0-451d-a194-c5d545cacbee@kernel.org>
References: <20240802091702.2057294-1-xu.yang_2@nxp.com>
 <21557eac-44f0-451d-a194-c5d545cacbee@kernel.org>
Message-ID: <20240805070429.rqykjd3ap5swd5vl@hippo>

On Sun, Aug 04, 2024 at 04:16:34PM +0200, Krzysztof Kozlowski wrote:
> On 02/08/2024 11:16, Xu Yang wrote:
> > The usb phy in i.MX95 is compatible with i.MX8MP's, this will add a
> > compatible "fsl,imx95-usb-phy" for i.MX95. Also change reg maxItems
> > to 2 since i.MX95 needs another regmap to control Type-C Assist (TCA)
> > block. Since i.MX95 usb phy is able to switch SS lanes, this will also
> > add orientation-switch and port property to the file.
> > 
> > Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> > ---
> >  .../bindings/phy/fsl,imx8mq-usb-phy.yaml      | 40 +++++++++++++++++--
> >  1 file changed, 36 insertions(+), 4 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
> > index dc3a3f709fea..b0a614a9556d 100644
> > --- a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
> > +++ b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
> > @@ -11,12 +11,17 @@ maintainers:
> >  
> >  properties:
> >    compatible:
> > -    enum:
> > -      - fsl,imx8mq-usb-phy
> > -      - fsl,imx8mp-usb-phy
> > +    oneOf:
> > +      - enum:
> > +          - fsl,imx8mq-usb-phy
> > +          - fsl,imx8mp-usb-phy
> > +      - items:
> > +          - const: fsl,imx95-usb-phy
> > +          - const: fsl,imx8mp-usb-phy
> >  
> >    reg:
> > -    maxItems: 1
> > +    minItems: 1
> > +    maxItems: 2
> >  
> >    "#phy-cells":
> >      const: 0
> > @@ -28,6 +33,17 @@ properties:
> >      items:
> >        - const: phy
> >  
> > +  orientation-switch:
> > +    description:
> > +      Flag the PHY as possible handler of USB Type-C orientation switching
> 
> No need to duplicate definitions of properties.

I replace it with "orientation-switch: true".

> 
> > +    type: boolean
> > +
> > +  port:
> > +    $ref: /schemas/graph.yaml#/properties/port
> > +    description:
> > +      A port node to link the PHY to a TypeC controller for the purpose of
> > +      handling orientation switching.
> 
> Same here. You probably miss reference to usb-switch.

How about port? Should I replace it with "port: true" or

"port:"
"  $ref: /schemas/usb/usb-switch.yaml#/properties/port"

Thanks,
Xu Yang

> 
> > +
> >    power-domains:
> >      maxItems: 1
> >  
> > @@ -89,6 +105,22 @@ required:
> >    - clocks
> >    - clock-names
> >  
> > +allOf:
> > +  - if:
> > +      properties:
> > +        compatible:
> > +          contains:
> > +            enum:
> > +              - fsl,imx95-usb-phy
> > +    then:
> > +      properties:
> > +        reg:
> > +          minItems: 2
> 
> list and describe the items here, instead.
> 
> 
> Krzysztof
> 


From krzk at kernel.org  Mon Aug  5 00:22:18 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Mon, 5 Aug 2024 09:22:18 +0200
Subject: [PATCH 1/5] dt-bindings: phy: imx8mq-usb: add compatible
 "fsl,imx95-usb-phy"
In-Reply-To: <20240805070429.rqykjd3ap5swd5vl@hippo>
References: <20240802091702.2057294-1-xu.yang_2@nxp.com>
 <21557eac-44f0-451d-a194-c5d545cacbee@kernel.org>
 <20240805070429.rqykjd3ap5swd5vl@hippo>
Message-ID: <0e1b0f11-152e-402c-97ea-788c7830267f@kernel.org>

On 05/08/2024 09:04, Xu Yang wrote:
> On Sun, Aug 04, 2024 at 04:16:34PM +0200, Krzysztof Kozlowski wrote:
>> On 02/08/2024 11:16, Xu Yang wrote:
>>> The usb phy in i.MX95 is compatible with i.MX8MP's, this will add a
>>> compatible "fsl,imx95-usb-phy" for i.MX95. Also change reg maxItems
>>> to 2 since i.MX95 needs another regmap to control Type-C Assist (TCA)
>>> block. Since i.MX95 usb phy is able to switch SS lanes, this will also
>>> add orientation-switch and port property to the file.
>>>
>>> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
>>> ---
>>>  .../bindings/phy/fsl,imx8mq-usb-phy.yaml      | 40 +++++++++++++++++--
>>>  1 file changed, 36 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
>>> index dc3a3f709fea..b0a614a9556d 100644
>>> --- a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
>>> +++ b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
>>> @@ -11,12 +11,17 @@ maintainers:
>>>  
>>>  properties:
>>>    compatible:
>>> -    enum:
>>> -      - fsl,imx8mq-usb-phy
>>> -      - fsl,imx8mp-usb-phy
>>> +    oneOf:
>>> +      - enum:
>>> +          - fsl,imx8mq-usb-phy
>>> +          - fsl,imx8mp-usb-phy
>>> +      - items:
>>> +          - const: fsl,imx95-usb-phy
>>> +          - const: fsl,imx8mp-usb-phy
>>>  
>>>    reg:
>>> -    maxItems: 1
>>> +    minItems: 1
>>> +    maxItems: 2
>>>  
>>>    "#phy-cells":
>>>      const: 0
>>> @@ -28,6 +33,17 @@ properties:
>>>      items:
>>>        - const: phy
>>>  
>>> +  orientation-switch:
>>> +    description:
>>> +      Flag the PHY as possible handler of USB Type-C orientation switching
>>
>> No need to duplicate definitions of properties.
> 
> I replace it with "orientation-switch: true".
> 
>>
>>> +    type: boolean
>>> +
>>> +  port:
>>> +    $ref: /schemas/graph.yaml#/properties/port
>>> +    description:
>>> +      A port node to link the PHY to a TypeC controller for the purpose of
>>> +      handling orientation switching.
>>
>> Same here. You probably miss reference to usb-switch.
> 
> How about port? Should I replace it with "port: true" or
> 
> "port:"
> "  $ref: /schemas/usb/usb-switch.yaml#/properties/port"

You can drop both if you add ref to usb-switch and use
unevaluatedProperties.

Best regards,
Krzysztof



From xu.yang_2 at nxp.com  Mon Aug  5 01:22:11 2024
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Mon, 5 Aug 2024 16:22:11 +0800
Subject: [PATCH 1/5] dt-bindings: phy: imx8mq-usb: add compatible
 "fsl,imx95-usb-phy"
In-Reply-To: <0e1b0f11-152e-402c-97ea-788c7830267f@kernel.org>
References: <20240802091702.2057294-1-xu.yang_2@nxp.com>
 <21557eac-44f0-451d-a194-c5d545cacbee@kernel.org>
 <20240805070429.rqykjd3ap5swd5vl@hippo>
 <0e1b0f11-152e-402c-97ea-788c7830267f@kernel.org>
Message-ID: <20240805082211.ngrokcmzuijnu26d@hippo>

On Mon, Aug 05, 2024 at 09:22:18AM +0200, Krzysztof Kozlowski wrote:
> On 05/08/2024 09:04, Xu Yang wrote:
> > On Sun, Aug 04, 2024 at 04:16:34PM +0200, Krzysztof Kozlowski wrote:
> >> On 02/08/2024 11:16, Xu Yang wrote:
> >>> The usb phy in i.MX95 is compatible with i.MX8MP's, this will add a
> >>> compatible "fsl,imx95-usb-phy" for i.MX95. Also change reg maxItems
> >>> to 2 since i.MX95 needs another regmap to control Type-C Assist (TCA)
> >>> block. Since i.MX95 usb phy is able to switch SS lanes, this will also
> >>> add orientation-switch and port property to the file.
> >>>
> >>> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> >>> ---
> >>>  .../bindings/phy/fsl,imx8mq-usb-phy.yaml      | 40 +++++++++++++++++--
> >>>  1 file changed, 36 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
> >>> index dc3a3f709fea..b0a614a9556d 100644
> >>> --- a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
> >>> +++ b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
> >>> @@ -11,12 +11,17 @@ maintainers:
> >>>  
> >>>  properties:
> >>>    compatible:
> >>> -    enum:
> >>> -      - fsl,imx8mq-usb-phy
> >>> -      - fsl,imx8mp-usb-phy
> >>> +    oneOf:
> >>> +      - enum:
> >>> +          - fsl,imx8mq-usb-phy
> >>> +          - fsl,imx8mp-usb-phy
> >>> +      - items:
> >>> +          - const: fsl,imx95-usb-phy
> >>> +          - const: fsl,imx8mp-usb-phy
> >>>  
> >>>    reg:
> >>> -    maxItems: 1
> >>> +    minItems: 1
> >>> +    maxItems: 2
> >>>  
> >>>    "#phy-cells":
> >>>      const: 0
> >>> @@ -28,6 +33,17 @@ properties:
> >>>      items:
> >>>        - const: phy
> >>>  
> >>> +  orientation-switch:
> >>> +    description:
> >>> +      Flag the PHY as possible handler of USB Type-C orientation switching
> >>
> >> No need to duplicate definitions of properties.
> > 
> > I replace it with "orientation-switch: true".
> > 
> >>
> >>> +    type: boolean
> >>> +
> >>> +  port:
> >>> +    $ref: /schemas/graph.yaml#/properties/port
> >>> +    description:
> >>> +      A port node to link the PHY to a TypeC controller for the purpose of
> >>> +      handling orientation switching.
> >>
> >> Same here. You probably miss reference to usb-switch.
> > 
> > How about port? Should I replace it with "port: true" or
> > 
> > "port:"
> > "  $ref: /schemas/usb/usb-switch.yaml#/properties/port"
> 
> You can drop both if you add ref to usb-switch and use
> unevaluatedProperties.

Got it! It's helpful

Thanks,
Xu Yang

> 
> Best regards,
> Krzysztof
> 


From s-vadapalli at ti.com  Mon Aug  5 02:26:07 2024
From: s-vadapalli at ti.com (Siddharth Vadapalli)
Date: Mon, 5 Aug 2024 14:56:07 +0530
Subject: [PATCH v4] phy: cadence-torrent: add support for three or more links using 2 protocols
Message-ID: <20240805092607.143869-1-s-vadapalli@ti.com>

The Torrent SERDES can support at most two different protocols (PHY types).
This only mandates that the device-tree sub-nodes used to represent the
configuration should describe links with at-most two different protocols.

The existing implementation however imposes an artificial constraint that
allows only two links (device-tree sub-nodes). As long as at-most two
protocols are chosen, using more than two links to describe them in an
alternating configuration is still a valid configuration of the Torrent
SERDES.

A 3-Link 2-Protocol configuration of the 4-Lane SERDES can be:
Lane 0 => Protocol 1 => Link 1
Lane 1 => Protocol 1 => Link 1
Lane 2 => Protocol 2 => Link 2
Lane 3 => Protocol 1 => Link 3

A 4-Link 2-Protocol configuration of the 4-Lane SERDES can be:
Lane 0 => Protocol 1 => Link 1
Lane 1 => Protocol 2 => Link 2
Lane 2 => Protocol 1 => Link 3
Lane 3 => Protocol 2 => Link 4

Signed-off-by: Siddharth Vadapalli <s-vadapalli at ti.com>
Reviewed-by: Roger Quadros <rogerq at kernel.org>
---

Hello,

This patch is based on linux-next tagged next-20240805.
Patch has been sanity tested and tested for functionality in the following
configurations with the Torrent SERDES0 on J7200-EVM:
1. PCIe (Lanes 0 and 1) + QSGMII (Lane 2)
   => 2 protocols, 2 links
2. PCIe (Lanes 0 and 1) + QSGMII (Lane 2) + PCIe (Lane 3)
   => 2 protocols, 3 links

v3:
https://lore.kernel.org/r/20240716102442.1605280-1-s-vadapalli at ti.com/
Changes since v3:
- Rebased patch on linux-next tagged next-20240805.
- Collected Reviewed-by tag from Roger Quadros <rogerq at kernel.org>
  https://lore.kernel.org/r/1c393235-3bf3-4c89-ab54-42de5a33c8c2 at kernel.org/

v2:
https://lore.kernel.org/r/20240710115624.3232925-1-s-vadapalli at ti.com/
Changes since v2:
- Based on Swapnil and Roger's feedback on the v2 patch, the
  configuration will be performed as follows:
  1) For Multilink configuration with 2 sub-nodes, irrespective of
  whether or not the protocols/phy-types are same or different,
  the phy-types present in the sub-nodes are used as-is and the
  configuration is performed by iterating over the sub-nodes.
  This is identical to the existing implementation and PCIe Multilink
  which is a single protocol expressed with 2 sub-nodes can also be
  supported.
  2) For Multilink configuration with 3 or more sub-nodes, the
  configuration is performed by iterating over all sub-nodes and
  configuring those which match the first protocol, followed by
  iterating over all sub-nodes and configuring the ones which match the
  second protocol. This supports 3 or 4 links as long as the number of
  protocols is still 2 (all array values are of the type
  [phy_t1][phy_t2], so only two different protocols are supported).

v1:
https://lore.kernel.org/r/20240709120703.2716397-1-s-vadapalli at ti.com/
Changes since v1:
- A multilink configuration doesn't necessarily imply two protocols
  since a single protocol may be split across links as follows:
  Lane 0 => Protocol 1
  Lane 1 => Unused
  Lane 2 => Protocol 1
  Lane 3 => Unused
  which corresponds to two links and therefore two sub-nodes. In such a
  case, treat it as two single-link configurations performed sequentially
  which happens to be the case prior to this patch. To address this,
  handle the case where cdns_torrent_phy_configure_multilink() can be
  invoked for a single protocol with multiple sub-nodes (links) by
  erroring out only when the number of protocols is strictly greater
  than two, followed by handling the configuration similar to how it was
  done prior to this patch.

Regards,
Siddharth.

 drivers/phy/cadence/phy-cadence-torrent.c | 291 +++++++++++++---------
 1 file changed, 172 insertions(+), 119 deletions(-)

diff --git a/drivers/phy/cadence/phy-cadence-torrent.c b/drivers/phy/cadence/phy-cadence-torrent.c
index a2d32d5f6b07..8bbbbb87bb22 100644
--- a/drivers/phy/cadence/phy-cadence-torrent.c
+++ b/drivers/phy/cadence/phy-cadence-torrent.c
@@ -351,6 +351,7 @@ struct cdns_torrent_phy {
 	void __iomem *sd_base; /* SD0801 registers base */
 	u32 max_bit_rate; /* Maximum link bit rate to use (in Mbps) */
 	u32 dp_pll;
+	u32 protocol_bitmask;
 	struct reset_control *phy_rst;
 	struct reset_control *apb_rst;
 	struct device *dev;
@@ -2473,156 +2474,206 @@ int cdns_torrent_phy_configure_multilink(struct cdns_torrent_phy *cdns_phy)
 	enum cdns_torrent_phy_type phy_t1, phy_t2;
 	const struct cdns_reg_pairs *reg_pairs;
 	int i, j, node, mlane, num_lanes, ret;
+	struct device *dev = cdns_phy->dev;
 	enum cdns_torrent_ssc_mode ssc;
 	struct regmap *regmap;
-	u32 num_regs;
+	u32 num_regs, num_protocols, protocol;
 
-	/* Maximum 2 links (subnodes) are supported */
-	if (cdns_phy->nsubnodes != 2)
+	num_protocols = hweight32(cdns_phy->protocol_bitmask);
+	/* Maximum 2 protocols are supported */
+	if (num_protocols > 2) {
+		dev_err(dev, "at most 2 protocols are supported\n");
 		return -EINVAL;
+	}
 
-	phy_t1 = cdns_phy->phys[0].phy_type;
-	phy_t2 = cdns_phy->phys[1].phy_type;
 
 	/**
-	 * First configure the PHY for first link with phy_t1. Get the array
-	 * values as [phy_t1][phy_t2][ssc].
+	 * Get PHY types directly from subnodes if only 2 subnodes exist.
+	 * It is possible for phy_t1 to be the same as phy_t2 for special
+	 * configurations such as PCIe Multilink.
 	 */
-	for (node = 0; node < cdns_phy->nsubnodes; node++) {
-		if (node == 1) {
+	if (cdns_phy->nsubnodes == 2) {
+		phy_t1 = cdns_phy->phys[0].phy_type;
+		phy_t2 = cdns_phy->phys[1].phy_type;
+	} else {
+		/**
+		 * Both PHY types / protocols should be unique.
+		 * If they are the same, it should be expressed with either
+		 * a) Single-Link (1 Sub-node) - handled via PHY APIs
+		 * OR
+		 * b) Double-Link (2 Sub-nodes) - handled above
+		 */
+		if (num_protocols != 2) {
+			dev_err(dev, "incorrect representation of link\n");
+			return -EINVAL;
+		}
+
+		phy_t1 = fns(cdns_phy->protocol_bitmask, 0);
+		phy_t2 = fns(cdns_phy->protocol_bitmask, 1);
+	}
+
+	/**
+	 * Configure all links with the protocol phy_t1 first followed by
+	 * configuring all links with the protocol phy_t2.
+	 *
+	 * When phy_t1 = phy_t2, it is a single protocol and configuration
+	 * is performed with a single iteration of the protocol and multiple
+	 * iterations over the sub-nodes (links).
+	 *
+	 * When phy_t1 != phy_t2, there are two protocols and configuration
+	 * is performed by iterating over all sub-nodes matching the first
+	 * protocol and configuring them first, followed by iterating over
+	 * all sub-nodes matching the second protocol and configuring them
+	 * next.
+	 */
+	for (protocol = 0; protocol < num_protocols; protocol++) {
+		/**
+		 * For the case where num_protocols is 1,
+		 * phy_t1 = phy_t2 and the swap is unnecessary.
+		 *
+		 * Swapping phy_t1 and phy_t2 is only required when the
+		 * number of protocols is 2 and there are 2 or more links.
+		 */
+		if (protocol == 1) {
 			/**
-			 * If first link with phy_t1 is configured, then
-			 * configure the PHY for second link with phy_t2.
+			 * If first protocol with phy_t1 is configured, then
+			 * configure the PHY for second protocol with phy_t2.
 			 * Get the array values as [phy_t2][phy_t1][ssc].
 			 */
 			swap(phy_t1, phy_t2);
 			swap(ref_clk, ref_clk1);
 		}
 
-		mlane = cdns_phy->phys[node].mlane;
-		ssc = cdns_phy->phys[node].ssc_mode;
-		num_lanes = cdns_phy->phys[node].num_lanes;
+		for (node = 0; node < cdns_phy->nsubnodes; node++) {
+			if (cdns_phy->phys[node].phy_type != phy_t1)
+				continue;
 
-		/**
-		 * PHY configuration specific registers:
-		 * link_cmn_vals depend on combination of PHY types being
-		 * configured and are common for both PHY types, so array
-		 * values should be same for [phy_t1][phy_t2][ssc] and
-		 * [phy_t2][phy_t1][ssc].
-		 * xcvr_diag_vals also depend on combination of PHY types
-		 * being configured, but these can be different for particular
-		 * PHY type and are per lane.
-		 */
-		link_cmn_vals = cdns_torrent_get_tbl_vals(&init_data->link_cmn_vals_tbl,
-							  CLK_ANY, CLK_ANY,
-							  phy_t1, phy_t2, ANY_SSC);
-		if (link_cmn_vals) {
-			reg_pairs = link_cmn_vals->reg_pairs;
-			num_regs = link_cmn_vals->num_regs;
-			regmap = cdns_phy->regmap_common_cdb;
+			mlane = cdns_phy->phys[node].mlane;
+			ssc = cdns_phy->phys[node].ssc_mode;
+			num_lanes = cdns_phy->phys[node].num_lanes;
 
 			/**
-			 * First array value in link_cmn_vals must be of
-			 * PHY_PLL_CFG register
+			 * PHY configuration specific registers:
+			 * link_cmn_vals depend on combination of PHY types being
+			 * configured and are common for both PHY types, so array
+			 * values should be same for [phy_t1][phy_t2][ssc] and
+			 * [phy_t2][phy_t1][ssc].
+			 * xcvr_diag_vals also depend on combination of PHY types
+			 * being configured, but these can be different for particular
+			 * PHY type and are per lane.
 			 */
-			regmap_field_write(cdns_phy->phy_pll_cfg,
-					   reg_pairs[0].val);
+			link_cmn_vals = cdns_torrent_get_tbl_vals(&init_data->link_cmn_vals_tbl,
+								  CLK_ANY, CLK_ANY,
+								  phy_t1, phy_t2, ANY_SSC);
+			if (link_cmn_vals) {
+				reg_pairs = link_cmn_vals->reg_pairs;
+				num_regs = link_cmn_vals->num_regs;
+				regmap = cdns_phy->regmap_common_cdb;
 
-			for (i = 1; i < num_regs; i++)
-				regmap_write(regmap, reg_pairs[i].off,
-					     reg_pairs[i].val);
-		}
+				/**
+				 * First array value in link_cmn_vals must be of
+				 * PHY_PLL_CFG register
+				 */
+				regmap_field_write(cdns_phy->phy_pll_cfg,
+						   reg_pairs[0].val);
 
-		xcvr_diag_vals = cdns_torrent_get_tbl_vals(&init_data->xcvr_diag_vals_tbl,
-							   CLK_ANY, CLK_ANY,
-							   phy_t1, phy_t2, ANY_SSC);
-		if (xcvr_diag_vals) {
-			reg_pairs = xcvr_diag_vals->reg_pairs;
-			num_regs = xcvr_diag_vals->num_regs;
-			for (i = 0; i < num_lanes; i++) {
-				regmap = cdns_phy->regmap_tx_lane_cdb[i + mlane];
-				for (j = 0; j < num_regs; j++)
-					regmap_write(regmap, reg_pairs[j].off,
-						     reg_pairs[j].val);
+				for (i = 1; i < num_regs; i++)
+					regmap_write(regmap, reg_pairs[i].off,
+						     reg_pairs[i].val);
 			}
-		}
 
-		/* PHY PCS common registers configurations */
-		pcs_cmn_vals = cdns_torrent_get_tbl_vals(&init_data->pcs_cmn_vals_tbl,
-							 CLK_ANY, CLK_ANY,
-							 phy_t1, phy_t2, ANY_SSC);
-		if (pcs_cmn_vals) {
-			reg_pairs = pcs_cmn_vals->reg_pairs;
-			num_regs = pcs_cmn_vals->num_regs;
-			regmap = cdns_phy->regmap_phy_pcs_common_cdb;
-			for (i = 0; i < num_regs; i++)
-				regmap_write(regmap, reg_pairs[i].off,
-					     reg_pairs[i].val);
-		}
+			xcvr_diag_vals = cdns_torrent_get_tbl_vals(&init_data->xcvr_diag_vals_tbl,
+								   CLK_ANY, CLK_ANY,
+								   phy_t1, phy_t2, ANY_SSC);
+			if (xcvr_diag_vals) {
+				reg_pairs = xcvr_diag_vals->reg_pairs;
+				num_regs = xcvr_diag_vals->num_regs;
+				for (i = 0; i < num_lanes; i++) {
+					regmap = cdns_phy->regmap_tx_lane_cdb[i + mlane];
+					for (j = 0; j < num_regs; j++)
+						regmap_write(regmap, reg_pairs[j].off,
+							     reg_pairs[j].val);
+				}
+			}
 
-		/* PHY PMA common registers configurations */
-		phy_pma_cmn_vals = cdns_torrent_get_tbl_vals(&init_data->phy_pma_cmn_vals_tbl,
-							     CLK_ANY, CLK_ANY,
-							     phy_t1, phy_t2, ANY_SSC);
-		if (phy_pma_cmn_vals) {
-			reg_pairs = phy_pma_cmn_vals->reg_pairs;
-			num_regs = phy_pma_cmn_vals->num_regs;
-			regmap = cdns_phy->regmap_phy_pma_common_cdb;
-			for (i = 0; i < num_regs; i++)
-				regmap_write(regmap, reg_pairs[i].off,
-					     reg_pairs[i].val);
-		}
+			/* PHY PCS common registers configurations */
+			pcs_cmn_vals = cdns_torrent_get_tbl_vals(&init_data->pcs_cmn_vals_tbl,
+								 CLK_ANY, CLK_ANY,
+								 phy_t1, phy_t2, ANY_SSC);
+			if (pcs_cmn_vals) {
+				reg_pairs = pcs_cmn_vals->reg_pairs;
+				num_regs = pcs_cmn_vals->num_regs;
+				regmap = cdns_phy->regmap_phy_pcs_common_cdb;
+				for (i = 0; i < num_regs; i++)
+					regmap_write(regmap, reg_pairs[i].off,
+						     reg_pairs[i].val);
+			}
 
-		/* PMA common registers configurations */
-		cmn_vals = cdns_torrent_get_tbl_vals(&init_data->cmn_vals_tbl,
-						     ref_clk, ref_clk1,
-						     phy_t1, phy_t2, ssc);
-		if (cmn_vals) {
-			reg_pairs = cmn_vals->reg_pairs;
-			num_regs = cmn_vals->num_regs;
-			regmap = cdns_phy->regmap_common_cdb;
-			for (i = 0; i < num_regs; i++)
-				regmap_write(regmap, reg_pairs[i].off,
-					     reg_pairs[i].val);
-		}
+			/* PHY PMA common registers configurations */
+			phy_pma_cmn_vals =
+				cdns_torrent_get_tbl_vals(&init_data->phy_pma_cmn_vals_tbl,
+							  CLK_ANY, CLK_ANY, phy_t1, phy_t2,
+							  ANY_SSC);
+			if (phy_pma_cmn_vals) {
+				reg_pairs = phy_pma_cmn_vals->reg_pairs;
+				num_regs = phy_pma_cmn_vals->num_regs;
+				regmap = cdns_phy->regmap_phy_pma_common_cdb;
+				for (i = 0; i < num_regs; i++)
+					regmap_write(regmap, reg_pairs[i].off,
+						     reg_pairs[i].val);
+			}
 
-		/* PMA TX lane registers configurations */
-		tx_ln_vals = cdns_torrent_get_tbl_vals(&init_data->tx_ln_vals_tbl,
-						       ref_clk, ref_clk1,
-						       phy_t1, phy_t2, ssc);
-		if (tx_ln_vals) {
-			reg_pairs = tx_ln_vals->reg_pairs;
-			num_regs = tx_ln_vals->num_regs;
-			for (i = 0; i < num_lanes; i++) {
-				regmap = cdns_phy->regmap_tx_lane_cdb[i + mlane];
-				for (j = 0; j < num_regs; j++)
-					regmap_write(regmap, reg_pairs[j].off,
-						     reg_pairs[j].val);
+			/* PMA common registers configurations */
+			cmn_vals = cdns_torrent_get_tbl_vals(&init_data->cmn_vals_tbl,
+							     ref_clk, ref_clk1,
+							     phy_t1, phy_t2, ssc);
+			if (cmn_vals) {
+				reg_pairs = cmn_vals->reg_pairs;
+				num_regs = cmn_vals->num_regs;
+				regmap = cdns_phy->regmap_common_cdb;
+				for (i = 0; i < num_regs; i++)
+					regmap_write(regmap, reg_pairs[i].off,
+						     reg_pairs[i].val);
 			}
-		}
 
-		/* PMA RX lane registers configurations */
-		rx_ln_vals = cdns_torrent_get_tbl_vals(&init_data->rx_ln_vals_tbl,
-						       ref_clk, ref_clk1,
-						       phy_t1, phy_t2, ssc);
-		if (rx_ln_vals) {
-			reg_pairs = rx_ln_vals->reg_pairs;
-			num_regs = rx_ln_vals->num_regs;
-			for (i = 0; i < num_lanes; i++) {
-				regmap = cdns_phy->regmap_rx_lane_cdb[i + mlane];
-				for (j = 0; j < num_regs; j++)
-					regmap_write(regmap, reg_pairs[j].off,
-						     reg_pairs[j].val);
+			/* PMA TX lane registers configurations */
+			tx_ln_vals = cdns_torrent_get_tbl_vals(&init_data->tx_ln_vals_tbl,
+							       ref_clk, ref_clk1,
+							       phy_t1, phy_t2, ssc);
+			if (tx_ln_vals) {
+				reg_pairs = tx_ln_vals->reg_pairs;
+				num_regs = tx_ln_vals->num_regs;
+				for (i = 0; i < num_lanes; i++) {
+					regmap = cdns_phy->regmap_tx_lane_cdb[i + mlane];
+					for (j = 0; j < num_regs; j++)
+						regmap_write(regmap, reg_pairs[j].off,
+							     reg_pairs[j].val);
+				}
 			}
-		}
 
-		if (phy_t1 == TYPE_DP) {
-			ret = cdns_torrent_dp_get_pll(cdns_phy, phy_t2);
-			if (ret)
-				return ret;
-		}
+			/* PMA RX lane registers configurations */
+			rx_ln_vals = cdns_torrent_get_tbl_vals(&init_data->rx_ln_vals_tbl,
+							       ref_clk, ref_clk1,
+							       phy_t1, phy_t2, ssc);
+			if (rx_ln_vals) {
+				reg_pairs = rx_ln_vals->reg_pairs;
+				num_regs = rx_ln_vals->num_regs;
+				for (i = 0; i < num_lanes; i++) {
+					regmap = cdns_phy->regmap_rx_lane_cdb[i + mlane];
+					for (j = 0; j < num_regs; j++)
+						regmap_write(regmap, reg_pairs[j].off,
+							     reg_pairs[j].val);
+				}
+			}
 
-		reset_control_deassert(cdns_phy->phys[node].lnk_rst);
+			if (phy_t1 == TYPE_DP) {
+				ret = cdns_torrent_dp_get_pll(cdns_phy, phy_t2);
+				if (ret)
+					return ret;
+			}
+
+			reset_control_deassert(cdns_phy->phys[node].lnk_rst);
+		}
 	}
 
 	/* Take the PHY out of reset */
@@ -2826,6 +2877,7 @@ static int cdns_torrent_phy_probe(struct platform_device *pdev)
 	dev_set_drvdata(dev, cdns_phy);
 	cdns_phy->dev = dev;
 	cdns_phy->init_data = data;
+	cdns_phy->protocol_bitmask = 0;
 
 	cdns_phy->sd_base = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(cdns_phy->sd_base))
@@ -3010,6 +3062,7 @@ static int cdns_torrent_phy_probe(struct platform_device *pdev)
 		}
 
 		cdns_phy->phys[node].phy = gphy;
+		cdns_phy->protocol_bitmask |= BIT(cdns_phy->phys[node].phy_type);
 		phy_set_drvdata(gphy, &cdns_phy->phys[node]);
 
 		node++;
-- 
2.40.1



From s-vadapalli at ti.com  Mon Aug  5 02:59:28 2024
From: s-vadapalli at ti.com (Siddharth Vadapalli)
Date: Mon, 5 Aug 2024 15:29:28 +0530
Subject: [PATCH v3] phy: cadence-torrent: add support for three or more
 links using 2 protocols
In-Reply-To: <Zq-15_enK919eUg_@matsya>
References: <20240716102442.1605280-1-s-vadapalli@ti.com>
 <Zq-15_enK919eUg_@matsya>
Message-ID: <d2329736-9697-4d73-b2d2-2b83c129221d@ti.com>

On Sun, Aug 04, 2024 at 10:39:59PM +0530, Vinod Koul wrote:
> On 16-07-24, 15:54, Siddharth Vadapalli wrote:
> > The Torrent SERDES can support at most two different protocols (PHY types).
> > This only mandates that the device-tree sub-nodes used to represent the
> > configuration should describe links with at-most two different protocols.
> > 
> > The existing implementation however imposes an artificial constraint that
> > allows only two links (device-tree sub-nodes). As long as at-most two
> > protocols are chosen, using more than two links to describe them in an
> > alternating configuration is still a valid configuration of the Torrent
> > SERDES.
> > 
> > A 3-Link 2-Protocol configuration of the 4-Lane SERDES can be:
> > Lane 0 => Protocol 1 => Link 1
> > Lane 1 => Protocol 1 => Link 1
> > Lane 2 => Protocol 2 => Link 2
> > Lane 3 => Protocol 1 => Link 3
> > 
> > A 4-Link 2-Protocol configuration of the 4-Lane SERDES can be:
> > Lane 0 => Protocol 1 => Link 1
> > Lane 1 => Protocol 2 => Link 2
> > Lane 2 => Protocol 1 => Link 3
> > Lane 3 => Protocol 2 => Link 4
> > 
> > Signed-off-by: Siddharth Vadapalli <s-vadapalli at ti.com>
> > ---
> > 
> > Hello,
> > 
> > This patch is based on linux-next tagged next-20240715.
> 
> Sorry this does not apply for me on phy/next, can you rebase..?

Thank you for pointing it out. I have rebased this patch on linux-next
tagged next-20240805 and have posted the v4 patch at:
https://lore.kernel.org/r/20240805092607.143869-1-s-vadapalli at ti.com/

Regards,
Siddharth.


From conor at kernel.org  Mon Aug  5 03:11:16 2024
From: conor at kernel.org (Conor Dooley)
Date: Mon, 5 Aug 2024 11:11:16 +0100
Subject: [PATCH 1/2] dt-bindings: phy: ti,tcan104x-can: Document
 Microchip ATA6561
In-Reply-To: <CAGCz5H=gDfJpfAhH-QbxN5VSDyVtwGU6Zt16z7=sqpTdjkeGqA@mail.gmail.com>
References: <20240718210322.37492-2-ilordash02@gmail.com>
 <20240719-ahead-kiwi-995e52bf3e74@spud>
 <CAGCz5HkF_WNZBVpY2SWVf071Pi896BvKFk0jnfNAYX5AKx2Zcw@mail.gmail.com>
 <20240723-dinginess-john-608d0b28293b@spud>
 <CAGCz5H=Gncw+Tr0XaQQhhGWQER5Rs1BcxbkPaJwx9jJ-8j7LGQ@mail.gmail.com>
 <20240723-municipal-snowy-136b08b6db90@spud>
 <CAGCz5HnJKjNj7A0YD2fw20m-NrEs3MoCLwox86mC11Kudq8xbg@mail.gmail.com>
 <CAMuHMdUf=McxMLqb1hgu_-4QkSFJkdWrdtbwiwn9yJoMSi3YWA@mail.gmail.com>
 <20240801-disarray-gesture-ebad121272b0@spud>
 <CAGCz5H=gDfJpfAhH-QbxN5VSDyVtwGU6Zt16z7=sqpTdjkeGqA@mail.gmail.com>
Message-ID: <20240805-fruit-chip-cf08a0e166a3@spud>

On Sat, Aug 03, 2024 at 03:31:52PM +0300, Ilya Orazov wrote:
> > > > > > I made my patch according to a similar one that adds support for
> > > > > > nxp,tjr1443. You can find it's conversation on
> > > > > > https://lore.kernel.org/all/6ee5e2ce00019bd3f77d6a702b38bab1a45f3bb0.1674037830.git.geert+renesas at glider.be/t/#u.
> > > > >
> > > > > > I thought we want to hold all PHY chip names in one compatible enum
> > > > > > and each in its own of_device_id struct in driver and extend them
> > > > > > where appropriate.
> > > > >
> > > > > Nah, fallbacks are preferred when the programming model is either
> > > > > identical or a "compatible superset" of an existing device. New
> > > > > of_device_id structs should only be used where we need to account for
> > > > > differences in the programming model.
> > > >
> > > > However, I am curious as to why the NXP CAN PHY transceiver was not
> > > > included as fallback compatible. Geert, could you please share your
> > > > thoughts on this matter?
> > >
> > > The TJR1443 looked sufficiently similar to the TCAN1043 to use the
> > > same driver configuration (which is limited to having standby and/or
> > > enable signals or not).  However, I'm not sure it behaves exactly
> > > the same, e.g. in case of reporting an error condition (which is not
> > > yet supported by the driver). The part numbers are also different,
> > > so this is not a simple case of SN74HCxx vs. CD74HCxx.
> > >
> > > Summary: I don't know if they are identical, or if TJR1443 is a
> > > compatible superset of TCAN1043, or vice versa. Hence I went for the
> > > safest way....
> >
> > If we don't know for sure what the craic is with compatibility, then we
> > should leave the existing tjr1443 compatible as-is I think.
> 
> If I understood the kernel documentation correctly, we use fallback
> compatibles when devices are similar or there is an iterative
> relationship between them. In my case, the TCAN1042 and ATA6561 are
> from different manufacturers, and I'm not sure about their fully
> identical functionality.

It's about programming models being compatible, not identical. The
manufacturer also doesn't matter.

> Therefore, I'll go back to the original idea where I shouldn't use a
> fallback compatible here and must leave it as another compatible
> property with its own of_device_id struct.
> 
> What do you think about it? In my opinion, this is not a case for
> fallback compatibility.

Why is it not a case, other than the reasons you already mentioned that
I don't agree with?

Cheers,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-phy/attachments/20240805/e1c8d78e/attachment.sig>

From virag.david003 at gmail.com  Mon Aug  5 05:44:01 2024
From: virag.david003 at gmail.com (David Virag)
Date: Mon, 05 Aug 2024 14:44:01 +0200
Subject: [PATCH 06/13] clk: samsung: exynos7885: Update CLKS_NR_FSYS
 after bindings fix
In-Reply-To: <bd7c76a6-b7a5-4f8d-8081-95b6cdb39186@kernel.org>
References: <20240804215458.404085-1-virag.david003@gmail.com>
	 <20240804215458.404085-7-virag.david003@gmail.com>
	 <bd7c76a6-b7a5-4f8d-8081-95b6cdb39186@kernel.org>
Message-ID: <5af8048741215bdafa5d8f7bf6ab8dec3cd7aed0.camel@gmail.com>

Hi Krzysztof,

On Mon, 2024-08-05 at 07:49 +0200, Krzysztof Kozlowski wrote:
> On 04/08/2024 23:53, David Virag wrote:
> > Update CLKS_NR_FSYS to the proper value after a fix in DT bindings.
> > This should always be the last clock in a CMU + 1.
> > 
> > Signed-off-by: David Virag <virag.david003 at gmail.com>
> > ---
> > ?drivers/clk/samsung/clk-exynos7885.c | 2 +-
> 
> This needs fixes and Cc-stable tag, same as the binding.

Would it fix ef4923c8e052 ("clk: samsung: exynos7885: do not define number of clocks in bindings")?
Or would it fix cd268e309c29 ("dt-bindings: clock: Add bindings for Exynos7885 CMU_FSYS")?

I'm guessing the former, but technically the latter introduced
the problem and the former transferred it to the clk driver.

For kernel 6.1, this fix wouldn't work, as we'd need a fix in the
dt-bindings instead (perhaps the dt-bindings fix should include
this fix there).

How would this work?

> 
> Best regards,
> Krzysztof
> 

Best regards,
David


From krzk at kernel.org  Mon Aug  5 06:38:49 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Mon, 5 Aug 2024 15:38:49 +0200
Subject: [PATCH 06/13] clk: samsung: exynos7885: Update CLKS_NR_FSYS after
 bindings fix
In-Reply-To: <5af8048741215bdafa5d8f7bf6ab8dec3cd7aed0.camel@gmail.com>
References: <20240804215458.404085-1-virag.david003@gmail.com>
 <20240804215458.404085-7-virag.david003@gmail.com>
 <bd7c76a6-b7a5-4f8d-8081-95b6cdb39186@kernel.org>
 <5af8048741215bdafa5d8f7bf6ab8dec3cd7aed0.camel@gmail.com>
Message-ID: <df81f36d-ca61-4fbd-8399-ac97a7fa898f@kernel.org>

On 05/08/2024 14:44, David Virag wrote:
> Hi Krzysztof,
> 
> On Mon, 2024-08-05 at 07:49 +0200, Krzysztof Kozlowski wrote:
>> On 04/08/2024 23:53, David Virag wrote:
>>> Update CLKS_NR_FSYS to the proper value after a fix in DT bindings.
>>> This should always be the last clock in a CMU + 1.
>>>
>>> Signed-off-by: David Virag <virag.david003 at gmail.com>
>>> ---
>>> ?drivers/clk/samsung/clk-exynos7885.c | 2 +-
>>
>> This needs fixes and Cc-stable tag, same as the binding.
> 
> Would it fix ef4923c8e052 ("clk: samsung: exynos7885: do not define number of clocks in bindings")?
> Or would it fix cd268e309c29 ("dt-bindings: clock: Add bindings for Exynos7885 CMU_FSYS")?
> 
> I'm guessing the former, but technically the latter introduced
> the problem and the former transferred it to the clk driver.
> 
> For kernel 6.1, this fix wouldn't work, as we'd need a fix in the
> dt-bindings instead (perhaps the dt-bindings fix should include
> this fix there).
> 
> How would this work?

I would say this fixes the latter - bindings commit which introduced
duplicated ID. If your bindings patch is backported, then the number of
IDs do not match anymore number of clocks.

Without your bindings fix, everything matches even though it is not
technically correct.

The bindings fix also needs Cc-stable.

Best regards,
Krzysztof



From manivannan.sadhasivam at linaro.org  Mon Aug  5 07:06:06 2024
From: manivannan.sadhasivam at linaro.org (Manivannan Sadhasivam)
Date: Mon, 5 Aug 2024 19:36:06 +0530
Subject: [PATCH v3] phy: qcom: qmp: Add debug prints for register writes
In-Reply-To: <Zq-ura3oYbhb8C9a@matsya>
References: <20240731152548.102987-1-manivannan.sadhasivam@linaro.org>
 <172249532035.256913.2685367794999812971.b4-ty@kernel.org>
 <20240801070026.GB3705@thinkpad>
 <Zq-ura3oYbhb8C9a@matsya>
Message-ID: <20240805140606.GD7274@thinkpad>

On Sun, Aug 04, 2024 at 10:09:09PM +0530, Vinod Koul wrote:
> On 01-08-24, 12:30, Manivannan Sadhasivam wrote:
> > On Thu, Aug 01, 2024 at 12:25:20PM +0530, Vinod Koul wrote:
> > > 
> > > On Wed, 31 Jul 2024 20:55:48 +0530, Manivannan Sadhasivam wrote:
> > > > These register prints are useful to validate the init sequence against the
> > > > Qcom internal documentation and also to share with the Qcom hw engineers to
> > > > debug issues related to PHY.
> > > > 
> > > > Sample debug prints:
> > > > 
> > > > qcom-qmp-pcie-phy 1c0e000.phy: Writing Reg: QSERDES_V5_COM_SYSCLK_EN_SEL Offset: 0x0094 Val: 0xd9
> > > > qcom-qmp-pcie-phy 1c0e000.phy: Writing Reg: QSERDES_V5_COM_HSCLK_SEL Offset: 0x0158 Val: 0x11
> > > > 
> > > > [...]
> > > 
> > > Applied, thanks!
> > > 
> > > [1/1] phy: qcom: qmp: Add debug prints for register writes
> > >       commit: 4e92d504475ea5841716ad775f412342520a3d26
> > > 
> > 
> > Thanks! Bjorn spotted that it is worth making 'char *name' a const. Can you
> > please ammend the commit?
> 
> Send a patch please, I dont like to rebase
> 

Ok, will do.

- Mani

-- 
????????? ????????


From vkoul at kernel.org  Mon Aug  5 09:22:39 2024
From: vkoul at kernel.org (Vinod Koul)
Date: Mon, 05 Aug 2024 21:52:39 +0530
Subject: [PATCH v2] phy: xilinx: phy-zynqmp: Fix SGMII linkup failure
 on resume
In-Reply-To: <1722837547-2578381-1-git-send-email-radhey.shyam.pandey@amd.com>
References: <1722837547-2578381-1-git-send-email-radhey.shyam.pandey@amd.com>
Message-ID: <172287495984.454961.1953933716423263529.b4-ty@kernel.org>


On Mon, 05 Aug 2024 11:29:07 +0530, Radhey Shyam Pandey wrote:
> On a few Kria KR260 Robotics Starter Kit the PS-GEM SGMII linkup is not
> happening after the resume. This is because serdes registers are reset
> when FPD is off (in suspend state) and needs to be reprogrammed in the
> resume path with the same default initialization as done in the first
> stage bootloader psu_init routine.
> 
> To address the failure introduce a set of serdes registers to be saved in
> the suspend path and then restore it on resume.
> 
> [...]

Applied, thanks!

[1/1] phy: xilinx: phy-zynqmp: Fix SGMII linkup failure on resume
      commit: 5af9b304bc6010723c02f74de0bfd24ff19b1a10

Best regards,
-- 
Vinod Koul <vkoul at kernel.org>



From vkoul at kernel.org  Mon Aug  5 09:24:56 2024
From: vkoul at kernel.org (Vinod Koul)
Date: Mon, 05 Aug 2024 21:54:56 +0530
Subject: [PATCH v3] phy: cadence-torrent: add support for three or more
 links using 2 protocols
In-Reply-To: <20240716102442.1605280-1-s-vadapalli@ti.com>
References: <20240716102442.1605280-1-s-vadapalli@ti.com>
Message-ID: <172287509695.465699.4333434090979215764.b4-ty@kernel.org>


On Tue, 16 Jul 2024 15:54:42 +0530, Siddharth Vadapalli wrote:
> The Torrent SERDES can support at most two different protocols (PHY types).
> This only mandates that the device-tree sub-nodes used to represent the
> configuration should describe links with at-most two different protocols.
> 
> The existing implementation however imposes an artificial constraint that
> allows only two links (device-tree sub-nodes). As long as at-most two
> protocols are chosen, using more than two links to describe them in an
> alternating configuration is still a valid configuration of the Torrent
> SERDES.
> 
> [...]

Applied, thanks!

[1/1] phy: cadence-torrent: add support for three or more links using 2 protocols
      commit: 5b7b83a9839be643410c31d56f17c2d430245813

Best regards,
-- 
Vinod Koul <vkoul at kernel.org>



From vkoul at kernel.org  Mon Aug  5 09:25:00 2024
From: vkoul at kernel.org (Vinod Koul)
Date: Mon, 05 Aug 2024 21:55:00 +0530
Subject: [PATCH v4] phy: cadence-torrent: add support for three or more
 links using 2 protocols
In-Reply-To: <20240805092607.143869-1-s-vadapalli@ti.com>
References: <20240805092607.143869-1-s-vadapalli@ti.com>
Message-ID: <172287510078.465699.11033590406839071386.b4-ty@kernel.org>


On Mon, 05 Aug 2024 14:56:07 +0530, Siddharth Vadapalli wrote:
> The Torrent SERDES can support at most two different protocols (PHY types).
> This only mandates that the device-tree sub-nodes used to represent the
> configuration should describe links with at-most two different protocols.
> 
> The existing implementation however imposes an artificial constraint that
> allows only two links (device-tree sub-nodes). As long as at-most two
> protocols are chosen, using more than two links to describe them in an
> alternating configuration is still a valid configuration of the Torrent
> SERDES.
> 
> [...]

Applied, thanks!

[1/1] phy: cadence-torrent: add support for three or more links using 2 protocols
      commit: 5b7b83a9839be643410c31d56f17c2d430245813

Best regards,
-- 
Vinod Koul <vkoul at kernel.org>



From vkoul at kernel.org  Mon Aug  5 09:25:05 2024
From: vkoul at kernel.org (Vinod Koul)
Date: Mon, 05 Aug 2024 21:55:05 +0530
Subject: [PATCH v2 0/4] Add clock provider support to Rockchip RK3588
 HDMI TX PHY
In-Reply-To: <20240620-rk3588-hdmiphy-clkprov-v2-0-6a2d2164e508@collabora.com>
References: <20240620-rk3588-hdmiphy-clkprov-v2-0-6a2d2164e508@collabora.com>
Message-ID: <172287510559.465699.10935386894693742033.b4-ty@kernel.org>


On Thu, 20 Jun 2024 03:36:21 +0300, Cristian Ciocaltea wrote:
> The HDMI PHY PLL can be used as an alternative clock source to RK3588
> SoC CRU. Since it provides more accurate clock rates, it can be used by
> VOP2 to improve display modes handling, such as supporting non-integer
> refresh rates.
> 
> The first two patches in the series provide a couple of fixes and
> improvements to the existing HDPTX PHY driver, while the next two add
> the necessary changes to support the clock provider functionality.
> 
> [...]

Applied, thanks!

[1/4] phy: phy-rockchip-samsung-hdptx: Explicitly include pm_runtime.h
      commit: 1b369ff94bc36d2e16c8a91c0ea8ebd329555976
[2/4] phy: phy-rockchip-samsung-hdptx: Enable runtime PM at PHY core level
      commit: 10ba8479f460e9256f7d884dc1b7d89006a89c7b
[3/4] dt-bindings: phy: rockchip,rk3588-hdptx-phy: Add #clock-cells
      commit: a652f2210054276990d45626a3b9ad5c99465f5a
[4/4] phy: phy-rockchip-samsung-hdptx: Add clock provider support
      commit: c4b09c562086f32588d962d30d0b7e93fe3e7cbb

Best regards,
-- 
Vinod Koul <vkoul at kernel.org>



From abel.vesa at linaro.org  Mon Aug  5 09:45:18 2024
From: abel.vesa at linaro.org (Abel Vesa)
Date: Mon, 05 Aug 2024 19:45:18 +0300
Subject: [PATCH v3] phy: qcom: qmp-pcie: Configure all tables on port B PHY
Message-ID: <20240805-phy-qcom-qmp-pcie-write-all-tbls-second-port-v3-1-6967c6bf61d1@linaro.org>

From: Qiang Yu <quic_qianyu at quicinc.com>

Currently, only the RX and TX tables are written to the second PHY
(port B) when the 4-lanes mode is configured, but according to Qualcomm
internal documentation, the pcs, pcs_misc, serdes and ln_shrd tables need
to be written as well.

Signed-off-by: Qiang Yu <quic_qianyu at quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
Signed-off-by: Abel Vesa <abel.vesa at linaro.org>
---
Changes in v3:
- Rebased on phy/next
- Fetched Dmitry's R-b tag
- Link to v2: https://lore.kernel.org/r/20240801-phy-qcom-qmp-pcie-write-all-tbls-second-port-v2-1-6e53c701e87e at linaro.org

Changes in v2:
- Reordered tables as Johan has suggested
- Link to v1: https://lore.kernel.org/r/20240726-phy-qcom-qmp-pcie-write-all-tbls-second-port-v1-1-751b9ee01184 at linaro.org
---
 drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
index 4b4a10f7f6d6..a7e2ce0c500d 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
@@ -3669,18 +3669,30 @@ static void qmp_pcie_init_port_b(struct qmp_pcie *qmp, const struct qmp_phy_cfg_
 {
 	const struct qmp_phy_cfg *cfg = qmp->cfg;
 	const struct qmp_pcie_offsets *offs = cfg->offsets;
-	void __iomem *tx3, *rx3, *tx4, *rx4;
+	void __iomem *serdes, *tx3, *rx3, *tx4, *rx4, *pcs, *pcs_misc, *ln_shrd;
 
+	serdes = qmp->port_b + offs->serdes;
 	tx3 = qmp->port_b + offs->tx;
 	rx3 = qmp->port_b + offs->rx;
 	tx4 = qmp->port_b + offs->tx2;
 	rx4 = qmp->port_b + offs->rx2;
+	pcs = qmp->port_b + offs->pcs;
+	pcs_misc = qmp->port_b + offs->pcs_misc;
+	ln_shrd = qmp->port_b + offs->ln_shrd;
+
+	qmp_configure(qmp->dev, serdes, tbls->serdes, tbls->serdes_num);
+	qmp_configure(qmp->dev, serdes, cfg->serdes_4ln_tbl, cfg->serdes_4ln_num);
 
 	qmp_configure_lane(qmp->dev, tx3, tbls->tx, tbls->tx_num, 1);
 	qmp_configure_lane(qmp->dev, rx3, tbls->rx, tbls->rx_num, 1);
 
 	qmp_configure_lane(qmp->dev, tx4, tbls->tx, tbls->tx_num, 2);
 	qmp_configure_lane(qmp->dev, rx4, tbls->rx, tbls->rx_num, 2);
+
+	qmp_configure(qmp->dev, pcs, tbls->pcs, tbls->pcs_num);
+	qmp_configure(qmp->dev, pcs_misc, tbls->pcs_misc, tbls->pcs_misc_num);
+
+	qmp_configure(qmp->dev, ln_shrd, tbls->ln_shrd, tbls->ln_shrd_num);
 }
 
 static void qmp_pcie_init_registers(struct qmp_pcie *qmp, const struct qmp_phy_cfg_tbls *tbls)

---
base-commit: d6dbc9f56c3a70e915625b6f1887882c23dc5c91
change-id: 20240725-phy-qcom-qmp-pcie-write-all-tbls-second-port-8efeced876bf

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



From lorenzo at kernel.org  Mon Aug  5 10:17:54 2024
From: lorenzo at kernel.org (Lorenzo Bianconi)
Date: Mon, 5 Aug 2024 19:17:54 +0200
Subject: [PATCH] phy: airoha: adjust initialization delay in
 airoha_pcie_phy_init()
In-Reply-To: <Zq-67ZnlmMLh_Ssz@matsya>
References: <82e50875deba44e34f49bd92578b4dc24f121b01.1720508349.git.lorenzo@kernel.org>
 <Zq-67ZnlmMLh_Ssz@matsya>
Message-ID: <ZrEJQlCJbj5G0nI8@lore-rh-laptop>

> On 09-07-24, 09:03, Lorenzo Bianconi wrote:
> > Align phy-pcie initialization delay to the vendor sdk in
> > airoha_pcie_phy_init routine and allow the hw to complete required
> > configuration before proceeding
> > 
> > Signed-off-by: Lorenzo Bianconi <lorenzo at kernel.org>
> > ---
> >  drivers/phy/phy-airoha-pcie.c | 10 ++++++++--
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/phy/phy-airoha-pcie.c b/drivers/phy/phy-airoha-pcie.c
> > index bd3edaa986c8..445bacfdaaf4 100644
> > --- a/drivers/phy/phy-airoha-pcie.c
> > +++ b/drivers/phy/phy-airoha-pcie.c
> > @@ -18,6 +18,9 @@
> >  #define LEQ_LEN_CTRL_MAX_VAL	7
> >  #define FREQ_LOCK_MAX_ATTEMPT	10
> >  
> > +/* PCIe-PHY initialization time in ms needed by the hw to complete */
> > +#define PHY_HW_INIT_TIME_MS	30
> > +
> >  enum airoha_pcie_port_gen {
> >  	PCIE_PORT_GEN1 = 1,
> >  	PCIE_PORT_GEN2,
> > @@ -1180,8 +1183,11 @@ static int airoha_pcie_phy_init(struct phy *phy)
> >  				 PCIE_DA_XPON_CDR_PR_PWDB);
> >  	airoha_phy_pma1_set_bits(pcie_phy, REG_PCIE_PMA_SS_DA_XPON_PWDB0,
> >  				 PCIE_DA_XPON_CDR_PR_PWDB);
> > -
> > -	usleep_range(100, 200);
> > +	/*
> > +	 * Wait for the time in ms needed by the hw to complete the PCIe-PHY
> > +	 * initialization
> > +	 */
> > +	mdelay(PHY_HW_INIT_TIME_MS);
> 
> Why not use msleep()...?

ack, you are right, it is not in an atomic context. I will fix it in v2.

Regards,
Lorenzo

> 
> -- 
> ~Vinod
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-phy/attachments/20240805/c53fdb55/attachment.sig>

From lorenzo at kernel.org  Mon Aug  5 12:57:23 2024
From: lorenzo at kernel.org (Lorenzo Bianconi)
Date: Mon,  5 Aug 2024 21:57:23 +0200
Subject: [PATCH v2] phy: airoha: adjust initialization delay in airoha_pcie_phy_init()
Message-ID: <d174837bcb5a53f7b2c2580211d60a175d0ce8db.1722887003.git.lorenzo@kernel.org>

Align phy-pcie initialization delay to the vendor sdk in
airoha_pcie_phy_init routine and allow the hw to complete required
configuration before proceeding

Signed-off-by: Lorenzo Bianconi <lorenzo at kernel.org>
---
Changes since v1:
- use msleep() instead of mdelay()
---
 drivers/phy/phy-airoha-pcie.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/phy-airoha-pcie.c b/drivers/phy/phy-airoha-pcie.c
index bd3edaa986c8..6d61e6486a03 100644
--- a/drivers/phy/phy-airoha-pcie.c
+++ b/drivers/phy/phy-airoha-pcie.c
@@ -18,6 +18,9 @@
 #define LEQ_LEN_CTRL_MAX_VAL	7
 #define FREQ_LOCK_MAX_ATTEMPT	10
 
+/* PCIe-PHY initialization time in ms needed by the hw to complete */
+#define PHY_HW_INIT_TIME_MS	30
+
 enum airoha_pcie_port_gen {
 	PCIE_PORT_GEN1 = 1,
 	PCIE_PORT_GEN2,
@@ -1180,8 +1183,11 @@ static int airoha_pcie_phy_init(struct phy *phy)
 				 PCIE_DA_XPON_CDR_PR_PWDB);
 	airoha_phy_pma1_set_bits(pcie_phy, REG_PCIE_PMA_SS_DA_XPON_PWDB0,
 				 PCIE_DA_XPON_CDR_PR_PWDB);
-
-	usleep_range(100, 200);
+	/*
+	 * Wait for the time in ms needed by the hw to complete the PCIe-PHY
+	 * initialization
+	 */
+	msleep(PHY_HW_INIT_TIME_MS);
 
 	return 0;
 }
-- 
2.45.2



From xu.yang_2 at nxp.com  Mon Aug  5 22:06:35 2024
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Tue,  6 Aug 2024 13:06:35 +0800
Subject: [PATCH v2 1/5] dt-bindings: phy: imx8mq-usb: add compatible "fsl,imx95-usb-phy"
Message-ID: <20240806050639.1013152-1-xu.yang_2@nxp.com>

The usb phy in i.MX95 is compatible with i.MX8MP's, this will add a
compatible "fsl,imx95-usb-phy" for i.MX95. Also change reg maxItems
to 2 since i.MX95 needs another regmap to control Type-C Assist (TCA)
block. Since i.MX95 usb phy is able to switch SS lanes, this will also
add orientation-switch and port property to the file.

Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>

---
Changes in v2:
 - replace minItems with description in reg property
 - remove orientation-switch and port
 - refer to usb-switch.yaml
 - use unevaluatedProperties
---
 .../bindings/phy/fsl,imx8mq-usb-phy.yaml      | 42 ++++++++++++++++---
 1 file changed, 37 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
index dc3a3f709fea..6d6d211883ae 100644
--- a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
@@ -11,12 +11,17 @@ maintainers:
 
 properties:
   compatible:
-    enum:
-      - fsl,imx8mq-usb-phy
-      - fsl,imx8mp-usb-phy
+    oneOf:
+      - enum:
+          - fsl,imx8mq-usb-phy
+          - fsl,imx8mp-usb-phy
+      - items:
+          - const: fsl,imx95-usb-phy
+          - const: fsl,imx8mp-usb-phy
 
   reg:
-    maxItems: 1
+    minItems: 1
+    maxItems: 2
 
   "#phy-cells":
     const: 0
@@ -89,7 +94,34 @@ required:
   - clocks
   - clock-names
 
-additionalProperties: false
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - fsl,imx95-usb-phy
+    then:
+      properties:
+        reg:
+          items:
+            - description: USB PHY Control range
+            - description: USB PHY TCA Block range
+    else:
+      properties:
+        reg:
+          maxItems: 1
+
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - fsl,imx95-usb-phy
+    then:
+      $ref: /schemas/usb/usb-switch.yaml#
+
+unevaluatedProperties: false
 
 examples:
   - |
-- 
2.34.1



From xu.yang_2 at nxp.com  Mon Aug  5 22:06:36 2024
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Tue,  6 Aug 2024 13:06:36 +0800
Subject: [PATCH v2 2/5] dt-bindings: usb: dwc3-imx8mp: add compatible string for imx95
In-Reply-To: <20240806050639.1013152-1-xu.yang_2@nxp.com>
References: <20240806050639.1013152-1-xu.yang_2@nxp.com>
Message-ID: <20240806050639.1013152-2-xu.yang_2@nxp.com>

The i.MX95 is compatible with i.MX8MP's usb controller. This will add a
compatible string "fsl,imx95-dwc3" for i.MX95.

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>

---
Changes in v2:
 - add Ack-by tag
---
 Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml b/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml
index 9ea1e4cd0709..baf130669c38 100644
--- a/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml
@@ -12,7 +12,11 @@ maintainers:
 
 properties:
   compatible:
-    const: fsl,imx8mp-dwc3
+    oneOf:
+      - items:
+          - const: fsl,imx95-dwc3
+          - const: fsl,imx8mp-dwc3
+      - const: fsl,imx8mp-dwc3
 
   reg:
     items:
-- 
2.34.1



From xu.yang_2 at nxp.com  Mon Aug  5 22:06:37 2024
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Tue,  6 Aug 2024 13:06:37 +0800
Subject: [PATCH v2 3/5] phy: fsl-imx8mq-usb: add tca function driver for imx95
In-Reply-To: <20240806050639.1013152-1-xu.yang_2@nxp.com>
References: <20240806050639.1013152-1-xu.yang_2@nxp.com>
Message-ID: <20240806050639.1013152-3-xu.yang_2@nxp.com>

The i.MX95 USB3 phy has a Type-C Assist block (TCA). This block consists
two functional blocks (XBar assist and VBus assist) and one system
access interface using APB.

The primary functionality of XBar assist is:
 - switching lane for flip
 - moving unused lanes into lower power states.

This info can be get from:
i.MX95 RM Chapter 163.3.8 Type-C assist (TCA) block.

This will add support for TCA block to achieve lane switching and tca
lower power functionality.

Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
Reviewed-by: Jun Li <jun.li at nxp.com>

---
Changes in v2:
 - return the value of imx95_usb_phy_get_tca()
---
 drivers/phy/freescale/Kconfig              |   1 +
 drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 240 +++++++++++++++++++++
 2 files changed, 241 insertions(+)

diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
index dcd9acff6d01..81f53564ee15 100644
--- a/drivers/phy/freescale/Kconfig
+++ b/drivers/phy/freescale/Kconfig
@@ -5,6 +5,7 @@ if (ARCH_MXC && ARM64) || COMPILE_TEST
 config PHY_FSL_IMX8MQ_USB
 	tristate "Freescale i.MX8M USB3 PHY"
 	depends on OF && HAS_IOMEM
+	depends on TYPEC || TYPEC=n
 	select GENERIC_PHY
 	default ARCH_MXC && ARM64
 
diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
index adc6394626ce..8bd6d91951a2 100644
--- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
+++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
@@ -10,6 +10,7 @@
 #include <linux/phy/phy.h>
 #include <linux/platform_device.h>
 #include <linux/regulator/consumer.h>
+#include <linux/usb/typec_mux.h>
 
 #define PHY_CTRL0			0x0
 #define PHY_CTRL0_REF_SSP_EN		BIT(2)
@@ -50,11 +51,66 @@
 
 #define PHY_TUNE_DEFAULT		0xffffffff
 
+#define TCA_CLK_RST			0x00
+#define TCA_CLK_RST_SW			BIT(9)
+#define TCA_CLK_RST_REF_CLK_EN		BIT(1)
+#define TCA_CLK_RST_SUSPEND_CLK_EN	BIT(0)
+
+#define TCA_INTR_EN			0x04
+#define TCA_INTR_STS			0x08
+
+#define TCA_GCFG			0x10
+#define TCA_GCFG_ROLE_HSTDEV		BIT(4)
+#define TCA_GCFG_OP_MODE		GENMASK(1, 0)
+#define TCA_GCFG_OP_MODE_SYSMODE	0
+#define TCA_GCFG_OP_MODE_SYNCMODE	1
+
+#define TCA_TCPC			0x14
+#define TCA_TCPC_VALID			BIT(4)
+#define TCA_TCPC_LOW_POWER_EN		BIT(3)
+#define TCA_TCPC_ORIENTATION_NORMAL	BIT(2)
+#define TCA_TCPC_MUX_CONTRL		GENMASK(1, 0)
+#define TCA_TCPC_MUX_CONTRL_NO_CONN	0
+#define TCA_TCPC_MUX_CONTRL_USB_CONN	1
+
+#define TCA_SYSMODE_CFG			0x18
+#define TCA_SYSMODE_TCPC_DISABLE	BIT(3)
+#define TCA_SYSMODE_TCPC_FLIP		BIT(2)
+
+#define TCA_CTRLSYNCMODE_CFG0		0x20
+#define TCA_CTRLSYNCMODE_CFG1           0x20
+
+#define TCA_PSTATE			0x30
+#define TCA_PSTATE_CM_STS		BIT(4)
+#define TCA_PSTATE_TX_STS		BIT(3)
+#define TCA_PSTATE_RX_PLL_STS		BIT(2)
+#define TCA_PSTATE_PIPE0_POWER_DOWN	GENMASK(1, 0)
+
+#define TCA_GEN_STATUS			0x34
+#define TCA_GEN_DEV_POR			BIT(12)
+#define TCA_GEN_REF_CLK_SEL		BIT(8)
+#define TCA_GEN_TYPEC_FLIP_INVERT	BIT(4)
+#define TCA_GEN_PHY_TYPEC_DISABLE	BIT(3)
+#define TCA_GEN_PHY_TYPEC_FLIP		BIT(2)
+
+#define TCA_VBUS_CTRL			0x40
+#define TCA_VBUS_STATUS			0x44
+
+#define TCA_INFO			0xFC
+
+struct tca_blk {
+	struct typec_switch_dev *sw;
+	void __iomem *base;
+	struct mutex mutex;
+	enum typec_orientation orientation;
+};
+
 struct imx8mq_usb_phy {
 	struct phy *phy;
 	struct clk *clk;
 	void __iomem *base;
 	struct regulator *vbus;
+	struct tca_blk *tca;
 	u32 pcs_tx_swing_full;
 	u32 pcs_tx_deemph_3p5db;
 	u32 tx_vref_tune;
@@ -64,6 +120,170 @@ struct imx8mq_usb_phy {
 	u32 comp_dis_tune;
 };
 
+
+static void tca_blk_orientation_set(struct tca_blk *tca,
+				enum typec_orientation orientation);
+
+#ifdef CONFIG_TYPEC
+
+static int tca_blk_typec_switch_set(struct typec_switch_dev *sw,
+				enum typec_orientation orientation)
+{
+	struct imx8mq_usb_phy *imx_phy = typec_switch_get_drvdata(sw);
+	struct tca_blk *tca = imx_phy->tca;
+	int ret;
+
+	if (tca->orientation == orientation)
+		return 0;
+
+	ret = clk_prepare_enable(imx_phy->clk);
+	if (ret)
+		return ret;
+
+	tca_blk_orientation_set(tca, orientation);
+	clk_disable_unprepare(imx_phy->clk);
+
+	return 0;
+}
+
+static struct typec_switch_dev *tca_blk_get_typec_switch(struct platform_device *pdev,
+					struct imx8mq_usb_phy *imx_phy)
+{
+	struct device *dev = &pdev->dev;
+	struct typec_switch_dev *sw;
+	struct typec_switch_desc sw_desc = { };
+
+	sw_desc.drvdata = imx_phy;
+	sw_desc.fwnode = dev->fwnode;
+	sw_desc.set = tca_blk_typec_switch_set;
+	sw_desc.name = NULL;
+
+	sw = typec_switch_register(dev, &sw_desc);
+	if (IS_ERR(sw)) {
+		dev_err(dev, "Error register tca orientation switch: %ld",
+				PTR_ERR(sw));
+		return NULL;
+	}
+
+	return sw;
+}
+
+static void tca_blk_put_typec_switch(struct typec_switch_dev *sw)
+{
+	typec_switch_unregister(sw);
+}
+
+#else
+
+static struct typec_switch_dev *tca_blk_get_typec_switch(struct platform_device *pdev,
+			struct imx8mq_usb_phy *imx_phy)
+{
+	return NULL;
+}
+
+static void tca_blk_put_typec_switch(struct typec_switch_dev *sw) {}
+
+#endif /* CONFIG_TYPEC */
+
+static void tca_blk_orientation_set(struct tca_blk *tca,
+				enum typec_orientation orientation)
+{
+	u32 val;
+
+	mutex_lock(&tca->mutex);
+
+	if (orientation == TYPEC_ORIENTATION_NONE) {
+		/*
+		 * use Controller Synced Mode for TCA low power enable and
+		 * put PHY to USB safe state.
+		 */
+		val = readl(tca->base + TCA_GCFG);
+		val = FIELD_PREP(TCA_GCFG_OP_MODE, TCA_GCFG_OP_MODE_SYNCMODE);
+		writel(val, tca->base + TCA_GCFG);
+
+		val = readl(tca->base + TCA_TCPC);
+		val = TCA_TCPC_VALID | TCA_TCPC_LOW_POWER_EN;
+		writel(val, tca->base + TCA_TCPC);
+
+		goto out;
+	}
+
+	/* use System Configuration Mode for TCA mux control. */
+	val = readl(tca->base + TCA_GCFG);
+	val = FIELD_PREP(TCA_GCFG_OP_MODE, TCA_GCFG_OP_MODE_SYSMODE);
+	writel(val, tca->base + TCA_GCFG);
+
+	/* Disable TCA module */
+	val = readl(tca->base + TCA_SYSMODE_CFG);
+	val |= TCA_SYSMODE_TCPC_DISABLE;
+	writel(val, tca->base + TCA_SYSMODE_CFG);
+
+	if (orientation == TYPEC_ORIENTATION_REVERSE)
+		val |= TCA_SYSMODE_TCPC_FLIP;
+	else if (orientation == TYPEC_ORIENTATION_NORMAL)
+		val &= ~TCA_SYSMODE_TCPC_FLIP;
+
+	writel(val, tca->base + TCA_SYSMODE_CFG);
+
+	/* Enable TCA module */
+	val &= ~TCA_SYSMODE_TCPC_DISABLE;
+	writel(val, tca->base + TCA_SYSMODE_CFG);
+
+out:
+	tca->orientation = orientation;
+	mutex_unlock(&tca->mutex);
+}
+
+static void tca_blk_init(struct tca_blk *tca)
+{
+	u32 val;
+
+	/* reset XBar block */
+	val = readl(tca->base + TCA_CLK_RST);
+	val &= ~TCA_CLK_RST_SW;
+	writel(val, tca->base + TCA_CLK_RST);
+
+	udelay(100);
+
+	/* clear reset */
+	val |= TCA_CLK_RST_SW;
+	writel(val, tca->base + TCA_CLK_RST);
+
+	tca_blk_orientation_set(tca, tca->orientation);
+}
+
+static struct tca_blk *imx95_usb_phy_get_tca(struct platform_device *pdev,
+				struct imx8mq_usb_phy *imx_phy)
+{
+	struct device *dev = &pdev->dev;
+	struct tca_blk *tca;
+
+	tca = devm_kzalloc(dev, sizeof(*tca), GFP_KERNEL);
+	if (!tca)
+		return ERR_PTR(-ENOMEM);
+
+	tca->base = devm_platform_ioremap_resource(pdev, 1);
+	if (IS_ERR(tca->base))
+		return tca->base;
+
+	mutex_init(&tca->mutex);
+
+	tca->orientation = TYPEC_ORIENTATION_NORMAL;
+	tca->sw = tca_blk_get_typec_switch(pdev, imx_phy);
+
+	return tca;
+}
+
+static void imx95_usb_phy_put_tca(struct imx8mq_usb_phy *imx_phy)
+{
+	struct tca_blk *tca = imx_phy->tca;
+
+	if (!tca)
+		return;
+
+	tca_blk_put_typec_switch(tca->sw);
+}
+
 static u32 phy_tx_vref_tune_from_property(u32 percent)
 {
 	percent = clamp(percent, 94U, 124U);
@@ -315,6 +535,9 @@ static int imx8mp_usb_phy_init(struct phy *phy)
 
 	imx8m_phy_tune(imx_phy);
 
+	if (imx_phy->tca)
+		tca_blk_init(imx_phy->tca);
+
 	return 0;
 }
 
@@ -359,6 +582,8 @@ static const struct of_device_id imx8mq_usb_phy_of_match[] = {
 	 .data = &imx8mq_usb_phy_ops,},
 	{.compatible = "fsl,imx8mp-usb-phy",
 	 .data = &imx8mp_usb_phy_ops,},
+	{.compatible = "fsl,imx95-usb-phy",
+	 .data = &imx8mp_usb_phy_ops,},
 	{ }
 };
 MODULE_DEVICE_TABLE(of, imx8mq_usb_phy_of_match);
@@ -398,6 +623,13 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
 
 	phy_set_drvdata(imx_phy->phy, imx_phy);
 
+	if (device_is_compatible(dev, "fsl,imx95-usb-phy")) {
+		imx_phy->tca = imx95_usb_phy_get_tca(pdev, imx_phy);
+		if (IS_ERR(imx_phy->tca))
+			return dev_err_probe(dev, PTR_ERR(imx_phy->tca),
+						"failed to get tca\n");
+	}
+
 	imx8m_get_phy_tuning_data(imx_phy);
 
 	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
@@ -405,8 +637,16 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
 	return PTR_ERR_OR_ZERO(phy_provider);
 }
 
+static void imx8mq_usb_phy_remove(struct platform_device *pdev)
+{
+	struct imx8mq_usb_phy *imx_phy = platform_get_drvdata(pdev);
+
+	imx95_usb_phy_put_tca(imx_phy);
+}
+
 static struct platform_driver imx8mq_usb_phy_driver = {
 	.probe	= imx8mq_usb_phy_probe,
+	.remove = imx8mq_usb_phy_remove,
 	.driver = {
 		.name	= "imx8mq-usb-phy",
 		.of_match_table	= imx8mq_usb_phy_of_match,
-- 
2.34.1



From xu.yang_2 at nxp.com  Mon Aug  5 22:06:38 2024
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Tue,  6 Aug 2024 13:06:38 +0800
Subject: [PATCH v2 4/5] arm64: dts: imx95: add usb3 related nodes
In-Reply-To: <20240806050639.1013152-1-xu.yang_2@nxp.com>
References: <20240806050639.1013152-1-xu.yang_2@nxp.com>
Message-ID: <20240806050639.1013152-4-xu.yang_2@nxp.com>

Add usb3 phy and controller nodes for imx95.

Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>

---
Changes in v2:
 - no changes
---
 arch/arm64/boot/dts/freescale/imx95.dtsi | 43 ++++++++++++++++++++++++
 1 file changed, 43 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
index 1bbf9a0468f6..06a7c2f1e211 100644
--- a/arch/arm64/boot/dts/freescale/imx95.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
@@ -1188,5 +1188,48 @@ pcie1_ep: pcie-ep at 4c380000 {
 			power-domains = <&scmi_devpd IMX95_PD_HSIO_TOP>;
 			status = "disabled";
 		};
+
+		usb3_phy: phy at 4c1f0040 {
+			compatible = "fsl,imx95-usb-phy", "fsl,imx8mp-usb-phy";
+			reg = <0x0 0x4c1f0040 0x0 0x40>,
+			      <0x0 0x4c1fc000 0x0 0x100>;
+			clocks = <&scmi_clk IMX95_CLK_HSIO>;
+			clock-names = "phy";
+			#phy-cells = <0>;
+			power-domains = <&scmi_devpd IMX95_PD_HSIO_TOP>;
+			orientation-switch;
+			status = "disabled";
+		};
+
+		usb3: usb at 4c010010 {
+			compatible = "fsl,imx95-dwc3", "fsl,imx8mp-dwc3";
+			reg = <0x0 0x4c010010 0x0 0x04>,
+			      <0x0 0x4c1f0000 0x0 0x20>;
+			clocks = <&scmi_clk IMX95_CLK_HSIO>,
+				 <&scmi_clk IMX95_CLK_32K>;
+			clock-names = "hsio", "suspend";
+			interrupts = <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>;
+			#address-cells = <2>;
+			#size-cells = <2>;
+			ranges;
+			power-domains = <&scmi_devpd IMX95_PD_HSIO_TOP>;
+			dma-ranges = <0x0 0x0 0x0 0x0 0x10 0x0>;
+			status = "disabled";
+
+			usb3_dwc3: usb at 4c100000 {
+				compatible = "snps,dwc3";
+				reg = <0x0 0x4c100000 0x0 0x10000>;
+				clocks = <&scmi_clk IMX95_CLK_HSIO>,
+					 <&scmi_clk IMX95_CLK_24M>,
+					 <&scmi_clk IMX95_CLK_32K>;
+				clock-names = "bus_early", "ref", "suspend";
+				interrupts = <GIC_SPI 175 IRQ_TYPE_LEVEL_HIGH>;
+				phys = <&usb3_phy>, <&usb3_phy>;
+				phy-names = "usb2-phy", "usb3-phy";
+				snps,gfladj-refclk-lpm-sel-quirk;
+				snps,parkmode-disable-ss-quirk;
+				iommus = <&smmu 0xe>;
+			};
+		};
 	};
 };
-- 
2.34.1



From xu.yang_2 at nxp.com  Mon Aug  5 22:06:39 2024
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Tue,  6 Aug 2024 13:06:39 +0800
Subject: [PATCH v2 5/5] arm64: dts: imx95-19x19-evk: add typec nodes and enable usb3 node
In-Reply-To: <20240806050639.1013152-1-xu.yang_2@nxp.com>
References: <20240806050639.1013152-1-xu.yang_2@nxp.com>
Message-ID: <20240806050639.1013152-5-xu.yang_2@nxp.com>

This board has one Type-C port which has USB3 capability. This will
add typec nodes and enable usb3 node.

Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>

---
Changes in v2:
 - no changes
---
 .../boot/dts/freescale/imx95-19x19-evk.dts    | 81 +++++++++++++++++++
 1 file changed, 81 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
index d14a54ab4fd4..46a9cd3d4403 100644
--- a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
@@ -5,6 +5,7 @@
 
 /dts-v1/;
 
+#include <dt-bindings/usb/pd.h>
 #include "imx95.dtsi"
 
 / {
@@ -99,6 +100,48 @@ i2c7_pcal6524: i2c7-gpio at 22 {
 		interrupt-parent = <&gpio5>;
 		interrupts = <16 IRQ_TYPE_LEVEL_LOW>;
 	};
+
+	ptn5110: tcpc at 50 {
+		compatible = "nxp,ptn5110", "tcpci";
+		reg = <0x50>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_typec>;
+		interrupt-parent = <&gpio5>;
+		interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
+
+		typec_con: connector {
+			compatible = "usb-c-connector";
+			label = "USB-C";
+			power-role = "dual";
+			data-role = "dual";
+			try-power-role = "sink";
+			source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+			sink-pdos = <PDO_FIXED(5000, 0, PDO_FIXED_USB_COMM)>;
+			op-sink-microwatt = <0>;
+			self-powered;
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				port at 0 {
+					reg = <0>;
+
+					typec_con_hs: endpoint {
+						remote-endpoint = <&usb3_data_hs>;
+					};
+				};
+
+				port at 1 {
+					reg = <1>;
+
+					typec_con_ss: endpoint {
+						remote-endpoint = <&usb3_data_ss>;
+					};
+				};
+			};
+		};
+	};
 };
 
 &lpuart1 {
@@ -128,6 +171,38 @@ &pcie1 {
 	status = "okay";
 };
 
+&usb3 {
+	status = "okay";
+};
+
+&usb3_phy {
+	status = "okay";
+
+	port {
+		usb3_data_ss: endpoint {
+			remote-endpoint = <&typec_con_ss>;
+		};
+	};
+};
+
+&usb3_dwc3 {
+	dr_mode = "otg";
+	hnp-disable;
+	srp-disable;
+	adp-disable;
+	usb-role-switch;
+	role-switch-default-mode = "peripheral";
+	snps,dis-u1-entry-quirk;
+	snps,dis-u2-entry-quirk;
+	status = "okay";
+
+	port {
+		usb3_data_hs: endpoint {
+			remote-endpoint = <&typec_con_hs>;
+		};
+	};
+};
+
 &usdhc1 {
 	pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
 	pinctrl-0 = <&pinctrl_usdhc1>;
@@ -245,6 +320,12 @@ IMX95_PAD_SD2_RESET_B__GPIO3_IO_BIT7		0x31e
 		>;
 	};
 
+	pinctrl_typec: typecgrp {
+		fsl,pins = <
+			IMX95_PAD_GPIO_IO34__GPIO5_IO_BIT14			0x31e
+		>;
+	};
+
 	pinctrl_usdhc2_gpio: usdhc2gpiogrp {
 		fsl,pins = <
 			IMX95_PAD_SD2_CD_B__GPIO3_IO_BIT0		0x31e
-- 
2.34.1



From angelogioacchino.delregno at collabora.com  Tue Aug  6 01:17:12 2024
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Tue, 6 Aug 2024 10:17:12 +0200
Subject: [PATCH v2] phy: airoha: adjust initialization delay in
 airoha_pcie_phy_init()
In-Reply-To: <d174837bcb5a53f7b2c2580211d60a175d0ce8db.1722887003.git.lorenzo@kernel.org>
References: <d174837bcb5a53f7b2c2580211d60a175d0ce8db.1722887003.git.lorenzo@kernel.org>
Message-ID: <47f25caf-8d0d-4c9f-8550-fa9506680113@collabora.com>

Il 05/08/24 21:57, Lorenzo Bianconi ha scritto:
> Align phy-pcie initialization delay to the vendor sdk in
> airoha_pcie_phy_init routine and allow the hw to complete required
> configuration before proceeding
> 
> Signed-off-by: Lorenzo Bianconi <lorenzo at kernel.org>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>

> ---
> Changes since v1:
> - use msleep() instead of mdelay()
> ---
>   drivers/phy/phy-airoha-pcie.c | 10 ++++++++--
>   1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/phy/phy-airoha-pcie.c b/drivers/phy/phy-airoha-pcie.c
> index bd3edaa986c8..6d61e6486a03 100644
> --- a/drivers/phy/phy-airoha-pcie.c
> +++ b/drivers/phy/phy-airoha-pcie.c
> @@ -18,6 +18,9 @@
>   #define LEQ_LEN_CTRL_MAX_VAL	7
>   #define FREQ_LOCK_MAX_ATTEMPT	10
>   
> +/* PCIe-PHY initialization time in ms needed by the hw to complete */
> +#define PHY_HW_INIT_TIME_MS	30
> +
>   enum airoha_pcie_port_gen {
>   	PCIE_PORT_GEN1 = 1,
>   	PCIE_PORT_GEN2,
> @@ -1180,8 +1183,11 @@ static int airoha_pcie_phy_init(struct phy *phy)
>   				 PCIE_DA_XPON_CDR_PR_PWDB);
>   	airoha_phy_pma1_set_bits(pcie_phy, REG_PCIE_PMA_SS_DA_XPON_PWDB0,
>   				 PCIE_DA_XPON_CDR_PR_PWDB);
> -
> -	usleep_range(100, 200);
> +	/*
> +	 * Wait for the time in ms needed by the hw to complete the PCIe-PHY
> +	 * initialization

...but regardless, I have a nit here (not a blocker for me, hence the R-b tag):
there's no need to say that we're waiting for milliseconds, so this comment can
be just one line:

	/* Wait for the PCIe PHY to complete initialization before returning */

Cheers,
Angelo

> +	 */
> +	msleep(PHY_HW_INIT_TIME_MS);
>   
>   	return 0;
>   }




From krzk at kernel.org  Tue Aug  6 01:29:47 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Tue, 6 Aug 2024 10:29:47 +0200
Subject: [PATCH v2 1/5] dt-bindings: phy: imx8mq-usb: add compatible
 "fsl,imx95-usb-phy"
In-Reply-To: <20240806050639.1013152-1-xu.yang_2@nxp.com>
References: <20240806050639.1013152-1-xu.yang_2@nxp.com>
Message-ID: <160dd5fc-83ba-4311-a173-44521342a3d8@kernel.org>

On 06/08/2024 07:06, Xu Yang wrote:
> The usb phy in i.MX95 is compatible with i.MX8MP's, this will add a
> compatible "fsl,imx95-usb-phy" for i.MX95. Also change reg maxItems
> to 2 since i.MX95 needs another regmap to control Type-C Assist (TCA)
> block. Since i.MX95 usb phy is able to switch SS lanes, this will also
> add orientation-switch and port property to the file.
> 
> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> 
> ---
> Changes in v2:
>  - replace minItems with description in reg property
>  - remove orientation-switch and port
>  - refer to usb-switch.yaml
>  - use unevaluatedProperties
> ---
>  .../bindings/phy/fsl,imx8mq-usb-phy.yaml      | 42 ++++++++++++++++---
>  1 file changed, 37 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
> index dc3a3f709fea..6d6d211883ae 100644
> --- a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
> @@ -11,12 +11,17 @@ maintainers:
>  
>  properties:
>    compatible:
> -    enum:
> -      - fsl,imx8mq-usb-phy
> -      - fsl,imx8mp-usb-phy
> +    oneOf:
> +      - enum:
> +          - fsl,imx8mq-usb-phy
> +          - fsl,imx8mp-usb-phy
> +      - items:
> +          - const: fsl,imx95-usb-phy
> +          - const: fsl,imx8mp-usb-phy
>  
>    reg:
> -    maxItems: 1
> +    minItems: 1
> +    maxItems: 2
>  
>    "#phy-cells":
>      const: 0
> @@ -89,7 +94,34 @@ required:
>    - clocks
>    - clock-names
>  
> -additionalProperties: false
> +allOf:
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - fsl,imx95-usb-phy
> +    then:
> +      properties:
> +        reg:
> +          items:
> +            - description: USB PHY Control range
> +            - description: USB PHY TCA Block range
> +    else:
> +      properties:
> +        reg:
> +          maxItems: 1
> +
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - fsl,imx95-usb-phy
> +    then:
> +      $ref: /schemas/usb/usb-switch.yaml#

ref should be rather in top-level. You can always disallow certain
properties for devices, if they are really not applicable.

Best regards,
Krzysztof



From lorenzo at kernel.org  Tue Aug  6 08:55:48 2024
From: lorenzo at kernel.org (Lorenzo Bianconi)
Date: Tue,  6 Aug 2024 17:55:48 +0200
Subject: [PATCH v3] phy: airoha: adjust initialization delay in airoha_pcie_phy_init()
Message-ID: <8af6f27857619f1e0dd227f08b8584ae8fb22fb2.1722959625.git.lorenzo@kernel.org>

Align phy-pcie initialization delay to the vendor sdk in
airoha_pcie_phy_init routine and allow the hw to complete required
configuration before proceeding

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Signed-off-by: Lorenzo Bianconi <lorenzo at kernel.org>
---
Changes since v2:
- fix comment
Changes since v1:
- use msleep() instead of mdelay()
---
 drivers/phy/phy-airoha-pcie.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/phy/phy-airoha-pcie.c b/drivers/phy/phy-airoha-pcie.c
index bd3edaa986c8..1e410eb41058 100644
--- a/drivers/phy/phy-airoha-pcie.c
+++ b/drivers/phy/phy-airoha-pcie.c
@@ -18,6 +18,9 @@
 #define LEQ_LEN_CTRL_MAX_VAL	7
 #define FREQ_LOCK_MAX_ATTEMPT	10
 
+/* PCIe-PHY initialization time in ms needed by the hw to complete */
+#define PHY_HW_INIT_TIME_MS	30
+
 enum airoha_pcie_port_gen {
 	PCIE_PORT_GEN1 = 1,
 	PCIE_PORT_GEN2,
@@ -1181,7 +1184,8 @@ static int airoha_pcie_phy_init(struct phy *phy)
 	airoha_phy_pma1_set_bits(pcie_phy, REG_PCIE_PMA_SS_DA_XPON_PWDB0,
 				 PCIE_DA_XPON_CDR_PR_PWDB);
 
-	usleep_range(100, 200);
+	/* Wait for the PCIe PHY to complete initialization before returning */
+	msleep(PHY_HW_INIT_TIME_MS);
 
 	return 0;
 }
-- 
2.45.2



From lorenzo at kernel.org  Tue Aug  6 08:56:45 2024
From: lorenzo at kernel.org (Lorenzo Bianconi)
Date: Tue, 6 Aug 2024 17:56:45 +0200
Subject: [PATCH v2] phy: airoha: adjust initialization delay in
 airoha_pcie_phy_init()
In-Reply-To: <47f25caf-8d0d-4c9f-8550-fa9506680113@collabora.com>
References: <d174837bcb5a53f7b2c2580211d60a175d0ce8db.1722887003.git.lorenzo@kernel.org>
 <47f25caf-8d0d-4c9f-8550-fa9506680113@collabora.com>
Message-ID: <ZrJHvS39CCdR_Kcz@lore-rh-laptop>

> Il 05/08/24 21:57, Lorenzo Bianconi ha scritto:
> > Align phy-pcie initialization delay to the vendor sdk in
> > airoha_pcie_phy_init routine and allow the hw to complete required
> > configuration before proceeding
> > 
> > Signed-off-by: Lorenzo Bianconi <lorenzo at kernel.org>
> 
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
> 
> > ---
> > Changes since v1:
> > - use msleep() instead of mdelay()
> > ---
> >   drivers/phy/phy-airoha-pcie.c | 10 ++++++++--
> >   1 file changed, 8 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/phy/phy-airoha-pcie.c b/drivers/phy/phy-airoha-pcie.c
> > index bd3edaa986c8..6d61e6486a03 100644
> > --- a/drivers/phy/phy-airoha-pcie.c
> > +++ b/drivers/phy/phy-airoha-pcie.c
> > @@ -18,6 +18,9 @@
> >   #define LEQ_LEN_CTRL_MAX_VAL	7
> >   #define FREQ_LOCK_MAX_ATTEMPT	10
> > +/* PCIe-PHY initialization time in ms needed by the hw to complete */
> > +#define PHY_HW_INIT_TIME_MS	30
> > +
> >   enum airoha_pcie_port_gen {
> >   	PCIE_PORT_GEN1 = 1,
> >   	PCIE_PORT_GEN2,
> > @@ -1180,8 +1183,11 @@ static int airoha_pcie_phy_init(struct phy *phy)
> >   				 PCIE_DA_XPON_CDR_PR_PWDB);
> >   	airoha_phy_pma1_set_bits(pcie_phy, REG_PCIE_PMA_SS_DA_XPON_PWDB0,
> >   				 PCIE_DA_XPON_CDR_PR_PWDB);
> > -
> > -	usleep_range(100, 200);
> > +	/*
> > +	 * Wait for the time in ms needed by the hw to complete the PCIe-PHY
> > +	 * initialization
> 
> ...but regardless, I have a nit here (not a blocker for me, hence the R-b tag):
> there's no need to say that we're waiting for milliseconds, so this comment can
> be just one line:
> 
> 	/* Wait for the PCIe PHY to complete initialization before returning */
> 
> Cheers,
> Angelo

ack, no worries, already fixed in v3.

Regards,
Lorenzo

> 
> > +	 */
> > +	msleep(PHY_HW_INIT_TIME_MS);
> >   	return 0;
> >   }
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-phy/attachments/20240806/4c6485d3/attachment.sig>

From Frank.li at nxp.com  Tue Aug  6 09:11:55 2024
From: Frank.li at nxp.com (Frank Li)
Date: Tue, 6 Aug 2024 12:11:55 -0400
Subject: [PATCH v2 1/5] dt-bindings: phy: imx8mq-usb: add compatible
 "fsl,imx95-usb-phy"
In-Reply-To: <160dd5fc-83ba-4311-a173-44521342a3d8@kernel.org>
References: <20240806050639.1013152-1-xu.yang_2@nxp.com>
 <160dd5fc-83ba-4311-a173-44521342a3d8@kernel.org>
Message-ID: <ZrJLS37GFmvkQpml@lizhi-Precision-Tower-5810>

On Tue, Aug 06, 2024 at 10:29:47AM +0200, Krzysztof Kozlowski wrote:
> On 06/08/2024 07:06, Xu Yang wrote:
> > The usb phy in i.MX95 is compatible with i.MX8MP's, this will add a
> > compatible "fsl,imx95-usb-phy" for i.MX95. Also change reg maxItems
> > to 2 since i.MX95 needs another regmap to control Type-C Assist (TCA)
> > block. Since i.MX95 usb phy is able to switch SS lanes, this will also
> > add orientation-switch and port property to the file.
> >
> > Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> >
> > ---
> > Changes in v2:
> >  - replace minItems with description in reg property
> >  - remove orientation-switch and port
> >  - refer to usb-switch.yaml
> >  - use unevaluatedProperties
> > ---
> >  .../bindings/phy/fsl,imx8mq-usb-phy.yaml      | 42 ++++++++++++++++---
> >  1 file changed, 37 insertions(+), 5 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
> > index dc3a3f709fea..6d6d211883ae 100644
> > --- a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
> > +++ b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
> > @@ -11,12 +11,17 @@ maintainers:
> >
> >  properties:
> >    compatible:
> > -    enum:
> > -      - fsl,imx8mq-usb-phy
> > -      - fsl,imx8mp-usb-phy
> > +    oneOf:
> > +      - enum:
> > +          - fsl,imx8mq-usb-phy
> > +          - fsl,imx8mp-usb-phy
> > +      - items:
> > +          - const: fsl,imx95-usb-phy
> > +          - const: fsl,imx8mp-usb-phy
> >
> >    reg:
> > -    maxItems: 1
> > +    minItems: 1
> > +    maxItems: 2
> >
> >    "#phy-cells":
> >      const: 0
> > @@ -89,7 +94,34 @@ required:
> >    - clocks
> >    - clock-names
> >
> > -additionalProperties: false
> > +allOf:
> > +  - if:
> > +      properties:
> > +        compatible:
> > +          contains:
> > +            enum:
> > +              - fsl,imx95-usb-phy
> > +    then:
> > +      properties:
> > +        reg:
> > +          items:
> > +            - description: USB PHY Control range
> > +            - description: USB PHY TCA Block range
> > +    else:
> > +      properties:
> > +        reg:
> > +          maxItems: 1
> > +
> > +  - if:
> > +      properties:
> > +        compatible:
> > +          contains:
> > +            enum:
> > +              - fsl,imx95-usb-phy
> > +    then:
> > +      $ref: /schemas/usb/usb-switch.yaml#
>
> ref should be rather in top-level. You can always disallow certain
> properties for devices, if they are really not applicable.

There are some "required" in usb-switch.yaml,

oneOf:
  - required:
      - port
  - required:
      - ports

If put on the top, it may cause DTB check warning for other compatible
strings, which have not support usb-switch.

Frank
>
> Best regards,
> Krzysztof
>


From robh at kernel.org  Tue Aug  6 10:07:42 2024
From: robh at kernel.org (Rob Herring (Arm))
Date: Tue, 6 Aug 2024 11:07:42 -0600
Subject: [PATCH 1/3] dt-bindings: phy: jh7110-usb-phy: Add sys-syscon
 property
In-Reply-To: <ebcfe039b13097e53b3721f56a45d99807f2925b.1722457123.git.jan.kiszka@siemens.com>
References: <cover.1722457123.git.jan.kiszka@siemens.com>
 <ebcfe039b13097e53b3721f56a45d99807f2925b.1722457123.git.jan.kiszka@siemens.com>
Message-ID: <172296406163.1706072.1585378061823817206.robh@kernel.org>


On Wed, 31 Jul 2024 22:18:41 +0200, Jan Kiszka wrote:
> From: Jan Kiszka <jan.kiszka at siemens.com>
> 
> Analogously to the PCI PHY, access to sys_syscon is needed to connect
> the USB PHY to its controller.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com>
> ---
> CC: Rob Herring <robh at kernel.org>
> CC: Krzysztof Kozlowski <krzk+dt at kernel.org>
> CC: Conor Dooley <conor+dt at kernel.org>
> ---
>  .../bindings/phy/starfive,jh7110-usb-phy.yaml         | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 

Reviewed-by: Rob Herring (Arm) <robh at kernel.org>



From xu.yang_2 at nxp.com  Tue Aug  6 19:24:58 2024
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Wed, 7 Aug 2024 10:24:58 +0800
Subject: [PATCH v2 1/5] dt-bindings: phy: imx8mq-usb: add compatible
 "fsl,imx95-usb-phy"
In-Reply-To: <ZrJLS37GFmvkQpml@lizhi-Precision-Tower-5810>
References: <20240806050639.1013152-1-xu.yang_2@nxp.com>
 <160dd5fc-83ba-4311-a173-44521342a3d8@kernel.org>
 <ZrJLS37GFmvkQpml@lizhi-Precision-Tower-5810>
Message-ID: <20240807022458.m4njz4tsxfadzro5@hippo>

On Tue, Aug 06, 2024 at 12:11:55PM -0400, Frank Li wrote:
> On Tue, Aug 06, 2024 at 10:29:47AM +0200, Krzysztof Kozlowski wrote:
> > On 06/08/2024 07:06, Xu Yang wrote:
> > > The usb phy in i.MX95 is compatible with i.MX8MP's, this will add a
> > > compatible "fsl,imx95-usb-phy" for i.MX95. Also change reg maxItems
> > > to 2 since i.MX95 needs another regmap to control Type-C Assist (TCA)
> > > block. Since i.MX95 usb phy is able to switch SS lanes, this will also
> > > add orientation-switch and port property to the file.
> > >
> > > Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> > >
> > > ---
> > > Changes in v2:
> > >  - replace minItems with description in reg property
> > >  - remove orientation-switch and port
> > >  - refer to usb-switch.yaml
> > >  - use unevaluatedProperties
> > > ---
> > >  .../bindings/phy/fsl,imx8mq-usb-phy.yaml      | 42 ++++++++++++++++---
> > >  1 file changed, 37 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
> > > index dc3a3f709fea..6d6d211883ae 100644
> > > --- a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
> > > +++ b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
> > > @@ -11,12 +11,17 @@ maintainers:
> > >
> > >  properties:
> > >    compatible:
> > > -    enum:
> > > -      - fsl,imx8mq-usb-phy
> > > -      - fsl,imx8mp-usb-phy
> > > +    oneOf:
> > > +      - enum:
> > > +          - fsl,imx8mq-usb-phy
> > > +          - fsl,imx8mp-usb-phy
> > > +      - items:
> > > +          - const: fsl,imx95-usb-phy
> > > +          - const: fsl,imx8mp-usb-phy
> > >
> > >    reg:
> > > -    maxItems: 1
> > > +    minItems: 1
> > > +    maxItems: 2
> > >
> > >    "#phy-cells":
> > >      const: 0
> > > @@ -89,7 +94,34 @@ required:
> > >    - clocks
> > >    - clock-names
> > >
> > > -additionalProperties: false
> > > +allOf:
> > > +  - if:
> > > +      properties:
> > > +        compatible:
> > > +          contains:
> > > +            enum:
> > > +              - fsl,imx95-usb-phy
> > > +    then:
> > > +      properties:
> > > +        reg:
> > > +          items:
> > > +            - description: USB PHY Control range
> > > +            - description: USB PHY TCA Block range
> > > +    else:
> > > +      properties:
> > > +        reg:
> > > +          maxItems: 1
> > > +
> > > +  - if:
> > > +      properties:
> > > +        compatible:
> > > +          contains:
> > > +            enum:
> > > +              - fsl,imx95-usb-phy
> > > +    then:
> > > +      $ref: /schemas/usb/usb-switch.yaml#
> >
> > ref should be rather in top-level. You can always disallow certain
> > properties for devices, if they are really not applicable.
> 
> There are some "required" in usb-switch.yaml,
> 
> oneOf:
>   - required:
>       - port
>   - required:
>       - ports
> 
> If put on the top, it may cause DTB check warning for other compatible
> strings, which have not support usb-switch.

Yes, even though I move usb-switch to top and set false for certain properties,
dtbinding check still has below error:

/home/nxf75279/work/usb/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.example.dtb: phy at 381f0040: 'oneOf' conditional failed, one must be fixed:
        'port' is a required property
        'ports' is a required property
        from schema $id: http://devicetree.org/schemas/phy/fsl,imx8mq-usb-phy.yaml#

Thanks,
Xu Yang

> 
> Frank
> >
> > Best regards,
> > Krzysztof
> >


From krzk at kernel.org  Tue Aug  6 22:48:43 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Wed, 7 Aug 2024 07:48:43 +0200
Subject: [PATCH v2 1/5] dt-bindings: phy: imx8mq-usb: add compatible
 "fsl,imx95-usb-phy"
In-Reply-To: <ZrJLS37GFmvkQpml@lizhi-Precision-Tower-5810>
References: <20240806050639.1013152-1-xu.yang_2@nxp.com>
 <160dd5fc-83ba-4311-a173-44521342a3d8@kernel.org>
 <ZrJLS37GFmvkQpml@lizhi-Precision-Tower-5810>
Message-ID: <bfe6430c-a022-4e8f-ab7f-8d8e8cb10fca@kernel.org>

On 06/08/2024 18:11, Frank Li wrote:
> On Tue, Aug 06, 2024 at 10:29:47AM +0200, Krzysztof Kozlowski wrote:
>> On 06/08/2024 07:06, Xu Yang wrote:
>>> The usb phy in i.MX95 is compatible with i.MX8MP's, this will add a
>>> compatible "fsl,imx95-usb-phy" for i.MX95. Also change reg maxItems
>>> to 2 since i.MX95 needs another regmap to control Type-C Assist (TCA)
>>> block. Since i.MX95 usb phy is able to switch SS lanes, this will also
>>> add orientation-switch and port property to the file.
>>>
>>> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
>>>
>>> ---
>>> Changes in v2:
>>>  - replace minItems with description in reg property
>>>  - remove orientation-switch and port
>>>  - refer to usb-switch.yaml
>>>  - use unevaluatedProperties
>>> ---
>>>  .../bindings/phy/fsl,imx8mq-usb-phy.yaml      | 42 ++++++++++++++++---
>>>  1 file changed, 37 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
>>> index dc3a3f709fea..6d6d211883ae 100644
>>> --- a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
>>> +++ b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
>>> @@ -11,12 +11,17 @@ maintainers:
>>>
>>>  properties:
>>>    compatible:
>>> -    enum:
>>> -      - fsl,imx8mq-usb-phy
>>> -      - fsl,imx8mp-usb-phy
>>> +    oneOf:
>>> +      - enum:
>>> +          - fsl,imx8mq-usb-phy
>>> +          - fsl,imx8mp-usb-phy
>>> +      - items:
>>> +          - const: fsl,imx95-usb-phy
>>> +          - const: fsl,imx8mp-usb-phy
>>>
>>>    reg:
>>> -    maxItems: 1
>>> +    minItems: 1
>>> +    maxItems: 2
>>>
>>>    "#phy-cells":
>>>      const: 0
>>> @@ -89,7 +94,34 @@ required:
>>>    - clocks
>>>    - clock-names
>>>
>>> -additionalProperties: false
>>> +allOf:
>>> +  - if:
>>> +      properties:
>>> +        compatible:
>>> +          contains:
>>> +            enum:
>>> +              - fsl,imx95-usb-phy
>>> +    then:
>>> +      properties:
>>> +        reg:
>>> +          items:
>>> +            - description: USB PHY Control range
>>> +            - description: USB PHY TCA Block range
>>> +    else:
>>> +      properties:
>>> +        reg:
>>> +          maxItems: 1
>>> +
>>> +  - if:
>>> +      properties:
>>> +        compatible:
>>> +          contains:
>>> +            enum:
>>> +              - fsl,imx95-usb-phy
>>> +    then:
>>> +      $ref: /schemas/usb/usb-switch.yaml#
>>
>> ref should be rather in top-level. You can always disallow certain
>> properties for devices, if they are really not applicable.
> 
> There are some "required" in usb-switch.yaml,
> 
> oneOf:
>   - required:
>       - port
>   - required:
>       - ports
> 
> If put on the top, it may cause DTB check warning for other compatible
> strings, which have not support usb-switch.

Hm, indeed, that's unusual case to have such different devices in one
schema. Did you test that above $ref in if: actually works?

Best regards,
Krzysztof



From xu.yang_2 at nxp.com  Tue Aug  6 22:57:01 2024
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Wed, 7 Aug 2024 13:57:01 +0800
Subject: [PATCH v2 1/5] dt-bindings: phy: imx8mq-usb: add compatible
 "fsl,imx95-usb-phy"
In-Reply-To: <bfe6430c-a022-4e8f-ab7f-8d8e8cb10fca@kernel.org>
References: <20240806050639.1013152-1-xu.yang_2@nxp.com>
 <160dd5fc-83ba-4311-a173-44521342a3d8@kernel.org>
 <ZrJLS37GFmvkQpml@lizhi-Precision-Tower-5810>
 <bfe6430c-a022-4e8f-ab7f-8d8e8cb10fca@kernel.org>
Message-ID: <20240807055701.o7fo43efvv3jxlhv@hippo>

On Wed, Aug 07, 2024 at 07:48:43AM +0200, Krzysztof Kozlowski wrote:
> On 06/08/2024 18:11, Frank Li wrote:
> > On Tue, Aug 06, 2024 at 10:29:47AM +0200, Krzysztof Kozlowski wrote:
> >> On 06/08/2024 07:06, Xu Yang wrote:
> >>> The usb phy in i.MX95 is compatible with i.MX8MP's, this will add a
> >>> compatible "fsl,imx95-usb-phy" for i.MX95. Also change reg maxItems
> >>> to 2 since i.MX95 needs another regmap to control Type-C Assist (TCA)
> >>> block. Since i.MX95 usb phy is able to switch SS lanes, this will also
> >>> add orientation-switch and port property to the file.
> >>>
> >>> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> >>>
> >>> ---
> >>> Changes in v2:
> >>>  - replace minItems with description in reg property
> >>>  - remove orientation-switch and port
> >>>  - refer to usb-switch.yaml
> >>>  - use unevaluatedProperties
> >>> ---
> >>>  .../bindings/phy/fsl,imx8mq-usb-phy.yaml      | 42 ++++++++++++++++---
> >>>  1 file changed, 37 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
> >>> index dc3a3f709fea..6d6d211883ae 100644
> >>> --- a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
> >>> +++ b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
> >>> @@ -11,12 +11,17 @@ maintainers:
> >>>
> >>>  properties:
> >>>    compatible:
> >>> -    enum:
> >>> -      - fsl,imx8mq-usb-phy
> >>> -      - fsl,imx8mp-usb-phy
> >>> +    oneOf:
> >>> +      - enum:
> >>> +          - fsl,imx8mq-usb-phy
> >>> +          - fsl,imx8mp-usb-phy
> >>> +      - items:
> >>> +          - const: fsl,imx95-usb-phy
> >>> +          - const: fsl,imx8mp-usb-phy
> >>>
> >>>    reg:
> >>> -    maxItems: 1
> >>> +    minItems: 1
> >>> +    maxItems: 2
> >>>
> >>>    "#phy-cells":
> >>>      const: 0
> >>> @@ -89,7 +94,34 @@ required:
> >>>    - clocks
> >>>    - clock-names
> >>>
> >>> -additionalProperties: false
> >>> +allOf:
> >>> +  - if:
> >>> +      properties:
> >>> +        compatible:
> >>> +          contains:
> >>> +            enum:
> >>> +              - fsl,imx95-usb-phy
> >>> +    then:
> >>> +      properties:
> >>> +        reg:
> >>> +          items:
> >>> +            - description: USB PHY Control range
> >>> +            - description: USB PHY TCA Block range
> >>> +    else:
> >>> +      properties:
> >>> +        reg:
> >>> +          maxItems: 1
> >>> +
> >>> +  - if:
> >>> +      properties:
> >>> +        compatible:
> >>> +          contains:
> >>> +            enum:
> >>> +              - fsl,imx95-usb-phy
> >>> +    then:
> >>> +      $ref: /schemas/usb/usb-switch.yaml#
> >>
> >> ref should be rather in top-level. You can always disallow certain
> >> properties for devices, if they are really not applicable.
> > 
> > There are some "required" in usb-switch.yaml,
> > 
> > oneOf:
> >   - required:
> >       - port
> >   - required:
> >       - ports
> > 
> > If put on the top, it may cause DTB check warning for other compatible
> > strings, which have not support usb-switch.
> 
> Hm, indeed, that's unusual case to have such different devices in one
> schema. Did you test that above $ref in if: actually works?

Yes, it works and this yaml pass dt_binding_check and dtbs_check. 

Thanks,
Xu Yang

> 
> Best regards,
> Krzysztof
> 


From krzk at kernel.org  Tue Aug  6 22:59:02 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Wed, 7 Aug 2024 07:59:02 +0200
Subject: [PATCH v2 1/5] dt-bindings: phy: imx8mq-usb: add compatible
 "fsl,imx95-usb-phy"
In-Reply-To: <20240807055701.o7fo43efvv3jxlhv@hippo>
References: <20240806050639.1013152-1-xu.yang_2@nxp.com>
 <160dd5fc-83ba-4311-a173-44521342a3d8@kernel.org>
 <ZrJLS37GFmvkQpml@lizhi-Precision-Tower-5810>
 <bfe6430c-a022-4e8f-ab7f-8d8e8cb10fca@kernel.org>
 <20240807055701.o7fo43efvv3jxlhv@hippo>
Message-ID: <9127e97e-64ad-47df-aa4f-03feafafdbb1@kernel.org>

On 07/08/2024 07:57, Xu Yang wrote:
> On Wed, Aug 07, 2024 at 07:48:43AM +0200, Krzysztof Kozlowski wrote:
>> On 06/08/2024 18:11, Frank Li wrote:
>>> On Tue, Aug 06, 2024 at 10:29:47AM +0200, Krzysztof Kozlowski wrote:
>>>> On 06/08/2024 07:06, Xu Yang wrote:
>>>>> The usb phy in i.MX95 is compatible with i.MX8MP's, this will add a
>>>>> compatible "fsl,imx95-usb-phy" for i.MX95. Also change reg maxItems
>>>>> to 2 since i.MX95 needs another regmap to control Type-C Assist (TCA)
>>>>> block. Since i.MX95 usb phy is able to switch SS lanes, this will also
>>>>> add orientation-switch and port property to the file.
>>>>>
>>>>> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
>>>>>
>>>>> ---
>>>>> Changes in v2:
>>>>>  - replace minItems with description in reg property
>>>>>  - remove orientation-switch and port
>>>>>  - refer to usb-switch.yaml
>>>>>  - use unevaluatedProperties
>>>>> ---
>>>>>  .../bindings/phy/fsl,imx8mq-usb-phy.yaml      | 42 ++++++++++++++++---
>>>>>  1 file changed, 37 insertions(+), 5 deletions(-)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
>>>>> index dc3a3f709fea..6d6d211883ae 100644
>>>>> --- a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
>>>>> +++ b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
>>>>> @@ -11,12 +11,17 @@ maintainers:
>>>>>
>>>>>  properties:
>>>>>    compatible:
>>>>> -    enum:
>>>>> -      - fsl,imx8mq-usb-phy
>>>>> -      - fsl,imx8mp-usb-phy
>>>>> +    oneOf:
>>>>> +      - enum:
>>>>> +          - fsl,imx8mq-usb-phy
>>>>> +          - fsl,imx8mp-usb-phy
>>>>> +      - items:
>>>>> +          - const: fsl,imx95-usb-phy
>>>>> +          - const: fsl,imx8mp-usb-phy
>>>>>
>>>>>    reg:
>>>>> -    maxItems: 1
>>>>> +    minItems: 1
>>>>> +    maxItems: 2
>>>>>
>>>>>    "#phy-cells":
>>>>>      const: 0
>>>>> @@ -89,7 +94,34 @@ required:
>>>>>    - clocks
>>>>>    - clock-names
>>>>>
>>>>> -additionalProperties: false
>>>>> +allOf:
>>>>> +  - if:
>>>>> +      properties:
>>>>> +        compatible:
>>>>> +          contains:
>>>>> +            enum:
>>>>> +              - fsl,imx95-usb-phy
>>>>> +    then:
>>>>> +      properties:
>>>>> +        reg:
>>>>> +          items:
>>>>> +            - description: USB PHY Control range
>>>>> +            - description: USB PHY TCA Block range
>>>>> +    else:
>>>>> +      properties:
>>>>> +        reg:
>>>>> +          maxItems: 1
>>>>> +
>>>>> +  - if:
>>>>> +      properties:
>>>>> +        compatible:
>>>>> +          contains:
>>>>> +            enum:
>>>>> +              - fsl,imx95-usb-phy
>>>>> +    then:
>>>>> +      $ref: /schemas/usb/usb-switch.yaml#
>>>>
>>>> ref should be rather in top-level. You can always disallow certain
>>>> properties for devices, if they are really not applicable.
>>>
>>> There are some "required" in usb-switch.yaml,
>>>
>>> oneOf:
>>>   - required:
>>>       - port
>>>   - required:
>>>       - ports
>>>
>>> If put on the top, it may cause DTB check warning for other compatible
>>> strings, which have not support usb-switch.
>>
>> Hm, indeed, that's unusual case to have such different devices in one
>> schema. Did you test that above $ref in if: actually works?
> 
> Yes, it works and this yaml pass dt_binding_check and dtbs_check. 

I know it passes, I am asking whether it actually works. Is the $ref
actually effective? Is it properly applied?

Best regards,
Krzysztof



From xu.yang_2 at nxp.com  Wed Aug  7 00:11:43 2024
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Wed, 7 Aug 2024 15:11:43 +0800
Subject: [PATCH v2 1/5] dt-bindings: phy: imx8mq-usb: add compatible
 "fsl,imx95-usb-phy"
In-Reply-To: <9127e97e-64ad-47df-aa4f-03feafafdbb1@kernel.org>
References: <20240806050639.1013152-1-xu.yang_2@nxp.com>
 <160dd5fc-83ba-4311-a173-44521342a3d8@kernel.org>
 <ZrJLS37GFmvkQpml@lizhi-Precision-Tower-5810>
 <bfe6430c-a022-4e8f-ab7f-8d8e8cb10fca@kernel.org>
 <20240807055701.o7fo43efvv3jxlhv@hippo>
 <9127e97e-64ad-47df-aa4f-03feafafdbb1@kernel.org>
Message-ID: <20240807071143.6njojidi75xsjkxr@hippo>

On Wed, Aug 07, 2024 at 07:59:02AM +0200, Krzysztof Kozlowski wrote:
> On 07/08/2024 07:57, Xu Yang wrote:
> > On Wed, Aug 07, 2024 at 07:48:43AM +0200, Krzysztof Kozlowski wrote:
> >> On 06/08/2024 18:11, Frank Li wrote:
> >>> On Tue, Aug 06, 2024 at 10:29:47AM +0200, Krzysztof Kozlowski wrote:
> >>>> On 06/08/2024 07:06, Xu Yang wrote:
> >>>>> The usb phy in i.MX95 is compatible with i.MX8MP's, this will add a
> >>>>> compatible "fsl,imx95-usb-phy" for i.MX95. Also change reg maxItems
> >>>>> to 2 since i.MX95 needs another regmap to control Type-C Assist (TCA)
> >>>>> block. Since i.MX95 usb phy is able to switch SS lanes, this will also
> >>>>> add orientation-switch and port property to the file.
> >>>>>
> >>>>> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> >>>>>
> >>>>> ---
> >>>>> Changes in v2:
> >>>>>  - replace minItems with description in reg property
> >>>>>  - remove orientation-switch and port
> >>>>>  - refer to usb-switch.yaml
> >>>>>  - use unevaluatedProperties
> >>>>>
[...]
> >>>>
> >>>> ref should be rather in top-level. You can always disallow certain
> >>>> properties for devices, if they are really not applicable.
> >>>
> >>> There are some "required" in usb-switch.yaml,
> >>>
> >>> oneOf:
> >>>   - required:
> >>>       - port
> >>>   - required:
> >>>       - ports
> >>>
> >>> If put on the top, it may cause DTB check warning for other compatible
> >>> strings, which have not support usb-switch.
> >>
> >> Hm, indeed, that's unusual case to have such different devices in one
> >> schema. Did you test that above $ref in if: actually works?
> > 
> > Yes, it works and this yaml pass dt_binding_check and dtbs_check. 
> 
> I know it passes, I am asking whether it actually works. Is the $ref
> actually effective? Is it properly applied?

If imx95 usb phy node doesn't contain "orientation-switch" and "port", dtb check will
show below error:

usb/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dtb: phy at 4c1f0040: 'oneOf' conditional failed, one must be fixed:
        'port' is a required property
        'ports' is a required property
        from schema $id: http://devicetree.org/schemas/phy/fsl,imx8mq-usb-phy.yaml#

Do you want other test results?

Thanks,
Xu Yang

> 
> Best regards,
> Krzysztof
> 


From krzk at kernel.org  Wed Aug  7 00:20:12 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Wed, 7 Aug 2024 09:20:12 +0200
Subject: [PATCH v2 1/5] dt-bindings: phy: imx8mq-usb: add compatible
 "fsl,imx95-usb-phy"
In-Reply-To: <20240807071143.6njojidi75xsjkxr@hippo>
References: <20240806050639.1013152-1-xu.yang_2@nxp.com>
 <160dd5fc-83ba-4311-a173-44521342a3d8@kernel.org>
 <ZrJLS37GFmvkQpml@lizhi-Precision-Tower-5810>
 <bfe6430c-a022-4e8f-ab7f-8d8e8cb10fca@kernel.org>
 <20240807055701.o7fo43efvv3jxlhv@hippo>
 <9127e97e-64ad-47df-aa4f-03feafafdbb1@kernel.org>
 <20240807071143.6njojidi75xsjkxr@hippo>
Message-ID: <f85de847-3476-4b6c-ae45-bb625061db94@kernel.org>

On 07/08/2024 09:11, Xu Yang wrote:
> On Wed, Aug 07, 2024 at 07:59:02AM +0200, Krzysztof Kozlowski wrote:
>> On 07/08/2024 07:57, Xu Yang wrote:
>>> On Wed, Aug 07, 2024 at 07:48:43AM +0200, Krzysztof Kozlowski wrote:
>>>> On 06/08/2024 18:11, Frank Li wrote:
>>>>> On Tue, Aug 06, 2024 at 10:29:47AM +0200, Krzysztof Kozlowski wrote:
>>>>>> On 06/08/2024 07:06, Xu Yang wrote:
>>>>>>> The usb phy in i.MX95 is compatible with i.MX8MP's, this will add a
>>>>>>> compatible "fsl,imx95-usb-phy" for i.MX95. Also change reg maxItems
>>>>>>> to 2 since i.MX95 needs another regmap to control Type-C Assist (TCA)
>>>>>>> block. Since i.MX95 usb phy is able to switch SS lanes, this will also
>>>>>>> add orientation-switch and port property to the file.
>>>>>>>
>>>>>>> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
>>>>>>>
>>>>>>> ---
>>>>>>> Changes in v2:
>>>>>>>  - replace minItems with description in reg property
>>>>>>>  - remove orientation-switch and port
>>>>>>>  - refer to usb-switch.yaml
>>>>>>>  - use unevaluatedProperties
>>>>>>>
> [...]
>>>>>>
>>>>>> ref should be rather in top-level. You can always disallow certain
>>>>>> properties for devices, if they are really not applicable.
>>>>>
>>>>> There are some "required" in usb-switch.yaml,
>>>>>
>>>>> oneOf:
>>>>>   - required:
>>>>>       - port
>>>>>   - required:
>>>>>       - ports
>>>>>
>>>>> If put on the top, it may cause DTB check warning for other compatible
>>>>> strings, which have not support usb-switch.
>>>>
>>>> Hm, indeed, that's unusual case to have such different devices in one
>>>> schema. Did you test that above $ref in if: actually works?
>>>
>>> Yes, it works and this yaml pass dt_binding_check and dtbs_check. 
>>
>> I know it passes, I am asking whether it actually works. Is the $ref
>> actually effective? Is it properly applied?
> 
> If imx95 usb phy node doesn't contain "orientation-switch" and "port", dtb check will
> show below error:
> 
> usb/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dtb: phy at 4c1f0040: 'oneOf' conditional failed, one must be fixed:
>         'port' is a required property
>         'ports' is a required property
>         from schema $id: http://devicetree.org/schemas/phy/fsl,imx8mq-usb-phy.yaml#
> 
> Do you want other test results?

Thank you for confirmation, it's enough.

Best regards,
Krzysztof



From krzk at kernel.org  Wed Aug  7 00:20:22 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Wed, 7 Aug 2024 09:20:22 +0200
Subject: [PATCH v2 1/5] dt-bindings: phy: imx8mq-usb: add compatible
 "fsl,imx95-usb-phy"
In-Reply-To: <20240806050639.1013152-1-xu.yang_2@nxp.com>
References: <20240806050639.1013152-1-xu.yang_2@nxp.com>
Message-ID: <ad38013a-f132-4b64-b895-12eb3611d557@kernel.org>

On 06/08/2024 07:06, Xu Yang wrote:
> The usb phy in i.MX95 is compatible with i.MX8MP's, this will add a
> compatible "fsl,imx95-usb-phy" for i.MX95. Also change reg maxItems
> to 2 since i.MX95 needs another regmap to control Type-C Assist (TCA)
> block. Since i.MX95 usb phy is able to switch SS lanes, this will also
> add orientation-switch and port property to the file.
> 
> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>


Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From ilordash02 at gmail.com  Wed Aug  7 11:02:09 2024
From: ilordash02 at gmail.com (Ilya Orazov)
Date: Wed,  7 Aug 2024 21:02:09 +0300
Subject: [PATCH v2 0/1] phy: Add support for Microchip ATA6561 CAN Transceiver
In-Reply-To: <20240805-fruit-chip-cf08a0e166a3@spud>
References: <20240805-fruit-chip-cf08a0e166a3@spud>
Message-ID: <20240807180210.1334724-1-ilordash02@gmail.com>

Ok, I changed patch to allow ti,tcan1042 as fallback compatible.

Ilya Orazov (1):
  dt-bindings: phy: ti,tcan104x-can: Document Microchip ATA6561

 .../devicetree/bindings/phy/ti,tcan104x-can.yaml    | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

-- 
2.34.1



From ilordash02 at gmail.com  Wed Aug  7 11:02:10 2024
From: ilordash02 at gmail.com (Ilya Orazov)
Date: Wed,  7 Aug 2024 21:02:10 +0300
Subject: [PATCH v2 1/1] dt-bindings: phy: ti,tcan104x-can: Document Microchip ATA6561
In-Reply-To: <20240807180210.1334724-1-ilordash02@gmail.com>
References: <20240805-fruit-chip-cf08a0e166a3@spud>
 <20240807180210.1334724-1-ilordash02@gmail.com>
Message-ID: <20240807180210.1334724-2-ilordash02@gmail.com>

Microchip ATA6561 is High-Speed CAN Transceiver with Standby Mode.
It is pin-compatible with TI TCAN1042 and has a compatible programming
model, therefore use ATA6561 as fallback device for TCAN1042.

Signed-off-by: Ilya Orazov <ilordash02 at gmail.com>
---
 .../devicetree/bindings/phy/ti,tcan104x-can.yaml    | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
index 79dad3e89aa6..f6f1fd843874 100644
--- a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
+++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
@@ -14,10 +14,15 @@ properties:
     pattern: "^can-phy"
 
   compatible:
-    enum:
-      - nxp,tjr1443
-      - ti,tcan1042
-      - ti,tcan1043
+    oneOf:
+      - items:
+        - enum:
+          - microchip,ata6561
+        - const: ti,tcan1042
+      - enum:
+          const: ti,tcan1042
+          const: ti,tcan1043
+          const: nxp,tjr1443
 
   '#phy-cells':
     const: 0
-- 
2.34.1



From ilordash02 at gmail.com  Wed Aug  7 11:09:55 2024
From: ilordash02 at gmail.com (Ilya Orazov)
Date: Wed,  7 Aug 2024 21:09:55 +0300
Subject: [PATCH v2 0/1] phy: Add support for Microchip ATA6561 CAN Transceiver
In-Reply-To: <20240807180210.1334724-2-ilordash02@gmail.com>
References: <20240807180210.1334724-2-ilordash02@gmail.com>
Message-ID: <20240807180956.1341332-1-ilordash02@gmail.com>

I'm sorry, I missed mistake in commit message, fixed it.

Ilya Orazov (1):
  dt-bindings: phy: ti,tcan104x-can: Document Microchip ATA6561

 .../devicetree/bindings/phy/ti,tcan104x-can.yaml    | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

-- 
2.34.1



From ilordash02 at gmail.com  Wed Aug  7 11:09:56 2024
From: ilordash02 at gmail.com (Ilya Orazov)
Date: Wed,  7 Aug 2024 21:09:56 +0300
Subject: [PATCH v2 1/1] dt-bindings: phy: ti,tcan104x-can: Document Microchip ATA6561
In-Reply-To: <20240807180956.1341332-1-ilordash02@gmail.com>
References: <20240807180210.1334724-2-ilordash02@gmail.com>
 <20240807180956.1341332-1-ilordash02@gmail.com>
Message-ID: <20240807180956.1341332-2-ilordash02@gmail.com>

Microchip ATA6561 is High-Speed CAN Transceiver with Standby Mode.
It is pin-compatible with TI TCAN1042 and has a compatible programming
model, therefore use ti,tcan1042 as fallback compatible.

Signed-off-by: Ilya Orazov <ilordash02 at gmail.com>
---
 .../devicetree/bindings/phy/ti,tcan104x-can.yaml    | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
index 79dad3e89aa6..f6f1fd843874 100644
--- a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
+++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
@@ -14,10 +14,15 @@ properties:
     pattern: "^can-phy"
 
   compatible:
-    enum:
-      - nxp,tjr1443
-      - ti,tcan1042
-      - ti,tcan1043
+    oneOf:
+      - items:
+        - enum:
+          - microchip,ata6561
+        - const: ti,tcan1042
+      - enum:
+          const: ti,tcan1042
+          const: ti,tcan1043
+          const: nxp,tjr1443
 
   '#phy-cells':
     const: 0
-- 
2.34.1



From robh at kernel.org  Wed Aug  7 12:12:40 2024
From: robh at kernel.org (Rob Herring (Arm))
Date: Wed, 07 Aug 2024 13:12:40 -0600
Subject: [PATCH v2 1/1] dt-bindings: phy: ti,tcan104x-can: Document
 Microchip ATA6561
In-Reply-To: <20240807180956.1341332-2-ilordash02@gmail.com>
References: <20240807180210.1334724-2-ilordash02@gmail.com>
 <20240807180956.1341332-1-ilordash02@gmail.com>
 <20240807180956.1341332-2-ilordash02@gmail.com>
Message-ID: <172305796084.3042321.10920811109606243151.robh@kernel.org>


On Wed, 07 Aug 2024 21:09:56 +0300, Ilya Orazov wrote:
> Microchip ATA6561 is High-Speed CAN Transceiver with Standby Mode.
> It is pin-compatible with TI TCAN1042 and has a compatible programming
> model, therefore use ti,tcan1042 as fallback compatible.
> 
> Signed-off-by: Ilya Orazov <ilordash02 at gmail.com>
> ---
>  .../devicetree/bindings/phy/ti,tcan104x-can.yaml    | 13 +++++++++----
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:
./Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml:19:9: [warning] wrong indentation: expected 10 but found 8 (indentation)
./Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml:20:11: [warning] wrong indentation: expected 12 but found 10 (indentation)
./Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml:24:11: [error] duplication of key "const" in mapping (key-duplicates)
./Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml:25:11: [error] duplication of key "const" in mapping (key-duplicates)

dtschema/dtc warnings/errors:
make[2]: *** Deleting file 'Documentation/devicetree/bindings/phy/ti,tcan104x-can.example.dts'
Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml:24:11: found duplicate key "const" with value "ti,tcan1043" (original value: "ti,tcan1042")
make[2]: *** [Documentation/devicetree/bindings/Makefile:26: Documentation/devicetree/bindings/phy/ti,tcan104x-can.example.dts] Error 1
make[2]: *** Waiting for unfinished jobs....
./Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml:24:11: found duplicate key "const" with value "ti,tcan1043" (original value: "ti,tcan1042")
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml: ignoring, error parsing file
make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1430: dt_binding_check] Error 2
make: *** [Makefile:240: __sub-make] Error 2

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240807180956.1341332-2-ilordash02 at gmail.com

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.



From conor at kernel.org  Thu Aug  8 08:48:14 2024
From: conor at kernel.org (Conor Dooley)
Date: Thu, 8 Aug 2024 16:48:14 +0100
Subject: [PATCH v2 1/1] dt-bindings: phy: ti,tcan104x-can: Document
 Microchip ATA6561
In-Reply-To: <20240807180956.1341332-2-ilordash02@gmail.com>
References: <20240807180210.1334724-2-ilordash02@gmail.com>
 <20240807180956.1341332-1-ilordash02@gmail.com>
 <20240807180956.1341332-2-ilordash02@gmail.com>
Message-ID: <20240808-caucasian-cartridge-f728ed4982cd@spud>

On Wed, Aug 07, 2024 at 09:09:56PM +0300, Ilya Orazov wrote:
> Microchip ATA6561 is High-Speed CAN Transceiver with Standby Mode.
> It is pin-compatible with TI TCAN1042 and has a compatible programming
> model, therefore use ti,tcan1042 as fallback compatible.
> 
> Signed-off-by: Ilya Orazov <ilordash02 at gmail.com>
> ---
>  .../devicetree/bindings/phy/ti,tcan104x-can.yaml    | 13 +++++++++----
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> index 79dad3e89aa6..f6f1fd843874 100644
> --- a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> +++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> @@ -14,10 +14,15 @@ properties:
>      pattern: "^can-phy"
>  
>    compatible:
> -    enum:
> -      - nxp,tjr1443
> -      - ti,tcan1042
> -      - ti,tcan1043
> +    oneOf:
> +      - items:
> +        - enum:
> +          - microchip,ata6561
> +        - const: ti,tcan1042
> +      - enum:
> +          const: ti,tcan1042
> +          const: ti,tcan1043
> +          const: nxp,tjr1443

The enum doesn't need the "const:s", just a "-", hence the bot
complaining.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-phy/attachments/20240808/b91b9e76/attachment.sig>

From krzk at kernel.org  Thu Aug  8 09:40:36 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Thu, 8 Aug 2024 18:40:36 +0200
Subject: [PATCH v2 1/1] dt-bindings: phy: ti,tcan104x-can: Document
 Microchip ATA6561
In-Reply-To: <20240808-caucasian-cartridge-f728ed4982cd@spud>
References: <20240807180210.1334724-2-ilordash02@gmail.com>
 <20240807180956.1341332-1-ilordash02@gmail.com>
 <20240807180956.1341332-2-ilordash02@gmail.com>
 <20240808-caucasian-cartridge-f728ed4982cd@spud>
Message-ID: <56a52c81-68de-438d-94ae-9decc799d824@kernel.org>

On 08/08/2024 17:48, Conor Dooley wrote:
> On Wed, Aug 07, 2024 at 09:09:56PM +0300, Ilya Orazov wrote:
>> Microchip ATA6561 is High-Speed CAN Transceiver with Standby Mode.
>> It is pin-compatible with TI TCAN1042 and has a compatible programming
>> model, therefore use ti,tcan1042 as fallback compatible.
>>
>> Signed-off-by: Ilya Orazov <ilordash02 at gmail.com>
>> ---
>>  .../devicetree/bindings/phy/ti,tcan104x-can.yaml    | 13 +++++++++----
>>  1 file changed, 9 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
>> index 79dad3e89aa6..f6f1fd843874 100644
>> --- a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
>> +++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
>> @@ -14,10 +14,15 @@ properties:
>>      pattern: "^can-phy"
>>  
>>    compatible:
>> -    enum:
>> -      - nxp,tjr1443
>> -      - ti,tcan1042
>> -      - ti,tcan1043
>> +    oneOf:
>> +      - items:
>> +        - enum:
>> +          - microchip,ata6561
>> +        - const: ti,tcan1042
>> +      - enum:
>> +          const: ti,tcan1042
>> +          const: ti,tcan1043
>> +          const: nxp,tjr1443
> 
> The enum doesn't need the "const:s", just a "-", hence the bot
> complaining.

Plus indentation is broken, which is important for YAML. Before posting
the patch, please test it.

Please run `make dt_binding_check` (see
Documentation/devicetree/bindings/writing-schema.rst for instructions).
Maybe you need to update your dtschema and yamllint.

Best regards,
Krzysztof



From ilordash02 at gmail.com  Thu Aug  8 12:17:35 2024
From: ilordash02 at gmail.com (Ilya Orazov)
Date: Thu,  8 Aug 2024 22:17:35 +0300
Subject: [PATCH v3 1/1] dt-bindings: phy: ti,tcan104x-can: Document Microchip ATA6561
In-Reply-To: <56a52c81-68de-438d-94ae-9decc799d824@kernel.org>
References: <56a52c81-68de-438d-94ae-9decc799d824@kernel.org>
Message-ID: <20240808191735.1483572-1-ilordash02@gmail.com>

Microchip ATA6561 is High-Speed CAN Transceiver with Standby Mode.
It is pin-compatible with TI TCAN1042 and has a compatible programming
model, therefore use ti,tcan1042 as fallback compatible.

Signed-off-by: Ilya Orazov <ilordash02 at gmail.com>
---
 .../devicetree/bindings/phy/ti,tcan104x-can.yaml    | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
index 79dad3e89aa6..4a8c3829d85d 100644
--- a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
+++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
@@ -14,10 +14,15 @@ properties:
     pattern: "^can-phy"
 
   compatible:
-    enum:
-      - nxp,tjr1443
-      - ti,tcan1042
-      - ti,tcan1043
+    oneOf:
+      - items:
+          - enum:
+              - microchip,ata6561
+          - const: ti,tcan1042
+      - enum:
+          - ti,tcan1042
+          - ti,tcan1043
+          - nxp,tjr1443
 
   '#phy-cells':
     const: 0

base-commit: 6a0e38264012809afa24113ee2162dc07f4ed22b
-- 
2.34.1



From peter.chen at kernel.org  Thu Aug  8 18:26:25 2024
From: peter.chen at kernel.org (Peter Chen)
Date: Fri, 9 Aug 2024 09:26:25 +0800
Subject: [PATCH v2 1/6] usb: phy: mxs: enable regulator phy-3p0 to
 improve signal qualilty
In-Reply-To: <20240726113207.3393247-1-xu.yang_2@nxp.com>
References: <20240726113207.3393247-1-xu.yang_2@nxp.com>
Message-ID: <20240809012625.GC2673490@nchen-desktop>

On 24-07-26 19:32:02, Xu Yang wrote:
> Enable regulator 'phy-3p0' to pass eye diagram test since it improve signal
> qualilty.
> 
> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>

Reviewed-by: Peter Chen <peter.chen at kernel.org>

> 
> ---
> Changes in v2:
>  - rewrite commit message
>  - use dev_err_probe() as suggested by Frank Li
> ---
>  drivers/usb/phy/phy-mxs-usb.c | 26 ++++++++++++++++++++++++++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
> index 920a32cd094d..d9d29f0b37de 100644
> --- a/drivers/usb/phy/phy-mxs-usb.c
> +++ b/drivers/usb/phy/phy-mxs-usb.c
> @@ -18,6 +18,7 @@
>  #include <linux/regmap.h>
>  #include <linux/mfd/syscon.h>
>  #include <linux/iopoll.h>
> +#include <linux/regulator/consumer.h>
>  
>  #define DRIVER_NAME "mxs_phy"
>  
> @@ -204,6 +205,7 @@ struct mxs_phy {
>  	int port_id;
>  	u32 tx_reg_set;
>  	u32 tx_reg_mask;
> +	struct regulator *phy_3p0;
>  };
>  
>  static inline bool is_imx6q_phy(struct mxs_phy *mxs_phy)
> @@ -288,6 +290,16 @@ static int mxs_phy_hw_init(struct mxs_phy *mxs_phy)
>  	if (ret)
>  		goto disable_pll;
>  
> +	if (mxs_phy->phy_3p0) {
> +		ret = regulator_enable(mxs_phy->phy_3p0);
> +		if (ret) {
> +			dev_err(mxs_phy->phy.dev,
> +				"Failed to enable 3p0 regulator, ret=%d\n",
> +				ret);
> +			return ret;
> +		}
> +	}
> +
>  	/* Power up the PHY */
>  	writel(0, base + HW_USBPHY_PWD);
>  
> @@ -448,6 +460,9 @@ static void mxs_phy_shutdown(struct usb_phy *phy)
>  	if (is_imx7ulp_phy(mxs_phy))
>  		mxs_phy_pll_enable(phy->io_priv, false);
>  
> +	if (mxs_phy->phy_3p0)
> +		regulator_disable(mxs_phy->phy_3p0);
> +
>  	clk_disable_unprepare(mxs_phy->clk);
>  }
>  
> @@ -789,6 +804,17 @@ static int mxs_phy_probe(struct platform_device *pdev)
>  	mxs_phy->clk = clk;
>  	mxs_phy->data = of_device_get_match_data(&pdev->dev);
>  
> +	mxs_phy->phy_3p0 = devm_regulator_get(&pdev->dev, "phy-3p0");
> +	if (PTR_ERR(mxs_phy->phy_3p0) == -ENODEV)
> +		/* not exist */
> +		mxs_phy->phy_3p0 = NULL;
> +	else if (IS_ERR(mxs_phy->phy_3p0))
> +		return dev_err_probe(&pdev->dev, PTR_ERR(mxs_phy->phy_3p0),
> +				"Getting regulator error\n");
> +
> +	if (mxs_phy->phy_3p0)
> +		regulator_set_voltage(mxs_phy->phy_3p0, 3200000, 3200000);
> +
>  	platform_set_drvdata(pdev, mxs_phy);
>  
>  	device_set_wakeup_capable(&pdev->dev, true);
> -- 
> 2.34.1
> 


From peter.chen at kernel.org  Thu Aug  8 18:33:25 2024
From: peter.chen at kernel.org (Peter Chen)
Date: Fri, 9 Aug 2024 09:33:25 +0800
Subject: [PATCH v2 5/6] usb: phy: mxs: enable weak 1p1 regulator for
 imx6ul during suspend
In-Reply-To: <20240726113207.3393247-5-xu.yang_2@nxp.com>
References: <20240726113207.3393247-1-xu.yang_2@nxp.com>
 <20240726113207.3393247-5-xu.yang_2@nxp.com>
Message-ID: <20240809013325.GD2673490@nchen-desktop>

On 24-07-26 19:32:06, Xu Yang wrote:
> 1p1 is off when the system enters suspend at i.MX6UL. It cause the PHY
> get wrong USB DP/DM value, then unexpected wakeup may occur if USB wakeup
> enabled. This will enable weak 1p1 during PHY suspend if vbus exist. So
> USB DP/DM is correct when system suspend.
> 
> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> 
> ---
> Changes in v2:
>  - modify commit message
> ---
>  drivers/usb/phy/phy-mxs-usb.c | 32 ++++++++++++++++++++++++++++----
>  1 file changed, 28 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
> index acaae22df3ba..cc4156c1b148 100644
> --- a/drivers/usb/phy/phy-mxs-usb.c
> +++ b/drivers/usb/phy/phy-mxs-usb.c
> @@ -71,6 +71,9 @@
>  #define BM_USBPHY_PLL_EN_USB_CLKS		BIT(6)
>  
>  /* Anatop Registers */
> +#define ANADIG_REG_1P1_SET			0x114
> +#define ANADIG_REG_1P1_CLR			0x118
> +
>  #define ANADIG_ANA_MISC0			0x150
>  #define ANADIG_ANA_MISC0_SET			0x154
>  #define ANADIG_ANA_MISC0_CLR			0x158
> @@ -123,6 +126,9 @@
>  
>  #define USB_PHY_VLLS_WAKEUP_EN			BIT(0)
>  
> +#define BM_ANADIG_REG_1P1_ENABLE_WEAK_LINREG	BIT(18)
> +#define BM_ANADIG_REG_1P1_TRACK_VDD_SOC_CAP	BIT(19)
> +
>  #define to_mxs_phy(p) container_of((p), struct mxs_phy, phy)
>  
>  /* Do disconnection between PHY and controller without vbus */
> @@ -196,7 +202,8 @@ static const struct mxs_phy_data imx6sx_phy_data = {
>  };
>  
>  static const struct mxs_phy_data imx6ul_phy_data = {
> -	.flags = MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS,
> +	.flags = MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS |
> +		MXS_PHY_HARDWARE_CONTROL_PHY2_CLK,
>  };
>  
>  static const struct mxs_phy_data imx7ulp_phy_data = {
> @@ -241,6 +248,11 @@ static inline bool is_imx7ulp_phy(struct mxs_phy *mxs_phy)
>  	return mxs_phy->data == &imx7ulp_phy_data;
>  }
>  
> +static inline bool is_imx6ul_phy(struct mxs_phy *mxs_phy)
> +{
> +	return mxs_phy->data == &imx6ul_phy_data;
> +}
> +
>  /*
>   * PHY needs some 32K cycles to switch from 32K clock to
>   * bus (such as AHB/AXI, etc) clock.
> @@ -884,18 +896,30 @@ static void mxs_phy_wakeup_enable(struct mxs_phy *mxs_phy, bool on)
>  
>  static void mxs_phy_enable_ldo_in_suspend(struct mxs_phy *mxs_phy, bool on)
>  {
> -	unsigned int reg = on ? ANADIG_ANA_MISC0_SET : ANADIG_ANA_MISC0_CLR;
> +	unsigned int reg;
> +	u32 value;
>  
>  	/* If the SoCs don't have anatop, quit */
>  	if (!mxs_phy->regmap_anatop)
>  		return;
>  
> -	if (is_imx6q_phy(mxs_phy))
> +	if (is_imx6q_phy(mxs_phy)) {
> +		reg = on ? ANADIG_ANA_MISC0_SET : ANADIG_ANA_MISC0_CLR;
>  		regmap_write(mxs_phy->regmap_anatop, reg,
>  			BM_ANADIG_ANA_MISC0_STOP_MODE_CONFIG);
> -	else if (is_imx6sl_phy(mxs_phy))
> +	} else if (is_imx6sl_phy(mxs_phy)) {
> +		reg = on ? ANADIG_ANA_MISC0_SET : ANADIG_ANA_MISC0_CLR;
>  		regmap_write(mxs_phy->regmap_anatop,
>  			reg, BM_ANADIG_ANA_MISC0_STOP_MODE_CONFIG_SL);
> +	} else if (is_imx6ul_phy(mxs_phy)) {
> +		reg = on ? ANADIG_REG_1P1_SET : ANADIG_REG_1P1_CLR;
> +		value = BM_ANADIG_REG_1P1_ENABLE_WEAK_LINREG |
> +			BM_ANADIG_REG_1P1_TRACK_VDD_SOC_CAP;
> +		if (mxs_phy_get_vbus_status(mxs_phy) && on)
> +			regmap_write(mxs_phy->regmap_anatop, reg, value);
> +		else if (!on)
> +			regmap_write(mxs_phy->regmap_anatop, reg, value);

Please check if vbus is not there but wakeup is enabled, and see the
behaviour is expected or not.

Peter
> +	}
>  }
>  
>  static int mxs_phy_system_suspend(struct device *dev)
> -- 
> 2.34.1
> 


From peter.chen at kernel.org  Thu Aug  8 18:34:58 2024
From: peter.chen at kernel.org (Peter Chen)
Date: Fri, 9 Aug 2024 09:34:58 +0800
Subject: [PATCH v2 4/6] usb: phy: mxs: add wakeup enable for imx7ulp
In-Reply-To: <20240726113207.3393247-4-xu.yang_2@nxp.com>
References: <20240726113207.3393247-1-xu.yang_2@nxp.com>
 <20240726113207.3393247-4-xu.yang_2@nxp.com>
Message-ID: <20240809013458.GE2673490@nchen-desktop>

On 24-07-26 19:32:05, Xu Yang wrote:
> This wakeup setting can enable USB wakeup function even the
> controller's power is lost, and both A7 and M4 are in VLLS mode.
> 
> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>

Reviewed-by: Peter Chen <peter.chen at kernel.org>
> 
> ---
> Changes in v2:
>  - no changes
> ---
>  drivers/usb/phy/phy-mxs-usb.c | 41 +++++++++++++++++++++++++++++++++--
>  1 file changed, 39 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
> index e172af75f602..acaae22df3ba 100644
> --- a/drivers/usb/phy/phy-mxs-usb.c
> +++ b/drivers/usb/phy/phy-mxs-usb.c
> @@ -118,6 +118,11 @@
>  #define BM_ANADIG_USB2_MISC_RX_VPIN_FS		BIT(29)
>  #define BM_ANADIG_USB2_MISC_RX_VMIN_FS		BIT(28)
>  
> +/* System Integration Module (SIM) Registers */
> +#define SIM_GPR1				0x30
> +
> +#define USB_PHY_VLLS_WAKEUP_EN			BIT(0)
> +
>  #define to_mxs_phy(p) container_of((p), struct mxs_phy, phy)
>  
>  /* Do disconnection between PHY and controller without vbus */
> @@ -214,6 +219,7 @@ struct mxs_phy {
>  	struct clk *clk;
>  	const struct mxs_phy_data *data;
>  	struct regmap *regmap_anatop;
> +	struct regmap *regmap_sim;
>  	int port_id;
>  	u32 tx_reg_set;
>  	u32 tx_reg_mask;
> @@ -772,6 +778,17 @@ static int mxs_phy_probe(struct platform_device *pdev)
>  		}
>  	}
>  
> +	/* Currently, only imx7ulp has SIM module */
> +	if (of_get_property(np, "nxp,sim", NULL)) {
> +		mxs_phy->regmap_sim = syscon_regmap_lookup_by_phandle
> +			(np, "nxp,sim");
> +		if (IS_ERR(mxs_phy->regmap_sim)) {
> +			dev_dbg(&pdev->dev,
> +				"failed to find regmap for sim\n");
> +			return PTR_ERR(mxs_phy->regmap_sim);
> +		}
> +	}
> +
>  	/* Precompute which bits of the TX register are to be updated, if any */
>  	if (!of_property_read_u32(np, "fsl,tx-cal-45-dn-ohms", &val) &&
>  	    val >= MXS_PHY_TX_CAL45_MIN && val <= MXS_PHY_TX_CAL45_MAX) {
> @@ -849,6 +866,22 @@ static void mxs_phy_remove(struct platform_device *pdev)
>  }
>  
>  #ifdef CONFIG_PM_SLEEP
> +static void mxs_phy_wakeup_enable(struct mxs_phy *mxs_phy, bool on)
> +{
> +	u32 mask = USB_PHY_VLLS_WAKEUP_EN;
> +
> +	/* If the SoCs don't have SIM, quit */
> +	if (!mxs_phy->regmap_sim)
> +		return;
> +
> +	if (on) {
> +		regmap_update_bits(mxs_phy->regmap_sim, SIM_GPR1, mask, mask);
> +		udelay(500);
> +	} else {
> +		regmap_update_bits(mxs_phy->regmap_sim, SIM_GPR1, mask, 0);
> +	}
> +}
> +
>  static void mxs_phy_enable_ldo_in_suspend(struct mxs_phy *mxs_phy, bool on)
>  {
>  	unsigned int reg = on ? ANADIG_ANA_MISC0_SET : ANADIG_ANA_MISC0_CLR;
> @@ -869,8 +902,10 @@ static int mxs_phy_system_suspend(struct device *dev)
>  {
>  	struct mxs_phy *mxs_phy = dev_get_drvdata(dev);
>  
> -	if (device_may_wakeup(dev))
> +	if (device_may_wakeup(dev)) {
>  		mxs_phy_enable_ldo_in_suspend(mxs_phy, true);
> +		mxs_phy_wakeup_enable(mxs_phy, true);
> +	}
>  
>  	return 0;
>  }
> @@ -879,8 +914,10 @@ static int mxs_phy_system_resume(struct device *dev)
>  {
>  	struct mxs_phy *mxs_phy = dev_get_drvdata(dev);
>  
> -	if (device_may_wakeup(dev))
> +	if (device_may_wakeup(dev)) {
>  		mxs_phy_enable_ldo_in_suspend(mxs_phy, false);
> +		mxs_phy_wakeup_enable(mxs_phy, false);
> +	}
>  
>  	return 0;
>  }
> -- 
> 2.34.1
> 


From peter.chen at kernel.org  Thu Aug  8 18:36:42 2024
From: peter.chen at kernel.org (Peter Chen)
Date: Fri, 9 Aug 2024 09:36:42 +0800
Subject: [PATCH v2 2/6] usb: phy: mxs: keep USBPHY2's clk always on
In-Reply-To: <20240726113207.3393247-2-xu.yang_2@nxp.com>
References: <20240726113207.3393247-1-xu.yang_2@nxp.com>
 <20240726113207.3393247-2-xu.yang_2@nxp.com>
Message-ID: <20240809013642.GF2673490@nchen-desktop>

On 24-07-26 19:32:03, Xu Yang wrote:
> IP require keep USBPHY2's clk always on, so USBPHY2 (PLL7) power can be
> controlled by suspend signal. USB remote wakeup needs resume signal be
> sent out as soon as possible to match USB requirements.
> 
> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>

Reviewed-by: Peter Chen <peter.chen at kernel.org>
> 
> ---
> Changes in v2:
>  - modify commit message
>  - remove hardware_control_phy2_clk
> ---
>  drivers/usb/phy/phy-mxs-usb.c | 33 ++++++++++++++++++++++++++-------
>  1 file changed, 26 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
> index d9d29f0b37de..e172af75f602 100644
> --- a/drivers/usb/phy/phy-mxs-usb.c
> +++ b/drivers/usb/phy/phy-mxs-usb.c
> @@ -150,6 +150,15 @@
>  #define MXS_PHY_TX_D_CAL_MIN			79
>  #define MXS_PHY_TX_D_CAL_MAX			119
>  
> +/*
> + * At imx6q/6sl/6sx, the PHY2's clock is controlled by hardware directly,
> + * eg, according to PHY's suspend status. In these PHYs, we only need to
> + * open the clock at the initialization and close it at its shutdown routine.
> + * These PHYs can send resume signal without software interfere if not
> + * gate clock.
> + */
> +#define MXS_PHY_HARDWARE_CONTROL_PHY2_CLK	BIT(4)
> +
>  struct mxs_phy_data {
>  	unsigned int flags;
>  };
> @@ -161,12 +170,14 @@ static const struct mxs_phy_data imx23_phy_data = {
>  static const struct mxs_phy_data imx6q_phy_data = {
>  	.flags = MXS_PHY_SENDING_SOF_TOO_FAST |
>  		MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS |
> -		MXS_PHY_NEED_IP_FIX,
> +		MXS_PHY_NEED_IP_FIX |
> +		MXS_PHY_HARDWARE_CONTROL_PHY2_CLK,
>  };
>  
>  static const struct mxs_phy_data imx6sl_phy_data = {
>  	.flags = MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS |
> -		MXS_PHY_NEED_IP_FIX,
> +		MXS_PHY_NEED_IP_FIX |
> +		MXS_PHY_HARDWARE_CONTROL_PHY2_CLK,
>  };
>  
>  static const struct mxs_phy_data vf610_phy_data = {
> @@ -175,7 +186,8 @@ static const struct mxs_phy_data vf610_phy_data = {
>  };
>  
>  static const struct mxs_phy_data imx6sx_phy_data = {
> -	.flags = MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS,
> +	.flags = MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS |
> +		MXS_PHY_HARDWARE_CONTROL_PHY2_CLK,
>  };
>  
>  static const struct mxs_phy_data imx6ul_phy_data = {
> @@ -518,12 +530,19 @@ static int mxs_phy_suspend(struct usb_phy *x, int suspend)
>  		}
>  		writel(BM_USBPHY_CTRL_CLKGATE,
>  		       x->io_priv + HW_USBPHY_CTRL_SET);
> -		clk_disable_unprepare(mxs_phy->clk);
> +		if (!(mxs_phy->port_id == 1 &&
> +			(mxs_phy->data->flags &
> +				MXS_PHY_HARDWARE_CONTROL_PHY2_CLK)))
> +			clk_disable_unprepare(mxs_phy->clk);
>  	} else {
>  		mxs_phy_clock_switch_delay();
> -		ret = clk_prepare_enable(mxs_phy->clk);
> -		if (ret)
> -			return ret;
> +		if (!(mxs_phy->port_id == 1 &&
> +			(mxs_phy->data->flags &
> +				MXS_PHY_HARDWARE_CONTROL_PHY2_CLK))) {
> +			ret = clk_prepare_enable(mxs_phy->clk);
> +			if (ret)
> +				return ret;
> +		}
>  		writel(BM_USBPHY_CTRL_CLKGATE,
>  		       x->io_priv + HW_USBPHY_CTRL_CLR);
>  		writel(0, x->io_priv + HW_USBPHY_PWD);
> -- 
> 2.34.1
> 


From conor at kernel.org  Fri Aug  9 07:57:22 2024
From: conor at kernel.org (Conor Dooley)
Date: Fri, 9 Aug 2024 15:57:22 +0100
Subject: [PATCH v3 1/1] dt-bindings: phy: ti,tcan104x-can: Document
 Microchip ATA6561
In-Reply-To: <20240808191735.1483572-1-ilordash02@gmail.com>
References: <56a52c81-68de-438d-94ae-9decc799d824@kernel.org>
 <20240808191735.1483572-1-ilordash02@gmail.com>
Message-ID: <20240809-guru-tassel-84a14486a596@spud>

On Thu, Aug 08, 2024 at 10:17:35PM +0300, Ilya Orazov wrote:
> Microchip ATA6561 is High-Speed CAN Transceiver with Standby Mode.
> It is pin-compatible with TI TCAN1042 and has a compatible programming
> model, therefore use ti,tcan1042 as fallback compatible.
> 
> Signed-off-by: Ilya Orazov <ilordash02 at gmail.com>
> ---

Acked-by: Conor Dooley <conor.dooley at microchip.com>

btw, please don't send new versions as a reply to existing ones, it's a
shortcut to getting lost in deep mailboxes that sort by thread (or as I
almost did here, deletion of the mail without reading it).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-phy/attachments/20240809/9a729a1f/attachment.sig>

From dan.carpenter at linaro.org  Sun Aug 11 06:36:49 2024
From: dan.carpenter at linaro.org (Dan Carpenter)
Date: Sun, 11 Aug 2024 16:36:49 +0300
Subject: [PATCH 3/3] phy: starfive: jh7110-usb: Fix link configuration to
 controller
In-Reply-To: <cd7b125c8c797f9d63440944df7121f9db0a49ad.1722457123.git.jan.kiszka@siemens.com>
Message-ID: <053d3e9f-ba32-406c-a799-91ea577a0cb9@stanley.mountain>

Hi Jan,

kernel test robot noticed the following build warnings:

https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Jan-Kiszka/dt-bindings-phy-jh7110-usb-phy-Add-sys-syscon-property/20240802-101748
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
patch link:    https://lore.kernel.org/r/cd7b125c8c797f9d63440944df7121f9db0a49ad.1722457123.git.jan.kiszka%40siemens.com
patch subject: [PATCH 3/3] phy: starfive: jh7110-usb: Fix link configuration to controller
config: microblaze-randconfig-r072-20240810 (https://download.01.org/0day-ci/archive/20240811/202408110917.hE9xidPH-lkp at intel.com/config)
compiler: microblaze-linux-gcc (GCC) 14.1.0

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Reported-by: Dan Carpenter <dan.carpenter at linaro.org>
| Closes: https://lore.kernel.org/r/202408110917.hE9xidPH-lkp at intel.com/

smatch warnings:
drivers/phy/starfive/phy-jh7110-usb.c:148 jh7110_usb_phy_probe() warn: passing zero to 'PTR_ERR'

vim +/PTR_ERR +148 drivers/phy/starfive/phy-jh7110-usb.c

16d3a71c20cf2e Minda Chen 2023-06-29  109  static int jh7110_usb_phy_probe(struct platform_device *pdev)
16d3a71c20cf2e Minda Chen 2023-06-29  110  {
16d3a71c20cf2e Minda Chen 2023-06-29  111  	struct jh7110_usb2_phy *phy;
16d3a71c20cf2e Minda Chen 2023-06-29  112  	struct device *dev = &pdev->dev;
16d3a71c20cf2e Minda Chen 2023-06-29  113  	struct phy_provider *phy_provider;
0ed73d833230fd Jan Kiszka 2024-07-31  114  	u32 args[1];
16d3a71c20cf2e Minda Chen 2023-06-29  115  
16d3a71c20cf2e Minda Chen 2023-06-29  116  	phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
16d3a71c20cf2e Minda Chen 2023-06-29  117  	if (!phy)
16d3a71c20cf2e Minda Chen 2023-06-29  118  		return -ENOMEM;
16d3a71c20cf2e Minda Chen 2023-06-29  119  
16d3a71c20cf2e Minda Chen 2023-06-29  120  	phy->usb_125m_clk = devm_clk_get(dev, "125m");
16d3a71c20cf2e Minda Chen 2023-06-29  121  	if (IS_ERR(phy->usb_125m_clk))
16d3a71c20cf2e Minda Chen 2023-06-29  122  		return dev_err_probe(dev, PTR_ERR(phy->usb_125m_clk),
16d3a71c20cf2e Minda Chen 2023-06-29  123  			"Failed to get 125m clock\n");
16d3a71c20cf2e Minda Chen 2023-06-29  124  
16d3a71c20cf2e Minda Chen 2023-06-29  125  	phy->app_125m = devm_clk_get(dev, "app_125m");
16d3a71c20cf2e Minda Chen 2023-06-29  126  	if (IS_ERR(phy->app_125m))
16d3a71c20cf2e Minda Chen 2023-06-29  127  		return dev_err_probe(dev, PTR_ERR(phy->app_125m),
16d3a71c20cf2e Minda Chen 2023-06-29  128  			"Failed to get app 125m clock\n");
16d3a71c20cf2e Minda Chen 2023-06-29  129  
16d3a71c20cf2e Minda Chen 2023-06-29  130  	phy->regs = devm_platform_ioremap_resource(pdev, 0);
16d3a71c20cf2e Minda Chen 2023-06-29  131  	if (IS_ERR(phy->regs))
16d3a71c20cf2e Minda Chen 2023-06-29  132  		return dev_err_probe(dev, PTR_ERR(phy->regs),
16d3a71c20cf2e Minda Chen 2023-06-29  133  			"Failed to map phy base\n");
16d3a71c20cf2e Minda Chen 2023-06-29  134  
16d3a71c20cf2e Minda Chen 2023-06-29  135  	phy->phy = devm_phy_create(dev, NULL, &jh7110_usb2_phy_ops);
16d3a71c20cf2e Minda Chen 2023-06-29  136  	if (IS_ERR(phy->phy))
16d3a71c20cf2e Minda Chen 2023-06-29  137  		return dev_err_probe(dev, PTR_ERR(phy->phy),
16d3a71c20cf2e Minda Chen 2023-06-29  138  			"Failed to create phy\n");
16d3a71c20cf2e Minda Chen 2023-06-29  139  
16d3a71c20cf2e Minda Chen 2023-06-29  140  	phy_set_drvdata(phy->phy, phy);
16d3a71c20cf2e Minda Chen 2023-06-29  141  	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
16d3a71c20cf2e Minda Chen 2023-06-29  142  
0ed73d833230fd Jan Kiszka 2024-07-31  143  	phy->sys_syscon =
0ed73d833230fd Jan Kiszka 2024-07-31  144  		syscon_regmap_lookup_by_phandle_args(pdev->dev.of_node,
0ed73d833230fd Jan Kiszka 2024-07-31  145  						     "starfive,sys-syscon",
0ed73d833230fd Jan Kiszka 2024-07-31  146  						     1, args);
0ed73d833230fd Jan Kiszka 2024-07-31  147  	if (IS_ERR(phy->sys_syscon))
0ed73d833230fd Jan Kiszka 2024-07-31 @148  		return dev_err_probe(dev, PTR_ERR(phy->phy),

Passing the wrong variable.  It should be phy->sys_syscon instead of phy->phy.

0ed73d833230fd Jan Kiszka 2024-07-31  149  			"Failed to get sys-syscon\n");
0ed73d833230fd Jan Kiszka 2024-07-31  150  	phy->sys_phy_connect = args[0];
0ed73d833230fd Jan Kiszka 2024-07-31  151  
16d3a71c20cf2e Minda Chen 2023-06-29  152  	return PTR_ERR_OR_ZERO(phy_provider);
16d3a71c20cf2e Minda Chen 2023-06-29  153  }

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki



From christian.bruel at foss.st.com  Mon Aug 12 05:05:24 2024
From: christian.bruel at foss.st.com (Christian Bruel)
Date: Mon, 12 Aug 2024 14:05:24 +0200
Subject: [PATCH 0/5] Add STM32MP25 USB3/PCIE COMBOPHY driver 
Message-ID: <20240812120529.3564390-1-christian.bruel@foss.st.com>

This patch series adds USB3/PCIE COMBOPHY driver for the STM32MP25 SoC from
STMicrolectronics, respective yaml schema and enable for the stm32mp257f-ev1
device into which it is used for PCIe.

Christian Bruel (5):
  MAINTAINERS: add entry for ST STM32MP25 COMBOPHY driver
  dt-bindings: phy: Add STM32MP25 COMBOPHY bindings
  phy: stm32: Add support for STM32MP25 COMBOPHY.
  arm64: dts: st: Add combophy node on stm32mp251
  arm64: dts: st: Enable COMBOPHY on the stm32mp257f-ev1 board

 .../bindings/phy/st,stm32-combophy.yaml       | 178 +++++
 MAINTAINERS                                   |   6 +
 arch/arm64/boot/dts/st/stm32mp251.dtsi        |  17 +
 arch/arm64/boot/dts/st/stm32mp257f-ev1.dts    |  14 +
 drivers/phy/st/Kconfig                        |  12 +
 drivers/phy/st/Makefile                       |   1 +
 drivers/phy/st/phy-stm32-combophy.c           | 607 ++++++++++++++++++
 7 files changed, 835 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml
 create mode 100644 drivers/phy/st/phy-stm32-combophy.c

-- 
2.34.1



From christian.bruel at foss.st.com  Mon Aug 12 05:05:25 2024
From: christian.bruel at foss.st.com (Christian Bruel)
Date: Mon, 12 Aug 2024 14:05:25 +0200
Subject: [PATCH 1/5] MAINTAINERS: add entry for ST STM32MP25 COMBOPHY driver
In-Reply-To: <20240812120529.3564390-1-christian.bruel@foss.st.com>
References: <20240812120529.3564390-1-christian.bruel@foss.st.com>
Message-ID: <20240812120529.3564390-2-christian.bruel@foss.st.com>

Add myself as STM32MP25 COMBOPHY maintainer

Signed-off-by: Christian Bruel <christian.bruel at foss.st.com>
---
 MAINTAINERS | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f328373463b0d..258fb57ccff58 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -21910,6 +21910,12 @@ F:	arch/m68k/kernel/*sun3*
 F:	arch/m68k/sun3*/
 F:	drivers/net/ethernet/i825xx/sun3*
 
+STMICROELECTRONICS STMP32MP25 USB3/PCIE COMBOPHY DRIVER
+M:	Christian Bruel <christian.bruel at foss.st.com>
+S:	Maintained
+F:	Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml
+F:	drivers/phy/st/phy-stm32-combophy.c
+
 SUN4I LOW RES ADC ATTACHED TABLET KEYS DRIVER
 M:	Hans de Goede <hdegoede at redhat.com>
 L:	linux-input at vger.kernel.org
-- 
2.34.1



From christian.bruel at foss.st.com  Mon Aug 12 05:05:28 2024
From: christian.bruel at foss.st.com (Christian Bruel)
Date: Mon, 12 Aug 2024 14:05:28 +0200
Subject: [PATCH 4/5] arm64: dts: st: Add combophy node on stm32mp251
In-Reply-To: <20240812120529.3564390-1-christian.bruel@foss.st.com>
References: <20240812120529.3564390-1-christian.bruel@foss.st.com>
Message-ID: <20240812120529.3564390-5-christian.bruel@foss.st.com>

Add support for COMBOPHY which is used either by the USB3 and PCIe
controller.
USB3 or PCIe mode is done with phy_set_mode().
PCIe internal reference clock can be generated from the internal clock
source or optionnaly from an external 100Mhz pad.

Signed-off-by: Christian Bruel <christian.bruel at foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp251.dtsi | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
index 1167cf63d7e87..4b99fa7e8e7a9 100644
--- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
@@ -7,6 +7,7 @@
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/reset/st,stm32mp25-rcc.h>
 #include <dt-bindings/regulator/st,stm32mp25-regulator.h>
+#include <dt-bindings/phy/phy.h>
 
 / {
 	#address-cells = <2>;
@@ -518,6 +519,22 @@ i2c8: i2c at 46040000 {
 				status = "disabled";
 			};
 
+			combophy: phy at 480c0000 {
+				compatible = "st,stm32mp25-combophy";
+				reg = <0x480c0000 0x1000>;
+				#phy-cells = <1>;
+				clocks = <&rcc CK_BUS_USB3PCIEPHY>, <&rcc CK_KER_USB3PCIEPHY>;
+				clock-names = "apb-clk", "ker-clk";
+				resets = <&rcc USB3PCIEPHY_R>;
+				reset-names = "phy-rst";
+				st,syscfg = <&syscfg>;
+				access-controllers = <&rifsc 67>;
+				power-domains = <&CLUSTER_PD>;
+				wakeup-source;
+				interrupts-extended = <&exti1 45 IRQ_TYPE_EDGE_FALLING>;
+				status = "disabled";
+			};
+
 			sdmmc1: mmc at 48220000 {
 				compatible = "st,stm32mp25-sdmmc2", "arm,pl18x", "arm,primecell";
 				arm,primecell-periphid = <0x00353180>;
-- 
2.34.1



From christian.bruel at foss.st.com  Mon Aug 12 05:05:26 2024
From: christian.bruel at foss.st.com (Christian Bruel)
Date: Mon, 12 Aug 2024 14:05:26 +0200
Subject: [PATCH 2/5] dt-bindings: phy: Add STM32MP25 COMBOPHY bindings
In-Reply-To: <20240812120529.3564390-1-christian.bruel@foss.st.com>
References: <20240812120529.3564390-1-christian.bruel@foss.st.com>
Message-ID: <20240812120529.3564390-3-christian.bruel@foss.st.com>

Document the bindings for STM32 COMBOPHY interface, used to support
the PCIe and USB3 stm32mp25 drivers.
Following entries can be used to tune caracterisation parameters
 - st,output-micro-ohms and st,output-vswing-microvolt bindings entries
to tune the impedance and voltage swing using discrete simulation results
 - st, phy_rx0_eq register to set the internal rx equalizer filter value.

Signed-off-by: Christian Bruel <christian.bruel at foss.st.com>
---
 .../bindings/phy/st,stm32-combophy.yaml       | 178 ++++++++++++++++++
 1 file changed, 178 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml

diff --git a/Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml b/Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml
new file mode 100644
index 0000000000000..6a53ab834b2a7
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml
@@ -0,0 +1,178 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/st,stm32-combophy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STM32MP25 USB3/PCIe COMBOPHY
+
+maintainers:
+  - Christian Bruel <christian.bruel at foss.st.com>
+
+description: |
+  Single lane PHY shared (exclusive) between the USB3 and PCIe controllers.
+  Supports 5Gbit/s for USB3 and PCIe gen2 or 2.5Gbit/s for PCIe gen1.
+
+properties:
+  compatible:
+    const: st,stm32mp25-combophy
+
+  reg:
+    maxItems: 1
+
+  st,syscfg:
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+    description: Phandle to the SYSCON entry required for configuring PCIe
+      or USB3.
+
+  "#phy-cells":
+    const: 1
+    description: |
+      The cells contain the following arguments.
+
+      - description: The PHY type
+          enum:
+            - PHY_TYPE_USB3
+            - PHY_TYPE_PCIE
+
+  clocks:
+    anyOf:
+      - description: apb-clk Bus clock mandatory to access registers.
+      - description: ker-clk Internal RCC reference clock for USB3 or PCIe
+      - description: pad-clk Optional on board clock input for PCIe only. Typically an
+                     external 100Mhz oscillator wired on dedicated CLKIN pad. Used as reference
+                     clock input instead of the ker-clk
+
+  clock-names:
+    oneOf:
+      - items:
+          - const: apb-clk
+          - const: ker-clk
+
+      - items:
+          - const: apb-clk
+          - const: ker-clk
+          - const: pad-clk
+
+  resets:
+    maxItems: 1
+
+  reset-names:
+    const: phy-rst
+
+  power-domains:
+    maxItems: 1
+
+  st,ssc-on:
+    type: boolean
+    description:
+      A boolean property whose presence indicates that the SSC for common clock
+      needs to be set.
+
+  st,rx_equalizer:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    minimum: 0
+    maximum: 7
+    default: 2
+    description:
+      A 3 bit value describing internal filter settings for the RX equalizer.
+
+  st,output-micro-ohms:
+    minimum: 3999000
+    maximum: 6090000
+    default: 4968000
+    description:
+      A value property to tune the Single Ended Output Impedance, simulations results
+      at 25C for a VDDP=0.8V. The hardware accepts discrete values in this range.
+
+  st,output-vswing-microvolt:
+    minimum: 442000
+    maximum: 803000
+    default: 803000
+    description:
+      A value property in microvolt to tune the Single Ended Output Voltage Swing to change the
+      Vlo, Vhi for a VDDP = 0.8V. The hardware accepts discrete values in this range.
+
+  wakeup-source: true
+
+  interrupts:
+    maxItems: 1
+    description: interrupt used for wakeup
+
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
+required:
+  - compatible
+  - reg
+  - st,syscfg
+  - '#phy-cells'
+  - resets
+  - reset-names
+  - clocks
+  - clock-names
+
+allOf:
+  - if:
+      required:
+        - wakeup-source
+    then:
+      anyOf:
+        - required: [interrupts]
+        - required: [interrupts-extended]
+
+additionalProperties: false
+
+examples:
+  - |
+    // Example 1: COMBOPHY configured to use internal reference clock
+    #include <dt-bindings/clock/st,stm32mp25-rcc.h>
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/reset/st,stm32mp25-rcc.h>
+
+    combophy_internal: phy at 480c0000 {
+        compatible = "st,stm32mp25-combophy";
+        reg = <0x480c0000 0x1000>;
+        #phy-cells = <1>;
+        clocks = <&rcc CK_BUS_USB3PCIEPHY>, <&rcc CK_KER_USB3PCIEPHY>;
+        clock-names = "apb-clk", "ker-clk";
+        resets = <&rcc USB3PCIEPHY_R>;
+        reset-names = "phy-rst";
+        st,syscfg = <&syscfg>;
+        access-controllers = <&rifsc 67>;
+        power-domains = <&CLUSTER_PD>;
+        wakeup-source;
+        interrupts-extended = <&exti1 45 IRQ_TYPE_EDGE_FALLING>;
+    };
+
+  - |
+    // Example 2: COMBOPHY configured to use extrenal 100MHz reference clock
+    // on CLKIN pad for PCIe
+    #include <dt-bindings/clock/st,stm32mp25-rcc.h>
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/reset/st,stm32mp25-rcc.h>
+
+    clocks {
+        pad_clk: pad-clk {
+            #clock-cells = <0>;
+            compatible = "fixed-clock";
+            clock-frequency = <100000000>;
+        };
+    };
+
+    combophy_pad: phy at 480c0000 {
+        compatible = "st,stm32mp25-combophy";
+        reg = <0x480c0000 0x1000>;
+        #phy-cells = <1>;
+        clocks = <&rcc CK_BUS_USB3PCIEPHY>, <&rcc CK_KER_USB3PCIEPHY>, <&pad_clk>;
+        clock-names = "apb-clk", "ker-clk", "pad-clk";
+        resets = <&rcc USB3PCIEPHY_R>;
+        reset-names = "phy-rst";
+        st,syscfg = <&syscfg>;
+        access-controllers = <&rifsc 67>;
+        power-domains = <&CLUSTER_PD>;
+        wakeup-source;
+        interrupts-extended = <&exti1 45 IRQ_TYPE_EDGE_FALLING>;
+    };
+...
-- 
2.34.1



From christian.bruel at foss.st.com  Mon Aug 12 05:05:27 2024
From: christian.bruel at foss.st.com (Christian Bruel)
Date: Mon, 12 Aug 2024 14:05:27 +0200
Subject: [PATCH 3/5] phy: stm32: Add support for STM32MP25 COMBOPHY.
In-Reply-To: <20240812120529.3564390-1-christian.bruel@foss.st.com>
References: <20240812120529.3564390-1-christian.bruel@foss.st.com>
Message-ID: <20240812120529.3564390-4-christian.bruel@foss.st.com>

Addition of the COMBOPHY driver found on STM32MP25 platforms

This single lane PHY is shared (exclusive) between the USB3 and PCIE
controllers.
Supports 5Gbit/s for PCIE gen2 or 2.5Gbit/s for PCIE gen1.

Supports wakeup-source capability to wakeup system using remote-wakeup
capable USB device

Signed-off-by: Christian Bruel <christian.bruel at foss.st.com>
---
 drivers/phy/st/Kconfig              |  11 +
 drivers/phy/st/Makefile             |   1 +
 drivers/phy/st/phy-stm32-combophy.c | 607 ++++++++++++++++++++++++++++
 3 files changed, 619 insertions(+)
 create mode 100644 drivers/phy/st/phy-stm32-combophy.c

diff --git a/drivers/phy/st/Kconfig b/drivers/phy/st/Kconfig
index 3fc3d0781fb8a..304614b6dabfc 100644
--- a/drivers/phy/st/Kconfig
+++ b/drivers/phy/st/Kconfig
@@ -33,6 +33,17 @@ config PHY_STIH407_USB
 	  Enable this support to enable the picoPHY device used by USB2
 	  and USB3 controllers on STMicroelectronics STiH407 SoC families.
 
+config PHY_STM32_COMBOPHY
+	tristate "STMicroelectronics COMBOPHY driver for STM32MP25"
+	depends on ARCH_STM32 || COMPILE_TEST
+	select GENERIC_PHY
+	help
+	  Enable this to support the COMBOPHY device used by USB3 or PCIe
+	  controllers on STMicroelectronics STM32MP25 SoC.
+	  This driver controls the COMBOPHY block to generate the PCIe 100Mhz
+	  reference clock from either the external clock generator or HSE
+	  internal SoC clock source.
+
 config PHY_STM32_USBPHYC
 	tristate "STMicroelectronics STM32 USB HS PHY Controller driver"
 	depends on ARCH_STM32 || COMPILE_TEST
diff --git a/drivers/phy/st/Makefile b/drivers/phy/st/Makefile
index c862dd937b647..cb80e954ea9f0 100644
--- a/drivers/phy/st/Makefile
+++ b/drivers/phy/st/Makefile
@@ -3,4 +3,5 @@ obj-$(CONFIG_PHY_MIPHY28LP) 		+= phy-miphy28lp.o
 obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)	+= phy-spear1310-miphy.o
 obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)	+= phy-spear1340-miphy.o
 obj-$(CONFIG_PHY_STIH407_USB)		+= phy-stih407-usb.o
+obj-$(CONFIG_PHY_STM32_COMBOPHY)	+= phy-stm32-combophy.o
 obj-$(CONFIG_PHY_STM32_USBPHYC) 	+= phy-stm32-usbphyc.o
diff --git a/drivers/phy/st/phy-stm32-combophy.c b/drivers/phy/st/phy-stm32-combophy.c
new file mode 100644
index 0000000000000..5ce9af0b569d7
--- /dev/null
+++ b/drivers/phy/st/phy-stm32-combophy.c
@@ -0,0 +1,607 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * STMicroelectronics COMBOPHY STM32MP25 Controller driver.
+ *
+ * Copyright (C) 2024 STMicroelectronics
+ * Author: Christian Bruel <christian.bruel at foss.st.com>
+ */
+
+#include <linux/clk.h>
+#include <linux/mfd/syscon.h>
+#include <linux/platform_device.h>
+#include <linux/phy/phy.h>
+#include <linux/pm_runtime.h>
+#include <linux/regmap.h>
+#include <linux/reset.h>
+#include <dt-bindings/phy/phy.h>
+
+#define SYSCFG_COMBOPHY_CR1 0x4C00
+#define SYSCFG_COMBOPHY_CR2 0x4C04
+#define SYSCFG_COMBOPHY_CR4 0x4C0C
+#define SYSCFG_COMBOPHY_CR5 0x4C10
+#define SYSCFG_COMBOPHY_SR  0x4C14
+#define SYSCFG_PCIEPRGCR    0x6080
+
+/* SYSCFG PCIEPRGCR */
+#define STM32MP25_PCIEPRGCR_EN	  BIT(0)
+#define STM32MP25_PCIEPRG_IMPCTRL_OHM     GENMASK(3, 1)
+#define STM32MP25_PCIEPRG_IMPCTRL_VSWING  GENMASK(5, 4)
+
+/* SYSCFG SYSCFG_COMBOPHY_SR */
+#define STM32MP25_PIPE0_PHYSTATUS BIT(1)
+
+/* SYSCFG CR1 */
+#define SYSCFG_COMBOPHY_CR1_REFUSEPAD BIT(0)
+#define SYSCFG_COMBOPHY_CR1_MPLLMULT GENMASK(7, 1)
+#define SYSCFG_COMBOPHY_CR1_REFCLKSEL GENMASK(16, 8)
+#define SYSCFG_COMBOPHY_CR1_REFCLKDIV2 BIT(17)
+#define SYSCFG_COMBOPHY_CR1_REFSSPEN BIT(18)
+#define SYSCFG_COMBOPHY_CR1_SSCEN BIT(19)
+
+/* SYSCFG CR4 */
+#define SYSCFG_COMBOPHY_CR4_RX0_EQ GENMASK(2, 0)
+
+#define MPLLMULT_19_2 (0x02u << 1)
+#define MPLLMULT_20   (0x7Du << 1)
+#define MPLLMULT_24   (0x68u << 1)
+#define MPLLMULT_25   (0x64u << 1)
+#define MPLLMULT_26   (0x60u << 1)
+#define MPLLMULT_38_4 (0x41u << 1)
+#define MPLLMULT_48   (0x6Cu << 1)
+#define MPLLMULT_50   (0x32u << 1)
+#define MPLLMULT_52   (0x30u << 1)
+#define MPLLMULT_100  (0x19u << 1)
+
+#define REFCLKSEL_0   0
+#define REFCLKSEL_1   (0x108u << 8)
+
+#define REFCLDIV_0    0
+
+/* SYSCFG CR2 */
+#define SYSCFG_COMBOPHY_CR2_MODESEL GENMASK(1, 0)
+#define SYSCFG_COMBOPHY_CR2_ISO_DIS BIT(15)
+
+#define COMBOPHY_MODESEL_PCIE 0
+#define COMBOPHY_MODESEL_USB  3
+
+/* SYSCFG CR5 */
+#define SYSCFG_COMBOPHY_CR5_COMMON_CLOCKS BIT(12)
+
+#define COMBOPHY_SUP_ANA_MPLL_LOOP_CTL 0xC0
+#define COMBOPHY_PROP_CNTRL GENMASK(7, 4)
+
+struct stm32_combophy {
+	struct phy *phy;
+	struct regmap *regmap;
+	struct device *dev;
+	void __iomem *base;
+	struct reset_control *phy_reset;
+	struct clk *phy_clk;
+	struct clk *pad_clk;
+	struct clk *ker_clk;
+	unsigned int type;
+	bool is_init;
+	int irq_wakeup;
+};
+
+struct clk_impedance  {
+	u32 microohm;
+	u32 vswing[4];
+};
+
+/*
+ * lookup table to hold the settings needed for a ref clock frequency
+ * impedance, the offset is used to set the IMP_CTL and DE_EMP bit of the
+ * PRG_IMP_CTRL register
+ */
+static const struct clk_impedance imp_lookup[] = {
+	{ 6090000, { 442000, 564000, 684000, 802000 } },
+	{ 5662000, { 528000, 621000, 712000, 803000 } },
+	{ 5292000, { 491000, 596000, 700000, 802000 } },
+	{ 4968000, { 558000, 640000, 722000, 803000 } },
+	{ 4684000, { 468000, 581000, 692000, 802000 } },
+	{ 4429000, { 554000, 613000, 717000, 803000 } },
+	{ 4204000, { 511000, 609000, 706000, 802000 } },
+	{ 3999000, { 571000, 648000, 726000, 803000 } }
+};
+
+static int stm32_impedance_tune(struct stm32_combophy *combophy)
+{
+	u8 imp_size = ARRAY_SIZE(imp_lookup);
+	u8 vswing_size = ARRAY_SIZE(imp_lookup[0].vswing);
+	u8 imp_of, vswing_of;
+	u32 max_imp = imp_lookup[0].microohm;
+	u32 min_imp = imp_lookup[imp_size - 1].microohm;
+	u32 max_vswing = imp_lookup[imp_size - 1].vswing[vswing_size - 1];
+	u32 min_vswing = imp_lookup[0].vswing[0];
+	u32 val;
+
+	if (!of_property_read_u32(combophy->dev->of_node, "st,output-micro-ohms", &val)) {
+		if (val < min_imp || val > max_imp) {
+			dev_err(combophy->dev, "Invalid value %u for output ohm\n", val);
+			return -EINVAL;
+		}
+
+		for (imp_of = 0 ; imp_of < ARRAY_SIZE(imp_lookup); imp_of++)
+			if (imp_lookup[imp_of].microohm <= val)
+				break;
+
+		dev_dbg(combophy->dev, "Set %u micro-ohms output impedance\n",
+			imp_lookup[imp_of].microohm);
+
+		regmap_update_bits(combophy->regmap, SYSCFG_PCIEPRGCR,
+				   STM32MP25_PCIEPRG_IMPCTRL_OHM,
+				   FIELD_PREP(STM32MP25_PCIEPRG_IMPCTRL_OHM, imp_of));
+	} else {
+		regmap_read(combophy->regmap, SYSCFG_PCIEPRGCR, &val);
+		imp_of = FIELD_GET(STM32MP25_PCIEPRG_IMPCTRL_OHM, val);
+	}
+
+	if (!of_property_read_u32(combophy->dev->of_node, "st,output-vswing-microvolt", &val)) {
+		if (val < min_vswing || val > max_vswing) {
+			dev_err(combophy->dev, "Invalid value %u for output vswing\n", val);
+			return -EINVAL;
+		}
+
+		for (vswing_of = 0 ; vswing_of < ARRAY_SIZE(imp_lookup[imp_of].vswing); vswing_of++)
+			if (imp_lookup[imp_of].vswing[vswing_of] >= val)
+				break;
+
+		dev_dbg(combophy->dev, "Set %u microvolt swing\n",
+			 imp_lookup[imp_of].vswing[vswing_of]);
+
+		regmap_update_bits(combophy->regmap, SYSCFG_PCIEPRGCR,
+				   STM32MP25_PCIEPRG_IMPCTRL_VSWING,
+				   FIELD_PREP(STM32MP25_PCIEPRG_IMPCTRL_VSWING, vswing_of));
+	}
+
+	return 0;
+}
+
+static int stm32_combophy_pll_init(struct stm32_combophy *combophy)
+{
+	int ret;
+	u32 refclksel, pllmult, propcntrl, val;
+	u32 clk_rate;
+
+	if (combophy->pad_clk)
+		clk_rate = clk_get_rate(combophy->pad_clk);
+	else
+		clk_rate = clk_get_rate(combophy->ker_clk);
+
+	reset_control_assert(combophy->phy_reset);
+
+	dev_dbg(combophy->dev, "%s pll init rate %d\n",
+		combophy->pad_clk ? "External" : "Ker", clk_rate);
+
+	/*
+	 * vddcombophy is interconnected with vddcore. Isolation bit should be unset
+	 * before using the ComboPHY.
+	 */
+	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR2,
+			   SYSCFG_COMBOPHY_CR2_ISO_DIS, SYSCFG_COMBOPHY_CR2_ISO_DIS);
+
+	if (combophy->type != PHY_TYPE_PCIE)
+		regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
+				   SYSCFG_COMBOPHY_CR1_REFSSPEN, SYSCFG_COMBOPHY_CR1_REFSSPEN);
+
+	if (combophy->type == PHY_TYPE_PCIE && !combophy->pad_clk)
+		regmap_update_bits(combophy->regmap, SYSCFG_PCIEPRGCR,
+				   STM32MP25_PCIEPRGCR_EN, STM32MP25_PCIEPRGCR_EN);
+
+	if (of_property_read_bool(combophy->dev->of_node, "st,ssc-on")) {
+		dev_dbg(combophy->dev, "Enabling clock with SSC\n");
+		regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
+				   SYSCFG_COMBOPHY_CR1_SSCEN, SYSCFG_COMBOPHY_CR1_SSCEN);
+	}
+
+	if (!of_property_read_u32(combophy->dev->of_node, "st,rx_equalizer", &val)) {
+		dev_dbg(combophy->dev, "Set RX equalizer %u\n", val);
+		if (val > SYSCFG_COMBOPHY_CR4_RX0_EQ) {
+			dev_err(combophy->dev, "Invalid value %u for rx0 equalizer\n", val);
+			return -EINVAL;
+		}
+
+		regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR4,
+			   SYSCFG_COMBOPHY_CR4_RX0_EQ, val);
+	}
+
+	if (combophy->type == PHY_TYPE_PCIE) {
+		ret = stm32_impedance_tune(combophy);
+		if (ret) {
+			reset_control_deassert(combophy->phy_reset);
+			goto out;
+		}
+
+		regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
+				   SYSCFG_COMBOPHY_CR1_REFUSEPAD,
+				   combophy->pad_clk ? SYSCFG_COMBOPHY_CR1_REFUSEPAD : 0);
+	}
+
+	switch (clk_rate) {
+	case 100000000:
+		pllmult = MPLLMULT_100;
+		refclksel = REFCLKSEL_0;
+		propcntrl = 0x8u << 4;
+		break;
+	case 19200000:
+		pllmult = MPLLMULT_19_2;
+		refclksel = REFCLKSEL_1;
+		propcntrl = 0x8u << 4;
+		break;
+	case 25000000:
+		pllmult = MPLLMULT_25;
+		refclksel = REFCLKSEL_0;
+		propcntrl = 0xEu << 4;
+		break;
+	case 24000000:
+		pllmult = MPLLMULT_24;
+		refclksel = REFCLKSEL_1;
+		propcntrl = 0xEu << 4;
+		break;
+	case 20000000:
+		pllmult = MPLLMULT_20;
+		refclksel = REFCLKSEL_0;
+		propcntrl = 0xEu << 4;
+		break;
+	default:
+		dev_err(combophy->dev, "Invalid rate 0x%x\n", clk_rate);
+		reset_control_deassert(combophy->phy_reset);
+		ret = -EINVAL;
+		goto out;
+	};
+
+	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
+			   SYSCFG_COMBOPHY_CR1_REFCLKDIV2, REFCLDIV_0);
+	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
+			   SYSCFG_COMBOPHY_CR1_REFCLKSEL, refclksel);
+	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
+			   SYSCFG_COMBOPHY_CR1_MPLLMULT, pllmult);
+
+	/*
+	 * Force elasticity buffer to be tuned for the reference clock as
+	 * the separated clock model is not supported
+	 */
+	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR5,
+			   SYSCFG_COMBOPHY_CR5_COMMON_CLOCKS, SYSCFG_COMBOPHY_CR5_COMMON_CLOCKS);
+
+	reset_control_deassert(combophy->phy_reset);
+
+	ret = regmap_read_poll_timeout(combophy->regmap, SYSCFG_COMBOPHY_SR, val,
+				       !(val & STM32MP25_PIPE0_PHYSTATUS),
+				       10, 1000);
+	if (ret) {
+		dev_err(combophy->dev, "timeout, cannot lock PLL\n");
+		goto out;
+	}
+
+	if (combophy->type == PHY_TYPE_PCIE) {
+		val = readl_relaxed(combophy->base + COMBOPHY_SUP_ANA_MPLL_LOOP_CTL);
+		val &= ~COMBOPHY_PROP_CNTRL;
+		val |= propcntrl;
+		writel_relaxed(val, combophy->base + COMBOPHY_SUP_ANA_MPLL_LOOP_CTL);
+	}
+
+	return 0;
+
+out:
+	if (combophy->type == PHY_TYPE_PCIE && !combophy->pad_clk)
+		regmap_update_bits(combophy->regmap, SYSCFG_PCIEPRGCR,
+				   STM32MP25_PCIEPRGCR_EN, 0);
+
+	if (combophy->type != PHY_TYPE_PCIE)
+		regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
+				   SYSCFG_COMBOPHY_CR1_REFSSPEN, 0);
+
+	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR2,
+			   SYSCFG_COMBOPHY_CR2_ISO_DIS, 0);
+
+	return ret;
+}
+
+static struct phy *stm32_combophy_xlate(struct device *dev,
+					const struct of_phandle_args *args)
+{
+	struct stm32_combophy *combophy = dev_get_drvdata(dev);
+	unsigned int type;
+
+	if (args->args_count != 1) {
+		dev_err(dev, "invalid number of cells in 'phy' property\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	type = args->args[0];
+	if (type != PHY_TYPE_USB3 && type != PHY_TYPE_PCIE) {
+		dev_err(dev, "unsupported device type: %d\n", type);
+		return ERR_PTR(-EINVAL);
+	}
+
+	if (combophy->pad_clk && type != PHY_TYPE_PCIE) {
+		dev_err(dev, "Invalid use of clk_pad for USB3 mode\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	combophy->type = type;
+
+	return combophy->phy;
+}
+
+static int stm32_combophy_set_mode(struct stm32_combophy *combophy)
+{
+	int type = combophy->type;
+	u32 val;
+
+	switch (type) {
+	case PHY_TYPE_PCIE:
+		dev_dbg(combophy->dev, "setting PCIe ComboPHY\n");
+		val = COMBOPHY_MODESEL_PCIE;
+		break;
+	case PHY_TYPE_USB3:
+		dev_dbg(combophy->dev, "setting USB3 ComboPHY\n");
+		val = COMBOPHY_MODESEL_USB;
+		break;
+	default:
+		dev_err(combophy->dev, "Invalid PHY mode %d\n", type);
+		return -EINVAL;
+	}
+
+	return regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR2,
+				  SYSCFG_COMBOPHY_CR2_MODESEL, val);
+}
+
+static int stm32_combophy_enable_clocks(struct stm32_combophy *combophy)
+{
+	int ret;
+
+	ret = clk_prepare_enable(combophy->phy_clk);
+	if (ret) {
+		dev_err(combophy->dev, "Core clock enable failed %d\n", ret);
+		return ret;
+	}
+
+	ret = clk_prepare_enable(combophy->ker_clk);
+	if (ret) {
+		dev_err(combophy->dev, "ker_usb3pcie clock enable failed %d\n", ret);
+		clk_disable_unprepare(combophy->phy_clk);
+		return ret;
+	}
+
+	if (combophy->pad_clk) {
+		ret = clk_prepare_enable(combophy->pad_clk);
+		if (ret) {
+			dev_err(combophy->dev, "External clock enable failed %d\n", ret);
+			clk_disable_unprepare(combophy->ker_clk);
+			clk_disable_unprepare(combophy->phy_clk);
+			return ret;
+		}
+	}
+
+	return 0;
+}
+
+static void stm32_combophy_disable_clocks(struct stm32_combophy *combophy)
+{
+	if (combophy->pad_clk)
+		clk_disable_unprepare(combophy->pad_clk);
+	clk_disable_unprepare(combophy->ker_clk);
+	clk_disable_unprepare(combophy->phy_clk);
+}
+
+static int stm32_combophy_suspend_noirq(struct device *dev)
+{
+	struct stm32_combophy *combophy = dev_get_drvdata(dev);
+
+	/*
+	 * Clocks should be turned off since it is not needed for
+	 * wakeup capability. In case usb-remote wakeup is not enabled,
+	 * combo-phy is already turned off by HCD driver using exit callback
+	 */
+	if (combophy->is_init) {
+		stm32_combophy_disable_clocks(combophy);
+
+		/* since wakeup is enabled for ctrl */
+		enable_irq_wake(combophy->irq_wakeup);
+	}
+
+	return 0;
+}
+
+static int stm32_combophy_resume_noirq(struct device *dev)
+{
+	struct stm32_combophy *combophy = dev_get_drvdata(dev);
+	int ret;
+
+	/*
+	 * If clocks was turned off by suspend call for wakeup then needs
+	 * to be turned back ON in resume. In case usb-remote wakeup is not
+	 * enabled, clocks already turned ON by HCD driver using init callback
+	 */
+	if (combophy->is_init) {
+		/* since wakeup was enabled for ctrl */
+		disable_irq_wake(combophy->irq_wakeup);
+
+		ret = stm32_combophy_enable_clocks(combophy);
+		if (ret) {
+			dev_err(dev, "can't enable clocks (%d)\n", ret);
+			return ret;
+		}
+	}
+
+	return 0;
+}
+
+static int stm32_combophy_exit(struct phy *phy)
+{
+	struct stm32_combophy *combophy = phy_get_drvdata(phy);
+	struct device *dev = combophy->dev;
+
+	combophy->is_init = false;
+
+	if (combophy->type == PHY_TYPE_PCIE && !combophy->pad_clk)
+		regmap_update_bits(combophy->regmap, SYSCFG_PCIEPRGCR,
+				   STM32MP25_PCIEPRGCR_EN, 0);
+
+	if (combophy->type != PHY_TYPE_PCIE)
+		regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
+				   SYSCFG_COMBOPHY_CR1_REFSSPEN, 0);
+
+	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR2,
+			   SYSCFG_COMBOPHY_CR2_ISO_DIS, 0);
+
+	stm32_combophy_disable_clocks(combophy);
+
+	pm_runtime_put_noidle(dev);
+
+	return 0;
+}
+
+static int stm32_combophy_init(struct phy *phy)
+{
+	struct stm32_combophy *combophy = phy_get_drvdata(phy);
+	struct device *dev = combophy->dev;
+	int ret;
+
+	pm_runtime_get_noresume(dev);
+
+	ret = stm32_combophy_enable_clocks(combophy);
+	if (ret) {
+		dev_err(dev, "Clock enable failed %d\n", ret);
+		pm_runtime_put_noidle(dev);
+		return ret;
+	}
+
+	ret = stm32_combophy_set_mode(combophy);
+	if (ret) {
+		dev_err(dev, "combophy mode not set\n");
+		stm32_combophy_disable_clocks(combophy);
+		pm_runtime_put_noidle(dev);
+		return ret;
+	}
+
+	ret = stm32_combophy_pll_init(combophy);
+	if (ret) {
+		stm32_combophy_disable_clocks(combophy);
+		pm_runtime_put_noidle(dev);
+		return ret;
+	}
+
+	pm_runtime_disable(dev);
+	pm_runtime_set_active(dev);
+	pm_runtime_enable(dev);
+
+	combophy->is_init = true;
+
+	return ret;
+}
+
+static const struct phy_ops stm32_combophy_phy_data = {
+	.init = stm32_combophy_init,
+	.exit = stm32_combophy_exit,
+	.owner = THIS_MODULE
+};
+
+static irqreturn_t stm32_combophy_irq_wakeup_handler(int irq, void *dev_id)
+{
+	return IRQ_HANDLED;
+}
+
+static int stm32_combophy_probe(struct platform_device *pdev)
+{
+	struct stm32_combophy *combophy;
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct phy_provider *phy_provider;
+	int ret, irq;
+
+	combophy = devm_kzalloc(dev, sizeof(*combophy), GFP_KERNEL);
+	if (!combophy)
+		return -ENOMEM;
+
+	combophy->dev = dev;
+
+	dev_set_drvdata(dev, combophy);
+
+	combophy->base = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(combophy->base))
+		return PTR_ERR(combophy->base);
+
+	combophy->phy_clk = devm_clk_get(dev, "apb-clk");
+	if (IS_ERR(combophy->phy_clk))
+		return dev_err_probe(dev, PTR_ERR(combophy->phy_clk),
+				     "Failed to get PHY clock source\n");
+
+	combophy->ker_clk = devm_clk_get(dev, "ker-clk");
+	if (IS_ERR(combophy->ker_clk))
+		return dev_err_probe(dev, PTR_ERR(combophy->ker_clk),
+				     "Failed to get PHY internal clock source\n");
+
+	combophy->pad_clk = devm_clk_get_optional(dev, "pad-clk");
+	if (IS_ERR(combophy->pad_clk))
+		return dev_err_probe(dev, PTR_ERR(combophy->pad_clk),
+				     "Failed to get PHY external clock source\n");
+
+	combophy->phy_reset = devm_reset_control_get(dev, "phy-rst");
+	if (IS_ERR(combophy->phy_reset))
+		return dev_err_probe(dev, PTR_ERR(combophy->phy_reset),
+				     "Failed to get PHY reset\n");
+
+	combophy->regmap = syscon_regmap_lookup_by_phandle(np, "st,syscfg");
+	if (IS_ERR(combophy->regmap))
+		return dev_err_probe(dev, PTR_ERR(combophy->regmap),
+				     "No syscfg phandle specified\n");
+
+	combophy->phy = devm_phy_create(dev, NULL, &stm32_combophy_phy_data);
+	if (IS_ERR(combophy->phy))
+		return dev_err_probe(dev, PTR_ERR(combophy->phy),
+				     "failed to create PCIe/USB3 ComboPHY\n");
+
+	if (device_property_read_bool(dev, "wakeup-source")) {
+		irq = platform_get_irq(pdev, 0);
+		if (irq < 0)
+			return dev_err_probe(dev, irq, "failed to get IRQ\n");
+		combophy->irq_wakeup = irq;
+
+		ret = devm_request_threaded_irq(dev, combophy->irq_wakeup, NULL,
+						stm32_combophy_irq_wakeup_handler, IRQF_ONESHOT,
+						NULL, NULL);
+		if (ret)
+			return dev_err_probe(dev, ret, "unable to request wake IRQ %d\n",
+						 combophy->irq_wakeup);
+	}
+
+	ret = devm_pm_runtime_enable(dev);
+	if (ret)
+		return dev_err_probe(dev, ret, "Failed to enable pm runtime\n");
+
+	phy_set_drvdata(combophy->phy, combophy);
+
+	phy_provider = devm_of_phy_provider_register(dev, stm32_combophy_xlate);
+
+	return PTR_ERR_OR_ZERO(phy_provider);
+}
+
+static const struct dev_pm_ops stm32_combophy_pm_ops = {
+	NOIRQ_SYSTEM_SLEEP_PM_OPS(stm32_combophy_suspend_noirq,
+				  stm32_combophy_resume_noirq)
+};
+
+static const struct of_device_id stm32_combophy_of_match[] = {
+	{ .compatible = "st,stm32mp25-combophy", },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, stm32_combophy_of_match);
+
+static struct platform_driver stm32_combophy_driver = {
+	.probe = stm32_combophy_probe,
+	.driver = {
+		   .name = "stm32-combophy",
+		   .of_match_table = stm32_combophy_of_match,
+		   .pm = pm_sleep_ptr(&stm32_combophy_pm_ops)
+	}
+};
+
+module_platform_driver(stm32_combophy_driver);
+
+MODULE_AUTHOR("Christian Bruel <christian.bruel at foss.st.com>");
+MODULE_DESCRIPTION("STM32MP25 Combophy USB3/PCIe controller driver");
+MODULE_LICENSE("GPL");
-- 
2.34.1



From christian.bruel at foss.st.com  Mon Aug 12 05:05:29 2024
From: christian.bruel at foss.st.com (Christian Bruel)
Date: Mon, 12 Aug 2024 14:05:29 +0200
Subject: [PATCH 5/5] arm64: dts: st: Enable COMBOPHY on the stm32mp257f-ev1 board
In-Reply-To: <20240812120529.3564390-1-christian.bruel@foss.st.com>
References: <20240812120529.3564390-1-christian.bruel@foss.st.com>
Message-ID: <20240812120529.3564390-6-christian.bruel@foss.st.com>

Enable the COMBOPHY with external pad clock on stm32mp257f-ev1
board, to be used for the PCIe clock provider.

Signed-off-by: Christian Bruel <christian.bruel at foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp257f-ev1.dts | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts b/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
index 214191a8322b8..b296ef1b018a3 100644
--- a/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
+++ b/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
@@ -27,6 +27,14 @@ chosen {
 		stdout-path = "serial0:115200n8";
 	};
 
+	clocks {
+		pad_clk: pad-clk {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <100000000>;
+		};
+	};
+
 	memory at 80000000 {
 		device_type = "memory";
 		reg = <0x0 0x80000000 0x1 0x0>;
@@ -50,6 +58,12 @@ &arm_wdt {
 	status = "okay";
 };
 
+&combophy {
+	clocks = <&rcc CK_BUS_USB3PCIEPHY>, <&rcc CK_KER_USB3PCIEPHY>, <&pad_clk>;
+	clock-names = "apb-clk", "ker-clk", "pad-clk";
+	status = "okay";
+};
+
 &ethernet2 {
 	pinctrl-names = "default", "sleep";
 	pinctrl-0 = <&eth2_rgmii_pins_a>;
-- 
2.34.1



From robh at kernel.org  Mon Aug 12 06:34:12 2024
From: robh at kernel.org (Rob Herring (Arm))
Date: Mon, 12 Aug 2024 07:34:12 -0600
Subject: [PATCH 2/5] dt-bindings: phy: Add STM32MP25 COMBOPHY bindings
In-Reply-To: <20240812120529.3564390-3-christian.bruel@foss.st.com>
References: <20240812120529.3564390-1-christian.bruel@foss.st.com>
 <20240812120529.3564390-3-christian.bruel@foss.st.com>
Message-ID: <172346965242.493337.13574697496053856.robh@kernel.org>


On Mon, 12 Aug 2024 14:05:26 +0200, Christian Bruel wrote:
> Document the bindings for STM32 COMBOPHY interface, used to support
> the PCIe and USB3 stm32mp25 drivers.
> Following entries can be used to tune caracterisation parameters
>  - st,output-micro-ohms and st,output-vswing-microvolt bindings entries
> to tune the impedance and voltage swing using discrete simulation results
>  - st, phy_rx0_eq register to set the internal rx equalizer filter value.
> 
> Signed-off-by: Christian Bruel <christian.bruel at foss.st.com>
> ---
>  .../bindings/phy/st,stm32-combophy.yaml       | 178 ++++++++++++++++++
>  1 file changed, 178 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml: access-controllers: missing type definition

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240812120529.3564390-3-christian.bruel at foss.st.com

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.



From mgonzalez at freebox.fr  Mon Aug 12 06:56:17 2024
From: mgonzalez at freebox.fr (Marc Gonzalez)
Date: Mon, 12 Aug 2024 15:56:17 +0200
Subject: [PATCH v7 0/6] HDMI TX support in msm8998
In-Reply-To: <20240724-hdmi-tx-v7-0-e44a20553464@freebox.fr>
References: <20240724-hdmi-tx-v7-0-e44a20553464@freebox.fr>
Message-ID: <0b2279f3-1591-4297-aae3-2b3b915b4a2b@freebox.fr>

Hello Rob, Abhinav, Dmitry,

This series might be ready this time?
Are all the patches supposed to go through
https://gitlab.freedesktop.org/drm/msm.git ?

(Probably not... patches 5 & 6 are probably
supposed to go through Bjorn's tree?)

Regards


On 24/07/2024 17:01, Marc Gonzalez wrote:

> DT bits required for HDMI TX support in qcom APQ8098 (MSM8998 cousin)
> 
> ---
> Changes in v7:
> - prefix the labels hdmi: and hdmi_phy: with mdss_ (Konrad)
> - DID NOT MODIFY patch 3, based on conversation between Conor & Dmitry
> - tested 40+40 boots with/without maxcpus=1 => no iommu panic witnessed
> - Collect tags from Konrad & Dmitry (hopefully b4 did the right thing)
> - Link to v6: https://lore.kernel.org/r/20240715-hdmi-tx-v6-0-d27f029627ad at freebox.fr
> 
> Changes in v6:
> - Fold HDMI PHY driver submission into this series
>   => [PATCH v2] drm/msm: add msm8998 hdmi phy/pll support
>   => Link to v2: https://lore.kernel.org/all/20240704-hdmi-phy-v2-1-a7f5af202cb5 at freebox.fr/
>      - Rebase onto v6.10
>      - Move drivers/gpu/drm/msm/hdmi/hdmi.xml.h to drivers/gpu/drm/msm/registers/display/hdmi.xml
>      - Add copyright attribution
>      - Remove all dead/debug/temporary code
>   => Link to v1: https://lore.kernel.org/all/63337d63-67ef-4499-8a24-5f6e9285c36b at freebox.fr/
> - split HDMI PHY driver patch in 2 parts (PHY & TX)
> - Use same regulator names as msm8996 (Dmitry)
> - Remove printk statements
> - Add Vinod's Ack on patch 1
> - Expand commit message on patch 4 = HDMI PHY driver
> - Link to v5: https://lore.kernel.org/r/20240627-hdmi-tx-v5-0-355d5c1fbc3c at freebox.fr
> 
> Changes in v5:
> - Fix property & property-names for TX pinctrl in DTSI (Konrad)
> - NOT CHANGED: clock trees for TX & PHY based on Dmitry & Jeffrey's remarks
> - Link to v4: https://lore.kernel.org/r/20240613-hdmi-tx-v4-0-4af17e468699 at freebox.fr
> 
> Changes in v4:
> - Collect tags since v3
> - Reword patch 1 subject (Vinod)
> - Link to v3: https://lore.kernel.org/r/20240606-hdmi-tx-v3-0-9d7feb6d3647 at freebox.fr
> 
> Changes in v3
> - Address Rob's comments on patch 2:
>   - 'maxItems: 5' for clocks in the 8996 if/then schema
>   - match the order of 8996 for the clock-names in common
> 
> ---
> Arnaud Vrac (2):
>       drm/msm: add msm8998 hdmi phy/pll support
>       arm64: dts: qcom: add HDMI nodes for msm8998
> 
> Marc Gonzalez (4):
>       dt-bindings: phy: add qcom,hdmi-phy-8998
>       dt-bindings: display/msm: hdmi: add qcom,hdmi-tx-8998
>       drm/msm/hdmi: add "qcom,hdmi-tx-8998" compatible
>       arm64: dts: qcom: msm8998: add HDMI GPIOs
> 
>  .../devicetree/bindings/display/msm/hdmi.yaml      |  28 +-
>  .../devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml |   1 +
>  arch/arm64/boot/dts/qcom/msm8998.dtsi              | 128 +++-
>  drivers/gpu/drm/msm/Makefile                       |   1 +
>  drivers/gpu/drm/msm/hdmi/hdmi.c                    |   1 +
>  drivers/gpu/drm/msm/hdmi/hdmi.h                    |   8 +
>  drivers/gpu/drm/msm/hdmi/hdmi_phy.c                |   5 +
>  drivers/gpu/drm/msm/hdmi/hdmi_phy_8998.c           | 779 +++++++++++++++++++++
>  drivers/gpu/drm/msm/registers/display/hdmi.xml     |  89 +++
>  9 files changed, 1037 insertions(+), 3 deletions(-)
> ---
> base-commit: 003a26f5074bfe024603cf76f8fd486a5344f307
> change-id: 20240606-hdmi-tx-00ee8e7ddbac




From jan.kiszka at siemens.com  Mon Aug 12 07:15:51 2024
From: jan.kiszka at siemens.com (Jan Kiszka)
Date: Mon, 12 Aug 2024 16:15:51 +0200
Subject: [PATCH v2 1/3] dt-bindings: phy: jh7110-usb-phy: Add sys-syscon property
In-Reply-To: <cover.1723472153.git.jan.kiszka@siemens.com>
References: <cover.1723472153.git.jan.kiszka@siemens.com>
Message-ID: <30f3ca9f6bd788e16767b36aa22c0e9dc4d1c6a4.1723472153.git.jan.kiszka@siemens.com>

From: Jan Kiszka <jan.kiszka at siemens.com>

Analogously to the PCI PHY, access to sys_syscon is needed to connect
the USB PHY to its controller.

Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com>
Reviewed-by: Rob Herring (Arm) <robh at kernel.org>
---
CC: Rob Herring <robh at kernel.org>
CC: Krzysztof Kozlowski <krzk+dt at kernel.org>
CC: Conor Dooley <conor+dt at kernel.org>
---
 .../bindings/phy/starfive,jh7110-usb-phy.yaml         | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yaml b/Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yaml
index 269e9f9f12b6..eaf0050c6f17 100644
--- a/Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yaml
@@ -19,6 +19,16 @@ properties:
   "#phy-cells":
     const: 0
 
+  starfive,sys-syscon:
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+    items:
+      - items:
+          - description: phandle to System Register Controller sys_syscon node.
+          - description: PHY connect offset of SYS_SYSCONSAIF__SYSCFG register for USB PHY.
+    description:
+      The phandle to System Register Controller syscon node and the PHY connect offset
+      of SYS_SYSCONSAIF__SYSCFG register. Connect PHY to USB controller.
+
   clocks:
     items:
       - description: PHY 125m
@@ -47,4 +57,5 @@ examples:
                  <&stgcrg 6>;
         clock-names = "125m", "app_125m";
         #phy-cells = <0>;
+        starfive,sys-syscon = <&sys_syscon 0x18>;
     };
-- 
2.43.0



From jan.kiszka at siemens.com  Mon Aug 12 07:15:53 2024
From: jan.kiszka at siemens.com (Jan Kiszka)
Date: Mon, 12 Aug 2024 16:15:53 +0200
Subject: [PATCH v2 3/3] phy: starfive: jh7110-usb: Fix link configuration to controller
In-Reply-To: <cover.1723472153.git.jan.kiszka@siemens.com>
References: <cover.1723472153.git.jan.kiszka@siemens.com>
Message-ID: <3ddd11484ffe22eee3459e1156cb4ee905cb45f6.1723472153.git.jan.kiszka@siemens.com>

From: Jan Kiszka <jan.kiszka at siemens.com>

In order to connect the USB 2.0 PHY to its controller, we also need to
set "u0_pdrstn_split_sw_usbpipe_plugen" [1]. Some downstream U-Boot
versions did that, but upstream firmware does not, and the kernel must
not rely on such behavior anyway. Failing to set this left the USB
gadget port invisible to connected hosts behind.

Link: https://doc-en.rvspace.org/JH7110/TRM/JH7110_TRM/sys_syscon.html#sys_syscon__section_b3l_fqs_wsb [1]
Fixes: 16d3a71c20cf ("phy: starfive: Add JH7110 USB 2.0 PHY driver")
Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com>
Reviewed-by: Minda Chen <minda.chen at starfivetech.com>
---
 drivers/phy/starfive/phy-jh7110-usb.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/drivers/phy/starfive/phy-jh7110-usb.c b/drivers/phy/starfive/phy-jh7110-usb.c
index 633912f8a05d..89451e740f77 100644
--- a/drivers/phy/starfive/phy-jh7110-usb.c
+++ b/drivers/phy/starfive/phy-jh7110-usb.c
@@ -10,18 +10,24 @@
 #include <linux/clk.h>
 #include <linux/err.h>
 #include <linux/io.h>
+#include <linux/mfd/syscon.h>
 #include <linux/module.h>
 #include <linux/phy/phy.h>
 #include <linux/platform_device.h>
+#include <linux/regmap.h>
 #include <linux/usb/of.h>
 
 #define USB_125M_CLK_RATE		125000000
 #define USB_LS_KEEPALIVE_OFF		0x4
 #define USB_LS_KEEPALIVE_ENABLE		BIT(4)
 
+#define USB_PDRSTN_SPLIT		BIT(17)
+
 struct jh7110_usb2_phy {
 	struct phy *phy;
 	void __iomem *regs;
+	struct regmap *sys_syscon;
+	u32 sys_phy_connect;
 	struct clk *usb_125m_clk;
 	struct clk *app_125m;
 	enum phy_mode mode;
@@ -61,6 +67,10 @@ static int usb2_phy_set_mode(struct phy *_phy,
 		usb2_set_ls_keepalive(phy, (mode != PHY_MODE_USB_DEVICE));
 	}
 
+	/* Connect usb 2.0 phy mode */
+	regmap_update_bits(phy->sys_syscon, phy->sys_phy_connect,
+			   USB_PDRSTN_SPLIT, USB_PDRSTN_SPLIT);
+
 	return 0;
 }
 
@@ -101,6 +111,7 @@ static int jh7110_usb_phy_probe(struct platform_device *pdev)
 	struct jh7110_usb2_phy *phy;
 	struct device *dev = &pdev->dev;
 	struct phy_provider *phy_provider;
+	u32 args[1];
 
 	phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
 	if (!phy)
@@ -129,6 +140,15 @@ static int jh7110_usb_phy_probe(struct platform_device *pdev)
 	phy_set_drvdata(phy->phy, phy);
 	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
 
+	phy->sys_syscon =
+		syscon_regmap_lookup_by_phandle_args(pdev->dev.of_node,
+						     "starfive,sys-syscon",
+						     1, args);
+	if (IS_ERR(phy->sys_syscon))
+		return dev_err_probe(dev, PTR_ERR(phy->sys_syscon),
+			"Failed to get sys-syscon\n");
+	phy->sys_phy_connect = args[0];
+
 	return PTR_ERR_OR_ZERO(phy_provider);
 }
 
-- 
2.43.0



From jan.kiszka at siemens.com  Mon Aug 12 07:15:50 2024
From: jan.kiszka at siemens.com (Jan Kiszka)
Date: Mon, 12 Aug 2024 16:15:50 +0200
Subject: [PATCH v2 0/3] riscv: jh7110: Fix configuration for on-chip USB 2.0 support
Message-ID: <cover.1723472153.git.jan.kiszka@siemens.com>

While mainline has support for the USB controller of the JH7110 since 6.5,
this never really worked, even not with latest downstream kernels by Starfive -
unless you were also using an old downstream U-Boot version. The reason for
that was a missing syscon setting that prevented the connection between USB
2.0 PHY and the controller. This series finally fixes the issue.

Changes in v2:
 - fix copy&paste mistake in error patch found by kernel test robot and Dan Carpenter

Jan

CC: Conor Dooley <conor+dt at kernel.org>
CC: Emil Renner Berthing <kernel at esmil.dk>
CC: Krzysztof Kozlowski <krzk+dt at kernel.org>
CC: Rob Herring <robh at kernel.org>

Jan Kiszka (3):
  dt-bindings: phy: jh7110-usb-phy: Add sys-syscon property
  riscv: dts: starfive: jh7110: Add sys-syscon property to usbphy0
  phy: starfive: jh7110-usb: Fix link configuration to controller

 .../bindings/phy/starfive,jh7110-usb-phy.yaml | 11 ++++++++++
 arch/riscv/boot/dts/starfive/jh7110.dtsi      |  1 +
 drivers/phy/starfive/phy-jh7110-usb.c         | 20 +++++++++++++++++++
 3 files changed, 32 insertions(+)

-- 
2.43.0



From jan.kiszka at siemens.com  Mon Aug 12 07:15:52 2024
From: jan.kiszka at siemens.com (Jan Kiszka)
Date: Mon, 12 Aug 2024 16:15:52 +0200
Subject: [PATCH v2 2/3] riscv: dts: starfive: jh7110: Add sys-syscon property to usbphy0
In-Reply-To: <cover.1723472153.git.jan.kiszka@siemens.com>
References: <cover.1723472153.git.jan.kiszka@siemens.com>
Message-ID: <699fd0f6b7271fa757d915516fed4df078fad5f7.1723472153.git.jan.kiszka@siemens.com>

From: Jan Kiszka <jan.kiszka at siemens.com>

Allows the PHY to connect to its USB controller.

Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com>
---
CC: Rob Herring <robh at kernel.org>
CC: Krzysztof Kozlowski <krzk+dt at kernel.org>
CC: Conor Dooley <conor+dt at kernel.org>
---
 arch/riscv/boot/dts/starfive/jh7110.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/riscv/boot/dts/starfive/jh7110.dtsi b/arch/riscv/boot/dts/starfive/jh7110.dtsi
index 0d8339357bad..0c0b66a69065 100644
--- a/arch/riscv/boot/dts/starfive/jh7110.dtsi
+++ b/arch/riscv/boot/dts/starfive/jh7110.dtsi
@@ -606,6 +606,7 @@ usbphy0: phy at 10200000 {
 				 <&stgcrg JH7110_STGCLK_USB0_APP_125>;
 			clock-names = "125m", "app_125m";
 			#phy-cells = <0>;
+			starfive,sys-syscon = <&sys_syscon 0x18>;
 		};
 
 		pciephy0: phy at 10210000 {
-- 
2.43.0



From robh at kernel.org  Mon Aug 12 08:20:48 2024
From: robh at kernel.org (Rob Herring)
Date: Mon, 12 Aug 2024 09:20:48 -0600
Subject: [PATCH 2/5] dt-bindings: phy: Add STM32MP25 COMBOPHY bindings
In-Reply-To: <172346965242.493337.13574697496053856.robh@kernel.org>
References: <20240812120529.3564390-1-christian.bruel@foss.st.com>
 <20240812120529.3564390-3-christian.bruel@foss.st.com>
 <172346965242.493337.13574697496053856.robh@kernel.org>
Message-ID: <20240812152048.GA593866-robh@kernel.org>

On Mon, Aug 12, 2024 at 07:34:12AM -0600, Rob Herring (Arm) wrote:
> 
> On Mon, 12 Aug 2024 14:05:26 +0200, Christian Bruel wrote:
> > Document the bindings for STM32 COMBOPHY interface, used to support
> > the PCIe and USB3 stm32mp25 drivers.
> > Following entries can be used to tune caracterisation parameters
> >  - st,output-micro-ohms and st,output-vswing-microvolt bindings entries
> > to tune the impedance and voltage swing using discrete simulation results
> >  - st, phy_rx0_eq register to set the internal rx equalizer filter value.
> > 
> > Signed-off-by: Christian Bruel <christian.bruel at foss.st.com>
> > ---
> >  .../bindings/phy/st,stm32-combophy.yaml       | 178 ++++++++++++++++++
> >  1 file changed, 178 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml
> > 
> 
> My bot found errors running 'make dt_binding_check' on your patch:
> 
> yamllint warnings/errors:
> 
> dtschema/dtc warnings/errors:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml: access-controllers: missing type definition

Ignore this. It's a problem with the build.

Rob


From robh at kernel.org  Mon Aug 12 08:46:33 2024
From: robh at kernel.org (Rob Herring)
Date: Mon, 12 Aug 2024 09:46:33 -0600
Subject: [PATCH 2/5] dt-bindings: phy: Add STM32MP25 COMBOPHY bindings
In-Reply-To: <20240812120529.3564390-3-christian.bruel@foss.st.com>
References: <20240812120529.3564390-1-christian.bruel@foss.st.com>
 <20240812120529.3564390-3-christian.bruel@foss.st.com>
Message-ID: <20240812154633.GB593866-robh@kernel.org>

On Mon, Aug 12, 2024 at 02:05:26PM +0200, Christian Bruel wrote:
> Document the bindings for STM32 COMBOPHY interface, used to support
> the PCIe and USB3 stm32mp25 drivers.
> Following entries can be used to tune caracterisation parameters
>  - st,output-micro-ohms and st,output-vswing-microvolt bindings entries
> to tune the impedance and voltage swing using discrete simulation results
>  - st, phy_rx0_eq register to set the internal rx equalizer filter value.
> 
> Signed-off-by: Christian Bruel <christian.bruel at foss.st.com>
> ---
>  .../bindings/phy/st,stm32-combophy.yaml       | 178 ++++++++++++++++++
>  1 file changed, 178 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml
> 
> diff --git a/Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml b/Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml
> new file mode 100644
> index 0000000000000..6a53ab834b2a7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml
> @@ -0,0 +1,178 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/st,stm32-combophy.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: STMicroelectronics STM32MP25 USB3/PCIe COMBOPHY
> +
> +maintainers:
> +  - Christian Bruel <christian.bruel at foss.st.com>
> +
> +description: |

Don't need '|' if no formatting to preserve.

> +  Single lane PHY shared (exclusive) between the USB3 and PCIe controllers.
> +  Supports 5Gbit/s for USB3 and PCIe gen2 or 2.5Gbit/s for PCIe gen1.
> +
> +properties:
> +  compatible:
> +    const: st,stm32mp25-combophy
> +
> +  reg:
> +    maxItems: 1
> +
> +  st,syscfg:

Order is standard properties first, vendor properties second. 

> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> +    description: Phandle to the SYSCON entry required for configuring PCIe
> +      or USB3.

You need constraints on the size of the phandle-array or perhaps this 
should be just 'phandle'.

> +
> +  "#phy-cells":
> +    const: 1
> +    description: |
> +      The cells contain the following arguments.
> +
> +      - description: The PHY type
> +          enum:
> +            - PHY_TYPE_USB3
> +            - PHY_TYPE_PCIE
> +
> +  clocks:
> +    anyOf:

Should be 'items'

> +      - description: apb-clk Bus clock mandatory to access registers.
> +      - description: ker-clk Internal RCC reference clock for USB3 or PCIe
> +      - description: pad-clk Optional on board clock input for PCIe only. Typically an
> +                     external 100Mhz oscillator wired on dedicated CLKIN pad. Used as reference
> +                     clock input instead of the ker-clk
> +
> +  clock-names:
> +    oneOf:
> +      - items:
> +          - const: apb-clk
> +          - const: ker-clk
> +
> +      - items:
> +          - const: apb-clk
> +          - const: ker-clk
> +          - const: pad-clk

Don't need oneOf here. Just add 'minItems: 2' on the 2nd entry.

'-clk' is also redundant. Drop.

> +
> +  resets:
> +    maxItems: 1
> +
> +  reset-names:
> +    const: phy-rst
> +
> +  power-domains:
> +    maxItems: 1
> +
> +  st,ssc-on:
> +    type: boolean
> +    description:
> +      A boolean property whose presence indicates that the SSC for common clock
> +      needs to be set.
> +
> +  st,rx_equalizer:

s/_/-/

> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    minimum: 0

That's already the minimum. Drop.

> +    maximum: 7
> +    default: 2
> +    description:
> +      A 3 bit value describing internal filter settings for the RX equalizer.

How does one decide what value to use?

> +
> +  st,output-micro-ohms:
> +    minimum: 3999000
> +    maximum: 6090000
> +    default: 4968000
> +    description:
> +      A value property to tune the Single Ended Output Impedance, simulations results
> +      at 25C for a VDDP=0.8V. The hardware accepts discrete values in this range.
> +
> +  st,output-vswing-microvolt:
> +    minimum: 442000
> +    maximum: 803000
> +    default: 803000
> +    description:
> +      A value property in microvolt to tune the Single Ended Output Voltage Swing to change the
> +      Vlo, Vhi for a VDDP = 0.8V. The hardware accepts discrete values in this range.
> +
> +  wakeup-source: true
> +
> +  interrupts:
> +    maxItems: 1
> +    description: interrupt used for wakeup
> +
> +  access-controllers:
> +    minItems: 1
> +    maxItems: 2
> +
> +required:
> +  - compatible
> +  - reg
> +  - st,syscfg
> +  - '#phy-cells'
> +  - resets
> +  - reset-names
> +  - clocks
> +  - clock-names
> +
> +allOf:
> +  - if:
> +      required:
> +        - wakeup-source
> +    then:
> +      anyOf:
> +        - required: [interrupts]
> +        - required: [interrupts-extended]
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    // Example 1: COMBOPHY configured to use internal reference clock
> +    #include <dt-bindings/clock/st,stm32mp25-rcc.h>
> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> +    #include <dt-bindings/reset/st,stm32mp25-rcc.h>
> +
> +    combophy_internal: phy at 480c0000 {
> +        compatible = "st,stm32mp25-combophy";
> +        reg = <0x480c0000 0x1000>;
> +        #phy-cells = <1>;
> +        clocks = <&rcc CK_BUS_USB3PCIEPHY>, <&rcc CK_KER_USB3PCIEPHY>;
> +        clock-names = "apb-clk", "ker-clk";
> +        resets = <&rcc USB3PCIEPHY_R>;
> +        reset-names = "phy-rst";
> +        st,syscfg = <&syscfg>;
> +        access-controllers = <&rifsc 67>;
> +        power-domains = <&CLUSTER_PD>;
> +        wakeup-source;
> +        interrupts-extended = <&exti1 45 IRQ_TYPE_EDGE_FALLING>;
> +    };
> +
> +  - |
> +    // Example 2: COMBOPHY configured to use extrenal 100MHz reference clock
> +    // on CLKIN pad for PCIe
> +    #include <dt-bindings/clock/st,stm32mp25-rcc.h>
> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> +    #include <dt-bindings/reset/st,stm32mp25-rcc.h>
> +
> +    clocks {
> +        pad_clk: pad-clk {
> +            #clock-cells = <0>;
> +            compatible = "fixed-clock";
> +            clock-frequency = <100000000>;
> +        };
> +    };

Drop. Providers aren't relevant to this binding.

Though just 1 optional clock doesn't justify a whole other example. So 
drop one of the examples.

> +
> +    combophy_pad: phy at 480c0000 {
> +        compatible = "st,stm32mp25-combophy";
> +        reg = <0x480c0000 0x1000>;
> +        #phy-cells = <1>;
> +        clocks = <&rcc CK_BUS_USB3PCIEPHY>, <&rcc CK_KER_USB3PCIEPHY>, <&pad_clk>;
> +        clock-names = "apb-clk", "ker-clk", "pad-clk";
> +        resets = <&rcc USB3PCIEPHY_R>;
> +        reset-names = "phy-rst";
> +        st,syscfg = <&syscfg>;
> +        access-controllers = <&rifsc 67>;
> +        power-domains = <&CLUSTER_PD>;
> +        wakeup-source;
> +        interrupts-extended = <&exti1 45 IRQ_TYPE_EDGE_FALLING>;
> +    };
> +...
> -- 
> 2.34.1
> 


From conor at kernel.org  Mon Aug 12 08:55:38 2024
From: conor at kernel.org (Conor Dooley)
Date: Mon, 12 Aug 2024 16:55:38 +0100
Subject: [PATCH v2 1/3] dt-bindings: phy: jh7110-usb-phy: Add sys-syscon
 property
In-Reply-To: <30f3ca9f6bd788e16767b36aa22c0e9dc4d1c6a4.1723472153.git.jan.kiszka@siemens.com>
References: <cover.1723472153.git.jan.kiszka@siemens.com>
 <30f3ca9f6bd788e16767b36aa22c0e9dc4d1c6a4.1723472153.git.jan.kiszka@siemens.com>
Message-ID: <20240812-overstuff-skirt-7a8aabbcdc6f@spud>

On Mon, Aug 12, 2024 at 04:15:51PM +0200, Jan Kiszka wrote:
> From: Jan Kiszka <jan.kiszka at siemens.com>
> 
> Analogously to the PCI PHY, access to sys_syscon is needed to connect
> the USB PHY to its controller.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com>
> Reviewed-by: Rob Herring (Arm) <robh at kernel.org>
> ---
> CC: Rob Herring <robh at kernel.org>
> CC: Krzysztof Kozlowski <krzk+dt at kernel.org>
> CC: Conor Dooley <conor+dt at kernel.org>
> ---
>  .../bindings/phy/starfive,jh7110-usb-phy.yaml         | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yaml b/Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yaml
> index 269e9f9f12b6..eaf0050c6f17 100644
> --- a/Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yaml
> @@ -19,6 +19,16 @@ properties:
>    "#phy-cells":
>      const: 0
>  
> +  starfive,sys-syscon:
> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> +    items:
> +      - items:
> +          - description: phandle to System Register Controller sys_syscon node.
> +          - description: PHY connect offset of SYS_SYSCONSAIF__SYSCFG register for USB PHY.

Why is having a new property for this required? The devicetree only has
a single usb phy, so isn't it sufficient to look up the syscon by
compatible, rather than via phandle + offset?

> +    description:
> +      The phandle to System Register Controller syscon node and the PHY connect offset
> +      of SYS_SYSCONSAIF__SYSCFG register. Connect PHY to USB controller.
> +
>    clocks:
>      items:
>        - description: PHY 125m
> @@ -47,4 +57,5 @@ examples:
>                   <&stgcrg 6>;
>          clock-names = "125m", "app_125m";
>          #phy-cells = <0>;
> +        starfive,sys-syscon = <&sys_syscon 0x18>;
>      };
> -- 
> 2.43.0
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-phy/attachments/20240812/6146580e/attachment-0001.sig>

From lkp at intel.com  Mon Aug 12 13:14:06 2024
From: lkp at intel.com (kernel test robot)
Date: Tue, 13 Aug 2024 04:14:06 +0800
Subject: [PATCH 3/5] phy: stm32: Add support for STM32MP25 COMBOPHY.
In-Reply-To: <20240812120529.3564390-4-christian.bruel@foss.st.com>
References: <20240812120529.3564390-4-christian.bruel@foss.st.com>
Message-ID: <202408130307.IK7U1H7o-lkp@intel.com>

Hi Christian,

kernel test robot noticed the following build errors:

[auto build test ERROR on atorgue-stm32/stm32-next]
[also build test ERROR on robh/for-next linus/master v6.11-rc3 next-20240812]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Christian-Bruel/MAINTAINERS-add-entry-for-ST-STM32MP25-COMBOPHY-driver/20240812-201003
base:   https://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git stm32-next
patch link:    https://lore.kernel.org/r/20240812120529.3564390-4-christian.bruel%40foss.st.com
patch subject: [PATCH 3/5] phy: stm32: Add support for STM32MP25 COMBOPHY.
config: hexagon-allmodconfig (https://download.01.org/0day-ci/archive/20240813/202408130307.IK7U1H7o-lkp at intel.com/config)
compiler: clang version 20.0.0git (https://github.com/llvm/llvm-project f86594788ce93b696675c94f54016d27a6c21d18)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240813/202408130307.IK7U1H7o-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202408130307.IK7U1H7o-lkp at intel.com/

All errors (new ones prefixed by >>):

   In file included from drivers/phy/st/phy-stm32-combophy.c:12:
   In file included from include/linux/phy/phy.h:17:
   In file included from include/linux/regulator/consumer.h:35:
   In file included from include/linux/suspend.h:5:
   In file included from include/linux/swap.h:9:
   In file included from include/linux/memcontrol.h:13:
   In file included from include/linux/cgroup.h:26:
   In file included from include/linux/kernel_stat.h:9:
   In file included from include/linux/interrupt.h:11:
   In file included from include/linux/hardirq.h:11:
   In file included from ./arch/hexagon/include/generated/asm/hardirq.h:1:
   In file included from include/asm-generic/hardirq.h:17:
   In file included from include/linux/irq.h:20:
   In file included from include/linux/io.h:14:
   In file included from arch/hexagon/include/asm/io.h:328:
   include/asm-generic/io.h:548:31: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
     548 |         val = __raw_readb(PCI_IOBASE + addr);
         |                           ~~~~~~~~~~ ^
   include/asm-generic/io.h:561:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
     561 |         val = __le16_to_cpu((__le16 __force)__raw_readw(PCI_IOBASE + addr));
         |                                                         ~~~~~~~~~~ ^
   include/uapi/linux/byteorder/little_endian.h:37:51: note: expanded from macro '__le16_to_cpu'
      37 | #define __le16_to_cpu(x) ((__force __u16)(__le16)(x))
         |                                                   ^
   In file included from drivers/phy/st/phy-stm32-combophy.c:12:
   In file included from include/linux/phy/phy.h:17:
   In file included from include/linux/regulator/consumer.h:35:
   In file included from include/linux/suspend.h:5:
   In file included from include/linux/swap.h:9:
   In file included from include/linux/memcontrol.h:13:
   In file included from include/linux/cgroup.h:26:
   In file included from include/linux/kernel_stat.h:9:
   In file included from include/linux/interrupt.h:11:
   In file included from include/linux/hardirq.h:11:
   In file included from ./arch/hexagon/include/generated/asm/hardirq.h:1:
   In file included from include/asm-generic/hardirq.h:17:
   In file included from include/linux/irq.h:20:
   In file included from include/linux/io.h:14:
   In file included from arch/hexagon/include/asm/io.h:328:
   include/asm-generic/io.h:574:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
     574 |         val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr));
         |                                                         ~~~~~~~~~~ ^
   include/uapi/linux/byteorder/little_endian.h:35:51: note: expanded from macro '__le32_to_cpu'
      35 | #define __le32_to_cpu(x) ((__force __u32)(__le32)(x))
         |                                                   ^
   In file included from drivers/phy/st/phy-stm32-combophy.c:12:
   In file included from include/linux/phy/phy.h:17:
   In file included from include/linux/regulator/consumer.h:35:
   In file included from include/linux/suspend.h:5:
   In file included from include/linux/swap.h:9:
   In file included from include/linux/memcontrol.h:13:
   In file included from include/linux/cgroup.h:26:
   In file included from include/linux/kernel_stat.h:9:
   In file included from include/linux/interrupt.h:11:
   In file included from include/linux/hardirq.h:11:
   In file included from ./arch/hexagon/include/generated/asm/hardirq.h:1:
   In file included from include/asm-generic/hardirq.h:17:
   In file included from include/linux/irq.h:20:
   In file included from include/linux/io.h:14:
   In file included from arch/hexagon/include/asm/io.h:328:
   include/asm-generic/io.h:585:33: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
     585 |         __raw_writeb(value, PCI_IOBASE + addr);
         |                             ~~~~~~~~~~ ^
   include/asm-generic/io.h:595:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
     595 |         __raw_writew((u16 __force)cpu_to_le16(value), PCI_IOBASE + addr);
         |                                                       ~~~~~~~~~~ ^
   include/asm-generic/io.h:605:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
     605 |         __raw_writel((u32 __force)cpu_to_le32(value), PCI_IOBASE + addr);
         |                                                       ~~~~~~~~~~ ^
   In file included from drivers/phy/st/phy-stm32-combophy.c:12:
   In file included from include/linux/phy/phy.h:17:
   In file included from include/linux/regulator/consumer.h:35:
   In file included from include/linux/suspend.h:5:
   In file included from include/linux/swap.h:9:
   In file included from include/linux/memcontrol.h:21:
   In file included from include/linux/mm.h:2253:
   include/linux/vmstat.h:514:36: warning: arithmetic between different enumeration types ('enum node_stat_item' and 'enum lru_list') [-Wenum-enum-conversion]
     514 |         return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_"
         |                               ~~~~~~~~~~~ ^ ~~~
>> drivers/phy/st/phy-stm32-combophy.c:134:8: error: call to undeclared function 'FIELD_PREP'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
     134 |                                    FIELD_PREP(STM32MP25_PCIEPRG_IMPCTRL_OHM, imp_of));
         |                                    ^
>> drivers/phy/st/phy-stm32-combophy.c:137:12: error: call to undeclared function 'FIELD_GET'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
     137 |                 imp_of = FIELD_GET(STM32MP25_PCIEPRG_IMPCTRL_OHM, val);
         |                          ^
   drivers/phy/st/phy-stm32-combophy.c:155:8: error: call to undeclared function 'FIELD_PREP'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
     155 |                                    FIELD_PREP(STM32MP25_PCIEPRG_IMPCTRL_VSWING, vswing_of));
         |                                    ^
   7 warnings and 3 errors generated.


vim +/FIELD_PREP +134 drivers/phy/st/phy-stm32-combophy.c

   107	
   108	static int stm32_impedance_tune(struct stm32_combophy *combophy)
   109	{
   110		u8 imp_size = ARRAY_SIZE(imp_lookup);
   111		u8 vswing_size = ARRAY_SIZE(imp_lookup[0].vswing);
   112		u8 imp_of, vswing_of;
   113		u32 max_imp = imp_lookup[0].microohm;
   114		u32 min_imp = imp_lookup[imp_size - 1].microohm;
   115		u32 max_vswing = imp_lookup[imp_size - 1].vswing[vswing_size - 1];
   116		u32 min_vswing = imp_lookup[0].vswing[0];
   117		u32 val;
   118	
   119		if (!of_property_read_u32(combophy->dev->of_node, "st,output-micro-ohms", &val)) {
   120			if (val < min_imp || val > max_imp) {
   121				dev_err(combophy->dev, "Invalid value %u for output ohm\n", val);
   122				return -EINVAL;
   123			}
   124	
   125			for (imp_of = 0 ; imp_of < ARRAY_SIZE(imp_lookup); imp_of++)
   126				if (imp_lookup[imp_of].microohm <= val)
   127					break;
   128	
   129			dev_dbg(combophy->dev, "Set %u micro-ohms output impedance\n",
   130				imp_lookup[imp_of].microohm);
   131	
   132			regmap_update_bits(combophy->regmap, SYSCFG_PCIEPRGCR,
   133					   STM32MP25_PCIEPRG_IMPCTRL_OHM,
 > 134					   FIELD_PREP(STM32MP25_PCIEPRG_IMPCTRL_OHM, imp_of));
   135		} else {
   136			regmap_read(combophy->regmap, SYSCFG_PCIEPRGCR, &val);
 > 137			imp_of = FIELD_GET(STM32MP25_PCIEPRG_IMPCTRL_OHM, val);
   138		}
   139	
   140		if (!of_property_read_u32(combophy->dev->of_node, "st,output-vswing-microvolt", &val)) {
   141			if (val < min_vswing || val > max_vswing) {
   142				dev_err(combophy->dev, "Invalid value %u for output vswing\n", val);
   143				return -EINVAL;
   144			}
   145	
   146			for (vswing_of = 0 ; vswing_of < ARRAY_SIZE(imp_lookup[imp_of].vswing); vswing_of++)
   147				if (imp_lookup[imp_of].vswing[vswing_of] >= val)
   148					break;
   149	
   150			dev_dbg(combophy->dev, "Set %u microvolt swing\n",
   151				 imp_lookup[imp_of].vswing[vswing_of]);
   152	
   153			regmap_update_bits(combophy->regmap, SYSCFG_PCIEPRGCR,
   154					   STM32MP25_PCIEPRG_IMPCTRL_VSWING,
   155					   FIELD_PREP(STM32MP25_PCIEPRG_IMPCTRL_VSWING, vswing_of));
   156		}
   157	
   158		return 0;
   159	}
   160	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From lkp at intel.com  Mon Aug 12 13:24:27 2024
From: lkp at intel.com (kernel test robot)
Date: Tue, 13 Aug 2024 04:24:27 +0800
Subject: [PATCH 3/5] phy: stm32: Add support for STM32MP25 COMBOPHY.
In-Reply-To: <20240812120529.3564390-4-christian.bruel@foss.st.com>
References: <20240812120529.3564390-4-christian.bruel@foss.st.com>
Message-ID: <202408130447.IzvuJERR-lkp@intel.com>

Hi Christian,

kernel test robot noticed the following build errors:

[auto build test ERROR on atorgue-stm32/stm32-next]
[also build test ERROR on robh/for-next linus/master v6.11-rc3 next-20240812]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Christian-Bruel/MAINTAINERS-add-entry-for-ST-STM32MP25-COMBOPHY-driver/20240812-201003
base:   https://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git stm32-next
patch link:    https://lore.kernel.org/r/20240812120529.3564390-4-christian.bruel%40foss.st.com
patch subject: [PATCH 3/5] phy: stm32: Add support for STM32MP25 COMBOPHY.
config: arc-allyesconfig (https://download.01.org/0day-ci/archive/20240813/202408130447.IzvuJERR-lkp at intel.com/config)
compiler: arceb-elf-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240813/202408130447.IzvuJERR-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202408130447.IzvuJERR-lkp at intel.com/

All errors (new ones prefixed by >>):

   drivers/phy/st/phy-stm32-combophy.c: In function 'stm32_impedance_tune':
>> drivers/phy/st/phy-stm32-combophy.c:134:36: error: implicit declaration of function 'FIELD_PREP' [-Werror=implicit-function-declaration]
     134 |                                    FIELD_PREP(STM32MP25_PCIEPRG_IMPCTRL_OHM, imp_of));
         |                                    ^~~~~~~~~~
>> drivers/phy/st/phy-stm32-combophy.c:137:26: error: implicit declaration of function 'FIELD_GET' [-Werror=implicit-function-declaration]
     137 |                 imp_of = FIELD_GET(STM32MP25_PCIEPRG_IMPCTRL_OHM, val);
         |                          ^~~~~~~~~
   cc1: some warnings being treated as errors


vim +/FIELD_PREP +134 drivers/phy/st/phy-stm32-combophy.c

   107	
   108	static int stm32_impedance_tune(struct stm32_combophy *combophy)
   109	{
   110		u8 imp_size = ARRAY_SIZE(imp_lookup);
   111		u8 vswing_size = ARRAY_SIZE(imp_lookup[0].vswing);
   112		u8 imp_of, vswing_of;
   113		u32 max_imp = imp_lookup[0].microohm;
   114		u32 min_imp = imp_lookup[imp_size - 1].microohm;
   115		u32 max_vswing = imp_lookup[imp_size - 1].vswing[vswing_size - 1];
   116		u32 min_vswing = imp_lookup[0].vswing[0];
   117		u32 val;
   118	
   119		if (!of_property_read_u32(combophy->dev->of_node, "st,output-micro-ohms", &val)) {
   120			if (val < min_imp || val > max_imp) {
   121				dev_err(combophy->dev, "Invalid value %u for output ohm\n", val);
   122				return -EINVAL;
   123			}
   124	
   125			for (imp_of = 0 ; imp_of < ARRAY_SIZE(imp_lookup); imp_of++)
   126				if (imp_lookup[imp_of].microohm <= val)
   127					break;
   128	
   129			dev_dbg(combophy->dev, "Set %u micro-ohms output impedance\n",
   130				imp_lookup[imp_of].microohm);
   131	
   132			regmap_update_bits(combophy->regmap, SYSCFG_PCIEPRGCR,
   133					   STM32MP25_PCIEPRG_IMPCTRL_OHM,
 > 134					   FIELD_PREP(STM32MP25_PCIEPRG_IMPCTRL_OHM, imp_of));
   135		} else {
   136			regmap_read(combophy->regmap, SYSCFG_PCIEPRGCR, &val);
 > 137			imp_of = FIELD_GET(STM32MP25_PCIEPRG_IMPCTRL_OHM, val);
   138		}
   139	
   140		if (!of_property_read_u32(combophy->dev->of_node, "st,output-vswing-microvolt", &val)) {
   141			if (val < min_vswing || val > max_vswing) {
   142				dev_err(combophy->dev, "Invalid value %u for output vswing\n", val);
   143				return -EINVAL;
   144			}
   145	
   146			for (vswing_of = 0 ; vswing_of < ARRAY_SIZE(imp_lookup[imp_of].vswing); vswing_of++)
   147				if (imp_lookup[imp_of].vswing[vswing_of] >= val)
   148					break;
   149	
   150			dev_dbg(combophy->dev, "Set %u microvolt swing\n",
   151				 imp_lookup[imp_of].vswing[vswing_of]);
   152	
   153			regmap_update_bits(combophy->regmap, SYSCFG_PCIEPRGCR,
   154					   STM32MP25_PCIEPRG_IMPCTRL_VSWING,
   155					   FIELD_PREP(STM32MP25_PCIEPRG_IMPCTRL_VSWING, vswing_of));
   156		}
   157	
   158		return 0;
   159	}
   160	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From jan.kiszka at siemens.com  Mon Aug 12 22:31:50 2024
From: jan.kiszka at siemens.com (Jan Kiszka)
Date: Tue, 13 Aug 2024 07:31:50 +0200
Subject: [PATCH v2 1/3] dt-bindings: phy: jh7110-usb-phy: Add sys-syscon
 property
In-Reply-To: <20240812-overstuff-skirt-7a8aabbcdc6f@spud>
References: <cover.1723472153.git.jan.kiszka@siemens.com>
 <30f3ca9f6bd788e16767b36aa22c0e9dc4d1c6a4.1723472153.git.jan.kiszka@siemens.com>
 <20240812-overstuff-skirt-7a8aabbcdc6f@spud>
Message-ID: <8cdba8b0-7364-4c09-b18a-f3f59da1eae2@siemens.com>

On 12.08.24 17:55, Conor Dooley wrote:
> On Mon, Aug 12, 2024 at 04:15:51PM +0200, Jan Kiszka wrote:
>> From: Jan Kiszka <jan.kiszka at siemens.com>
>>
>> Analogously to the PCI PHY, access to sys_syscon is needed to connect
>> the USB PHY to its controller.
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com>
>> Reviewed-by: Rob Herring (Arm) <robh at kernel.org>
>> ---
>> CC: Rob Herring <robh at kernel.org>
>> CC: Krzysztof Kozlowski <krzk+dt at kernel.org>
>> CC: Conor Dooley <conor+dt at kernel.org>
>> ---
>>  .../bindings/phy/starfive,jh7110-usb-phy.yaml         | 11 +++++++++++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yaml b/Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yaml
>> index 269e9f9f12b6..eaf0050c6f17 100644
>> --- a/Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yaml
>> +++ b/Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yaml
>> @@ -19,6 +19,16 @@ properties:
>>    "#phy-cells":
>>      const: 0
>>  
>> +  starfive,sys-syscon:
>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>> +    items:
>> +      - items:
>> +          - description: phandle to System Register Controller sys_syscon node.
>> +          - description: PHY connect offset of SYS_SYSCONSAIF__SYSCFG register for USB PHY.
> 
> Why is having a new property for this required? The devicetree only has
> a single usb phy, so isn't it sufficient to look up the syscon by
> compatible, rather than via phandle + offset?
> 

I didn't design this, I just copied it from
starfive,jh7110-pcie-phy.yaml. As that already exists, I'm neither sure
we want to change that anymore nor deviate in the pattern here.

Jan

>> +    description:
>> +      The phandle to System Register Controller syscon node and the PHY connect offset
>> +      of SYS_SYSCONSAIF__SYSCFG register. Connect PHY to USB controller.
>> +
>>    clocks:
>>      items:
>>        - description: PHY 125m
>> @@ -47,4 +57,5 @@ examples:
>>                   <&stgcrg 6>;
>>          clock-names = "125m", "app_125m";
>>          #phy-cells = <0>;
>> +        starfive,sys-syscon = <&sys_syscon 0x18>;
>>      };
>> -- 
>> 2.43.0
>>

-- 
Siemens AG, Technology
Linux Expert Center



From conor.dooley at microchip.com  Tue Aug 13 01:04:17 2024
From: conor.dooley at microchip.com (Conor Dooley)
Date: Tue, 13 Aug 2024 09:04:17 +0100
Subject: [PATCH v2 1/3] dt-bindings: phy: jh7110-usb-phy: Add sys-syscon
 property
In-Reply-To: <8cdba8b0-7364-4c09-b18a-f3f59da1eae2@siemens.com>
References: <cover.1723472153.git.jan.kiszka@siemens.com>
 <30f3ca9f6bd788e16767b36aa22c0e9dc4d1c6a4.1723472153.git.jan.kiszka@siemens.com>
 <20240812-overstuff-skirt-7a8aabbcdc6f@spud>
 <8cdba8b0-7364-4c09-b18a-f3f59da1eae2@siemens.com>
Message-ID: <20240813-haiku-pusher-f2fb037a2f49@wendy>

On Tue, Aug 13, 2024 at 07:31:50AM +0200, Jan Kiszka wrote:
> On 12.08.24 17:55, Conor Dooley wrote:
> > On Mon, Aug 12, 2024 at 04:15:51PM +0200, Jan Kiszka wrote:
> >> From: Jan Kiszka <jan.kiszka at siemens.com>
> >>
> >> Analogously to the PCI PHY, access to sys_syscon is needed to connect
> >> the USB PHY to its controller.
> >>
> >> Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com>
> >> Reviewed-by: Rob Herring (Arm) <robh at kernel.org>
> >> ---
> >> CC: Rob Herring <robh at kernel.org>
> >> CC: Krzysztof Kozlowski <krzk+dt at kernel.org>
> >> CC: Conor Dooley <conor+dt at kernel.org>
> >> ---
> >>  .../bindings/phy/starfive,jh7110-usb-phy.yaml         | 11 +++++++++++
> >>  1 file changed, 11 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yaml b/Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yaml
> >> index 269e9f9f12b6..eaf0050c6f17 100644
> >> --- a/Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yaml
> >> +++ b/Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yaml
> >> @@ -19,6 +19,16 @@ properties:
> >>    "#phy-cells":
> >>      const: 0
> >>  
> >> +  starfive,sys-syscon:
> >> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> >> +    items:
> >> +      - items:
> >> +          - description: phandle to System Register Controller sys_syscon node.
> >> +          - description: PHY connect offset of SYS_SYSCONSAIF__SYSCFG register for USB PHY.
> > 
> > Why is having a new property for this required? The devicetree only has
> > a single usb phy, so isn't it sufficient to look up the syscon by
> > compatible, rather than via phandle + offset?
> > 
> 
> I didn't design this, I just copied it from
> starfive,jh7110-pcie-phy.yaml. As that already exists, I'm neither sure
> we want to change that anymore nor deviate in the pattern here.

To be honest, I think some of the other users of phandle + offset on
this soc were just copy-pasted without thinking about whether or not they
were required too. This one seems like it should just be a lookup by
compatible in the driver instead of by phandle. As a bonus, it will work
with existing devicetrees - whereas your current implementation will
fail to probe on systems that have the old devicetree, a regression for
systems running with that devicetree and downstream firmware.

Cheers,
Conor.

> Jan
> 
> >> +    description:
> >> +      The phandle to System Register Controller syscon node and the PHY connect offset
> >> +      of SYS_SYSCONSAIF__SYSCFG register. Connect PHY to USB controller.
> >> +
> >>    clocks:
> >>      items:
> >>        - description: PHY 125m
> >> @@ -47,4 +57,5 @@ examples:
> >>                   <&stgcrg 6>;
> >>          clock-names = "125m", "app_125m";
> >>          #phy-cells = <0>;
> >> +        starfive,sys-syscon = <&sys_syscon 0x18>;
> >>      };
> >> -- 
> >> 2.43.0
> >>
> 
> -- 
> Siemens AG, Technology
> Linux Expert Center
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-phy/attachments/20240813/040e8876/attachment.sig>

From ilordash02 at gmail.com  Tue Aug 13 10:14:03 2024
From: ilordash02 at gmail.com (Ilya Orazov)
Date: Tue, 13 Aug 2024 20:14:03 +0300
Subject: [PATCH v3 1/1] dt-bindings: phy: ti,tcan104x-can: Document
 Microchip ATA6561
In-Reply-To: <20240808191735.1483572-1-ilordash02@gmail.com>
References: <56a52c81-68de-438d-94ae-9decc799d824@kernel.org> <20240808191735.1483572-1-ilordash02@gmail.com>
Message-ID: <CAGCz5Hk=mSjQ1eFWstQQu=JZUkavJ_mRhnp8DRELUXP_syq4Zw@mail.gmail.com>

On Thu, 8 Aug 2024 at 22:18, Ilya Orazov <ilordash02 at gmail.com> wrote:
>
> Microchip ATA6561 is High-Speed CAN Transceiver with Standby Mode.
> It is pin-compatible with TI TCAN1042 and has a compatible programming
> model, therefore use ti,tcan1042 as fallback compatible.
>
> Signed-off-by: Ilya Orazov <ilordash02 at gmail.com>
> ---
>  .../devicetree/bindings/phy/ti,tcan104x-can.yaml    | 13 +++++++++----
>  1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> index 79dad3e89aa6..4a8c3829d85d 100644
> --- a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> +++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> @@ -14,10 +14,15 @@ properties:
>      pattern: "^can-phy"
>
>    compatible:
> -    enum:
> -      - nxp,tjr1443
> -      - ti,tcan1042
> -      - ti,tcan1043
> +    oneOf:
> +      - items:
> +          - enum:
> +              - microchip,ata6561
> +          - const: ti,tcan1042
> +      - enum:
> +          - ti,tcan1042
> +          - ti,tcan1043
> +          - nxp,tjr1443
>
>    '#phy-cells':
>      const: 0
>
> base-commit: 6a0e38264012809afa24113ee2162dc07f4ed22b
> --
> 2.34.1
>

Could you please review my patch?

I hope the new patch version hasn't been lost in your inbox. Thanks to
Conor, I understand now that sending new versions as a reply wasn't
the best approach. I appreciate your time and feedback.

-- 
Best regards,
Ilya Orazov


From dsimic at manjaro.org  Tue Aug 13 11:38:17 2024
From: dsimic at manjaro.org (Dragan Simic)
Date: Tue, 13 Aug 2024 20:38:17 +0200
Subject: [PATCH] phy: phy-rockchip-inno-usb2: Handle failed extcon allocation better
Message-ID: <5fa7796d71e2f46344e972bc98a54539f55b6109.1723551599.git.dsimic@manjaro.org>

Return the actual error code upon failure to allocate extcon device, instead
of hardcoding -ENOMEM.  While there, produce an appropriate error message.

Signed-off-by: Dragan Simic <dsimic at manjaro.org>
---
 drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
index 4f71373ae6e1..d33418a1e7a8 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
@@ -434,8 +434,10 @@ static int rockchip_usb2phy_extcon_register(struct rockchip_usb2phy *rphy)
 		edev = devm_extcon_dev_allocate(rphy->dev,
 						rockchip_usb2phy_extcon_cable);
 
-		if (IS_ERR(edev))
-			return -ENOMEM;
+		if (IS_ERR(edev)) {
+			dev_err(rphy->dev, "failed to allocate extcon device\n");
+			return PTR_ERR(edev);
+		}
 
 		ret = devm_extcon_dev_register(rphy->dev, edev);
 		if (ret) {


From krzk at kernel.org  Wed Aug 14 02:03:47 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Wed, 14 Aug 2024 11:03:47 +0200
Subject: [PATCH v3 1/1] dt-bindings: phy: ti,tcan104x-can: Document
 Microchip ATA6561
In-Reply-To: <CAGCz5Hk=mSjQ1eFWstQQu=JZUkavJ_mRhnp8DRELUXP_syq4Zw@mail.gmail.com>
References: <56a52c81-68de-438d-94ae-9decc799d824@kernel.org>
 <20240808191735.1483572-1-ilordash02@gmail.com>
 <CAGCz5Hk=mSjQ1eFWstQQu=JZUkavJ_mRhnp8DRELUXP_syq4Zw@mail.gmail.com>
Message-ID: <eb04b684-eccd-4952-a310-022d00b50a55@kernel.org>

On 13/08/2024 19:14, Ilya Orazov wrote:
>>    '#phy-cells':
>>      const: 0
>>
>> base-commit: 6a0e38264012809afa24113ee2162dc07f4ed22b
>> --
>> 2.34.1
>>
> 
> Could you please review my patch?

You received review. Why do you ping after few days?

Best regards,
Krzysztof



From make24 at iscas.ac.cn  Wed Aug 14 07:11:25 2024
From: make24 at iscas.ac.cn (Ma Ke)
Date: Wed, 14 Aug 2024 22:11:25 +0800
Subject: [PATCH] phy: qualcomm: Check NULL ptr on data
Message-ID: <20240814141125.50763-1-make24@iscas.ac.cn>

Check NULL ptr on data, verify that data is not NULL before using it.

Cc: stable at vger.kernel.org
Fixes: ef19b117b834 ("phy: qualcomm: add qcom ipq806x dwc usb phy driver")
Signed-off-by: Ma Ke <make24 at iscas.ac.cn>
---
 drivers/phy/qualcomm/phy-qcom-ipq806x-usb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/phy/qualcomm/phy-qcom-ipq806x-usb.c b/drivers/phy/qualcomm/phy-qcom-ipq806x-usb.c
index 06392ed7c91b..9b9fd9c1b1f7 100644
--- a/drivers/phy/qualcomm/phy-qcom-ipq806x-usb.c
+++ b/drivers/phy/qualcomm/phy-qcom-ipq806x-usb.c
@@ -492,6 +492,8 @@ static int qcom_ipq806x_usb_phy_probe(struct platform_device *pdev)
 		return -ENOMEM;
 
 	data = of_device_get_match_data(&pdev->dev);
+	if (!data)
+		return -ENODEV;
 
 	phy_dwc3->dev = &pdev->dev;
 
-- 
2.25.1



From greg at kroah.com  Wed Aug 14 07:49:56 2024
From: greg at kroah.com (Greg KH)
Date: Wed, 14 Aug 2024 16:49:56 +0200
Subject: [PATCH] phy: qualcomm: Check NULL ptr on data
In-Reply-To: <20240814141125.50763-1-make24@iscas.ac.cn>
References: <20240814141125.50763-1-make24@iscas.ac.cn>
Message-ID: <2024081448-garden-module-40f7@gregkh>

On Wed, Aug 14, 2024 at 10:11:25PM +0800, Ma Ke wrote:
> Check NULL ptr on data, verify that data is not NULL before using it.
> 
> Cc: stable at vger.kernel.org
> Fixes: ef19b117b834 ("phy: qualcomm: add qcom ipq806x dwc usb phy driver")
> Signed-off-by: Ma Ke <make24 at iscas.ac.cn>
> ---
>  drivers/phy/qualcomm/phy-qcom-ipq806x-usb.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/phy/qualcomm/phy-qcom-ipq806x-usb.c b/drivers/phy/qualcomm/phy-qcom-ipq806x-usb.c
> index 06392ed7c91b..9b9fd9c1b1f7 100644
> --- a/drivers/phy/qualcomm/phy-qcom-ipq806x-usb.c
> +++ b/drivers/phy/qualcomm/phy-qcom-ipq806x-usb.c
> @@ -492,6 +492,8 @@ static int qcom_ipq806x_usb_phy_probe(struct platform_device *pdev)
>  		return -ENOMEM;
>  
>  	data = of_device_get_match_data(&pdev->dev);
> +	if (!data)
> +		return -ENODEV;

When will this ever fail?


From ilordash02 at gmail.com  Wed Aug 14 09:56:31 2024
From: ilordash02 at gmail.com (Ilya Orazov)
Date: Wed, 14 Aug 2024 19:56:31 +0300
Subject: [PATCH v3 1/1] dt-bindings: phy: ti,tcan104x-can: Document
 Microchip ATA6561
In-Reply-To: <eb04b684-eccd-4952-a310-022d00b50a55@kernel.org>
References: <56a52c81-68de-438d-94ae-9decc799d824@kernel.org>
 <20240808191735.1483572-1-ilordash02@gmail.com> <CAGCz5Hk=mSjQ1eFWstQQu=JZUkavJ_mRhnp8DRELUXP_syq4Zw@mail.gmail.com>
 <eb04b684-eccd-4952-a310-022d00b50a55@kernel.org>
Message-ID: <CAGCz5H=n_OOeTTNon2f=D97y==ysgXMijCkB5Nb2XVTDTQ6i4g@mail.gmail.com>

On Wed, 14 Aug 2024 at 12:03, Krzysztof Kozlowski <krzk at kernel.org> wrote:
>
> On 13/08/2024 19:14, Ilya Orazov wrote:
> >>    '#phy-cells':
> >>      const: 0
> >>
> >> base-commit: 6a0e38264012809afa24113ee2162dc07f4ed22b
> >> --
> >> 2.34.1
> >>
> >
> > Could you please review my patch?
>
> You received review. Why do you ping after few days?

I have uploaded new patch version and fixed all dt-binding errors, so
I thought you might want to review this updated version.

-- 
Best regards,
Ilya Orazov


From frieder.schrempf at kontron.de  Thu Aug 15 01:19:27 2024
From: frieder.schrempf at kontron.de (Frieder Schrempf)
Date: Thu, 15 Aug 2024 10:19:27 +0200
Subject: drm/bridge/imx8mp-hdmi-tx: Allow inexact pixel clock frequencies
 (Was: [PATCH V8 10/12] drm/bridge: imx: add bridge wrapper driver for i.MX8MP
 DWC HDMI)
In-Reply-To: <22a3f5266260dd3915269ae3eec7724f7537eb55.camel@pengutronix.de>
References: <20240203165307.7806-1-aford173@gmail.com>
 <20240203165307.7806-11-aford173@gmail.com>
 <Zm_UzO4Jmm7Aykcm@atmark-techno.com>
 <22a3f5266260dd3915269ae3eec7724f7537eb55.camel@pengutronix.de>
Message-ID: <cd03ecb1-100e-4699-95ed-d837a2802dc7@kontron.de>

Hi Dominique, hi Lucas,

On 17.06.24 6:32 PM, Lucas Stach wrote:
> Hi Dominique,
> 
> Am Montag, dem 17.06.2024 um 15:16 +0900 schrieb Dominique MARTINET:
>> Adam Ford wrote on Sat, Feb 03, 2024 at 10:52:50AM -0600:
>>> From: Lucas Stach <l.stach at pengutronix.de>
>>>
>>> Add a simple wrapper driver for the DWC HDMI bridge driver that
>>> implements the few bits that are necessary to abstract the i.MX8MP
>>> SoC integration.
>>
>> Hi Lucas, Adam,
>> (trimmed ccs a bit)
>>
>> First, thank you for the effort of upstreaming all of this!! It's really
>> appreciated, and with display working I'll really be wanting to upstream
>> our DTS as well as soon as I have time (which is going to be a while,
>> but better late than never ?)
>>
>> Until then, it's been a few months but I've got a question on this bit:
>>
>>> diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
>>> new file mode 100644
>>> index 000000000000..89fc432ac611
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
>>> +static enum drm_mode_status
>>> +imx8mp_hdmi_mode_valid(struct dw_hdmi *dw_hdmi, void *data,
>>> +		       const struct drm_display_info *info,
>>> +		       const struct drm_display_mode *mode)
>>> +{
>>> +	struct imx8mp_hdmi *hdmi = (struct imx8mp_hdmi *)data;
>>> +
>>> +	if (mode->clock < 13500)
>>> +		return MODE_CLOCK_LOW;
>>> +
>>> +	if (mode->clock > 297000)
>>> +		return MODE_CLOCK_HIGH;
>>> +
>>> +	if (clk_round_rate(hdmi->pixclk, mode->clock * 1000) !=
>>> +	    mode->clock * 1000)
>>> +		return MODE_CLOCK_RANGE;
>>
>> Do you know why such a check is here?
> 
> Sending a HDMI signal with a different rate than what the display
> expects rarely ends well, so this check avoids that.
> 
> However, this check is a bit overcautious in that it only allows exact
> rate matches. IIRC HDMI allows a rate mismatch of +- 0.5%, so this
> check could be relaxed quite a bit to allow for that.

I checked with a 1080p display that reports 23 possible modes via EDID.
Out of these 15 are accepted by the driver with the strict check.

Two more would be accepted with a relaxed check that allows a 0.5% margin.

For the remaining six modes, the pixel clock would deviate up to ~5%
from what the display expects. Still, if I remove the check altogether,
all 23 modes seem to work just fine.

>>
>> When plugging in a screen with no frequency identically supported in its
>> EDID this check causes the screen to stay black, and we've been telling
>> customers to override the EDID but it's a huge pain.
>>
>> Commit 6ad082bee902 ("phy: freescale: add Samsung HDMI PHY") already
>> "fixed" the samsung hdmi phy driver to return the next frequency if an
>> exact match hasn't been found (NXP tree's match frequencies exactly, but
>> this gets the first clock with pixclk <= rate), so if this check is also
>> relaxed our displays would work out of the box.
>>
>> I also don't see any other bridge doing this kind of check.
>> drivers/gpu/drm/bridge/imx/imx93-mipi-dsi.c has a similar check with a
>> 0.5% leeway, and all the other drivers don't check anything.
>> If you want to add some level of safety, I think we could make this work
>> with a 5% margin easily... Printing a warning in dmesg could work if
>> you're worried about artifacts, but litteraly anything is better than a
>> black screen with no error message in my opinion.
>>
>>
>> In practice the screen I'm looking at has an EDID which only supports
>> 51.2MHz and the closest frequency supported by the Samsung HDMI phy is
>> 50.4MHz, so that's a ~1.5% difference and it'd be great if it could work
>> out of the box.
> 
> For rate mismatches larger than the 0.5% allowed by the HDMI spec it
> would be better to actually add PHY PLL parameters matching those
> rates.

I'd really like to be able to add more PHY PLL setpoints for displays
that use non-CEA-861 modes. Unfortunately I didn't manage to figure out
the fractional-n PLL parameter calculation so far.

The i.MX8MP Reference Manual provides formulas to calculate the
parameters based on the register values and I tried to make sense of it
using the existing register values in the driver. But somehow it doesn't
add up for me.

Lucas, did you already work with the PLL parameters? By any chance, do
you now how the math behind them works?

> 
> We could potentially add some more leeway for displays like yours that
> aren't actually HDMI (as it doesn't seem to have a standard HDMI
> resolution). But that's more of a last resort option, as it may
> introduce other problems for displays that aren't as tolerant with
> their input rates. Remember the mode_valid call is used to filter modes
> that aren't compatible with the source, so for a display with multiple
> modes allowing too much leeway may lead to incompatible modes not
> getting tossed, in turn allowing userspace to set a mode that the
> display may not like due to too much rate deviation, instead of only
> presenting a list of valid modes. This again would present the user
> with a black-screen without warning situation.

What about adding some option to relax or remove the check for debugging
purposes? Maybe combined with printing a warning message?

I agree that we should prevent incompatible modes from passing the
filter, but it would be really helpful if people had an easy way to
relax/remove the check to see whether their display could potentially
work without them needing to modify and recompile the kernel.

Thanks
Frieder


From minda.chen at starfivetech.com  Thu Aug 15 03:33:55 2024
From: minda.chen at starfivetech.com (Minda Chen)
Date: Thu, 15 Aug 2024 10:33:55 +0000
Subject: =?gb2312?B?u9i4tDogW1BBVENIIHYyIDEvM10gZHQtYmluZGluZ3M6IHBoeTogamg3MTEw?=
 =?gb2312?Q?-usb-phy:_Add_sys-syscon_property?=
In-Reply-To: <20240813-haiku-pusher-f2fb037a2f49@wendy>
References: <cover.1723472153.git.jan.kiszka@siemens.com>
 <30f3ca9f6bd788e16767b36aa22c0e9dc4d1c6a4.1723472153.git.jan.kiszka@siemens.com>
 <20240812-overstuff-skirt-7a8aabbcdc6f@spud>
 <8cdba8b0-7364-4c09-b18a-f3f59da1eae2@siemens.com>
 <20240813-haiku-pusher-f2fb037a2f49@wendy>
Message-ID: <SHXPR01MB08633B523DA1F6C5632F6D9DE6802@SHXPR01MB0863.CHNPR01.prod.partner.outlook.cn>



> 
> On Tue, Aug 13, 2024 at 07:31:50AM +0200, Jan Kiszka wrote:
> > On 12.08.24 17:55, Conor Dooley wrote:
> > > On Mon, Aug 12, 2024 at 04:15:51PM +0200, Jan Kiszka wrote:
> > >> From: Jan Kiszka <jan.kiszka at siemens.com>
> > >>
> > >> Analogously to the PCI PHY, access to sys_syscon is needed to
> > >> connect the USB PHY to its controller.
> > >>
> > >> Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com>
> > >> Reviewed-by: Rob Herring (Arm) <robh at kernel.org>
> > >> ---
> > >> CC: Rob Herring <robh at kernel.org>
> > >> CC: Krzysztof Kozlowski <krzk+dt at kernel.org>
> > >> CC: Conor Dooley <conor+dt at kernel.org>
> > >> ---
> > >>  .../bindings/phy/starfive,jh7110-usb-phy.yaml         | 11
> +++++++++++
> > >>  1 file changed, 11 insertions(+)
> > >>
> > >> diff --git
> > >> a/Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yam
> > >> l
> > >> b/Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yam
> > >> l index 269e9f9f12b6..eaf0050c6f17 100644
> > >> ---
> > >> a/Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yam
> > >> l
> > >> +++ b/Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy
> > >> +++ .yaml
> > >> @@ -19,6 +19,16 @@ properties:
> > >>    "#phy-cells":
> > >>      const: 0
> > >>
> > >> +  starfive,sys-syscon:
> > >> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> > >> +    items:
> > >> +      - items:
> > >> +          - description: phandle to System Register Controller
> sys_syscon node.
> > >> +          - description: PHY connect offset of
> SYS_SYSCONSAIF__SYSCFG register for USB PHY.
> > >
> > > Why is having a new property for this required? The devicetree only
> > > has a single usb phy, so isn't it sufficient to look up the syscon
> > > by compatible, rather than via phandle + offset?
> > >
> >
> > I didn't design this, I just copied it from
> > starfive,jh7110-pcie-phy.yaml. As that already exists, I'm neither
> > sure we want to change that anymore nor deviate in the pattern here.
> 
> To be honest, I think some of the other users of phandle + offset on this soc were
> just copy-pasted without thinking about whether or not they were required too.
> This one seems like it should just be a lookup by compatible in the driver instead
> of by phandle. As a bonus, it will work with existing devicetrees - whereas your
> current implementation will fail to probe on systems that have the old
> devicetree, a regression for systems running with that devicetree and
> downstream firmware.
> 
> Cheers,
> Conor.
> 
Hi Conor
I know you would like to put the offset value to the code, Just set syscon in dts.
Just like pcie-starfive.c. right?

> > Jan
> >
> > >> +    description:
> > >> +      The phandle to System Register Controller syscon node and the
> PHY connect offset
> > >> +      of SYS_SYSCONSAIF__SYSCFG register. Connect PHY to USB
> controller.
> > >> +
> > >>    clocks:
> > >>      items:
> > >>        - description: PHY 125m
> > >> @@ -47,4 +57,5 @@ examples:
> > >>                   <&stgcrg 6>;
> > >>          clock-names = "125m", "app_125m";
> > >>          #phy-cells = <0>;
> > >> +        starfive,sys-syscon = <&sys_syscon 0x18>;
> > >>      };
> > >> --
> > >> 2.43.0
> > >>
> >
> > --
> > Siemens AG, Technology
> > Linux Expert Center
> >

From conor at kernel.org  Thu Aug 15 07:42:00 2024
From: conor at kernel.org (Conor Dooley)
Date: Thu, 15 Aug 2024 15:42:00 +0100
Subject: =?utf-8?B?5Zue5aSNOiBbUEFUQ0ggdjIgMS8z?= =?utf-8?Q?=5D?=
 dt-bindings: phy: jh7110-usb-phy: Add sys-syscon property
In-Reply-To: <SHXPR01MB08633B523DA1F6C5632F6D9DE6802@SHXPR01MB0863.CHNPR01.prod.partner.outlook.cn>
References: <cover.1723472153.git.jan.kiszka@siemens.com>
 <30f3ca9f6bd788e16767b36aa22c0e9dc4d1c6a4.1723472153.git.jan.kiszka@siemens.com>
 <20240812-overstuff-skirt-7a8aabbcdc6f@spud>
 <8cdba8b0-7364-4c09-b18a-f3f59da1eae2@siemens.com>
 <20240813-haiku-pusher-f2fb037a2f49@wendy>
 <SHXPR01MB08633B523DA1F6C5632F6D9DE6802@SHXPR01MB0863.CHNPR01.prod.partner.outlook.cn>
Message-ID: <20240815-endless-credible-324438d164f4@spud>

On Thu, Aug 15, 2024 at 10:33:55AM +0000, Minda Chen wrote:
> 
> 
> > 
> > On Tue, Aug 13, 2024 at 07:31:50AM +0200, Jan Kiszka wrote:
> > > On 12.08.24 17:55, Conor Dooley wrote:
> > > > On Mon, Aug 12, 2024 at 04:15:51PM +0200, Jan Kiszka wrote:
> > > >> From: Jan Kiszka <jan.kiszka at siemens.com>
> > > >>
> > > >> Analogously to the PCI PHY, access to sys_syscon is needed to
> > > >> connect the USB PHY to its controller.
> > > >>
> > > >> Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com>
> > > >> Reviewed-by: Rob Herring (Arm) <robh at kernel.org>
> > > >> ---
> > > >> CC: Rob Herring <robh at kernel.org>
> > > >> CC: Krzysztof Kozlowski <krzk+dt at kernel.org>
> > > >> CC: Conor Dooley <conor+dt at kernel.org>
> > > >> ---
> > > >>  .../bindings/phy/starfive,jh7110-usb-phy.yaml         | 11
> > +++++++++++
> > > >>  1 file changed, 11 insertions(+)
> > > >>
> > > >> diff --git
> > > >> a/Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yam
> > > >> l
> > > >> b/Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yam
> > > >> l index 269e9f9f12b6..eaf0050c6f17 100644
> > > >> ---
> > > >> a/Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yam
> > > >> l
> > > >> +++ b/Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy
> > > >> +++ .yaml
> > > >> @@ -19,6 +19,16 @@ properties:
> > > >>    "#phy-cells":
> > > >>      const: 0
> > > >>
> > > >> +  starfive,sys-syscon:
> > > >> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> > > >> +    items:
> > > >> +      - items:
> > > >> +          - description: phandle to System Register Controller
> > sys_syscon node.
> > > >> +          - description: PHY connect offset of
> > SYS_SYSCONSAIF__SYSCFG register for USB PHY.
> > > >
> > > > Why is having a new property for this required? The devicetree only
> > > > has a single usb phy, so isn't it sufficient to look up the syscon
> > > > by compatible, rather than via phandle + offset?
> > > >
> > >
> > > I didn't design this, I just copied it from
> > > starfive,jh7110-pcie-phy.yaml. As that already exists, I'm neither
> > > sure we want to change that anymore nor deviate in the pattern here.
> > 
> > To be honest, I think some of the other users of phandle + offset on this soc were
> > just copy-pasted without thinking about whether or not they were required too.
> > This one seems like it should just be a lookup by compatible in the driver instead
> > of by phandle. As a bonus, it will work with existing devicetrees - whereas your
> > current implementation will fail to probe on systems that have the old
> > devicetree, a regression for systems running with that devicetree and
> > downstream firmware.
> > 
> > Cheers,
> > Conor.
> > 
> Hi Conor
> I know you would like to put the offset value to the code, Just set syscon in dts.
> Just like pcie-starfive.c. right?

No, not quite. That still uses a phandle lookup, I was talking about
using syscon_regmap_lookup_by_compatible().
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-phy/attachments/20240815/14775870/attachment.sig>

From heiko at sntech.de  Thu Aug 15 09:12:48 2024
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Thu, 15 Aug 2024 18:12:48 +0200
Subject: [PATCH] phy: phy-rockchip-inno-usb2: Handle failed extcon allocation
 better
In-Reply-To: <5fa7796d71e2f46344e972bc98a54539f55b6109.1723551599.git.dsimic@manjaro.org>
References: <5fa7796d71e2f46344e972bc98a54539f55b6109.1723551599.git.dsimic@manjaro.org>
Message-ID: <4927264.xgNZFEDtJV@diego>

Am Dienstag, 13. August 2024, 20:38:17 CEST schrieb Dragan Simic:
> Return the actual error code upon failure to allocate extcon device, instead
> of hardcoding -ENOMEM.  While there, produce an appropriate error message.
> 
> Signed-off-by: Dragan Simic <dsimic at manjaro.org>
> ---
>  drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
> index 4f71373ae6e1..d33418a1e7a8 100644
> --- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
> +++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
> @@ -434,8 +434,10 @@ static int rockchip_usb2phy_extcon_register(struct rockchip_usb2phy *rphy)
>  		edev = devm_extcon_dev_allocate(rphy->dev,
>  						rockchip_usb2phy_extcon_cable);
>  
> -		if (IS_ERR(edev))
> -			return -ENOMEM;
> +		if (IS_ERR(edev)) {
> +			dev_err(rphy->dev, "failed to allocate extcon device\n");
> +			return PTR_ERR(edev);
> +		}

maybe even use dev_err_probe?

rockchip_usb2phy_extcon_register() gets called from the probe function,
so even using it is also sematically correct ;-) .


Heiko

>  
>  		ret = devm_extcon_dev_register(rphy->dev, edev);
>  		if (ret) {
> 






From luca.weiss at fairphone.com  Thu Aug 15 23:35:28 2024
From: luca.weiss at fairphone.com (Luca Weiss)
Date: Fri, 16 Aug 2024 08:35:28 +0200
Subject: [PATCH v2 0/7] arm64: qcom: allow up to 4 lanes for the Type-C
 DisplayPort Altmode
In-Reply-To: <20240527-topic-sm8x50-upstream-phy-combo-typec-mux-v2-0-a03e68d7b8fc@linaro.org>
References: <20240527-topic-sm8x50-upstream-phy-combo-typec-mux-v2-0-a03e68d7b8fc@linaro.org>
Message-ID: <D3H4LOY4UHKJ.2E21EUSJWXQGJ@fairphone.com>

On Mon May 27, 2024 at 10:42 AM CEST, Neil Armstrong wrote:
> Register a typec mux in order to change the PHY mode on the Type-C
> mux events depending on the mode and the svid when in Altmode setup.
>
> The DisplayPort phy should be left enabled if is still powered on
> by the DRM DisplayPort controller, so bail out until the DisplayPort
> PHY is not powered off.
>
> The Type-C Mode/SVID only changes on plug/unplug, and USB SAFE states
> will be set in between of USB-Only, Combo and DisplayPort Only so
> this will leave enough time to the DRM DisplayPort controller to
> turn of the DisplayPort PHY.
>
> The patchset also includes bindings changes and DT changes.
>
> This has been successfully tested on an SM8550 board, but the
> Thinkpad X13s deserved testing between non-PD USB, non-PD DisplayPort,
> PD USB Hubs and PD Altmode Dongles to make sure the switch works
> as expected.
>
> The DisplayPort 4 lanes setup can be check with:
> $ cat /sys/kernel/debug/dri/ae01000.display-controller/DP-1/dp_debug
> 	name = msm_dp
> 	drm_dp_link
> 		rate = 540000
> 		num_lanes = 4
> ...
>
> This patchset depends on [1] to allow broadcasting the type-c mode
> to the PHY, otherwise the PHY will keep the combo state while the
> retimer would setup the 4 lanes in DP mode.
>
> [1] https://lore.kernel.org/all/20240527-topic-sm8x50-upstream-retimer-broadcast-mode-v1-0-79ec91381aba at linaro.org/

Hi Neil,

Is there anything happening on this patchset? From what I can see there
were a few comments on the patches, would be nice if we could get this
in at some point.

Regards
Luca

>
> To: Bjorn Andersson <andersson at kernel.org>
> To: Konrad Dybcio <konrad.dybcio at linaro.org>
> To: Vinod Koul <vkoul at kernel.org>
> To: Kishon Vijay Abraham I <kishon at kernel.org>
> To: Rob Herring <robh at kernel.org>
> To: Krzysztof Kozlowski <krzysztof.kozlowski+dt at linaro.org>
> To: Conor Dooley <conor+dt at kernel.org>
> To: Krzysztof Kozlowski <krzk+dt at kernel.org>
> Cc: linux-arm-msm at vger.kernel.org
> Cc: linux-phy at lists.infradead.org
> Cc: devicetree at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> Signed-off-by: Neil Armstrong <neil.armstrong at linaro.org>
>
> Changes in v2:
> - Reference usb-switch.yaml in bindings patch
> - Fix switch/case indenting
> - Check svid for USB_TYPEC_DP_SID
> - Fix X13s patch subject
> - Update SM8650 patch to enable 4 lanes on HDK aswell
> - Link to v1: https://lore.kernel.org/r/20240229-topic-sm8x50-upstream-phy-combo-typec-mux-v1-0-07e24a231840 at linaro.org
>
> ---
> Neil Armstrong (7):
>       dt-bindings: phy: qcom,sc8280xp-qmp-usb43dp: Reference usb-switch.yaml to allow mode-switch
>       phy: qcom: qmp-combo: store DP phy power state
>       phy: qcom: qmp-combo: introduce QPHY_MODE
>       phy: qcom: qmp-combo: register a typec mux to change the QPHY_MODE
>       arm64: dts: qcom-sm8550: allow 4 lanes for DisplayPort and enable QMP PHY mode-switch
>       arm64: dts: qcom-sm8650: allow 4 lanes for DisplayPort and enable QMP PHY mode-switch
>       arm64: dts: qcom: sc8280xp-lenovo-thinkpad-x13: allow 4 lanes for DisplayPort and enable QMP PHY mode-switch
>
>  .../phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml         |   7 +-
>  .../dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts     |   6 +-
>  arch/arm64/boot/dts/qcom/sm8550-hdk.dts            |   3 +-
>  arch/arm64/boot/dts/qcom/sm8550-qrd.dts            |   3 +-
>  arch/arm64/boot/dts/qcom/sm8650-hdk.dts            |   3 +-
>  arch/arm64/boot/dts/qcom/sm8650-qrd.dts            |   3 +-
>  drivers/phy/qualcomm/phy-qcom-qmp-combo.c          | 169 +++++++++++++++++++--
>  7 files changed, 174 insertions(+), 20 deletions(-)
> ---
> base-commit: d4eef8b2e18d3e4d2343fb3bb975f8ac4522129a
> change-id: 20240229-topic-sm8x50-upstream-phy-combo-typec-mux-31b5252513c9
>
> Best regards,



From christian.bruel at foss.st.com  Fri Aug 16 06:20:52 2024
From: christian.bruel at foss.st.com (Christian Bruel)
Date: Fri, 16 Aug 2024 15:20:52 +0200
Subject: [PATCH v2 0/5] Add STM32MP25 USB3/PCIE COMBOPHY driver 
Message-ID: <20240816132058.920870-1-christian.bruel@foss.st.com>

Thanks Rob for your comments, addressed in v2.

This patch series adds USB3/PCIE COMBOPHY driver for the STM32MP25 SoC from
STMicrolectronics, respective yaml schema and enable for the stm32mp257f-ev1
device into which it is used for PCIe.

Changes in v2:
   - Reorder entries
   - Rename clock_names and reset_names bindings
   - Rename and clarify rx-equalizer binding 

Christian Bruel (5):
  MAINTAINERS: add entry for ST STM32MP25 COMBOPHY driver
  dt-bindings: phy: Add STM32MP25 COMBOPHY bindings
  phy: stm32: Add support for STM32MP25 COMBOPHY.
  arm64: dts: st: Add combophy node on stm32mp251
  arm64: dts: st: Enable COMBOPHY on the stm32mp257f-ev1 board

 .../bindings/phy/st,stm32-combophy.yaml       | 145 +++++
 MAINTAINERS                                   |   6 +
 arch/arm64/boot/dts/st/stm32mp251.dtsi        |  17 +
 arch/arm64/boot/dts/st/stm32mp257f-ev1.dts    |  14 +
 drivers/phy/st/Kconfig                        |  11 +
 drivers/phy/st/Makefile                       |   1 +
 drivers/phy/st/phy-stm32-combophy.c           | 607 ++++++++++++++++++
 7 files changed, 801 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml
 create mode 100644 drivers/phy/st/phy-stm32-combophy.c

-- 
2.34.1



From christian.bruel at foss.st.com  Fri Aug 16 06:20:55 2024
From: christian.bruel at foss.st.com (Christian Bruel)
Date: Fri, 16 Aug 2024 15:20:55 +0200
Subject: [PATCH v2 3/5] phy: stm32: Add support for STM32MP25 COMBOPHY.
In-Reply-To: <20240816132058.920870-1-christian.bruel@foss.st.com>
References: <20240816132058.920870-1-christian.bruel@foss.st.com>
Message-ID: <20240816132058.920870-4-christian.bruel@foss.st.com>

Addition of the COMBOPHY driver found on STM32MP25 platforms

This single lane PHY is shared (exclusive) between the USB3 and PCIE
controllers.
Supports 5Gbit/s for PCIE gen2 or 2.5Gbit/s for PCIE gen1.

Supports wakeup-source capability to wakeup system using remote-wakeup
capable USB device

Signed-off-by: Christian Bruel <christian.bruel at foss.st.com>
---
 drivers/phy/st/Kconfig              |  11 +
 drivers/phy/st/Makefile             |   1 +
 drivers/phy/st/phy-stm32-combophy.c | 607 ++++++++++++++++++++++++++++
 3 files changed, 619 insertions(+)
 create mode 100644 drivers/phy/st/phy-stm32-combophy.c

diff --git a/drivers/phy/st/Kconfig b/drivers/phy/st/Kconfig
index 3fc3d0781fb8..304614b6dabf 100644
--- a/drivers/phy/st/Kconfig
+++ b/drivers/phy/st/Kconfig
@@ -33,6 +33,17 @@ config PHY_STIH407_USB
 	  Enable this support to enable the picoPHY device used by USB2
 	  and USB3 controllers on STMicroelectronics STiH407 SoC families.
 
+config PHY_STM32_COMBOPHY
+	tristate "STMicroelectronics COMBOPHY driver for STM32MP25"
+	depends on ARCH_STM32 || COMPILE_TEST
+	select GENERIC_PHY
+	help
+	  Enable this to support the COMBOPHY device used by USB3 or PCIe
+	  controllers on STMicroelectronics STM32MP25 SoC.
+	  This driver controls the COMBOPHY block to generate the PCIe 100Mhz
+	  reference clock from either the external clock generator or HSE
+	  internal SoC clock source.
+
 config PHY_STM32_USBPHYC
 	tristate "STMicroelectronics STM32 USB HS PHY Controller driver"
 	depends on ARCH_STM32 || COMPILE_TEST
diff --git a/drivers/phy/st/Makefile b/drivers/phy/st/Makefile
index c862dd937b64..cb80e954ea9f 100644
--- a/drivers/phy/st/Makefile
+++ b/drivers/phy/st/Makefile
@@ -3,4 +3,5 @@ obj-$(CONFIG_PHY_MIPHY28LP) 		+= phy-miphy28lp.o
 obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)	+= phy-spear1310-miphy.o
 obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)	+= phy-spear1340-miphy.o
 obj-$(CONFIG_PHY_STIH407_USB)		+= phy-stih407-usb.o
+obj-$(CONFIG_PHY_STM32_COMBOPHY)	+= phy-stm32-combophy.o
 obj-$(CONFIG_PHY_STM32_USBPHYC) 	+= phy-stm32-usbphyc.o
diff --git a/drivers/phy/st/phy-stm32-combophy.c b/drivers/phy/st/phy-stm32-combophy.c
new file mode 100644
index 000000000000..7cd4193b0277
--- /dev/null
+++ b/drivers/phy/st/phy-stm32-combophy.c
@@ -0,0 +1,607 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * STMicroelectronics COMBOPHY STM32MP25 Controller driver.
+ *
+ * Copyright (C) 2024 STMicroelectronics
+ * Author: Christian Bruel <christian.bruel at foss.st.com>
+ */
+
+#include <linux/clk.h>
+#include <linux/mfd/syscon.h>
+#include <linux/platform_device.h>
+#include <linux/phy/phy.h>
+#include <linux/pm_runtime.h>
+#include <linux/regmap.h>
+#include <linux/reset.h>
+#include <dt-bindings/phy/phy.h>
+
+#define SYSCFG_COMBOPHY_CR1 0x4C00
+#define SYSCFG_COMBOPHY_CR2 0x4C04
+#define SYSCFG_COMBOPHY_CR4 0x4C0C
+#define SYSCFG_COMBOPHY_CR5 0x4C10
+#define SYSCFG_COMBOPHY_SR  0x4C14
+#define SYSCFG_PCIEPRGCR    0x6080
+
+/* SYSCFG PCIEPRGCR */
+#define STM32MP25_PCIEPRGCR_EN	  BIT(0)
+#define STM32MP25_PCIEPRG_IMPCTRL_OHM     GENMASK(3, 1)
+#define STM32MP25_PCIEPRG_IMPCTRL_VSWING  GENMASK(5, 4)
+
+/* SYSCFG SYSCFG_COMBOPHY_SR */
+#define STM32MP25_PIPE0_PHYSTATUS BIT(1)
+
+/* SYSCFG CR1 */
+#define SYSCFG_COMBOPHY_CR1_REFUSEPAD BIT(0)
+#define SYSCFG_COMBOPHY_CR1_MPLLMULT GENMASK(7, 1)
+#define SYSCFG_COMBOPHY_CR1_REFCLKSEL GENMASK(16, 8)
+#define SYSCFG_COMBOPHY_CR1_REFCLKDIV2 BIT(17)
+#define SYSCFG_COMBOPHY_CR1_REFSSPEN BIT(18)
+#define SYSCFG_COMBOPHY_CR1_SSCEN BIT(19)
+
+/* SYSCFG CR4 */
+#define SYSCFG_COMBOPHY_CR4_RX0_EQ GENMASK(2, 0)
+
+#define MPLLMULT_19_2 (0x02u << 1)
+#define MPLLMULT_20   (0x7Du << 1)
+#define MPLLMULT_24   (0x68u << 1)
+#define MPLLMULT_25   (0x64u << 1)
+#define MPLLMULT_26   (0x60u << 1)
+#define MPLLMULT_38_4 (0x41u << 1)
+#define MPLLMULT_48   (0x6Cu << 1)
+#define MPLLMULT_50   (0x32u << 1)
+#define MPLLMULT_52   (0x30u << 1)
+#define MPLLMULT_100  (0x19u << 1)
+
+#define REFCLKSEL_0   0
+#define REFCLKSEL_1   (0x108u << 8)
+
+#define REFCLDIV_0    0
+
+/* SYSCFG CR2 */
+#define SYSCFG_COMBOPHY_CR2_MODESEL GENMASK(1, 0)
+#define SYSCFG_COMBOPHY_CR2_ISO_DIS BIT(15)
+
+#define COMBOPHY_MODESEL_PCIE 0
+#define COMBOPHY_MODESEL_USB  3
+
+/* SYSCFG CR5 */
+#define SYSCFG_COMBOPHY_CR5_COMMON_CLOCKS BIT(12)
+
+#define COMBOPHY_SUP_ANA_MPLL_LOOP_CTL 0xC0
+#define COMBOPHY_PROP_CNTRL GENMASK(7, 4)
+
+struct stm32_combophy {
+	struct phy *phy;
+	struct regmap *regmap;
+	struct device *dev;
+	void __iomem *base;
+	struct reset_control *phy_reset;
+	struct clk *phy_clk;
+	struct clk *pad_clk;
+	struct clk *ker_clk;
+	unsigned int type;
+	bool is_init;
+	int irq_wakeup;
+};
+
+struct clk_impedance  {
+	u32 microohm;
+	u32 vswing[4];
+};
+
+/*
+ * lookup table to hold the settings needed for a ref clock frequency
+ * impedance, the offset is used to set the IMP_CTL and DE_EMP bit of the
+ * PRG_IMP_CTRL register
+ */
+static const struct clk_impedance imp_lookup[] = {
+	{ 6090000, { 442000, 564000, 684000, 802000 } },
+	{ 5662000, { 528000, 621000, 712000, 803000 } },
+	{ 5292000, { 491000, 596000, 700000, 802000 } },
+	{ 4968000, { 558000, 640000, 722000, 803000 } },
+	{ 4684000, { 468000, 581000, 692000, 802000 } },
+	{ 4429000, { 554000, 613000, 717000, 803000 } },
+	{ 4204000, { 511000, 609000, 706000, 802000 } },
+	{ 3999000, { 571000, 648000, 726000, 803000 } }
+};
+
+static int stm32_impedance_tune(struct stm32_combophy *combophy)
+{
+	u8 imp_size = ARRAY_SIZE(imp_lookup);
+	u8 vswing_size = ARRAY_SIZE(imp_lookup[0].vswing);
+	u8 imp_of, vswing_of;
+	u32 max_imp = imp_lookup[0].microohm;
+	u32 min_imp = imp_lookup[imp_size - 1].microohm;
+	u32 max_vswing = imp_lookup[imp_size - 1].vswing[vswing_size - 1];
+	u32 min_vswing = imp_lookup[0].vswing[0];
+	u32 val;
+
+	if (!of_property_read_u32(combophy->dev->of_node, "st,output-micro-ohms", &val)) {
+		if (val < min_imp || val > max_imp) {
+			dev_err(combophy->dev, "Invalid value %u for output ohm\n", val);
+			return -EINVAL;
+		}
+
+		for (imp_of = 0 ; imp_of < ARRAY_SIZE(imp_lookup); imp_of++)
+			if (imp_lookup[imp_of].microohm <= val)
+				break;
+
+		dev_dbg(combophy->dev, "Set %u micro-ohms output impedance\n",
+			imp_lookup[imp_of].microohm);
+
+		regmap_update_bits(combophy->regmap, SYSCFG_PCIEPRGCR,
+				   STM32MP25_PCIEPRG_IMPCTRL_OHM,
+				   FIELD_PREP(STM32MP25_PCIEPRG_IMPCTRL_OHM, imp_of));
+	} else {
+		regmap_read(combophy->regmap, SYSCFG_PCIEPRGCR, &val);
+		imp_of = FIELD_GET(STM32MP25_PCIEPRG_IMPCTRL_OHM, val);
+	}
+
+	if (!of_property_read_u32(combophy->dev->of_node, "st,output-vswing-microvolt", &val)) {
+		if (val < min_vswing || val > max_vswing) {
+			dev_err(combophy->dev, "Invalid value %u for output vswing\n", val);
+			return -EINVAL;
+		}
+
+		for (vswing_of = 0 ; vswing_of < ARRAY_SIZE(imp_lookup[imp_of].vswing); vswing_of++)
+			if (imp_lookup[imp_of].vswing[vswing_of] >= val)
+				break;
+
+		dev_dbg(combophy->dev, "Set %u microvolt swing\n",
+			 imp_lookup[imp_of].vswing[vswing_of]);
+
+		regmap_update_bits(combophy->regmap, SYSCFG_PCIEPRGCR,
+				   STM32MP25_PCIEPRG_IMPCTRL_VSWING,
+				   FIELD_PREP(STM32MP25_PCIEPRG_IMPCTRL_VSWING, vswing_of));
+	}
+
+	return 0;
+}
+
+static int stm32_combophy_pll_init(struct stm32_combophy *combophy)
+{
+	int ret;
+	u32 refclksel, pllmult, propcntrl, val;
+	u32 clk_rate;
+
+	if (combophy->pad_clk)
+		clk_rate = clk_get_rate(combophy->pad_clk);
+	else
+		clk_rate = clk_get_rate(combophy->ker_clk);
+
+	reset_control_assert(combophy->phy_reset);
+
+	dev_dbg(combophy->dev, "%s pll init rate %d\n",
+		combophy->pad_clk ? "External" : "Ker", clk_rate);
+
+	/*
+	 * vddcombophy is interconnected with vddcore. Isolation bit should be unset
+	 * before using the ComboPHY.
+	 */
+	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR2,
+			   SYSCFG_COMBOPHY_CR2_ISO_DIS, SYSCFG_COMBOPHY_CR2_ISO_DIS);
+
+	if (combophy->type != PHY_TYPE_PCIE)
+		regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
+				   SYSCFG_COMBOPHY_CR1_REFSSPEN, SYSCFG_COMBOPHY_CR1_REFSSPEN);
+
+	if (combophy->type == PHY_TYPE_PCIE && !combophy->pad_clk)
+		regmap_update_bits(combophy->regmap, SYSCFG_PCIEPRGCR,
+				   STM32MP25_PCIEPRGCR_EN, STM32MP25_PCIEPRGCR_EN);
+
+	if (of_property_read_bool(combophy->dev->of_node, "st,ssc-on")) {
+		dev_dbg(combophy->dev, "Enabling clock with SSC\n");
+		regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
+				   SYSCFG_COMBOPHY_CR1_SSCEN, SYSCFG_COMBOPHY_CR1_SSCEN);
+	}
+
+	if (!of_property_read_u32(combophy->dev->of_node, "st,rx-equalizer", &val)) {
+		dev_dbg(combophy->dev, "Set RX equalizer %u\n", val);
+		if (val > SYSCFG_COMBOPHY_CR4_RX0_EQ) {
+			dev_err(combophy->dev, "Invalid value %u for rx0 equalizer\n", val);
+			return -EINVAL;
+		}
+
+		regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR4,
+			   SYSCFG_COMBOPHY_CR4_RX0_EQ, val);
+	}
+
+	if (combophy->type == PHY_TYPE_PCIE) {
+		ret = stm32_impedance_tune(combophy);
+		if (ret) {
+			reset_control_deassert(combophy->phy_reset);
+			goto out;
+		}
+
+		regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
+				   SYSCFG_COMBOPHY_CR1_REFUSEPAD,
+				   combophy->pad_clk ? SYSCFG_COMBOPHY_CR1_REFUSEPAD : 0);
+	}
+
+	switch (clk_rate) {
+	case 100000000:
+		pllmult = MPLLMULT_100;
+		refclksel = REFCLKSEL_0;
+		propcntrl = 0x8u << 4;
+		break;
+	case 19200000:
+		pllmult = MPLLMULT_19_2;
+		refclksel = REFCLKSEL_1;
+		propcntrl = 0x8u << 4;
+		break;
+	case 25000000:
+		pllmult = MPLLMULT_25;
+		refclksel = REFCLKSEL_0;
+		propcntrl = 0xEu << 4;
+		break;
+	case 24000000:
+		pllmult = MPLLMULT_24;
+		refclksel = REFCLKSEL_1;
+		propcntrl = 0xEu << 4;
+		break;
+	case 20000000:
+		pllmult = MPLLMULT_20;
+		refclksel = REFCLKSEL_0;
+		propcntrl = 0xEu << 4;
+		break;
+	default:
+		dev_err(combophy->dev, "Invalid rate 0x%x\n", clk_rate);
+		reset_control_deassert(combophy->phy_reset);
+		ret = -EINVAL;
+		goto out;
+	};
+
+	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
+			   SYSCFG_COMBOPHY_CR1_REFCLKDIV2, REFCLDIV_0);
+	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
+			   SYSCFG_COMBOPHY_CR1_REFCLKSEL, refclksel);
+	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
+			   SYSCFG_COMBOPHY_CR1_MPLLMULT, pllmult);
+
+	/*
+	 * Force elasticity buffer to be tuned for the reference clock as
+	 * the separated clock model is not supported
+	 */
+	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR5,
+			   SYSCFG_COMBOPHY_CR5_COMMON_CLOCKS, SYSCFG_COMBOPHY_CR5_COMMON_CLOCKS);
+
+	reset_control_deassert(combophy->phy_reset);
+
+	ret = regmap_read_poll_timeout(combophy->regmap, SYSCFG_COMBOPHY_SR, val,
+				       !(val & STM32MP25_PIPE0_PHYSTATUS),
+				       10, 1000);
+	if (ret) {
+		dev_err(combophy->dev, "timeout, cannot lock PLL\n");
+		goto out;
+	}
+
+	if (combophy->type == PHY_TYPE_PCIE) {
+		val = readl_relaxed(combophy->base + COMBOPHY_SUP_ANA_MPLL_LOOP_CTL);
+		val &= ~COMBOPHY_PROP_CNTRL;
+		val |= propcntrl;
+		writel_relaxed(val, combophy->base + COMBOPHY_SUP_ANA_MPLL_LOOP_CTL);
+	}
+
+	return 0;
+
+out:
+	if (combophy->type == PHY_TYPE_PCIE && !combophy->pad_clk)
+		regmap_update_bits(combophy->regmap, SYSCFG_PCIEPRGCR,
+				   STM32MP25_PCIEPRGCR_EN, 0);
+
+	if (combophy->type != PHY_TYPE_PCIE)
+		regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
+				   SYSCFG_COMBOPHY_CR1_REFSSPEN, 0);
+
+	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR2,
+			   SYSCFG_COMBOPHY_CR2_ISO_DIS, 0);
+
+	return ret;
+}
+
+static struct phy *stm32_combophy_xlate(struct device *dev,
+					const struct of_phandle_args *args)
+{
+	struct stm32_combophy *combophy = dev_get_drvdata(dev);
+	unsigned int type;
+
+	if (args->args_count != 1) {
+		dev_err(dev, "invalid number of cells in 'phy' property\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	type = args->args[0];
+	if (type != PHY_TYPE_USB3 && type != PHY_TYPE_PCIE) {
+		dev_err(dev, "unsupported device type: %d\n", type);
+		return ERR_PTR(-EINVAL);
+	}
+
+	if (combophy->pad_clk && type != PHY_TYPE_PCIE) {
+		dev_err(dev, "Invalid use of clk_pad for USB3 mode\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	combophy->type = type;
+
+	return combophy->phy;
+}
+
+static int stm32_combophy_set_mode(struct stm32_combophy *combophy)
+{
+	int type = combophy->type;
+	u32 val;
+
+	switch (type) {
+	case PHY_TYPE_PCIE:
+		dev_dbg(combophy->dev, "setting PCIe ComboPHY\n");
+		val = COMBOPHY_MODESEL_PCIE;
+		break;
+	case PHY_TYPE_USB3:
+		dev_dbg(combophy->dev, "setting USB3 ComboPHY\n");
+		val = COMBOPHY_MODESEL_USB;
+		break;
+	default:
+		dev_err(combophy->dev, "Invalid PHY mode %d\n", type);
+		return -EINVAL;
+	}
+
+	return regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR2,
+				  SYSCFG_COMBOPHY_CR2_MODESEL, val);
+}
+
+static int stm32_combophy_enable_clocks(struct stm32_combophy *combophy)
+{
+	int ret;
+
+	ret = clk_prepare_enable(combophy->phy_clk);
+	if (ret) {
+		dev_err(combophy->dev, "Core clock enable failed %d\n", ret);
+		return ret;
+	}
+
+	ret = clk_prepare_enable(combophy->ker_clk);
+	if (ret) {
+		dev_err(combophy->dev, "ker_usb3pcie clock enable failed %d\n", ret);
+		clk_disable_unprepare(combophy->phy_clk);
+		return ret;
+	}
+
+	if (combophy->pad_clk) {
+		ret = clk_prepare_enable(combophy->pad_clk);
+		if (ret) {
+			dev_err(combophy->dev, "External clock enable failed %d\n", ret);
+			clk_disable_unprepare(combophy->ker_clk);
+			clk_disable_unprepare(combophy->phy_clk);
+			return ret;
+		}
+	}
+
+	return 0;
+}
+
+static void stm32_combophy_disable_clocks(struct stm32_combophy *combophy)
+{
+	if (combophy->pad_clk)
+		clk_disable_unprepare(combophy->pad_clk);
+	clk_disable_unprepare(combophy->ker_clk);
+	clk_disable_unprepare(combophy->phy_clk);
+}
+
+static int stm32_combophy_suspend_noirq(struct device *dev)
+{
+	struct stm32_combophy *combophy = dev_get_drvdata(dev);
+
+	/*
+	 * Clocks should be turned off since it is not needed for
+	 * wakeup capability. In case usb-remote wakeup is not enabled,
+	 * combo-phy is already turned off by HCD driver using exit callback
+	 */
+	if (combophy->is_init) {
+		stm32_combophy_disable_clocks(combophy);
+
+		/* since wakeup is enabled for ctrl */
+		enable_irq_wake(combophy->irq_wakeup);
+	}
+
+	return 0;
+}
+
+static int stm32_combophy_resume_noirq(struct device *dev)
+{
+	struct stm32_combophy *combophy = dev_get_drvdata(dev);
+	int ret;
+
+	/*
+	 * If clocks was turned off by suspend call for wakeup then needs
+	 * to be turned back ON in resume. In case usb-remote wakeup is not
+	 * enabled, clocks already turned ON by HCD driver using init callback
+	 */
+	if (combophy->is_init) {
+		/* since wakeup was enabled for ctrl */
+		disable_irq_wake(combophy->irq_wakeup);
+
+		ret = stm32_combophy_enable_clocks(combophy);
+		if (ret) {
+			dev_err(dev, "can't enable clocks (%d)\n", ret);
+			return ret;
+		}
+	}
+
+	return 0;
+}
+
+static int stm32_combophy_exit(struct phy *phy)
+{
+	struct stm32_combophy *combophy = phy_get_drvdata(phy);
+	struct device *dev = combophy->dev;
+
+	combophy->is_init = false;
+
+	if (combophy->type == PHY_TYPE_PCIE && !combophy->pad_clk)
+		regmap_update_bits(combophy->regmap, SYSCFG_PCIEPRGCR,
+				   STM32MP25_PCIEPRGCR_EN, 0);
+
+	if (combophy->type != PHY_TYPE_PCIE)
+		regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
+				   SYSCFG_COMBOPHY_CR1_REFSSPEN, 0);
+
+	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR2,
+			   SYSCFG_COMBOPHY_CR2_ISO_DIS, 0);
+
+	stm32_combophy_disable_clocks(combophy);
+
+	pm_runtime_put_noidle(dev);
+
+	return 0;
+}
+
+static int stm32_combophy_init(struct phy *phy)
+{
+	struct stm32_combophy *combophy = phy_get_drvdata(phy);
+	struct device *dev = combophy->dev;
+	int ret;
+
+	pm_runtime_get_noresume(dev);
+
+	ret = stm32_combophy_enable_clocks(combophy);
+	if (ret) {
+		dev_err(dev, "Clock enable failed %d\n", ret);
+		pm_runtime_put_noidle(dev);
+		return ret;
+	}
+
+	ret = stm32_combophy_set_mode(combophy);
+	if (ret) {
+		dev_err(dev, "combophy mode not set\n");
+		stm32_combophy_disable_clocks(combophy);
+		pm_runtime_put_noidle(dev);
+		return ret;
+	}
+
+	ret = stm32_combophy_pll_init(combophy);
+	if (ret) {
+		stm32_combophy_disable_clocks(combophy);
+		pm_runtime_put_noidle(dev);
+		return ret;
+	}
+
+	pm_runtime_disable(dev);
+	pm_runtime_set_active(dev);
+	pm_runtime_enable(dev);
+
+	combophy->is_init = true;
+
+	return ret;
+}
+
+static const struct phy_ops stm32_combophy_phy_data = {
+	.init = stm32_combophy_init,
+	.exit = stm32_combophy_exit,
+	.owner = THIS_MODULE
+};
+
+static irqreturn_t stm32_combophy_irq_wakeup_handler(int irq, void *dev_id)
+{
+	return IRQ_HANDLED;
+}
+
+static int stm32_combophy_probe(struct platform_device *pdev)
+{
+	struct stm32_combophy *combophy;
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct phy_provider *phy_provider;
+	int ret, irq;
+
+	combophy = devm_kzalloc(dev, sizeof(*combophy), GFP_KERNEL);
+	if (!combophy)
+		return -ENOMEM;
+
+	combophy->dev = dev;
+
+	dev_set_drvdata(dev, combophy);
+
+	combophy->base = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(combophy->base))
+		return PTR_ERR(combophy->base);
+
+	combophy->phy_clk = devm_clk_get(dev, "apb");
+	if (IS_ERR(combophy->phy_clk))
+		return dev_err_probe(dev, PTR_ERR(combophy->phy_clk),
+				     "Failed to get PHY clock source\n");
+
+	combophy->ker_clk = devm_clk_get(dev, "ker");
+	if (IS_ERR(combophy->ker_clk))
+		return dev_err_probe(dev, PTR_ERR(combophy->ker_clk),
+				     "Failed to get PHY internal clock source\n");
+
+	combophy->pad_clk = devm_clk_get_optional(dev, "pad");
+	if (IS_ERR(combophy->pad_clk))
+		return dev_err_probe(dev, PTR_ERR(combophy->pad_clk),
+				     "Failed to get PHY external clock source\n");
+
+	combophy->phy_reset = devm_reset_control_get(dev, "phy");
+	if (IS_ERR(combophy->phy_reset))
+		return dev_err_probe(dev, PTR_ERR(combophy->phy_reset),
+				     "Failed to get PHY reset\n");
+
+	combophy->regmap = syscon_regmap_lookup_by_phandle(np, "st,syscfg");
+	if (IS_ERR(combophy->regmap))
+		return dev_err_probe(dev, PTR_ERR(combophy->regmap),
+				     "No syscfg phandle specified\n");
+
+	combophy->phy = devm_phy_create(dev, NULL, &stm32_combophy_phy_data);
+	if (IS_ERR(combophy->phy))
+		return dev_err_probe(dev, PTR_ERR(combophy->phy),
+				     "failed to create PCIe/USB3 ComboPHY\n");
+
+	if (device_property_read_bool(dev, "wakeup-source")) {
+		irq = platform_get_irq(pdev, 0);
+		if (irq < 0)
+			return dev_err_probe(dev, irq, "failed to get IRQ\n");
+		combophy->irq_wakeup = irq;
+
+		ret = devm_request_threaded_irq(dev, combophy->irq_wakeup, NULL,
+						stm32_combophy_irq_wakeup_handler, IRQF_ONESHOT,
+						NULL, NULL);
+		if (ret)
+			return dev_err_probe(dev, ret, "unable to request wake IRQ %d\n",
+						 combophy->irq_wakeup);
+	}
+
+	ret = devm_pm_runtime_enable(dev);
+	if (ret)
+		return dev_err_probe(dev, ret, "Failed to enable pm runtime\n");
+
+	phy_set_drvdata(combophy->phy, combophy);
+
+	phy_provider = devm_of_phy_provider_register(dev, stm32_combophy_xlate);
+
+	return PTR_ERR_OR_ZERO(phy_provider);
+}
+
+static const struct dev_pm_ops stm32_combophy_pm_ops = {
+	NOIRQ_SYSTEM_SLEEP_PM_OPS(stm32_combophy_suspend_noirq,
+				  stm32_combophy_resume_noirq)
+};
+
+static const struct of_device_id stm32_combophy_of_match[] = {
+	{ .compatible = "st,stm32mp25-combophy", },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, stm32_combophy_of_match);
+
+static struct platform_driver stm32_combophy_driver = {
+	.probe = stm32_combophy_probe,
+	.driver = {
+		   .name = "stm32-combophy",
+		   .of_match_table = stm32_combophy_of_match,
+		   .pm = pm_sleep_ptr(&stm32_combophy_pm_ops)
+	}
+};
+
+module_platform_driver(stm32_combophy_driver);
+
+MODULE_AUTHOR("Christian Bruel <christian.bruel at foss.st.com>");
+MODULE_DESCRIPTION("STM32MP25 Combophy USB3/PCIe controller driver");
+MODULE_LICENSE("GPL");
-- 
2.34.1



From christian.bruel at foss.st.com  Fri Aug 16 06:20:53 2024
From: christian.bruel at foss.st.com (Christian Bruel)
Date: Fri, 16 Aug 2024 15:20:53 +0200
Subject: [PATCH v2 1/5] MAINTAINERS: add entry for ST STM32MP25 COMBOPHY driver
In-Reply-To: <20240816132058.920870-1-christian.bruel@foss.st.com>
References: <20240816132058.920870-1-christian.bruel@foss.st.com>
Message-ID: <20240816132058.920870-2-christian.bruel@foss.st.com>

Add myself as STM32MP25 COMBOPHY maintainer

Signed-off-by: Christian Bruel <christian.bruel at foss.st.com>
---
 MAINTAINERS | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f328373463b0..258fb57ccff5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -21910,6 +21910,12 @@ F:	arch/m68k/kernel/*sun3*
 F:	arch/m68k/sun3*/
 F:	drivers/net/ethernet/i825xx/sun3*
 
+STMICROELECTRONICS STMP32MP25 USB3/PCIE COMBOPHY DRIVER
+M:	Christian Bruel <christian.bruel at foss.st.com>
+S:	Maintained
+F:	Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml
+F:	drivers/phy/st/phy-stm32-combophy.c
+
 SUN4I LOW RES ADC ATTACHED TABLET KEYS DRIVER
 M:	Hans de Goede <hdegoede at redhat.com>
 L:	linux-input at vger.kernel.org
-- 
2.34.1



From christian.bruel at foss.st.com  Fri Aug 16 06:20:54 2024
From: christian.bruel at foss.st.com (Christian Bruel)
Date: Fri, 16 Aug 2024 15:20:54 +0200
Subject: [PATCH v2 2/5] dt-bindings: phy: Add STM32MP25 COMBOPHY bindings
In-Reply-To: <20240816132058.920870-1-christian.bruel@foss.st.com>
References: <20240816132058.920870-1-christian.bruel@foss.st.com>
Message-ID: <20240816132058.920870-3-christian.bruel@foss.st.com>

Document the bindings for STM32 COMBOPHY interface, used to support
the PCIe and USB3 stm32mp25 drivers.
Following entries can be used to tune caracterisation parameters
 - st,output-micro-ohms and st,output-vswing-microvolt bindings entries
to tune the impedance and voltage swing using discrete simulation results
 - st,rx-equalizer register to set the internal rx equalizer filter value.

Signed-off-by: Christian Bruel <christian.bruel at foss.st.com>
---
 .../bindings/phy/st,stm32-combophy.yaml       | 144 ++++++++++++++++++
 1 file changed, 144 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml

diff --git a/Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml b/Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml
new file mode 100644
index 000000000000..c33a843b83a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml
@@ -0,0 +1,144 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/st,stm32-combophy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STM32MP25 USB3/PCIe COMBOPHY
+
+maintainers:
+  - Christian Bruel <christian.bruel at foss.st.com>
+
+description:
+  Single lane PHY shared (exclusive) between the USB3 and PCIe controllers.
+  Supports 5Gbit/s for USB3 and PCIe gen2 or 2.5Gbit/s for PCIe gen1.
+
+properties:
+  compatible:
+    const: st,stm32mp25-combophy
+
+  reg:
+    maxItems: 1
+
+  "#phy-cells":
+    const: 1
+    description: |
+      The cells contain the following arguments.
+
+      - description: The PHY type
+          enum:
+            - PHY_TYPE_USB3
+            - PHY_TYPE_PCIE
+
+  clocks:
+    minItems: 2
+    items:
+      - description: apb Bus clock mandatory to access registers.
+      - description: ker Internal RCC reference clock for USB3 or PCIe
+      - description: pad Optional on board clock input for PCIe only. Typically an
+                     external 100Mhz oscillator wired on dedicated CLKIN pad. Used as reference
+                     clock input instead of the ker
+
+  clock-names:
+    minItems: 2
+    items:
+      - const: apb
+      - const: ker
+      - const: pad
+
+  resets:
+    maxItems: 1
+
+  reset-names:
+    const: phy
+
+  power-domains:
+    maxItems: 1
+
+  wakeup-source: true
+
+  interrupts:
+    maxItems: 1
+    description: interrupt used for wakeup
+
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
+  st,syscfg:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description: Phandle to the SYSCON entry required for configuring PCIe
+      or USB3.
+
+  st,ssc-on:
+    type: boolean
+    description:
+      A boolean property whose presence indicates that the SSC for common clock
+      needs to be set.
+
+  st,rx-equalizer:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    minimum: 0
+    maximum: 7
+    default: 2
+    description:
+      A 3 bit value to tune the RX fixed equalizer setting for optimal eye compliance
+
+  st,output-micro-ohms:
+    minimum: 3999000
+    maximum: 6090000
+    default: 4968000
+    description:
+      A value property to tune the Single Ended Output Impedance, simulations results
+      at 25C for a VDDP=0.8V. The hardware accepts discrete values in this range.
+
+  st,output-vswing-microvolt:
+    minimum: 442000
+    maximum: 803000
+    default: 803000
+    description:
+      A value property in microvolt to tune the Single Ended Output Voltage Swing to change the
+      Vlo, Vhi for a VDDP = 0.8V. The hardware accepts discrete values in this range.
+
+required:
+  - compatible
+  - reg
+  - st,syscfg
+  - '#phy-cells'
+  - resets
+  - reset-names
+  - clocks
+  - clock-names
+
+allOf:
+  - if:
+      required:
+        - wakeup-source
+    then:
+      anyOf:
+        - required: [interrupts]
+        - required: [interrupts-extended]
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/st,stm32mp25-rcc.h>
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/reset/st,stm32mp25-rcc.h>
+
+    combophy: phy at 480c0000 {
+        compatible = "st,stm32mp25-combophy";
+        reg = <0x480c0000 0x1000>;
+        #phy-cells = <1>;
+        clocks = <&rcc CK_BUS_USB3PCIEPHY>, <&rcc CK_KER_USB3PCIEPHY>;
+        clock-names = "apb", "ker";
+        resets = <&rcc USB3PCIEPHY_R>;
+        reset-names = "phy";
+        st,syscfg = <&syscfg>;
+        access-controllers = <&rifsc 67>;
+        power-domains = <&CLUSTER_PD>;
+        wakeup-source;
+        interrupts-extended = <&exti1 45 IRQ_TYPE_EDGE_FALLING>;
+    };
+...
-- 
2.34.1



From christian.bruel at foss.st.com  Fri Aug 16 06:20:56 2024
From: christian.bruel at foss.st.com (Christian Bruel)
Date: Fri, 16 Aug 2024 15:20:56 +0200
Subject: [PATCH v2 4/5] arm64: dts: st: Add combophy node on stm32mp251
In-Reply-To: <20240816132058.920870-1-christian.bruel@foss.st.com>
References: <20240816132058.920870-1-christian.bruel@foss.st.com>
Message-ID: <20240816132058.920870-5-christian.bruel@foss.st.com>

Add support for COMBOPHY which is used either by the USB3 and PCIe
controller.
USB3 or PCIe mode is done with phy_set_mode().
PCIe internal reference clock can be generated from the internal clock
source or optionnaly from an external 100Mhz pad.

Signed-off-by: Christian Bruel <christian.bruel at foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp251.dtsi | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
index 1167cf63d7e8..0d38763d9317 100644
--- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
@@ -7,6 +7,7 @@
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/reset/st,stm32mp25-rcc.h>
 #include <dt-bindings/regulator/st,stm32mp25-regulator.h>
+#include <dt-bindings/phy/phy.h>
 
 / {
 	#address-cells = <2>;
@@ -518,6 +519,22 @@ i2c8: i2c at 46040000 {
 				status = "disabled";
 			};
 
+			combophy: phy at 480c0000 {
+				compatible = "st,stm32mp25-combophy";
+				reg = <0x480c0000 0x1000>;
+				#phy-cells = <1>;
+				clocks = <&rcc CK_BUS_USB3PCIEPHY>, <&rcc CK_KER_USB3PCIEPHY>;
+				clock-names = "apb", "ker";
+				resets = <&rcc USB3PCIEPHY_R>;
+				reset-names = "phy";
+				st,syscfg = <&syscfg>;
+				access-controllers = <&rifsc 67>;
+				power-domains = <&CLUSTER_PD>;
+				wakeup-source;
+				interrupts-extended = <&exti1 45 IRQ_TYPE_EDGE_FALLING>;
+				status = "disabled";
+			};
+
 			sdmmc1: mmc at 48220000 {
 				compatible = "st,stm32mp25-sdmmc2", "arm,pl18x", "arm,primecell";
 				arm,primecell-periphid = <0x00353180>;
-- 
2.34.1



From christian.bruel at foss.st.com  Fri Aug 16 06:20:57 2024
From: christian.bruel at foss.st.com (Christian Bruel)
Date: Fri, 16 Aug 2024 15:20:57 +0200
Subject: [PATCH v2 5/5] arm64: dts: st: Enable COMBOPHY on the stm32mp257f-ev1 board
In-Reply-To: <20240816132058.920870-1-christian.bruel@foss.st.com>
References: <20240816132058.920870-1-christian.bruel@foss.st.com>
Message-ID: <20240816132058.920870-6-christian.bruel@foss.st.com>

Enable the COMBOPHY with external pad clock on stm32mp257f-ev1
board, to be used for the PCIe clock provider.

Signed-off-by: Christian Bruel <christian.bruel at foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp257f-ev1.dts | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts b/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
index 214191a8322b..bcf84d533cb2 100644
--- a/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
+++ b/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
@@ -27,6 +27,14 @@ chosen {
 		stdout-path = "serial0:115200n8";
 	};
 
+	clocks {
+		pad_clk: pad-clk {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <100000000>;
+		};
+	};
+
 	memory at 80000000 {
 		device_type = "memory";
 		reg = <0x0 0x80000000 0x1 0x0>;
@@ -50,6 +58,12 @@ &arm_wdt {
 	status = "okay";
 };
 
+&combophy {
+	clocks = <&rcc CK_BUS_USB3PCIEPHY>, <&rcc CK_KER_USB3PCIEPHY>, <&pad_clk>;
+	clock-names = "apb", "ker", "pad";
+	status = "okay";
+};
+
 &ethernet2 {
 	pinctrl-names = "default", "sleep";
 	pinctrl-0 = <&eth2_rgmii_pins_a>;
-- 
2.34.1



From robh at kernel.org  Fri Aug 16 15:37:10 2024
From: robh at kernel.org (Rob Herring)
Date: Fri, 16 Aug 2024 16:37:10 -0600
Subject: [PATCH v3 06/19] dt-bindings: display: imx: Add i.MX8qxp Display
 Controller command sequencer
In-Reply-To: <20240724092950.752536-7-victor.liu@nxp.com>
References: <20240724092950.752536-1-victor.liu@nxp.com>
 <20240724092950.752536-7-victor.liu@nxp.com>
Message-ID: <20240816223710.GA2394350-robh@kernel.org>

On Wed, Jul 24, 2024 at 05:29:37PM +0800, Liu Ying wrote:
> i.MX8qxp Display Controller contains a command sequencer is designed to
> autonomously process command lists.
> 
> Signed-off-by: Liu Ying <victor.liu at nxp.com>
> ---
> v3:
> * New patch. (Rob)
> 
>  .../imx/fsl,imx8qxp-dc-command-sequencer.yaml | 67 +++++++++++++++++++
>  1 file changed, 67 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-command-sequencer.yaml
> 
> diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-command-sequencer.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-command-sequencer.yaml
> new file mode 100644
> index 000000000000..2e0e8e40a185
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-command-sequencer.yaml
> @@ -0,0 +1,67 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dc-command-sequencer.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Freescale i.MX8qxp Display Controller Command Sequencer
> +
> +description: |
> +  The Command Sequencer is designed to autonomously process command lists.
> +  By that it can load setups into the DC configuration and synchronize to
> +  hardware events.  This releases a system's CPU from workload, because it
> +  does not need to wait for certain events.  Also it simplifies SW architecture,
> +  because no interrupt handlers are required.  Setups are read via AXI bus,
> +  while write access to configuration registers occurs directly via an internal
> +  bus.  This saves bandwidth for the AXI interconnect and improves the system
> +  architecture in terms of safety aspects.
> +
> +maintainers:
> +  - Liu Ying <victor.liu at nxp.com>
> +
> +properties:
> +  compatible:
> +    const: fsl,imx8qxp-dc-command-sequencer
> +
> +  reg:
> +    maxItems: 1
> +
> +  clocks:
> +    maxItems: 1
> +
> +  interrupts:
> +    maxItems: 5
> +
> +  interrupt-names:
> +    items:
> +      - const: error
> +      - const: sw0
> +      - const: sw1
> +      - const: sw2
> +      - const: sw3
> +
> +  fsl,iram:
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +    description: phandle pointing to the mmio-sram device node

'sram' is the standard property for this.

> +
> +required:
> +  - compatible
> +  - reg
> +  - clocks
> +  - interrupts
> +  - interrupt-names
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/clock/imx8-lpcg.h>
> +
> +    command-sequencer at 56180400 {
> +        compatible = "fsl,imx8qxp-dc-command-sequencer";
> +        reg = <0x56180400 0x1a4>;
> +        clocks = <&dc0_lpcg IMX_LPCG_CLK_5>;
> +        interrupt-parent = <&dc0_intc>;
> +        interrupts = <36>, <37>, <38>, <39>, <40>;
> +        interrupt-names = "error", "sw0", "sw1", "sw2", "sw3";
> +    };
> -- 
> 2.34.1
> 


From robh at kernel.org  Fri Aug 16 15:38:27 2024
From: robh at kernel.org (Rob Herring)
Date: Fri, 16 Aug 2024 16:38:27 -0600
Subject: [PATCH v3 05/19] dt-bindings: display: imx: Add i.MX8qxp Display
 Controller AXI performance counter
In-Reply-To: <20240724092950.752536-6-victor.liu@nxp.com>
References: <20240724092950.752536-1-victor.liu@nxp.com>
 <20240724092950.752536-6-victor.liu@nxp.com>
Message-ID: <20240816223827.GB2394350-robh@kernel.org>

On Wed, Jul 24, 2024 at 05:29:36PM +0800, Liu Ying wrote:
> i.MX8qxp Display Controller contains a AXI performance counter which allows
> measurement of average bandwidth and latency during operation.
> 
> Signed-off-by: Liu Ying <victor.liu at nxp.com>
> ---
> v3:
> * New patch. (Rob)
> 
>  ...sl,imx8qxp-dc-axi-performance-counter.yaml | 57 +++++++++++++++++++
>  1 file changed, 57 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-axi-performance-counter.yaml

Reviewed-by: Rob Herring (Arm) <robh at kernel.org>


From robh at kernel.org  Fri Aug 16 15:39:57 2024
From: robh at kernel.org (Rob Herring)
Date: Fri, 16 Aug 2024 16:39:57 -0600
Subject: [PATCH v3 04/19] dt-bindings: display: imx: Add i.MX8qxp Display
 Controller pixel engine
In-Reply-To: <20240724092950.752536-5-victor.liu@nxp.com>
References: <20240724092950.752536-1-victor.liu@nxp.com>
 <20240724092950.752536-5-victor.liu@nxp.com>
Message-ID: <20240816223957.GC2394350-robh@kernel.org>

On Wed, Jul 24, 2024 at 05:29:35PM +0800, Liu Ying wrote:
> i.MX8qxp Display Controller pixel engine consists of all processing units
> that operate in the AXI bus clock domain.  Command sequencer and interrupt
> controller of the Display Controller work with AXI bus clock, but they are
> not in pixel engine.
> 
> Signed-off-by: Liu Ying <victor.liu at nxp.com>
> ---
> v3:
> * No change.
> 
> v2:
> * Drop fsl,dc-*-id DT properties from example. (Krzysztof)
> * Fix register range sizes in example.
> 
>  .../imx/fsl,imx8qxp-dc-pixel-engine.yaml      | 250 ++++++++++++++++++
>  1 file changed, 250 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-pixel-engine.yaml

Reviewed-by: Rob Herring (Arm) <robh at kernel.org>


From robh at kernel.org  Fri Aug 16 15:40:52 2024
From: robh at kernel.org (Rob Herring)
Date: Fri, 16 Aug 2024 16:40:52 -0600
Subject: [PATCH v3 03/19] dt-bindings: display: imx: Add i.MX8qxp Display
 Controller display engine
In-Reply-To: <20240724092950.752536-4-victor.liu@nxp.com>
References: <20240724092950.752536-1-victor.liu@nxp.com>
 <20240724092950.752536-4-victor.liu@nxp.com>
Message-ID: <20240816224052.GD2394350-robh@kernel.org>

On Wed, Jul 24, 2024 at 05:29:34PM +0800, Liu Ying wrote:
> i.MX8qxp Display Controller display engine consists of all processing units
> that operate in a display clock domain.
> 
> Signed-off-by: Liu Ying <victor.liu at nxp.com>
> ---
> v3:
> * No change.
> 
> v2:
> * Drop fsl,dc-*-id DT properties. (Krzysztof)
> * Drop port property. (Krzysztof)
> * Fix register range sizes in example.
> 
>  .../imx/fsl,imx8qxp-dc-display-engine.yaml    | 152 ++++++++++++++++++
>  1 file changed, 152 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-display-engine.yaml

Reviewed-by: Rob Herring (Arm) <robh at kernel.org>



From robh at kernel.org  Fri Aug 16 15:43:52 2024
From: robh at kernel.org (Rob Herring)
Date: Fri, 16 Aug 2024 16:43:52 -0600
Subject: [PATCH v3 01/19] dt-bindings: display: imx: Add i.MX8qxp Display
 Controller processing units
In-Reply-To: <20240724092950.752536-2-victor.liu@nxp.com>
References: <20240724092950.752536-1-victor.liu@nxp.com>
 <20240724092950.752536-2-victor.liu@nxp.com>
Message-ID: <20240816224352.GE2394350-robh@kernel.org>

On Wed, Jul 24, 2024 at 05:29:32PM +0800, Liu Ying wrote:
> Freescale i.MX8qxp Display Controller is implemented as construction set of
> building blocks with unified concept and standardized interfaces.  Document
> all existing processing units.
> 
> Signed-off-by: Liu Ying <victor.liu at nxp.com>
> ---
> v3:
> * Combine fsl,imx8qxp-dc-fetchunit-common.yaml,
>   fsl,imx8qxp-dc-fetchlayer.yaml and fsl,imx8qxp-dc-fetchwarp.yaml
>   into 1 schema doc fsl,imx8qxp-dc-fetchunit.yaml. (Rob)
> * Document all processing units. (Rob)
> 
> v2:
> * Drop fsl,dc-*-id DT properties. (Krzysztof)
> * Add port property to fsl,imx8qxp-dc-tcon.yaml. (Krzysztof)
> * Fix register range sizes in examples.
> 
>  .../display/imx/fsl,imx8qxp-dc-blitblend.yaml |  41 +++++
>  .../display/imx/fsl,imx8qxp-dc-clut.yaml      |  44 ++++++
>  .../imx/fsl,imx8qxp-dc-constframe.yaml        |  44 ++++++
>  .../display/imx/fsl,imx8qxp-dc-dither.yaml    |  45 ++++++
>  .../display/imx/fsl,imx8qxp-dc-extdst.yaml    |  72 +++++++++
>  .../display/imx/fsl,imx8qxp-dc-fetchunit.yaml | 141 ++++++++++++++++++
>  .../display/imx/fsl,imx8qxp-dc-filter.yaml    |  43 ++++++
>  .../display/imx/fsl,imx8qxp-dc-framegen.yaml  |  64 ++++++++
>  .../display/imx/fsl,imx8qxp-dc-gammacor.yaml  |  32 ++++
>  .../imx/fsl,imx8qxp-dc-layerblend.yaml        |  39 +++++
>  .../display/imx/fsl,imx8qxp-dc-matrix.yaml    |  44 ++++++
>  .../display/imx/fsl,imx8qxp-dc-rop.yaml       |  43 ++++++
>  .../display/imx/fsl,imx8qxp-dc-safety.yaml    |  34 +++++
>  .../imx/fsl,imx8qxp-dc-scaling-engine.yaml    |  83 +++++++++++
>  .../display/imx/fsl,imx8qxp-dc-signature.yaml |  53 +++++++
>  .../display/imx/fsl,imx8qxp-dc-store.yaml     |  96 ++++++++++++
>  .../display/imx/fsl,imx8qxp-dc-tcon.yaml      |  45 ++++++
>  17 files changed, 963 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-blitblend.yaml
>  create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-clut.yaml
>  create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-constframe.yaml
>  create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-dither.yaml
>  create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-extdst.yaml
>  create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-fetchunit.yaml
>  create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-filter.yaml
>  create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-framegen.yaml
>  create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-gammacor.yaml
>  create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-layerblend.yaml
>  create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-matrix.yaml
>  create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-rop.yaml
>  create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-safety.yaml
>  create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-scaling-engine.yaml
>  create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-signature.yaml
>  create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-store.yaml
>  create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-tcon.yaml

Reviewed-by: Rob Herring (Arm) <robh at kernel.org>


From robh at kernel.org  Fri Aug 16 15:45:48 2024
From: robh at kernel.org (Rob Herring)
Date: Fri, 16 Aug 2024 16:45:48 -0600
Subject: [PATCH v3 02/19] dt-bindings: display: imx: Add i.MX8qxp Display
 Controller blit engine
In-Reply-To: <20240724092950.752536-3-victor.liu@nxp.com>
References: <20240724092950.752536-1-victor.liu@nxp.com>
 <20240724092950.752536-3-victor.liu@nxp.com>
Message-ID: <20240816224548.GF2394350-robh@kernel.org>

On Wed, Jul 24, 2024 at 05:29:33PM +0800, Liu Ying wrote:
> i.MX8qxp Display Controller contains a blit engine for raster graphics.
> It may read up to 3 source images from memory and computes one destination
> image from it, which is written back to memory.
> 
> Signed-off-by: Liu Ying <victor.liu at nxp.com>
> ---
> v3:
> * New patch. (Rob)
> 
>  .../imx/fsl,imx8qxp-dc-blit-engine.yaml       | 204 ++++++++++++++++++
>  1 file changed, 204 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-blit-engine.yaml

Reviewed-by: Rob Herring (Arm) <robh at kernel.org>


From dsimic at manjaro.org  Fri Aug 16 23:52:05 2024
From: dsimic at manjaro.org (Dragan Simic)
Date: Sat, 17 Aug 2024 08:52:05 +0200
Subject: [PATCH] phy: phy-rockchip-inno-usb2: Handle failed extcon
 allocation better
In-Reply-To: <4927264.xgNZFEDtJV@diego>
References: <5fa7796d71e2f46344e972bc98a54539f55b6109.1723551599.git.dsimic@manjaro.org>
 <4927264.xgNZFEDtJV@diego>
Message-ID: <93d7cfcf3ce97f22e29cc93241b65bc1@manjaro.org>

Hello Heiko,

On 2024-08-15 18:12, Heiko St?bner wrote:
> Am Dienstag, 13. August 2024, 20:38:17 CEST schrieb Dragan Simic:
>> Return the actual error code upon failure to allocate extcon device, 
>> instead
>> of hardcoding -ENOMEM.  While there, produce an appropriate error 
>> message.
>> 
>> Signed-off-by: Dragan Simic <dsimic at manjaro.org>
>> ---
>>  drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 6 ++++--
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>> 
>> diff --git a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c 
>> b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
>> index 4f71373ae6e1..d33418a1e7a8 100644
>> --- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
>> +++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
>> @@ -434,8 +434,10 @@ static int 
>> rockchip_usb2phy_extcon_register(struct rockchip_usb2phy *rphy)
>>  		edev = devm_extcon_dev_allocate(rphy->dev,
>>  						rockchip_usb2phy_extcon_cable);
>> 
>> -		if (IS_ERR(edev))
>> -			return -ENOMEM;
>> +		if (IS_ERR(edev)) {
>> +			dev_err(rphy->dev, "failed to allocate extcon device\n");
>> +			return PTR_ERR(edev);
>> +		}
> 
> maybe even use dev_err_probe?
> 
> rockchip_usb2phy_extcon_register() gets called from the probe function,
> so even using it is also sematically correct ;-) .

Good suggestion, thanks!  I'll use dev_err_probe() in the v2, albeit it
also calls for turning this into a small patch series that additionally
replaces dev_err() with dev_err_probe() in the rockchip_usb2phy_probe()
function, for consistency. :)

>>  		ret = devm_extcon_dev_register(rphy->dev, edev);
>>  		if (ret) {
>> 


From krzk at kernel.org  Sat Aug 17 02:16:07 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Sat, 17 Aug 2024 11:16:07 +0200
Subject: [PATCH v2 1/5] MAINTAINERS: add entry for ST STM32MP25 COMBOPHY
 driver
In-Reply-To: <20240816132058.920870-2-christian.bruel@foss.st.com>
References: <20240816132058.920870-1-christian.bruel@foss.st.com>
 <20240816132058.920870-2-christian.bruel@foss.st.com>
Message-ID: <63398875-6bd1-4c58-a343-9c490a15deb2@kernel.org>

On 16/08/2024 15:20, Christian Bruel wrote:
> Add myself as STM32MP25 COMBOPHY maintainer
> 
> Signed-off-by: Christian Bruel <christian.bruel at foss.st.com>
> ---
>  MAINTAINERS | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f328373463b0..258fb57ccff5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -21910,6 +21910,12 @@ F:	arch/m68k/kernel/*sun3*
>  F:	arch/m68k/sun3*/
>  F:	drivers/net/ethernet/i825xx/sun3*
>  
> +STMICROELECTRONICS STMP32MP25 USB3/PCIE COMBOPHY DRIVER
> +M:	Christian Bruel <christian.bruel at foss.st.com>
> +S:	Maintained
> +F:	Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml
> +F:	drivers/phy/st/phy-stm32-combophy.c

There are no such files. Organize your patchset in bisectable way.

Best regards,
Krzysztof



From robh at kernel.org  Sun Aug 18 07:24:02 2024
From: robh at kernel.org (Rob Herring (Arm))
Date: Sun, 18 Aug 2024 08:24:02 -0600
Subject: [PATCH v3 08/19] dt-bindings: display: imx: Add i.MX8qxp Display
 Controller
In-Reply-To: <20240724092950.752536-9-victor.liu@nxp.com>
References: <20240724092950.752536-1-victor.liu@nxp.com>
 <20240724092950.752536-9-victor.liu@nxp.com>
Message-ID: <172399104139.23572.10090663935384596561.robh@kernel.org>


On Wed, 24 Jul 2024 17:29:39 +0800, Liu Ying wrote:
> i.MX8qxp Display Controller(DC) is comprised of three main components that
> include a blit engine for 2D graphics accelerations, display controller for
> display output processing, as well as a command sequencer.
> 
> Signed-off-by: Liu Ying <victor.liu at nxp.com>
> ---
> v3:
> * No change.
> 
> v2:
> * Drop fsl,dc-*-id DT properties from example. (Krzysztof)
> * Use generic pmu pattern property. (Krzysztof)
> 
>  .../bindings/display/imx/fsl,imx8qxp-dc.yaml  | 236 ++++++++++++++++++
>  1 file changed, 236 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc.yaml
> 

Reviewed-by: Rob Herring (Arm) <robh at kernel.org>



From robh at kernel.org  Sun Aug 18 09:04:24 2024
From: robh at kernel.org (Rob Herring)
Date: Sun, 18 Aug 2024 10:04:24 -0600
Subject: [PATCH v2 2/5] dt-bindings: phy: Add STM32MP25 COMBOPHY bindings
In-Reply-To: <20240816132058.920870-3-christian.bruel@foss.st.com>
References: <20240816132058.920870-1-christian.bruel@foss.st.com>
 <20240816132058.920870-3-christian.bruel@foss.st.com>
Message-ID: <20240818160424.GA156214-robh@kernel.org>

On Fri, Aug 16, 2024 at 03:20:54PM +0200, Christian Bruel wrote:
> Document the bindings for STM32 COMBOPHY interface, used to support
> the PCIe and USB3 stm32mp25 drivers.
> Following entries can be used to tune caracterisation parameters
>  - st,output-micro-ohms and st,output-vswing-microvolt bindings entries
> to tune the impedance and voltage swing using discrete simulation results
>  - st,rx-equalizer register to set the internal rx equalizer filter value.
> 
> Signed-off-by: Christian Bruel <christian.bruel at foss.st.com>
> ---
>  .../bindings/phy/st,stm32-combophy.yaml       | 144 ++++++++++++++++++
>  1 file changed, 144 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml
> 
> diff --git a/Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml b/Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml
> new file mode 100644
> index 000000000000..c33a843b83a3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml
> @@ -0,0 +1,144 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/st,stm32-combophy.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: STMicroelectronics STM32MP25 USB3/PCIe COMBOPHY
> +
> +maintainers:
> +  - Christian Bruel <christian.bruel at foss.st.com>
> +
> +description:
> +  Single lane PHY shared (exclusive) between the USB3 and PCIe controllers.
> +  Supports 5Gbit/s for USB3 and PCIe gen2 or 2.5Gbit/s for PCIe gen1.
> +
> +properties:
> +  compatible:
> +    const: st,stm32mp25-combophy
> +
> +  reg:
> +    maxItems: 1
> +
> +  "#phy-cells":
> +    const: 1
> +    description: |
> +      The cells contain the following arguments.
> +
> +      - description: The PHY type
> +          enum:
> +            - PHY_TYPE_USB3
> +            - PHY_TYPE_PCIE
> +
> +  clocks:
> +    minItems: 2
> +    items:
> +      - description: apb Bus clock mandatory to access registers.
> +      - description: ker Internal RCC reference clock for USB3 or PCIe
> +      - description: pad Optional on board clock input for PCIe only. Typically an
> +                     external 100Mhz oscillator wired on dedicated CLKIN pad. Used as reference
> +                     clock input instead of the ker
> +
> +  clock-names:
> +    minItems: 2
> +    items:
> +      - const: apb
> +      - const: ker
> +      - const: pad
> +
> +  resets:
> +    maxItems: 1
> +
> +  reset-names:
> +    const: phy
> +
> +  power-domains:
> +    maxItems: 1
> +
> +  wakeup-source: true
> +
> +  interrupts:
> +    maxItems: 1
> +    description: interrupt used for wakeup
> +
> +  access-controllers:
> +    minItems: 1
> +    maxItems: 2
> +
> +  st,syscfg:
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +    description: Phandle to the SYSCON entry required for configuring PCIe
> +      or USB3.
> +
> +  st,ssc-on:
> +    type: boolean
> +    description:
> +      A boolean property whose presence indicates that the SSC for common clock
> +      needs to be set.
> +
> +  st,rx-equalizer:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    minimum: 0
> +    maximum: 7
> +    default: 2
> +    description:
> +      A 3 bit value to tune the RX fixed equalizer setting for optimal eye compliance
> +
> +  st,output-micro-ohms:
> +    minimum: 3999000
> +    maximum: 6090000
> +    default: 4968000
> +    description:
> +      A value property to tune the Single Ended Output Impedance, simulations results
> +      at 25C for a VDDP=0.8V. The hardware accepts discrete values in this range.
> +
> +  st,output-vswing-microvolt:
> +    minimum: 442000
> +    maximum: 803000
> +    default: 803000
> +    description:
> +      A value property in microvolt to tune the Single Ended Output Voltage Swing to change the
> +      Vlo, Vhi for a VDDP = 0.8V. The hardware accepts discrete values in this range.
> +
> +required:
> +  - compatible
> +  - reg
> +  - st,syscfg
> +  - '#phy-cells'
> +  - resets
> +  - reset-names
> +  - clocks
> +  - clock-names
> +
> +allOf:
> +  - if:
> +      required:
> +        - wakeup-source
> +    then:
> +      anyOf:
> +        - required: [interrupts]
> +        - required: [interrupts-extended]

Drop this if/then. We should have this somewhere common as it applies to 
all.

Reviewed-by: Rob Herring (Arm) <robh at kernel.org>


From krzysztof.kozlowski at linaro.org  Sun Aug 18 10:28:35 2024
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 18 Aug 2024 19:28:35 +0200
Subject: [PATCH] dt-bindings: phy: socionext,uniphier: add top-level constraints
Message-ID: <20240818172835.121757-1-krzysztof.kozlowski@linaro.org>

Properties with variable number of items per each device are expected to
have widest constraints in top-level "properties:" block and further
customized (narrowed) in "if:then:".  Add missing top-level constraints
for clock-names and reset-names.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 .../bindings/phy/socionext,uniphier-ahci-phy.yaml         | 8 ++++++--
 .../bindings/phy/socionext,uniphier-pcie-phy.yaml         | 8 ++++++--
 .../bindings/phy/socionext,uniphier-usb3hs-phy.yaml       | 7 +++++--
 .../bindings/phy/socionext,uniphier-usb3ss-phy.yaml       | 7 +++++--
 4 files changed, 22 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml b/Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml
index de3cffc850bc..e34b875a1bb8 100644
--- a/Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml
@@ -30,13 +30,17 @@ properties:
     minItems: 1
     maxItems: 2
 
-  clock-names: true
+  clock-names:
+    minItems: 1
+    maxItems: 6
 
   resets:
     minItems: 2
     maxItems: 6
 
-  reset-names: true
+  reset-names:
+    minItems: 2
+    maxItems: 6
 
 allOf:
   - if:
diff --git a/Documentation/devicetree/bindings/phy/socionext,uniphier-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/socionext,uniphier-pcie-phy.yaml
index b3ed2f74a414..9fc0e87c508e 100644
--- a/Documentation/devicetree/bindings/phy/socionext,uniphier-pcie-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-pcie-phy.yaml
@@ -31,13 +31,17 @@ properties:
     minItems: 1
     maxItems: 2
 
-  clock-names: true
+  clock-names:
+    minItems: 1
+    maxItems: 2
 
   resets:
     minItems: 1
     maxItems: 2
 
-  reset-names: true
+  reset-names:
+    minItems: 1
+    maxItems: 2
 
   socionext,syscon:
     $ref: /schemas/types.yaml#/definitions/phandle
diff --git a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml
index 2107d98ace15..25c4159f86e4 100644
--- a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml
@@ -34,12 +34,15 @@ properties:
     minItems: 2
     maxItems: 3
 
-  clock-names: true
+  clock-names:
+    minItems: 2
+    maxItems: 3
 
   resets:
     maxItems: 2
 
-  reset-names: true
+  reset-names:
+    maxItems: 2
 
   vbus-supply:
     description: A phandle to the regulator for USB VBUS
diff --git a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.yaml b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.yaml
index 8f5aa6238bf3..1f663e9901da 100644
--- a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.yaml
@@ -35,12 +35,15 @@ properties:
     minItems: 2
     maxItems: 3
 
-  clock-names: true
+  clock-names:
+    minItems: 2
+    maxItems: 3
 
   resets:
     maxItems: 2
 
-  reset-names: true
+  reset-names:
+    maxItems: 2
 
   vbus-supply:
     description: A phandle to the regulator for USB VBUS, only for USB host
-- 
2.43.0



From victor.liu at nxp.com  Mon Aug 19 00:37:14 2024
From: victor.liu at nxp.com (Liu Ying)
Date: Mon, 19 Aug 2024 15:37:14 +0800
Subject: [PATCH v3 06/19] dt-bindings: display: imx: Add i.MX8qxp Display
 Controller command sequencer
In-Reply-To: <20240816223710.GA2394350-robh@kernel.org>
References: <20240724092950.752536-1-victor.liu@nxp.com>
 <20240724092950.752536-7-victor.liu@nxp.com>
 <20240816223710.GA2394350-robh@kernel.org>
Message-ID: <d5558c70-ca9a-4a68-9e88-9efd353d1250@nxp.com>

On 08/17/2024, Rob Herring wrote:
> On Wed, Jul 24, 2024 at 05:29:37PM +0800, Liu Ying wrote:
>> i.MX8qxp Display Controller contains a command sequencer is designed to
>> autonomously process command lists.
>>
>> Signed-off-by: Liu Ying <victor.liu at nxp.com>
>> ---
>> v3:
>> * New patch. (Rob)
>>
>>  .../imx/fsl,imx8qxp-dc-command-sequencer.yaml | 67 +++++++++++++++++++
>>  1 file changed, 67 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-command-sequencer.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-command-sequencer.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-command-sequencer.yaml
>> new file mode 100644
>> index 000000000000..2e0e8e40a185
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-command-sequencer.yaml
>> @@ -0,0 +1,67 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dc-command-sequencer.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Freescale i.MX8qxp Display Controller Command Sequencer
>> +
>> +description: |
>> +  The Command Sequencer is designed to autonomously process command lists.
>> +  By that it can load setups into the DC configuration and synchronize to
>> +  hardware events.  This releases a system's CPU from workload, because it
>> +  does not need to wait for certain events.  Also it simplifies SW architecture,
>> +  because no interrupt handlers are required.  Setups are read via AXI bus,
>> +  while write access to configuration registers occurs directly via an internal
>> +  bus.  This saves bandwidth for the AXI interconnect and improves the system
>> +  architecture in terms of safety aspects.
>> +
>> +maintainers:
>> +  - Liu Ying <victor.liu at nxp.com>
>> +
>> +properties:
>> +  compatible:
>> +    const: fsl,imx8qxp-dc-command-sequencer
>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  clocks:
>> +    maxItems: 1
>> +
>> +  interrupts:
>> +    maxItems: 5
>> +
>> +  interrupt-names:
>> +    items:
>> +      - const: error
>> +      - const: sw0
>> +      - const: sw1
>> +      - const: sw2
>> +      - const: sw3
>> +
>> +  fsl,iram:
>> +    $ref: /schemas/types.yaml#/definitions/phandle
>> +    description: phandle pointing to the mmio-sram device node
> 
> 'sram' is the standard property for this.

Will use 'sram' in next version.  Thanks.

> 
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +  - clocks
>> +  - interrupts
>> +  - interrupt-names
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +    #include <dt-bindings/clock/imx8-lpcg.h>
>> +
>> +    command-sequencer at 56180400 {
>> +        compatible = "fsl,imx8qxp-dc-command-sequencer";
>> +        reg = <0x56180400 0x1a4>;
>> +        clocks = <&dc0_lpcg IMX_LPCG_CLK_5>;
>> +        interrupt-parent = <&dc0_intc>;
>> +        interrupts = <36>, <37>, <38>, <39>, <40>;
>> +        interrupt-names = "error", "sw0", "sw1", "sw2", "sw3";
>> +    };
>> -- 
>> 2.34.1
>>
> 

-- 
Regards,
Liu Ying



From robh at kernel.org  Mon Aug 19 10:14:01 2024
From: robh at kernel.org (Rob Herring (Arm))
Date: Mon, 19 Aug 2024 11:14:01 -0600
Subject: [PATCH] dt-bindings: phy: socionext,uniphier: add top-level
 constraints
In-Reply-To: <20240818172835.121757-1-krzysztof.kozlowski@linaro.org>
References: <20240818172835.121757-1-krzysztof.kozlowski@linaro.org>
Message-ID: <172408764120.1697315.1961179049740064713.robh@kernel.org>


On Sun, 18 Aug 2024 19:28:35 +0200, Krzysztof Kozlowski wrote:
> Properties with variable number of items per each device are expected to
> have widest constraints in top-level "properties:" block and further
> customized (narrowed) in "if:then:".  Add missing top-level constraints
> for clock-names and reset-names.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> ---
>  .../bindings/phy/socionext,uniphier-ahci-phy.yaml         | 8 ++++++--
>  .../bindings/phy/socionext,uniphier-pcie-phy.yaml         | 8 ++++++--
>  .../bindings/phy/socionext,uniphier-usb3hs-phy.yaml       | 7 +++++--
>  .../bindings/phy/socionext,uniphier-usb3ss-phy.yaml       | 7 +++++--
>  4 files changed, 22 insertions(+), 8 deletions(-)
> 

Reviewed-by: Rob Herring (Arm) <robh at kernel.org>



From aford173 at gmail.com  Tue Aug 20 19:49:03 2024
From: aford173 at gmail.com (Adam Ford)
Date: Tue, 20 Aug 2024 21:49:03 -0500
Subject: drm/bridge/imx8mp-hdmi-tx: Allow inexact pixel clock frequencies
 (Was: [PATCH V8 10/12] drm/bridge: imx: add bridge wrapper driver for i.MX8MP
 DWC HDMI)
In-Reply-To: <cd03ecb1-100e-4699-95ed-d837a2802dc7@kontron.de>
References: <20240203165307.7806-1-aford173@gmail.com> <20240203165307.7806-11-aford173@gmail.com>
 <Zm_UzO4Jmm7Aykcm@atmark-techno.com> <22a3f5266260dd3915269ae3eec7724f7537eb55.camel@pengutronix.de>
 <cd03ecb1-100e-4699-95ed-d837a2802dc7@kontron.de>
Message-ID: <CAHCN7x+bh_ka250hOCenO3Et6re4EJ=5TG8=kpG1hs-PV0dQxQ@mail.gmail.com>

On Thu, Aug 15, 2024 at 3:19?AM Frieder Schrempf
<frieder.schrempf at kontron.de> wrote:
>
> Hi Dominique, hi Lucas,
>
> On 17.06.24 6:32 PM, Lucas Stach wrote:
> > Hi Dominique,
> >
> > Am Montag, dem 17.06.2024 um 15:16 +0900 schrieb Dominique MARTINET:
> >> Adam Ford wrote on Sat, Feb 03, 2024 at 10:52:50AM -0600:
> >>> From: Lucas Stach <l.stach at pengutronix.de>
> >>>
> >>> Add a simple wrapper driver for the DWC HDMI bridge driver that
> >>> implements the few bits that are necessary to abstract the i.MX8MP
> >>> SoC integration.
> >>
> >> Hi Lucas, Adam,
> >> (trimmed ccs a bit)
> >>
> >> First, thank you for the effort of upstreaming all of this!! It's really
> >> appreciated, and with display working I'll really be wanting to upstream
> >> our DTS as well as soon as I have time (which is going to be a while,
> >> but better late than never ?)
> >>
> >> Until then, it's been a few months but I've got a question on this bit:
> >>
> >>> diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
> >>> new file mode 100644
> >>> index 000000000000..89fc432ac611
> >>> --- /dev/null
> >>> +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
> >>> +static enum drm_mode_status
> >>> +imx8mp_hdmi_mode_valid(struct dw_hdmi *dw_hdmi, void *data,
> >>> +                  const struct drm_display_info *info,
> >>> +                  const struct drm_display_mode *mode)
> >>> +{
> >>> +   struct imx8mp_hdmi *hdmi = (struct imx8mp_hdmi *)data;
> >>> +
> >>> +   if (mode->clock < 13500)
> >>> +           return MODE_CLOCK_LOW;
> >>> +
> >>> +   if (mode->clock > 297000)
> >>> +           return MODE_CLOCK_HIGH;
> >>> +
> >>> +   if (clk_round_rate(hdmi->pixclk, mode->clock * 1000) !=
> >>> +       mode->clock * 1000)
> >>> +           return MODE_CLOCK_RANGE;
> >>
> >> Do you know why such a check is here?
> >
> > Sending a HDMI signal with a different rate than what the display
> > expects rarely ends well, so this check avoids that.
> >
> > However, this check is a bit overcautious in that it only allows exact
> > rate matches. IIRC HDMI allows a rate mismatch of +- 0.5%, so this
> > check could be relaxed quite a bit to allow for that.
>
> I checked with a 1080p display that reports 23 possible modes via EDID.
> Out of these 15 are accepted by the driver with the strict check.
>
> Two more would be accepted with a relaxed check that allows a 0.5% margin.
>
> For the remaining six modes, the pixel clock would deviate up to ~5%
> from what the display expects. Still, if I remove the check altogether,
> all 23 modes seem to work just fine.
>
> >>
> >> When plugging in a screen with no frequency identically supported in its
> >> EDID this check causes the screen to stay black, and we've been telling
> >> customers to override the EDID but it's a huge pain.
> >>
> >> Commit 6ad082bee902 ("phy: freescale: add Samsung HDMI PHY") already
> >> "fixed" the samsung hdmi phy driver to return the next frequency if an
> >> exact match hasn't been found (NXP tree's match frequencies exactly, but
> >> this gets the first clock with pixclk <= rate), so if this check is also
> >> relaxed our displays would work out of the box.
> >>
> >> I also don't see any other bridge doing this kind of check.
> >> drivers/gpu/drm/bridge/imx/imx93-mipi-dsi.c has a similar check with a
> >> 0.5% leeway, and all the other drivers don't check anything.
> >> If you want to add some level of safety, I think we could make this work
> >> with a 5% margin easily... Printing a warning in dmesg could work if
> >> you're worried about artifacts, but litteraly anything is better than a
> >> black screen with no error message in my opinion.
> >>
> >>
> >> In practice the screen I'm looking at has an EDID which only supports
> >> 51.2MHz and the closest frequency supported by the Samsung HDMI phy is
> >> 50.4MHz, so that's a ~1.5% difference and it'd be great if it could work
> >> out of the box.
> >
> > For rate mismatches larger than the 0.5% allowed by the HDMI spec it
> > would be better to actually add PHY PLL parameters matching those
> > rates.
>
> I'd really like to be able to add more PHY PLL setpoints for displays
> that use non-CEA-861 modes. Unfortunately I didn't manage to figure out
> the fractional-n PLL parameter calculation so far.
>
> The i.MX8MP Reference Manual provides formulas to calculate the
> parameters based on the register values and I tried to make sense of it
> using the existing register values in the driver. But somehow it doesn't
> add up for me.
>
> Lucas, did you already work with the PLL parameters? By any chance, do
> you now how the math behind them works?

I spent a little time trying to understand it a bit.  I created a PMS
calculator similar to the one used on the DSI controller, except that
the M seems to be fixed at a value of 62 per the data sheet, so it's
more of a PS calculator.

Anyway, When I run my P-S calculator to generate the 'best rate' I get
a value that's usually 0.2% variance from nominal, but I only verified
a handful of values:

Several which were +0.2%
297600000 vs 297000000 (4k at 30)
148800000 vs 148500000 (1080p60)
74400 vs 74200

One value was -0.16%
24800000 vs 25200000

If the M value was a bit more flexible, we might be able to reduce
that variance more.

If / when I get some time, I might play with trying to disable the
fractional mode and just use the PMS calculator for simplicity despite
the inaccuracy.  Maybe we could fall back to using the PMS calculator
if the desired frequency isn't in the look-up-table.

adam

>
> >
> > We could potentially add some more leeway for displays like yours that
> > aren't actually HDMI (as it doesn't seem to have a standard HDMI
> > resolution). But that's more of a last resort option, as it may
> > introduce other problems for displays that aren't as tolerant with
> > their input rates. Remember the mode_valid call is used to filter modes
> > that aren't compatible with the source, so for a display with multiple
> > modes allowing too much leeway may lead to incompatible modes not
> > getting tossed, in turn allowing userspace to set a mode that the
> > display may not like due to too much rate deviation, instead of only
> > presenting a list of valid modes. This again would present the user
> > with a black-screen without warning situation.
>
> What about adding some option to relax or remove the check for debugging
> purposes? Maybe combined with printing a warning message?
>
> I agree that we should prevent incompatible modes from passing the
> filter, but it would be really helpful if people had an easy way to
> relax/remove the check to see whether their display could potentially
> work without them needing to modify and recompile the kernel.
>
> Thanks
> Frieder


From dominique.martinet at atmark-techno.com  Tue Aug 20 20:57:45 2024
From: dominique.martinet at atmark-techno.com (Dominique MARTINET)
Date: Wed, 21 Aug 2024 12:57:45 +0900
Subject: drm/bridge/imx8mp-hdmi-tx: Allow inexact pixel clock frequencies
 (Was: [PATCH V8 10/12] drm/bridge: imx: add bridge wrapper driver for
 i.MX8MP DWC HDMI)
In-Reply-To: <CAHCN7x+bh_ka250hOCenO3Et6re4EJ=5TG8=kpG1hs-PV0dQxQ@mail.gmail.com>
References: <20240203165307.7806-1-aford173@gmail.com>
 <20240203165307.7806-11-aford173@gmail.com>
 <Zm_UzO4Jmm7Aykcm@atmark-techno.com>
 <22a3f5266260dd3915269ae3eec7724f7537eb55.camel@pengutronix.de>
 <cd03ecb1-100e-4699-95ed-d837a2802dc7@kontron.de>
 <CAHCN7x+bh_ka250hOCenO3Et6re4EJ=5TG8=kpG1hs-PV0dQxQ@mail.gmail.com>
Message-ID: <ZsVluV50NvuGGHFX@atmark-techno.com>

Adam Ford wrote on Tue, Aug 20, 2024 at 09:49:03PM -0500:
> > > However, this check is a bit overcautious in that it only allows exact
> > > rate matches. IIRC HDMI allows a rate mismatch of +- 0.5%, so this
> > > check could be relaxed quite a bit to allow for that.
> >
> > I checked with a 1080p display that reports 23 possible modes via EDID.
> > Out of these 15 are accepted by the driver with the strict check.
> >
> > Two more would be accepted with a relaxed check that allows a 0.5% margin.
> >
> > For the remaining six modes, the pixel clock would deviate up to ~5%
> > from what the display expects. Still, if I remove the check altogether,
> > all 23 modes seem to work just fine.

I can confirm the displays I tested also seem pretty tolerant in
practice (up to ~3-4% at least), but I agree with Lucas that this isn't
something we can rely on for a general purpose driver as having examples
of things being tolerant doesn't mean all hardware will be as flexible..

> > I'd really like to be able to add more PHY PLL setpoints for displays
> > that use non-CEA-861 modes. Unfortunately I didn't manage to figure out
> > the fractional-n PLL parameter calculation so far.
> >
> > The i.MX8MP Reference Manual provides formulas to calculate the
> > parameters based on the register values and I tried to make sense of it
> > using the existing register values in the driver. But somehow it doesn't
> > add up for me.
> >
> > Lucas, did you already work with the PLL parameters? By any chance, do
> > you now how the math behind them works?
> 
> I spent a little time trying to understand it a bit.  I created a PMS
> calculator similar to the one used on the DSI controller,

Great! I'll admit this also flies over my head and I don't have the
time to study this, so this is much appreciated.

> except that
> the M seems to be fixed at a value of 62 per the data sheet, so it's
> more of a PS calculator.

Hmm... PHY_REG2 in the datasheet only lists '0011_1110b - 62' as
example(?) values, but it doesn't say other values are reserved either,
I'm not sure what to make of it.
In the current driver PHY_REG_02 (driver macro) is assigned the first
field of .pll_div_regs, which goes anywhere from 0x4b to 0x7b -- pretty
far from 62(0x3e)...

Since other frequencies have been adjusting this main diviser ratio we
actually tried copying neighboring values and adjusting only that reg 2
(so the M if I get this right?), but the end result ended up not
synchronizing properly every time... We didn't have time to check with a
scope if the generated signal was ugly or if it just didn't lock
properly, but the display worked when we just re-used the neighboring
values without changing anything despite being ~3-4% off, so we took the
easy way out here and didn't dig much further.

> Anyway, When I run my P-S calculator to generate the 'best rate' I get
> a value that's usually 0.2% variance from nominal, but I only verified
> a handful of values:
> 
> Several which were +0.2%
> 297600000 vs 297000000 (4k at 30)
> 148800000 vs 148500000 (1080p60)
> 74400 vs 74200
> 
> One value was -0.16%
> 24800000 vs 25200000
> 
> If the M value was a bit more flexible, we might be able to reduce
> that variance more.

Yes, I think the M value could be more flexible, but that'd require
checking if it actually works, whereas having slightly off frequencies
will most likely be OK so I don't think it's worth the effort -- happy
to stick to what the datasheet describes.

> If / when I get some time, I might play with trying to disable the
> fractional mode and just use the PMS calculator for simplicity despite
> the inaccuracy.  Maybe we could fall back to using the PMS calculator
> if the desired frequency isn't in the look-up-table.

That'd be greatly appreciated, I don't have any strong opinion on
whether that should completely replace the table, or only be used if
there is no exact match in the table as these are values we know will
work; but we can definitely test any patch you can throw at us here.


Cheers,
-- 
Dominique




From dsimic at manjaro.org  Wed Aug 21 00:37:53 2024
From: dsimic at manjaro.org (Dragan Simic)
Date: Wed, 21 Aug 2024 09:37:53 +0200
Subject: [PATCH v2 1/3] phy: phy-rockchip-inno-usb2: Perform trivial code cleanups
In-Reply-To: <cover.1724225528.git.dsimic@manjaro.org>
References: <cover.1724225528.git.dsimic@manjaro.org>
Message-ID: <14167d6b025e18d2a06ee429feea6551ef6f9c44.1724225528.git.dsimic@manjaro.org>

Perform a few trivial code cleanups, e.g. to obey the reverse Christmas tree
rule, to avoid use of "{ ... }" code blocks where they aren't really needed,
or to avoid line wrapping by using the 100-column width better.

No intended functional changes are introduced by these code cleanups.

Signed-off-by: Dragan Simic <dsimic at manjaro.org>
---
 drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 27 +++++++------------
 1 file changed, 9 insertions(+), 18 deletions(-)

diff --git a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
index 4f71373ae6e1..113bfc717ff0 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
@@ -418,9 +418,9 @@ rockchip_usb2phy_clk480m_register(struct rockchip_usb2phy *rphy)
 
 static int rockchip_usb2phy_extcon_register(struct rockchip_usb2phy *rphy)
 {
-	int ret;
 	struct device_node *node = rphy->dev->of_node;
 	struct extcon_dev *edev;
+	int ret;
 
 	if (of_property_read_bool(node, "extcon")) {
 		edev = extcon_get_edev_by_phandle(rphy->dev, 0);
@@ -445,7 +445,6 @@ static int rockchip_usb2phy_extcon_register(struct rockchip_usb2phy *rphy)
 	}
 
 	rphy->edev = edev;
-
 	return 0;
 }
 
@@ -1327,21 +1326,19 @@ static int rockchip_usb2phy_probe(struct platform_device *pdev)
 	struct rockchip_usb2phy *rphy;
 	const struct rockchip_usb2phy_cfg *phy_cfgs;
 	unsigned int reg;
-	int index, ret;
+	int index = 0, ret;
 
 	rphy = devm_kzalloc(dev, sizeof(*rphy), GFP_KERNEL);
 	if (!rphy)
 		return -ENOMEM;
 
 	if (!dev->parent || !dev->parent->of_node) {
 		rphy->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,usbgrf");
 		if (IS_ERR(rphy->grf)) {
 			dev_err(dev, "failed to locate usbgrf\n");
 			return PTR_ERR(rphy->grf);
 		}
-	}
-
-	else {
+	} else {
 		rphy->grf = syscon_node_to_regmap(dev->parent->of_node);
 		if (IS_ERR(rphy->grf))
 			return PTR_ERR(rphy->grf);
@@ -1358,16 +1355,14 @@ static int rockchip_usb2phy_probe(struct platform_device *pdev)
 	}
 
 	if (of_property_read_u32_index(np, "reg", 0, &reg)) {
-		dev_err(dev, "the reg property is not assigned in %pOFn node\n",
-			np);
+		dev_err(dev, "the reg property is not assigned in %pOFn node\n", np);
 		return -EINVAL;
 	}
 
 	/* support address_cells=2 */
 	if (of_property_count_u32_elems(np, "reg") > 2 && reg == 0) {
 		if (of_property_read_u32_index(np, "reg", 1, &reg)) {
-			dev_err(dev, "the reg property is not assigned in %pOFn node\n",
-				np);
+			dev_err(dev, "the reg property is not assigned in %pOFn node\n", np);
 			return -EINVAL;
 		}
 	}
@@ -1386,8 +1381,7 @@ static int rockchip_usb2phy_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
-	/* find out a proper config which can be matched with dt. */
-	index = 0;
+	/* find a proper config that can be matched with the DT */
 	do {
 		if (phy_cfgs[index].reg == reg) {
 			rphy->phy_cfg = &phy_cfgs[index];
@@ -1407,10 +1401,9 @@ static int rockchip_usb2phy_probe(struct platform_device *pdev)
 		return PTR_ERR(rphy->phy_reset);
 
 	rphy->clk = devm_clk_get_optional_enabled(dev, "phyclk");
-	if (IS_ERR(rphy->clk)) {
+	if (IS_ERR(rphy->clk))
 		return dev_err_probe(&pdev->dev, PTR_ERR(rphy->clk),
 				     "failed to get phyclk\n");
-	}
 
 	ret = rockchip_usb2phy_clk480m_register(rphy);
 	if (ret) {
@@ -1446,13 +1439,11 @@ static int rockchip_usb2phy_probe(struct platform_device *pdev)
 
 		/* initialize otg/host port separately */
 		if (of_node_name_eq(child_np, "host-port")) {
-			ret = rockchip_usb2phy_host_port_init(rphy, rport,
-							      child_np);
+			ret = rockchip_usb2phy_host_port_init(rphy, rport, child_np);
 			if (ret)
 				goto put_child;
 		} else {
-			ret = rockchip_usb2phy_otg_port_init(rphy, rport,
-							     child_np);
+			ret = rockchip_usb2phy_otg_port_init(rphy, rport, child_np);
 			if (ret)
 				goto put_child;
 		}


From dsimic at manjaro.org  Wed Aug 21 00:37:52 2024
From: dsimic at manjaro.org (Dragan Simic)
Date: Wed, 21 Aug 2024 09:37:52 +0200
Subject: [PATCH v2 0/3] Improve error handling in Rockchip Inno USB 2.0 PHY driver
Message-ID: <cover.1724225528.git.dsimic@manjaro.org>

This is a small series that improves error handling in the probe path
of the Rockchip Innosilicon USB 2.0 PHY driver, by returning the actual
error code in one place and by using dev_err_probe() properly in multiple
places.  It also performs a bunch of small, rather trivial code cleanups,
to make the code neater and a bit easier to read.

Changes in v2:
  - Expanded into a small series, after a suggestion from Heiko [1] to
    use dev_err_probe(), because it all happens in the probe path

Link to v1: https://lore.kernel.org/linux-phy/5fa7796d71e2f46344e972bc98a54539f55b6109.1723551599.git.dsimic at manjaro.org/T/#u

[1] https://lore.kernel.org/linux-phy/4927264.xgNZFEDtJV at diego/

Dragan Simic (3):
  phy: phy-rockchip-inno-usb2: Perform trivial code cleanups
  phy: phy-rockchip-inno-usb2: Handle failed extcon allocation better
  phy: phy-rockchip-inno-usb2: Improve error handling while probing

 drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 63 ++++++++-----------
 1 file changed, 25 insertions(+), 38 deletions(-)



From dsimic at manjaro.org  Wed Aug 21 00:37:54 2024
From: dsimic at manjaro.org (Dragan Simic)
Date: Wed, 21 Aug 2024 09:37:54 +0200
Subject: [PATCH v2 2/3] phy: phy-rockchip-inno-usb2: Handle failed extcon allocation better
In-Reply-To: <cover.1724225528.git.dsimic@manjaro.org>
References: <cover.1724225528.git.dsimic@manjaro.org>
Message-ID: <96200baf794a0c451f3bbc3f5530b8cf0e359dfc.1724225528.git.dsimic@manjaro.org>

Return the actual error code upon failure to allocate extcon device, instead
of hardcoding -ENOMEM.  Use dev_err_probe() to also log appropriate messages,
which is fine because the containing function is used in the probe path.

Helped-by: Heiko Stubner <heiko at sntech.de>
Signed-off-by: Dragan Simic <dsimic at manjaro.org>
---
 drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
index 113bfc717ff0..05af46dda11d 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
@@ -435,7 +435,8 @@ static int rockchip_usb2phy_extcon_register(struct rockchip_usb2phy *rphy)
 						rockchip_usb2phy_extcon_cable);
 
 		if (IS_ERR(edev))
-			return -ENOMEM;
+			return dev_err_probe(rphy->dev, PTR_ERR(edev),
+					     "failed to allocate extcon device\n");
 
 		ret = devm_extcon_dev_register(rphy->dev, edev);
 		if (ret) {


From dsimic at manjaro.org  Wed Aug 21 00:37:55 2024
From: dsimic at manjaro.org (Dragan Simic)
Date: Wed, 21 Aug 2024 09:37:55 +0200
Subject: [PATCH v2 3/3] phy: phy-rockchip-inno-usb2: Improve error handling while probing
In-Reply-To: <cover.1724225528.git.dsimic@manjaro.org>
References: <cover.1724225528.git.dsimic@manjaro.org>
Message-ID: <866445027a4f41165c872f494b04c218b6e67b09.1724225528.git.dsimic@manjaro.org>

Improve error handling in the probe path by using function dev_err_probe()
where appropriate, and by no longer using it rather pointlessly in one place
that actually produces a single, hardcoded error code.

Signed-off-by: Dragan Simic <dsimic at manjaro.org>
---
 drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 33 ++++++++-----------
 1 file changed, 14 insertions(+), 19 deletions(-)

diff --git a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
index 05af46dda11d..30b6134365ec 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
@@ -424,25 +424,22 @@ static int rockchip_usb2phy_extcon_register(struct rockchip_usb2phy *rphy)
 
 	if (of_property_read_bool(node, "extcon")) {
 		edev = extcon_get_edev_by_phandle(rphy->dev, 0);
-		if (IS_ERR(edev)) {
-			if (PTR_ERR(edev) != -EPROBE_DEFER)
-				dev_err(rphy->dev, "Invalid or missing extcon\n");
-			return PTR_ERR(edev);
-		}
+		if (IS_ERR(edev))
+			return dev_err_probe(rphy->dev, PTR_ERR(edev),
+					     "invalid or missing extcon\n");
 	} else {
 		/* Initialize extcon device */
 		edev = devm_extcon_dev_allocate(rphy->dev,
 						rockchip_usb2phy_extcon_cable);
 
 		if (IS_ERR(edev))
 			return dev_err_probe(rphy->dev, PTR_ERR(edev),
 					     "failed to allocate extcon device\n");
 
 		ret = devm_extcon_dev_register(rphy->dev, edev);
-		if (ret) {
-			dev_err(rphy->dev, "failed to register extcon device\n");
-			return ret;
-		}
+		if (ret)
+			return dev_err_probe(rphy->dev, ret,
+					     "failed to register extcon device\n");
 	}
 
 	rphy->edev = edev;
@@ -1375,8 +1372,10 @@ static int rockchip_usb2phy_probe(struct platform_device *pdev)
 	rphy->irq = platform_get_irq_optional(pdev, 0);
 	platform_set_drvdata(pdev, rphy);
 
-	if (!phy_cfgs)
-		return dev_err_probe(dev, -EINVAL, "phy configs are not assigned!\n");
+	if (!phy_cfgs) {
+		dev_err(dev, "phy configs are not assigned\n");
+		return -EINVAL;
+	}
 
 	ret = rockchip_usb2phy_extcon_register(rphy);
 	if (ret)
@@ -1407,10 +1406,8 @@ static int rockchip_usb2phy_probe(struct platform_device *pdev)
 				     "failed to get phyclk\n");
 
 	ret = rockchip_usb2phy_clk480m_register(rphy);
-	if (ret) {
-		dev_err(dev, "failed to register 480m output clock\n");
-		return ret;
-	}
+	if (ret)
+		return dev_err_probe(dev, ret, "failed to register 480m output clock\n");
 
 	if (rphy->phy_cfg->phy_tuning) {
 		ret = rphy->phy_cfg->phy_tuning(rphy);
@@ -1430,8 +1427,7 @@ static int rockchip_usb2phy_probe(struct platform_device *pdev)
 
 		phy = devm_phy_create(dev, child_np, &rockchip_usb2phy_ops);
 		if (IS_ERR(phy)) {
-			dev_err_probe(dev, PTR_ERR(phy), "failed to create phy\n");
-			ret = PTR_ERR(phy);
+			ret = dev_err_probe(dev, PTR_ERR(phy), "failed to create phy\n");
 			goto put_child;
 		}
 
@@ -1466,8 +1462,7 @@ static int rockchip_usb2phy_probe(struct platform_device *pdev)
 						"rockchip_usb2phy",
 						rphy);
 		if (ret) {
-			dev_err(rphy->dev,
-				"failed to request usb2phy irq handle\n");
+			dev_err_probe(rphy->dev, ret, "failed to request usb2phy irq handle\n");
 			goto put_child;
 		}
 	}


From abel.vesa at linaro.org  Wed Aug 21 01:38:59 2024
From: abel.vesa at linaro.org (Abel Vesa)
Date: Wed, 21 Aug 2024 11:38:59 +0300
Subject: [PATCH v2 0/2] phy: qcom: qmp-pcie: Add support for Gen4 4-lane
 mode for X1E80100
Message-ID: <20240821-x1e80100-phy-add-gen4x4-v2-0-c34db42230e9@linaro.org>

On all X Elite boards currently supported upstream, the NVMe sits
on the PCIe 6. Until now that has been configured in dual lane mode
only. The schematics reveal that the NVMe is actually using 4 lanes.
So add support for the 4-lane mode and document the compatible for it.

This patchset depends on:
https://lore.kernel.org/all/20240805-phy-qcom-qmp-pcie-write-all-tbls-second-port-v3-1-6967c6bf61d1 at linaro.org/

Signed-off-by: Abel Vesa <abel.vesa at linaro.org>
---
Changes in v2:
- Re-worded the commit message following Johan's suggestions.
- Picked up Krzysztof's R-b tag for the bindings patch
- Link to v1: https://lore.kernel.org/r/20240531-x1e80100-phy-add-gen4x4-v1-0-5c841dae7850 at linaro.org

---
Abel Vesa (2):
      dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Document the X1E80100 QMP PCIe PHY Gen4 x4
      phy: qcom: qmp-pcie: Add Gen4 4-lanes mode for X1E80100

 .../bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml   |  3 ++
 drivers/phy/qualcomm/phy-qcom-qmp-pcie.c           | 42 ++++++++++++++++++++++
 2 files changed, 45 insertions(+)
---
base-commit: 81528d2de965dafd6911a0f9a975fc30b25e7080
change-id: 20240531-x1e80100-phy-add-gen4x4-fa830a5505b6

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



From abel.vesa at linaro.org  Wed Aug 21 01:39:00 2024
From: abel.vesa at linaro.org (Abel Vesa)
Date: Wed, 21 Aug 2024 11:39:00 +0300
Subject: [PATCH v2 1/2] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy:
 Document the X1E80100 QMP PCIe PHY Gen4 x4
In-Reply-To: <20240821-x1e80100-phy-add-gen4x4-v2-0-c34db42230e9@linaro.org>
References: <20240821-x1e80100-phy-add-gen4x4-v2-0-c34db42230e9@linaro.org>
Message-ID: <20240821-x1e80100-phy-add-gen4x4-v2-1-c34db42230e9@linaro.org>

The sixth PCIe instance on X1E80100 can be used in either 4-lane mode or
2-lane mode. Document the 4-lane mode as a separate compatible.

Reviewed-by: Krzysztof Kozlowski <krzk at kernel.org>
Signed-off-by: Abel Vesa <abel.vesa at linaro.org>
---
 Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
index 03dbd02cf9e7..dcf4fa55fbba 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
@@ -40,6 +40,7 @@ properties:
       - qcom,sm8650-qmp-gen4x2-pcie-phy
       - qcom,x1e80100-qmp-gen3x2-pcie-phy
       - qcom,x1e80100-qmp-gen4x2-pcie-phy
+      - qcom,x1e80100-qmp-gen4x4-pcie-phy
 
   reg:
     minItems: 1
@@ -118,6 +119,7 @@ allOf:
           contains:
             enum:
               - qcom,sc8280xp-qmp-gen3x4-pcie-phy
+              - qcom,x1e80100-qmp-gen4x4-pcie-phy
     then:
       properties:
         reg:
@@ -169,6 +171,7 @@ allOf:
               - qcom,sc8280xp-qmp-gen3x1-pcie-phy
               - qcom,sc8280xp-qmp-gen3x2-pcie-phy
               - qcom,sc8280xp-qmp-gen3x4-pcie-phy
+              - qcom,x1e80100-qmp-gen4x4-pcie-phy
     then:
       properties:
         clocks:

-- 
2.34.1



From abel.vesa at linaro.org  Wed Aug 21 01:39:01 2024
From: abel.vesa at linaro.org (Abel Vesa)
Date: Wed, 21 Aug 2024 11:39:01 +0300
Subject: [PATCH v2 2/2] phy: qcom: qmp-pcie: Add Gen4 4-lanes mode for
 X1E80100
In-Reply-To: <20240821-x1e80100-phy-add-gen4x4-v2-0-c34db42230e9@linaro.org>
References: <20240821-x1e80100-phy-add-gen4x4-v2-0-c34db42230e9@linaro.org>
Message-ID: <20240821-x1e80100-phy-add-gen4x4-v2-2-c34db42230e9@linaro.org>

The sixth PCIe controller on X1E80100 can be used in either
4-lanes mode or 2-lanes mode. Add the configuration and compatible
for the 4-lane mode.

Signed-off-by: Abel Vesa <abel.vesa at linaro.org>
---
 drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 42 ++++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
index a7e2ce0c500d..df1ebc19c117 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
@@ -1266,6 +1266,10 @@ static const struct qmp_phy_init_tbl x1e80100_qmp_gen4x2_pcie_ln_shrd_tbl[] = {
 	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_SUMMER_CAL_SPD_MODE, 0x5b),
 };
 
+static const struct qmp_phy_init_tbl x1e80100_qmp_gen4x4_pcie_serdes_4ln_tbl[] = {
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_BIAS_EN_CLK_BUFLR_EN, 0x1c),
+};
+
 static const struct qmp_phy_init_tbl x1e80100_qmp_gen4x2_pcie_tx_tbl[] = {
 	QMP_PHY_INIT_CFG(QSERDES_V6_20_TX_RES_CODE_LANE_OFFSET_TX, 0x1d),
 	QMP_PHY_INIT_CFG(QSERDES_V6_20_TX_RES_CODE_LANE_OFFSET_RX, 0x03),
@@ -3654,6 +3658,41 @@ static const struct qmp_phy_cfg x1e80100_qmp_gen4x2_pciephy_cfg = {
 		.ln_shrd		= x1e80100_qmp_gen4x2_pcie_ln_shrd_tbl,
 		.ln_shrd_num		= ARRAY_SIZE(x1e80100_qmp_gen4x2_pcie_ln_shrd_tbl),
 	},
+
+	.reset_list		= sdm845_pciephy_reset_l,
+	.num_resets		= ARRAY_SIZE(sdm845_pciephy_reset_l),
+	.vreg_list		= sm8550_qmp_phy_vreg_l,
+	.num_vregs		= ARRAY_SIZE(sm8550_qmp_phy_vreg_l),
+	.regs			= pciephy_v6_regs_layout,
+
+	.pwrdn_ctrl		= SW_PWRDN | REFCLK_DRV_DSBL,
+	.phy_status		= PHYSTATUS_4_20,
+	.has_nocsr_reset	= true,
+};
+
+static const struct qmp_phy_cfg x1e80100_qmp_gen4x4_pciephy_cfg = {
+	.lanes = 4,
+
+	.offsets		= &qmp_pcie_offsets_v6_20,
+
+	.tbls = {
+		.serdes			= x1e80100_qmp_gen4x2_pcie_serdes_tbl,
+		.serdes_num		= ARRAY_SIZE(x1e80100_qmp_gen4x2_pcie_serdes_tbl),
+		.tx			= x1e80100_qmp_gen4x2_pcie_tx_tbl,
+		.tx_num			= ARRAY_SIZE(x1e80100_qmp_gen4x2_pcie_tx_tbl),
+		.rx			= x1e80100_qmp_gen4x2_pcie_rx_tbl,
+		.rx_num			= ARRAY_SIZE(x1e80100_qmp_gen4x2_pcie_rx_tbl),
+		.pcs			= x1e80100_qmp_gen4x2_pcie_pcs_tbl,
+		.pcs_num		= ARRAY_SIZE(x1e80100_qmp_gen4x2_pcie_pcs_tbl),
+		.pcs_misc		= x1e80100_qmp_gen4x2_pcie_pcs_misc_tbl,
+		.pcs_misc_num		= ARRAY_SIZE(x1e80100_qmp_gen4x2_pcie_pcs_misc_tbl),
+		.ln_shrd		= x1e80100_qmp_gen4x2_pcie_ln_shrd_tbl,
+		.ln_shrd_num		= ARRAY_SIZE(x1e80100_qmp_gen4x2_pcie_ln_shrd_tbl),
+	},
+
+	.serdes_4ln_tbl		= x1e80100_qmp_gen4x4_pcie_serdes_4ln_tbl,
+	.serdes_4ln_num		= ARRAY_SIZE(x1e80100_qmp_gen4x4_pcie_serdes_4ln_tbl),
+
 	.reset_list		= sdm845_pciephy_reset_l,
 	.num_resets		= ARRAY_SIZE(sdm845_pciephy_reset_l),
 	.vreg_list		= sm8550_qmp_phy_vreg_l,
@@ -4436,6 +4475,9 @@ static const struct of_device_id qmp_pcie_of_match_table[] = {
 	}, {
 		.compatible = "qcom,x1e80100-qmp-gen4x2-pcie-phy",
 		.data = &x1e80100_qmp_gen4x2_pciephy_cfg,
+	}, {
+		.compatible = "qcom,x1e80100-qmp-gen4x4-pcie-phy",
+		.data = &x1e80100_qmp_gen4x4_pciephy_cfg,
 	},
 	{ },
 };

-- 
2.34.1



From heiko at sntech.de  Wed Aug 21 01:39:54 2024
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Wed, 21 Aug 2024 10:39:54 +0200
Subject: [PATCH v2 1/3] phy: phy-rockchip-inno-usb2: Perform trivial code cleanups
In-Reply-To: <14167d6b025e18d2a06ee429feea6551ef6f9c44.1724225528.git.dsimic@manjaro.org>
References: <cover.1724225528.git.dsimic@manjaro.org>
 <14167d6b025e18d2a06ee429feea6551ef6f9c44.1724225528.git.dsimic@manjaro.org>
Message-ID: <5307900.6fTUFtlzNn@diego>

Am Mittwoch, 21. August 2024, 09:37:53 CEST schrieb Dragan Simic:
> Perform a few trivial code cleanups, e.g. to obey the reverse Christmas tree
> rule, to avoid use of "{ ... }" code blocks where they aren't really needed,
> or to avoid line wrapping by using the 100-column width better.
> 
> No intended functional changes are introduced by these code cleanups.
> 
> Signed-off-by: Dragan Simic <dsimic at manjaro.org>

> @@ -445,7 +445,6 @@ static int rockchip_usb2phy_extcon_register(struct rockchip_usb2phy *rphy)
>  	}
>  
>  	rphy->edev = edev;
> -
>  	return 0;
>  }

depending on how nitpicky we want to be, I'm not very fond of this change.
Assigning the extcon-dev and returning "0" are two different actions, and
I think most drivers do actually use a blank line between those.

But that really is just a style preference for me, so anyway

Reviewed-by: Heiko Stuebner <heiko at sntech.de>




From heiko at sntech.de  Wed Aug 21 01:41:07 2024
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Wed, 21 Aug 2024 10:41:07 +0200
Subject: [PATCH v2 2/3] phy: phy-rockchip-inno-usb2: Handle failed extcon
 allocation better
In-Reply-To: <96200baf794a0c451f3bbc3f5530b8cf0e359dfc.1724225528.git.dsimic@manjaro.org>
References: <cover.1724225528.git.dsimic@manjaro.org>
 <96200baf794a0c451f3bbc3f5530b8cf0e359dfc.1724225528.git.dsimic@manjaro.org>
Message-ID: <39189616.J2Yia2DhmK@diego>

Am Mittwoch, 21. August 2024, 09:37:54 CEST schrieb Dragan Simic:
> Return the actual error code upon failure to allocate extcon device, instead
> of hardcoding -ENOMEM.  Use dev_err_probe() to also log appropriate messages,
> which is fine because the containing function is used in the probe path.
> 
> Helped-by: Heiko Stubner <heiko at sntech.de>

How did I help with this? :-D

Reviewed-by: Heiko Stuebner <heiko at sntech.de>






From heiko at sntech.de  Wed Aug 21 01:44:00 2024
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Wed, 21 Aug 2024 10:44:00 +0200
Subject: [PATCH v2 3/3] phy: phy-rockchip-inno-usb2: Improve error handling while
 probing
In-Reply-To: <866445027a4f41165c872f494b04c218b6e67b09.1724225528.git.dsimic@manjaro.org>
References: <cover.1724225528.git.dsimic@manjaro.org>
 <866445027a4f41165c872f494b04c218b6e67b09.1724225528.git.dsimic@manjaro.org>
Message-ID: <12869965.VsHLxoZxqI@diego>

Am Mittwoch, 21. August 2024, 09:37:55 CEST schrieb Dragan Simic:
> Improve error handling in the probe path by using function dev_err_probe()
> where appropriate, and by no longer using it rather pointlessly in one place
> that actually produces a single, hardcoded error code.
> 
> Signed-off-by: Dragan Simic <dsimic at manjaro.org>

> @@ -1375,8 +1372,10 @@ static int rockchip_usb2phy_probe(struct platform_device *pdev)
>  	rphy->irq = platform_get_irq_optional(pdev, 0);
>  	platform_set_drvdata(pdev, rphy);
>  
> -	if (!phy_cfgs)
> -		return dev_err_probe(dev, -EINVAL, "phy configs are not assigned!\n");
> +	if (!phy_cfgs) {
> +		dev_err(dev, "phy configs are not assigned\n");
> +		return -EINVAL;
> +	}
>  
>  	ret = rockchip_usb2phy_extcon_register(rphy);
>  	if (ret)

I really don't understand the rationale here. Using dev_err_probe here 
is just fine and with that change you just introduce more lines of code
for exactly the same functionality?




From dsimic at manjaro.org  Wed Aug 21 01:53:14 2024
From: dsimic at manjaro.org (Dragan Simic)
Date: Wed, 21 Aug 2024 10:53:14 +0200
Subject: [PATCH v2 1/3] phy: phy-rockchip-inno-usb2: Perform trivial code
 cleanups
In-Reply-To: <5307900.6fTUFtlzNn@diego>
References: <cover.1724225528.git.dsimic@manjaro.org>
 <14167d6b025e18d2a06ee429feea6551ef6f9c44.1724225528.git.dsimic@manjaro.org>
 <5307900.6fTUFtlzNn@diego>
Message-ID: <83a33b5ad6dd13668b6d8733f5546725@manjaro.org>

Hello Heiko,

On 2024-08-21 10:39, Heiko St?bner wrote:
> Am Mittwoch, 21. August 2024, 09:37:53 CEST schrieb Dragan Simic:
>> Perform a few trivial code cleanups, e.g. to obey the reverse 
>> Christmas tree
>> rule, to avoid use of "{ ... }" code blocks where they aren't really 
>> needed,
>> or to avoid line wrapping by using the 100-column width better.
>> 
>> No intended functional changes are introduced by these code cleanups.
>> 
>> Signed-off-by: Dragan Simic <dsimic at manjaro.org>
> 
>> @@ -445,7 +445,6 @@ static int rockchip_usb2phy_extcon_register(struct 
>> rockchip_usb2phy *rphy)
>>  	}
>> 
>>  	rphy->edev = edev;
>> -
>>  	return 0;
>>  }
> 
> depending on how nitpicky we want to be, I'm not very fond of this 
> change.
> Assigning the extcon-dev and returning "0" are two different actions, 
> and
> I think most drivers do actually use a blank line between those.
> 
> But that really is just a style preference for me, so anyway
> 
> Reviewed-by: Heiko Stuebner <heiko at sntech.de>

Thanks for your review; I had similar thoughts, believe it or not. :)  
If
there will be v3, I'll bring the empty separator line back.


From dsimic at manjaro.org  Wed Aug 21 01:55:38 2024
From: dsimic at manjaro.org (Dragan Simic)
Date: Wed, 21 Aug 2024 10:55:38 +0200
Subject: [PATCH v2 2/3] phy: phy-rockchip-inno-usb2: Handle failed extcon
 allocation better
In-Reply-To: <39189616.J2Yia2DhmK@diego>
References: <cover.1724225528.git.dsimic@manjaro.org>
 <96200baf794a0c451f3bbc3f5530b8cf0e359dfc.1724225528.git.dsimic@manjaro.org>
 <39189616.J2Yia2DhmK@diego>
Message-ID: <8f1f70ffdf5f52347c47cad31bf0a7da@manjaro.org>

On 2024-08-21 10:41, Heiko St?bner wrote:
> Am Mittwoch, 21. August 2024, 09:37:54 CEST schrieb Dragan Simic:
>> Return the actual error code upon failure to allocate extcon device, 
>> instead
>> of hardcoding -ENOMEM.  Use dev_err_probe() to also log appropriate 
>> messages,
>> which is fine because the containing function is used in the probe 
>> path.
>> 
>> Helped-by: Heiko Stubner <heiko at sntech.de>
> 
> How did I help with this? :-D
> 
> Reviewed-by: Heiko Stuebner <heiko at sntech.de>

Thanks for your review.  Well, you suggested that dev_err_probe() is 
used. :)


From dsimic at manjaro.org  Wed Aug 21 02:09:03 2024
From: dsimic at manjaro.org (Dragan Simic)
Date: Wed, 21 Aug 2024 11:09:03 +0200
Subject: [PATCH v2 3/3] phy: phy-rockchip-inno-usb2: Improve error
 handling while probing
In-Reply-To: <12869965.VsHLxoZxqI@diego>
References: <cover.1724225528.git.dsimic@manjaro.org>
 <866445027a4f41165c872f494b04c218b6e67b09.1724225528.git.dsimic@manjaro.org>
 <12869965.VsHLxoZxqI@diego>
Message-ID: <486bddb6aad14d05a3fb2d876d0d9d0d@manjaro.org>

On 2024-08-21 10:44, Heiko St?bner wrote:
> Am Mittwoch, 21. August 2024, 09:37:55 CEST schrieb Dragan Simic:
>> Improve error handling in the probe path by using function 
>> dev_err_probe()
>> where appropriate, and by no longer using it rather pointlessly in one 
>> place
>> that actually produces a single, hardcoded error code.
>> 
>> Signed-off-by: Dragan Simic <dsimic at manjaro.org>
> 
>> @@ -1375,8 +1372,10 @@ static int rockchip_usb2phy_probe(struct 
>> platform_device *pdev)
>>  	rphy->irq = platform_get_irq_optional(pdev, 0);
>>  	platform_set_drvdata(pdev, rphy);
>> 
>> -	if (!phy_cfgs)
>> -		return dev_err_probe(dev, -EINVAL, "phy configs are not 
>> assigned!\n");
>> +	if (!phy_cfgs) {
>> +		dev_err(dev, "phy configs are not assigned\n");
>> +		return -EINVAL;
>> +	}
>> 
>>  	ret = rockchip_usb2phy_extcon_register(rphy);
>>  	if (ret)
> 
> I really don't understand the rationale here. Using dev_err_probe here
> is just fine and with that change you just introduce more lines of code
> for exactly the same functionality?

As we know, dev_err_probe() decides how to log the received error 
message
based on the error code it receives, but in this case the error code is
hardcoded as -EINVAL.  Thus, in this case it isn't about keeping the LoC
count a bit lower, but about using dev_err() where the resulting outcome
of error logging is aleady known, and where logging the error code 
actually
isn't helpful, because it's hardcoded and the logged error message 
already
tells everything about the error condition.

In other words, it's about being as precise as possible when deciding 
between
dev_err() and dev_err_probe(), in both directions.  I hope it makes 
sense.


From heiko at sntech.de  Wed Aug 21 02:17:06 2024
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Wed, 21 Aug 2024 11:17:06 +0200
Subject: [PATCH v2 3/3] phy: phy-rockchip-inno-usb2: Improve error handling while
 probing
In-Reply-To: <486bddb6aad14d05a3fb2d876d0d9d0d@manjaro.org>
References: <cover.1724225528.git.dsimic@manjaro.org> <12869965.VsHLxoZxqI@diego>
 <486bddb6aad14d05a3fb2d876d0d9d0d@manjaro.org>
Message-ID: <6073817.31tnzDBltd@diego>

Am Mittwoch, 21. August 2024, 11:09:03 CEST schrieb Dragan Simic:
> On 2024-08-21 10:44, Heiko St?bner wrote:
> > Am Mittwoch, 21. August 2024, 09:37:55 CEST schrieb Dragan Simic:
> >> Improve error handling in the probe path by using function 
> >> dev_err_probe()
> >> where appropriate, and by no longer using it rather pointlessly in one 
> >> place
> >> that actually produces a single, hardcoded error code.
> >> 
> >> Signed-off-by: Dragan Simic <dsimic at manjaro.org>
> > 
> >> @@ -1375,8 +1372,10 @@ static int rockchip_usb2phy_probe(struct 
> >> platform_device *pdev)
> >>  	rphy->irq = platform_get_irq_optional(pdev, 0);
> >>  	platform_set_drvdata(pdev, rphy);
> >> 
> >> -	if (!phy_cfgs)
> >> -		return dev_err_probe(dev, -EINVAL, "phy configs are not 
> >> assigned!\n");
> >> +	if (!phy_cfgs) {
> >> +		dev_err(dev, "phy configs are not assigned\n");
> >> +		return -EINVAL;
> >> +	}
> >> 
> >>  	ret = rockchip_usb2phy_extcon_register(rphy);
> >>  	if (ret)
> > 
> > I really don't understand the rationale here. Using dev_err_probe here
> > is just fine and with that change you just introduce more lines of code
> > for exactly the same functionality?
> 
> As we know, dev_err_probe() decides how to log the received error 
> message
> based on the error code it receives, but in this case the error code is
> hardcoded as -EINVAL.  Thus, in this case it isn't about keeping the LoC
> count a bit lower, but about using dev_err() where the resulting outcome
> of error logging is aleady known, and where logging the error code 
> actually
> isn't helpful, because it's hardcoded and the logged error message 
> already
> tells everything about the error condition.
> 
> In other words, it's about being as precise as possible when deciding 
> between
> dev_err() and dev_err_probe(), in both directions.  I hope it makes 
> sense.

I'd disagree a bit, using one format only creates a way nicer pattern in the
driver, by not mixing different styles.

dev_err_probe documentation seems to agree [0], by stating:

"Using this helper in your probe function is totally fine even if @err is
 known to never be -EPROBE_DEFER.
 The benefit compared to a normal dev_err() is the standardized format
 of the error code, it being emitted symbolically (i.e. you get "EAGAIN"
 instead of "-35") and the fact that the error code is returned which allows
 more compact error paths."



[0] https://elixir.bootlin.com/linux/v6.10.6/source/drivers/base/core.c#L5009





From dsimic at manjaro.org  Wed Aug 21 02:34:41 2024
From: dsimic at manjaro.org (Dragan Simic)
Date: Wed, 21 Aug 2024 11:34:41 +0200
Subject: [PATCH v2 3/3] phy: phy-rockchip-inno-usb2: Improve error
 handling while probing
In-Reply-To: <6073817.31tnzDBltd@diego>
References: <cover.1724225528.git.dsimic@manjaro.org>
 <12869965.VsHLxoZxqI@diego> <486bddb6aad14d05a3fb2d876d0d9d0d@manjaro.org>
 <6073817.31tnzDBltd@diego>
Message-ID: <8bb17c887eb9122d90e0887068b32da2@manjaro.org>

On 2024-08-21 11:17, Heiko St?bner wrote:
> Am Mittwoch, 21. August 2024, 11:09:03 CEST schrieb Dragan Simic:
>> On 2024-08-21 10:44, Heiko St?bner wrote:
>> > Am Mittwoch, 21. August 2024, 09:37:55 CEST schrieb Dragan Simic:
>> >> Improve error handling in the probe path by using function
>> >> dev_err_probe()
>> >> where appropriate, and by no longer using it rather pointlessly in one
>> >> place
>> >> that actually produces a single, hardcoded error code.
>> >>
>> >> Signed-off-by: Dragan Simic <dsimic at manjaro.org>
>> >
>> >> @@ -1375,8 +1372,10 @@ static int rockchip_usb2phy_probe(struct
>> >> platform_device *pdev)
>> >>  	rphy->irq = platform_get_irq_optional(pdev, 0);
>> >>  	platform_set_drvdata(pdev, rphy);
>> >>
>> >> -	if (!phy_cfgs)
>> >> -		return dev_err_probe(dev, -EINVAL, "phy configs are not
>> >> assigned!\n");
>> >> +	if (!phy_cfgs) {
>> >> +		dev_err(dev, "phy configs are not assigned\n");
>> >> +		return -EINVAL;
>> >> +	}
>> >>
>> >>  	ret = rockchip_usb2phy_extcon_register(rphy);
>> >>  	if (ret)
>> >
>> > I really don't understand the rationale here. Using dev_err_probe here
>> > is just fine and with that change you just introduce more lines of code
>> > for exactly the same functionality?
>> 
>> As we know, dev_err_probe() decides how to log the received error
>> message
>> based on the error code it receives, but in this case the error code 
>> is
>> hardcoded as -EINVAL.  Thus, in this case it isn't about keeping the 
>> LoC
>> count a bit lower, but about using dev_err() where the resulting 
>> outcome
>> of error logging is aleady known, and where logging the error code
>> actually
>> isn't helpful, because it's hardcoded and the logged error message
>> already
>> tells everything about the error condition.
>> 
>> In other words, it's about being as precise as possible when deciding
>> between
>> dev_err() and dev_err_probe(), in both directions.  I hope it makes
>> sense.
> 
> I'd disagree a bit, using one format only creates a way nicer pattern 
> in the
> driver, by not mixing different styles.
> 
> dev_err_probe documentation seems to agree [0], by stating:
> 
> "Using this helper in your probe function is totally fine even if @err 
> is
>  known to never be -EPROBE_DEFER.
>  The benefit compared to a normal dev_err() is the standardized format
>  of the error code, it being emitted symbolically (i.e. you get 
> "EAGAIN"
>  instead of "-35") and the fact that the error code is returned which 
> allows
>  more compact error paths."

Yes, I saw that already in the documentation.  Though, it might be 
debatable
does hardcoding the passed error code to some value qualifies as knowing 
that
it can't be -EPROBE_DEFER.  The way I read that part of the 
documentation is
that using dev_err_probe() is fine without going into the implementation 
of
the previously invoked function that may fail, and researching can it 
actually
return -EPROBE_DEFER or not.  Also, the invoked function may change at 
some
point in future and start returning -EPROBE_DEFER, but a hardcoded error 
code
that's produced locally can't become changed that way.

In addition to that, we already have at least a couple of instances 
[1][2] in
the same function in which dev_err() is used when the error code is 
hardcoded,
so there's actually already another pattern to follow.

I know that replacing dev_err_probe() with dev_err() may look strange in 
a
patch that mostly performs the opposite replacement, but the patch just 
tries
to be strict and precise, and to follow other examples of how dev_err() 
is
already used in the same function when the error code is produced 
locally
instead of being received from another invoked function.

> [0] 
> https://elixir.bootlin.com/linux/v6.10.6/source/drivers/base/core.c#L5009
[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/phy/rockchip/phy-rockchip-inno-usb2.c?h=v6.11-rc4#n1361
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/phy/rockchip/phy-rockchip-inno-usb2.c?h=v6.11-rc4#n1369


From hayashi.kunihiko at socionext.com  Wed Aug 21 03:31:24 2024
From: hayashi.kunihiko at socionext.com (Kunihiko Hayashi)
Date: Wed, 21 Aug 2024 19:31:24 +0900
Subject: [PATCH] dt-bindings: phy: socionext,uniphier: add top-level
 constraints
In-Reply-To: <20240818172835.121757-1-krzysztof.kozlowski@linaro.org>
References: <20240818172835.121757-1-krzysztof.kozlowski@linaro.org>
Message-ID: <fa07f751-06ae-44c0-8994-9634c5aa9824@socionext.com>

Hi Krzysztof,

I have one comment.

On 2024/08/19 2:28, Krzysztof Kozlowski wrote:
> Properties with variable number of items per each device are expected to
> have widest constraints in top-level "properties:" block and further
> customized (narrowed) in "if:then:".  Add missing top-level constraints
> for clock-names and reset-names.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> ---
>   .../bindings/phy/socionext,uniphier-ahci-phy.yaml         | 8 ++++++--
>   .../bindings/phy/socionext,uniphier-pcie-phy.yaml         | 8 ++++++--
>   .../bindings/phy/socionext,uniphier-usb3hs-phy.yaml       | 7 +++++--
>   .../bindings/phy/socionext,uniphier-usb3ss-phy.yaml       | 7 +++++--
>   4 files changed, 22 insertions(+), 8 deletions(-)
> 
> diff --git
> a/Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml
> b/Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml
> index de3cffc850bc..e34b875a1bb8 100644
> ---
> a/Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml
> +++
> b/Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml
> @@ -30,13 +30,17 @@ properties:
>       minItems: 1
>       maxItems: 2
>   
> -  clock-names: true
> +  clock-names:
> +    minItems: 1
> +    maxItems: 6

The maxItems of clocks is 2, so it should be 2.

>   
>     resets:
>       minItems: 2
>       maxItems: 6
>   
> -  reset-names: true
> +  reset-names:
> +    minItems: 2
> +    maxItems: 6
>   
>   allOf:
>     - if:
> diff --git
> a/Documentation/devicetree/bindings/phy/socionext,uniphier-pcie-phy.yaml
> b/Documentation/devicetree/bindings/phy/socionext,uniphier-pcie-phy.yaml
> index b3ed2f74a414..9fc0e87c508e 100644
> ---
> a/Documentation/devicetree/bindings/phy/socionext,uniphier-pcie-phy.yaml
> +++
> b/Documentation/devicetree/bindings/phy/socionext,uniphier-pcie-phy.yaml
> @@ -31,13 +31,17 @@ properties:
>       minItems: 1
>       maxItems: 2
>   
> -  clock-names: true
> +  clock-names:
> +    minItems: 1
> +    maxItems: 2
>   
>     resets:
>       minItems: 1
>       maxItems: 2
>   
> -  reset-names: true
> +  reset-names:
> +    minItems: 1
> +    maxItems: 2
>   
>     socionext,syscon:
>       $ref: /schemas/types.yaml#/definitions/phandle
> diff --git
> a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml
> b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml
> index 2107d98ace15..25c4159f86e4 100644
> --- a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.
> yaml
> +++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.
> yaml
> @@ -34,12 +34,15 @@ properties:
>       minItems: 2
>       maxItems: 3
>   
> -  clock-names: true
> +  clock-names:
> +    minItems: 2
> +    maxItems: 3
>   
>     resets:
>       maxItems: 2
>   
> -  reset-names: true
> +  reset-names:
> +    maxItems: 2
>   
>     vbus-supply:
>       description: A phandle to the regulator for USB VBUS
> diff --git
> a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.yaml
> b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.yaml
> index 8f5aa6238bf3..1f663e9901da 100644
> --- a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.
> yaml
> +++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.
> yaml
> @@ -35,12 +35,15 @@ properties:
>       minItems: 2
>       maxItems: 3
>   
> -  clock-names: true
> +  clock-names:
> +    minItems: 2
> +    maxItems: 3
>   
>     resets:
>       maxItems: 2
>   
> -  reset-names: true
> +  reset-names:
> +    maxItems: 2
>   
>     vbus-supply:
>       description: A phandle to the regulator for USB VBUS, only for USB
> host

Other than that:
Reviewed-by: Kunihiko Hayashi <hayashi.kunihiko at socionext.com>

I'd appreciate if it could be applied in devicetree or phy.

Thank you,

---
Best Regards
Kunihiko Hayashi


From christophe.jaillet at wanadoo.fr  Wed Aug 21 04:17:23 2024
From: christophe.jaillet at wanadoo.fr (Christophe JAILLET)
Date: Wed, 21 Aug 2024 13:17:23 +0200
Subject: [PATCH v2 2/3] phy: phy-rockchip-inno-usb2: Handle failed extcon
 allocation better
In-Reply-To: <96200baf794a0c451f3bbc3f5530b8cf0e359dfc.1724225528.git.dsimic@manjaro.org>
References: <cover.1724225528.git.dsimic@manjaro.org>
 <96200baf794a0c451f3bbc3f5530b8cf0e359dfc.1724225528.git.dsimic@manjaro.org>
Message-ID: <816aa82c-1f50-4dfe-a41f-e396e0bdf219@wanadoo.fr>

Le 21/08/2024 ? 09:37, Dragan Simic a ?crit?:
> Return the actual error code upon failure to allocate extcon device, instead
> of hardcoding -ENOMEM.  Use dev_err_probe() to also log appropriate messages,
> which is fine because the containing function is used in the probe path.
> 
> Helped-by: Heiko Stubner <heiko at sntech.de>
> Signed-off-by: Dragan Simic <dsimic at manjaro.org>
> ---
>   drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
> index 113bfc717ff0..05af46dda11d 100644
> --- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
> +++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
> @@ -435,7 +435,8 @@ static int rockchip_usb2phy_extcon_register(struct rockchip_usb2phy *rphy)
>   						rockchip_usb2phy_extcon_cable);
>   
>   		if (IS_ERR(edev))
> -			return -ENOMEM;
> +			return dev_err_probe(rphy->dev, PTR_ERR(edev),
> +					     "failed to allocate extcon device\n");

Returning PTR_ERR(edev) may make sense, but I don't think that adding a 
dev_err_probe() really helps.

devm_extcon_dev_allocate() can only return -EINVAL if it 2nd argument is 
NULL. It is trivial to see that it can't happen here, 
rockchip_usb2phy_extcon_cable is a global variable.

in all other cases, it returns -ENOMEM because of a failed memory 
allocation. In this case, usually it is not needed to log anything 
because it is already loud enough.

Just my 2c.

CJ


>   
>   		ret = devm_extcon_dev_register(rphy->dev, edev);
>   		if (ret) {
> 
> 



From aford173 at gmail.com  Wed Aug 21 05:45:58 2024
From: aford173 at gmail.com (Adam Ford)
Date: Wed, 21 Aug 2024 07:45:58 -0500
Subject: drm/bridge/imx8mp-hdmi-tx: Allow inexact pixel clock frequencies
 (Was: [PATCH V8 10/12] drm/bridge: imx: add bridge wrapper driver for i.MX8MP
 DWC HDMI)
In-Reply-To: <ZsVluV50NvuGGHFX@atmark-techno.com>
References: <20240203165307.7806-1-aford173@gmail.com> <20240203165307.7806-11-aford173@gmail.com>
 <Zm_UzO4Jmm7Aykcm@atmark-techno.com> <22a3f5266260dd3915269ae3eec7724f7537eb55.camel@pengutronix.de>
 <cd03ecb1-100e-4699-95ed-d837a2802dc7@kontron.de> <CAHCN7x+bh_ka250hOCenO3Et6re4EJ=5TG8=kpG1hs-PV0dQxQ@mail.gmail.com>
 <ZsVluV50NvuGGHFX@atmark-techno.com>
Message-ID: <CAHCN7xJnjfjr7HfKF+4pwbENP+p2=vvMXWW1AQShNy87vfQ=-A@mail.gmail.com>

On Tue, Aug 20, 2024 at 10:58?PM Dominique MARTINET
<dominique.martinet at atmark-techno.com> wrote:
>
> Adam Ford wrote on Tue, Aug 20, 2024 at 09:49:03PM -0500:
> > > > However, this check is a bit overcautious in that it only allows exact
> > > > rate matches. IIRC HDMI allows a rate mismatch of +- 0.5%, so this
> > > > check could be relaxed quite a bit to allow for that.
> > >
> > > I checked with a 1080p display that reports 23 possible modes via EDID.
> > > Out of these 15 are accepted by the driver with the strict check.
> > >
> > > Two more would be accepted with a relaxed check that allows a 0.5% margin.
> > >
> > > For the remaining six modes, the pixel clock would deviate up to ~5%
> > > from what the display expects. Still, if I remove the check altogether,
> > > all 23 modes seem to work just fine.
>
> I can confirm the displays I tested also seem pretty tolerant in
> practice (up to ~3-4% at least), but I agree with Lucas that this isn't
> something we can rely on for a general purpose driver as having examples
> of things being tolerant doesn't mean all hardware will be as flexible..
>
> > > I'd really like to be able to add more PHY PLL setpoints for displays
> > > that use non-CEA-861 modes. Unfortunately I didn't manage to figure out
> > > the fractional-n PLL parameter calculation so far.
> > >
> > > The i.MX8MP Reference Manual provides formulas to calculate the
> > > parameters based on the register values and I tried to make sense of it
> > > using the existing register values in the driver. But somehow it doesn't
> > > add up for me.
> > >
> > > Lucas, did you already work with the PLL parameters? By any chance, do
> > > you now how the math behind them works?
> >
> > I spent a little time trying to understand it a bit.  I created a PMS
> > calculator similar to the one used on the DSI controller,
>
> Great! I'll admit this also flies over my head and I don't have the
> time to study this, so this is much appreciated.
>
> > except that
> > the M seems to be fixed at a value of 62 per the data sheet, so it's
> > more of a PS calculator.
>
> Hmm... PHY_REG2 in the datasheet only lists '0011_1110b - 62' as
> example(?) values, but it doesn't say other values are reserved either,
> I'm not sure what to make of it.
> In the current driver PHY_REG_02 (driver macro) is assigned the first
> field of .pll_div_regs, which goes anywhere from 0x4b to 0x7b -- pretty
> far from 62(0x3e)...

OK.  I will experiment with increasing the range of M from being fixed
at 3e to a range of 3b to 7b to see if my PMS integer calculator can
get more accurate.

>
> Since other frequencies have been adjusting this main diviser ratio we
> actually tried copying neighboring values and adjusting only that reg 2
> (so the M if I get this right?), but the end result ended up not
> synchronizing properly every time... We didn't have time to check with a
> scope if the generated signal was ugly or if it just didn't lock
> properly, but the display worked when we just re-used the neighboring
> values without changing anything despite being ~3-4% off, so we took the
> easy way out here and didn't dig much further.
>
> > Anyway, When I run my P-S calculator to generate the 'best rate' I get
> > a value that's usually 0.2% variance from nominal, but I only verified
> > a handful of values:
> >
> > Several which were +0.2%
> > 297600000 vs 297000000 (4k at 30)
> > 148800000 vs 148500000 (1080p60)
> > 74400 vs 74200
> >
> > One value was -0.16%
> > 24800000 vs 25200000
> >
> > If the M value was a bit more flexible, we might be able to reduce
> > that variance more.
>
> Yes, I think the M value could be more flexible, but that'd require
> checking if it actually works, whereas having slightly off frequencies
> will most likely be OK so I don't think it's worth the effort -- happy
> to stick to what the datasheet describes.
>
> > If / when I get some time, I might play with trying to disable the
> > fractional mode and just use the PMS calculator for simplicity despite
> > the inaccuracy.  Maybe we could fall back to using the PMS calculator
> > if the desired frequency isn't in the look-up-table.
>
> That'd be greatly appreciated, I don't have any strong opinion on
> whether that should completely replace the table, or only be used if
> there is no exact match in the table as these are values we know will
> work; but we can definitely test any patch you can throw at us here.

I can't promise it'll be quick.  I am not fully certain I understand
how the whole thing works, but as a rule, I don't generally like look
up tables if they can be calculated dynamically.

adam
>
>
> Cheers,
> --
> Dominique
>
>


From make24 at iscas.ac.cn  Wed Aug 21 06:10:42 2024
From: make24 at iscas.ac.cn (Ma Ke)
Date: Wed, 21 Aug 2024 21:10:42 +0800
Subject: [PATCH] phy: qualcomm: Check NULL ptr on lvts_data in qcom_ipq806x_usb_phy_probe()
Message-ID: <20240821131042.1464529-1-make24@iscas.ac.cn>

of_device_get_match_data() can return NULL if of_match_device failed, and
the pointer 'data' was dereferenced without checking against NULL. Add
checking of pointer 'data' in qcom_ipq806x_usb_phy_probe().

Cc: stable at vger.kernel.org
Fixes: ef19b117b834 ("phy: qualcomm: add qcom ipq806x dwc usb phy driver")
Signed-off-by: Ma Ke <make24 at iscas.ac.cn>
---
 drivers/phy/qualcomm/phy-qcom-ipq806x-usb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/phy/qualcomm/phy-qcom-ipq806x-usb.c b/drivers/phy/qualcomm/phy-qcom-ipq806x-usb.c
index 06392ed7c91b..9b9fd9c1b1f7 100644
--- a/drivers/phy/qualcomm/phy-qcom-ipq806x-usb.c
+++ b/drivers/phy/qualcomm/phy-qcom-ipq806x-usb.c
@@ -492,6 +492,8 @@ static int qcom_ipq806x_usb_phy_probe(struct platform_device *pdev)
 		return -ENOMEM;
 
 	data = of_device_get_match_data(&pdev->dev);
+	if (!data)
+		return -ENODEV;
 
 	phy_dwc3->dev = &pdev->dev;
 
-- 
2.25.1



From andersson at kernel.org  Wed Aug 21 07:50:27 2024
From: andersson at kernel.org (Bjorn Andersson)
Date: Wed, 21 Aug 2024 09:50:27 -0500
Subject: [PATCH] phy: qualcomm: Check NULL ptr on lvts_data in
 qcom_ipq806x_usb_phy_probe()
In-Reply-To: <20240821131042.1464529-1-make24@iscas.ac.cn>
References: <20240821131042.1464529-1-make24@iscas.ac.cn>
Message-ID: <4kpmkjp6pp6r34v7se24rscnk2t7g2pjcrqm6l7nt7h3lgsu3v@rauqrchifqjj>

On Wed, Aug 21, 2024 at 09:10:42PM GMT, Ma Ke wrote:
> of_device_get_match_data() can return NULL if of_match_device failed, and
> the pointer 'data' was dereferenced without checking against NULL. Add
> checking of pointer 'data' in qcom_ipq806x_usb_phy_probe().

How do you create the platform_device such that this happens?

Regards,
Bjorn

> 
> Cc: stable at vger.kernel.org
> Fixes: ef19b117b834 ("phy: qualcomm: add qcom ipq806x dwc usb phy driver")
> Signed-off-by: Ma Ke <make24 at iscas.ac.cn>
> ---
>  drivers/phy/qualcomm/phy-qcom-ipq806x-usb.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/phy/qualcomm/phy-qcom-ipq806x-usb.c b/drivers/phy/qualcomm/phy-qcom-ipq806x-usb.c
> index 06392ed7c91b..9b9fd9c1b1f7 100644
> --- a/drivers/phy/qualcomm/phy-qcom-ipq806x-usb.c
> +++ b/drivers/phy/qualcomm/phy-qcom-ipq806x-usb.c
> @@ -492,6 +492,8 @@ static int qcom_ipq806x_usb_phy_probe(struct platform_device *pdev)
>  		return -ENOMEM;
>  
>  	data = of_device_get_match_data(&pdev->dev);
> +	if (!data)
> +		return -ENODEV;
>  
>  	phy_dwc3->dev = &pdev->dev;
>  
> -- 
> 2.25.1
> 
> 


From ansuelsmth at gmail.com  Tue Aug 20 14:50:12 2024
From: ansuelsmth at gmail.com (Christian Marangi)
Date: Tue, 20 Aug 2024 23:50:12 +0200
Subject: [PATCH] phy: qualcomm: Check NULL ptr on lvts_data in
 qcom_ipq806x_usb_phy_probe()
In-Reply-To: <4kpmkjp6pp6r34v7se24rscnk2t7g2pjcrqm6l7nt7h3lgsu3v@rauqrchifqjj>
References: <20240821131042.1464529-1-make24@iscas.ac.cn>
 <4kpmkjp6pp6r34v7se24rscnk2t7g2pjcrqm6l7nt7h3lgsu3v@rauqrchifqjj>
Message-ID: <66c629cd.df0a0220.1532f3.0f92@mx.google.com>

On Wed, Aug 21, 2024 at 09:50:27AM -0500, Bjorn Andersson wrote:
> On Wed, Aug 21, 2024 at 09:10:42PM GMT, Ma Ke wrote:
> > of_device_get_match_data() can return NULL if of_match_device failed, and
> > the pointer 'data' was dereferenced without checking against NULL. Add
> > checking of pointer 'data' in qcom_ipq806x_usb_phy_probe().
> 
> How do you create the platform_device such that this happens?
>

I have the same question and this sounds like warning produced by
automated checks of some sort... (and these kind of patch are suspicious
given what happens in the last few years)

In practice this can never happen... of_match_device can't fail as it's
called only if a matching compatible is found hence the thing MUST be
present BEFORE probe is even called.

> 
> > 
> > Cc: stable at vger.kernel.org
> > Fixes: ef19b117b834 ("phy: qualcomm: add qcom ipq806x dwc usb phy driver")
> > Signed-off-by: Ma Ke <make24 at iscas.ac.cn>
> > ---
> >  drivers/phy/qualcomm/phy-qcom-ipq806x-usb.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/phy/qualcomm/phy-qcom-ipq806x-usb.c b/drivers/phy/qualcomm/phy-qcom-ipq806x-usb.c
> > index 06392ed7c91b..9b9fd9c1b1f7 100644
> > --- a/drivers/phy/qualcomm/phy-qcom-ipq806x-usb.c
> > +++ b/drivers/phy/qualcomm/phy-qcom-ipq806x-usb.c
> > @@ -492,6 +492,8 @@ static int qcom_ipq806x_usb_phy_probe(struct platform_device *pdev)
> >  		return -ENOMEM;
> >  
> >  	data = of_device_get_match_data(&pdev->dev);
> > +	if (!data)
> > +		return -ENODEV;
> >  
> >  	phy_dwc3->dev = &pdev->dev;
> >  
> > -- 
> > 2.25.1
> > 
> > 

-- 
	Ansuel


From dsimic at manjaro.org  Wed Aug 21 12:05:07 2024
From: dsimic at manjaro.org (Dragan Simic)
Date: Wed, 21 Aug 2024 21:05:07 +0200
Subject: [PATCH v2 2/3] phy: phy-rockchip-inno-usb2: Handle failed extcon
 allocation better
In-Reply-To: <816aa82c-1f50-4dfe-a41f-e396e0bdf219@wanadoo.fr>
References: <cover.1724225528.git.dsimic@manjaro.org>
 <96200baf794a0c451f3bbc3f5530b8cf0e359dfc.1724225528.git.dsimic@manjaro.org>
 <816aa82c-1f50-4dfe-a41f-e396e0bdf219@wanadoo.fr>
Message-ID: <a34cbce8633fda9ed805adde3eeb1467@manjaro.org>

Hello Christophe,

On 2024-08-21 13:17, Christophe JAILLET wrote:
> Le 21/08/2024 ? 09:37, Dragan Simic a ?crit?:
>> Return the actual error code upon failure to allocate extcon device, 
>> instead
>> of hardcoding -ENOMEM.  Use dev_err_probe() to also log appropriate 
>> messages,
>> which is fine because the containing function is used in the probe 
>> path.
>> 
>> Helped-by: Heiko Stubner <heiko at sntech.de>
>> Signed-off-by: Dragan Simic <dsimic at manjaro.org>
>> ---
>>   drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c 
>> b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
>> index 113bfc717ff0..05af46dda11d 100644
>> --- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
>> +++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
>> @@ -435,7 +435,8 @@ static int rockchip_usb2phy_extcon_register(struct 
>> rockchip_usb2phy *rphy)
>>   						rockchip_usb2phy_extcon_cable);
>>     		if (IS_ERR(edev))
>> -			return -ENOMEM;
>> +			return dev_err_probe(rphy->dev, PTR_ERR(edev),
>> +					     "failed to allocate extcon device\n");
> 
> Returning PTR_ERR(edev) may make sense, but I don't think that adding
> a dev_err_probe() really helps.
> 
> devm_extcon_dev_allocate() can only return -EINVAL if it 2nd argument
> is NULL. It is trivial to see that it can't happen here,
> rockchip_usb2phy_extcon_cable is a global variable.
> 
> in all other cases, it returns -ENOMEM because of a failed memory
> allocation. In this case, usually it is not needed to log anything
> because it is already loud enough.

True, using dev_err_probe() in this case is somewhat redundant,
but it falls under the "still fine to use" category, [1] because
the error code passed to dev_err_probe() is received from another
function that was invoked.

On the other hand, another patch in this series tries to be strict
in another direction, by not using dev_err_probe() where the error
code passed to it is basically hardcoded. [2]

I hope this makes sense.

[1] 
https://lore.kernel.org/linux-phy/cover.1724225528.git.dsimic at manjaro.org/T/#mc3af7d24e31ed885732e6f26ca0d107b157d478b
[2] 
https://lore.kernel.org/linux-phy/cover.1724225528.git.dsimic at manjaro.org/T/#ma26b614412787814dab7923987b8c814f7e86beb

>>     		ret = devm_extcon_dev_register(rphy->dev, edev);
>>   		if (ret) {
>> 
>> 


From ilordash02 at gmail.com  Wed Aug 21 14:53:56 2024
From: ilordash02 at gmail.com (Ilya Orazov)
Date: Thu, 22 Aug 2024 00:53:56 +0300
Subject: [PATCH v3 0/1] dt-bindings: phy: ti,tcan104x-can: Document Microchip
Message-ID: <20240821215357.20224-1-ilordash02@gmail.com>

Hi all,

As suggested in the previous email conversation on this patch, I am
sending this new version as a standalone email. I hope this approach
makes it easier to review and keeps the conversation history clearer.

Thank you for your feedback!

Ilya Orazov (1):
  dt-bindings: phy: ti,tcan104x-can: Document Microchip ATA6561

 .../devicetree/bindings/phy/ti,tcan104x-can.yaml    | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)


base-commit: b311c1b497e51a628aa89e7cb954481e5f9dced2
-- 
2.34.1



From ilordash02 at gmail.com  Wed Aug 21 14:53:57 2024
From: ilordash02 at gmail.com (Ilya Orazov)
Date: Thu, 22 Aug 2024 00:53:57 +0300
Subject: [PATCH v3 1/1] dt-bindings: phy: ti,tcan104x-can: Document Microchip ATA6561
In-Reply-To: <20240821215357.20224-1-ilordash02@gmail.com>
References: <20240821215357.20224-1-ilordash02@gmail.com>
Message-ID: <20240821215357.20224-2-ilordash02@gmail.com>

Microchip ATA6561 is High-Speed CAN Transceiver with Standby Mode.
It is pin-compatible with TI TCAN1042 and has a compatible programming
model, therefore use ti,tcan1042 as fallback compatible.

Signed-off-by: Ilya Orazov <ilordash02 at gmail.com>
---
 .../devicetree/bindings/phy/ti,tcan104x-can.yaml    | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
index 79dad3e89aa6..4a8c3829d85d 100644
--- a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
+++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
@@ -14,10 +14,15 @@ properties:
     pattern: "^can-phy"
 
   compatible:
-    enum:
-      - nxp,tjr1443
-      - ti,tcan1042
-      - ti,tcan1043
+    oneOf:
+      - items:
+          - enum:
+              - microchip,ata6561
+          - const: ti,tcan1042
+      - enum:
+          - ti,tcan1042
+          - ti,tcan1043
+          - nxp,tjr1443
 
   '#phy-cells':
     const: 0
-- 
2.34.1



From aford173 at gmail.com  Wed Aug 21 18:59:05 2024
From: aford173 at gmail.com (Adam Ford)
Date: Wed, 21 Aug 2024 20:59:05 -0500
Subject: drm/bridge/imx8mp-hdmi-tx: Allow inexact pixel clock frequencies
 (Was: [PATCH V8 10/12] drm/bridge: imx: add bridge wrapper driver for i.MX8MP
 DWC HDMI)
In-Reply-To: <CAHCN7xJnjfjr7HfKF+4pwbENP+p2=vvMXWW1AQShNy87vfQ=-A@mail.gmail.com>
References: <20240203165307.7806-1-aford173@gmail.com> <20240203165307.7806-11-aford173@gmail.com>
 <Zm_UzO4Jmm7Aykcm@atmark-techno.com> <22a3f5266260dd3915269ae3eec7724f7537eb55.camel@pengutronix.de>
 <cd03ecb1-100e-4699-95ed-d837a2802dc7@kontron.de> <CAHCN7x+bh_ka250hOCenO3Et6re4EJ=5TG8=kpG1hs-PV0dQxQ@mail.gmail.com>
 <ZsVluV50NvuGGHFX@atmark-techno.com> <CAHCN7xJnjfjr7HfKF+4pwbENP+p2=vvMXWW1AQShNy87vfQ=-A@mail.gmail.com>
Message-ID: <CAHCN7xKgpqfRf_2p1z5NyKiOYubbcDA7YE5ML8G56pVmcV+1xA@mail.gmail.com>

On Wed, Aug 21, 2024 at 7:45?AM Adam Ford <aford173 at gmail.com> wrote:
>
> On Tue, Aug 20, 2024 at 10:58?PM Dominique MARTINET
> <dominique.martinet at atmark-techno.com> wrote:
> >
> > Adam Ford wrote on Tue, Aug 20, 2024 at 09:49:03PM -0500:
> > > > > However, this check is a bit overcautious in that it only allows exact
> > > > > rate matches. IIRC HDMI allows a rate mismatch of +- 0.5%, so this
> > > > > check could be relaxed quite a bit to allow for that.
> > > >
> > > > I checked with a 1080p display that reports 23 possible modes via EDID.
> > > > Out of these 15 are accepted by the driver with the strict check.
> > > >
> > > > Two more would be accepted with a relaxed check that allows a 0.5% margin.
> > > >
> > > > For the remaining six modes, the pixel clock would deviate up to ~5%
> > > > from what the display expects. Still, if I remove the check altogether,
> > > > all 23 modes seem to work just fine.
> >
> > I can confirm the displays I tested also seem pretty tolerant in
> > practice (up to ~3-4% at least), but I agree with Lucas that this isn't
> > something we can rely on for a general purpose driver as having examples
> > of things being tolerant doesn't mean all hardware will be as flexible..
> >
> > > > I'd really like to be able to add more PHY PLL setpoints for displays
> > > > that use non-CEA-861 modes. Unfortunately I didn't manage to figure out
> > > > the fractional-n PLL parameter calculation so far.
> > > >
> > > > The i.MX8MP Reference Manual provides formulas to calculate the
> > > > parameters based on the register values and I tried to make sense of it
> > > > using the existing register values in the driver. But somehow it doesn't
> > > > add up for me.
> > > >
> > > > Lucas, did you already work with the PLL parameters? By any chance, do
> > > > you now how the math behind them works?
> > >
> > > I spent a little time trying to understand it a bit.  I created a PMS
> > > calculator similar to the one used on the DSI controller,
> >
> > Great! I'll admit this also flies over my head and I don't have the
> > time to study this, so this is much appreciated.
> >
> > > except that
> > > the M seems to be fixed at a value of 62 per the data sheet, so it's
> > > more of a PS calculator.
> >
> > Hmm... PHY_REG2 in the datasheet only lists '0011_1110b - 62' as
> > example(?) values, but it doesn't say other values are reserved either,
> > I'm not sure what to make of it.
> > In the current driver PHY_REG_02 (driver macro) is assigned the first
> > field of .pll_div_regs, which goes anywhere from 0x4b to 0x7b -- pretty
> > far from 62(0x3e)...
>
> OK.  I will experiment with increasing the range of M from being fixed
> at 3e to a range of 3b to 7b to see if my PMS integer calculator can
> get more accurate.
>
> >
> > Since other frequencies have been adjusting this main diviser ratio we
> > actually tried copying neighboring values and adjusting only that reg 2
> > (so the M if I get this right?), but the end result ended up not
> > synchronizing properly every time... We didn't have time to check with a
> > scope if the generated signal was ugly or if it just didn't lock
> > properly, but the display worked when we just re-used the neighboring
> > values without changing anything despite being ~3-4% off, so we took the
> > easy way out here and didn't dig much further.
> >
> > > Anyway, When I run my P-S calculator to generate the 'best rate' I get
> > > a value that's usually 0.2% variance from nominal, but I only verified
> > > a handful of values:
> > >
> > > Several which were +0.2%
> > > 297600000 vs 297000000 (4k at 30)
> > > 148800000 vs 148500000 (1080p60)
> > > 74400 vs 74200
> > >
> > > One value was -0.16%
> > > 24800000 vs 25200000
> > >
> > > If the M value was a bit more flexible, we might be able to reduce
> > > that variance more.
> >
> > Yes, I think the M value could be more flexible, but that'd require
> > checking if it actually works, whereas having slightly off frequencies
> > will most likely be OK so I don't think it's worth the effort -- happy
> > to stick to what the datasheet describes.
> >
> > > If / when I get some time, I might play with trying to disable the
> > > fractional mode and just use the PMS calculator for simplicity despite
> > > the inaccuracy.  Maybe we could fall back to using the PMS calculator
> > > if the desired frequency isn't in the look-up-table.
> >
> > That'd be greatly appreciated, I don't have any strong opinion on
> > whether that should completely replace the table, or only be used if
> > there is no exact match in the table as these are values we know will
> > work; but we can definitely test any patch you can throw at us here.
>
> I can't promise it'll be quick.  I am not fully certain I understand
> how the whole thing works, but as a rule, I don't generally like look
> up tables if they can be calculated dynamically.

I updated my PMS calculator, and I randomly selected 5 resolutions and
they all returned an exact clock match, so I'll attempt to use the PMS
integer clock instead of the fractional one.

It'll be a little while longer before I can do anything with it.

adam
>
> adam
> >
> >
> > Cheers,
> > --
> > Dominique
> >
> >


From johan at kernel.org  Wed Aug 21 23:49:44 2024
From: johan at kernel.org (Johan Hovold)
Date: Thu, 22 Aug 2024 08:49:44 +0200
Subject: [PATCH v2 1/2] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy:
 Document the X1E80100 QMP PCIe PHY Gen4 x4
In-Reply-To: <20240821-x1e80100-phy-add-gen4x4-v2-1-c34db42230e9@linaro.org>
References: <20240821-x1e80100-phy-add-gen4x4-v2-0-c34db42230e9@linaro.org>
 <20240821-x1e80100-phy-add-gen4x4-v2-1-c34db42230e9@linaro.org>
Message-ID: <ZsbfiMGP4aLmfwkv@hovoldconsulting.com>

On Wed, Aug 21, 2024 at 11:39:00AM +0300, Abel Vesa wrote:
> The sixth PCIe instance on X1E80100 can be used in either 4-lane mode or
> 2-lane mode. Document the 4-lane mode as a separate compatible.
> 
> Reviewed-by: Krzysztof Kozlowski <krzk at kernel.org>
> Signed-off-by: Abel Vesa <abel.vesa at linaro.org>

Reviewed-by: Johan Hovold <johan+linaro at kernel.org>


From johan at kernel.org  Wed Aug 21 23:52:38 2024
From: johan at kernel.org (Johan Hovold)
Date: Thu, 22 Aug 2024 08:52:38 +0200
Subject: [PATCH v2 2/2] phy: qcom: qmp-pcie: Add Gen4 4-lanes mode for
 X1E80100
In-Reply-To: <20240821-x1e80100-phy-add-gen4x4-v2-2-c34db42230e9@linaro.org>
References: <20240821-x1e80100-phy-add-gen4x4-v2-0-c34db42230e9@linaro.org>
 <20240821-x1e80100-phy-add-gen4x4-v2-2-c34db42230e9@linaro.org>
Message-ID: <ZsbgNmHYj3jE9CpO@hovoldconsulting.com>

On Wed, Aug 21, 2024 at 11:39:01AM +0300, Abel Vesa wrote:
> The sixth PCIe controller on X1E80100 can be used in either
> 4-lanes mode or 2-lanes mode. Add the configuration and compatible
> for the 4-lane mode.
> 
> Signed-off-by: Abel Vesa <abel.vesa at linaro.org>
> ---
>  drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 42 ++++++++++++++++++++++++++++++++
>  1 file changed, 42 insertions(+)
> 
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
> index a7e2ce0c500d..df1ebc19c117 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
> @@ -1266,6 +1266,10 @@ static const struct qmp_phy_init_tbl x1e80100_qmp_gen4x2_pcie_ln_shrd_tbl[] = {
>  	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_SUMMER_CAL_SPD_MODE, 0x5b),
>  };
>  
> +static const struct qmp_phy_init_tbl x1e80100_qmp_gen4x4_pcie_serdes_4ln_tbl[] = {
> +	QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_BIAS_EN_CLK_BUFLR_EN, 0x1c),
> +};

Nit: This is a serdes subtable (override) so should go under the serdes
table above (not ln_shrd).

Looks good otherwise:

Reviewed-by: Johan Hovold <johan+linaro at kernel.org>

Johan


From krzk at kernel.org  Thu Aug 22 00:09:53 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Thu, 22 Aug 2024 09:09:53 +0200
Subject: [PATCH v3 0/1] dt-bindings: phy: ti,tcan104x-can: Document
 Microchip
In-Reply-To: <20240821215357.20224-1-ilordash02@gmail.com>
References: <20240821215357.20224-1-ilordash02@gmail.com>
Message-ID: <thpryn4unrebkvx4a7jhqmxt5ntmog2gcw3ekh6h72jews4een@b43tsg7poegn>

On Thu, Aug 22, 2024 at 12:53:56AM +0300, Ilya Orazov wrote:
> Hi all,
> 
> As suggested in the previous email conversation on this patch, I am
> sending this new version as a standalone email. I hope this approach
> makes it easier to review and keeps the conversation history clearer.

Where was it suggested?

Best regards,
Krzysztof



From krzk at kernel.org  Thu Aug 22 00:10:37 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Thu, 22 Aug 2024 09:10:37 +0200
Subject: [PATCH v3 1/1] dt-bindings: phy: ti,tcan104x-can: Document
 Microchip ATA6561
In-Reply-To: <20240821215357.20224-2-ilordash02@gmail.com>
References: <20240821215357.20224-1-ilordash02@gmail.com>
 <20240821215357.20224-2-ilordash02@gmail.com>
Message-ID: <txb77x3lkk6gnhzavx5j7ahqg6wjdm2zjpk2fe3z7vopit5kvg@pxom5ang6izt>

On Thu, Aug 22, 2024 at 12:53:57AM +0300, Ilya Orazov wrote:
> Microchip ATA6561 is High-Speed CAN Transceiver with Standby Mode.
> It is pin-compatible with TI TCAN1042 and has a compatible programming
> model, therefore use ti,tcan1042 as fallback compatible.
> 
> Signed-off-by: Ilya Orazov <ilordash02 at gmail.com>
> ---

Where is the changelog?

Where is the tag you received?

Why sending it again without any of the above?

<form letter>
This is a friendly reminder during the review process.

It looks like you received a tag and forgot to add it.

If you do not know the process, here is a short explanation: Please add
Acked-by/Reviewed-by/Tested-by tags when posting new versions, under
or above your Signed-off-by tag. Tag is "received", when provided
in a message replied to you on the mailing list. Tools like b4 can help
here. However, there's no need to repost patches *only* to add the tags.
The upstream maintainer will do that for tags received on the version
they apply.

https://elixir.bootlin.com/linux/v6.5-rc3/source/Documentation/process/submitting-patches.rst#L577

If a tag was not added on purpose, please state why and what changed.
</form letter>

Best regards,
Krzysztof



From frank.li at vivo.com  Thu Aug 22 01:42:42 2024
From: frank.li at vivo.com (Yangtao Li)
Date: Thu, 22 Aug 2024 02:42:42 -0600
Subject: [PATCH 0/4] phy: convert to devm_clk_get_*()
Message-ID: <20240822084245.1594474-1-frank.li@vivo.com>

This patchset simplify code w/ devm_clk_get_*() API.

Yangtao Li (4):
  phy: ti: phy-dm816x-usb: Convert to devm_clk_get_prepared()
  phy: qualcomm: phy-qcom-apq8064-sata: Convert to
    devm_clk_get_enabled()
  phy: qualcomm: phy-qcom-ipq806x-sata: Convert to
    devm_clk_get_enabled()
  phy: samsung: exynos5250-sata: fix missing clock disable in remove
    path

 drivers/phy/qualcomm/phy-qcom-apq8064-sata.c | 22 ++++----------------
 drivers/phy/qualcomm/phy-qcom-ipq806x-sata.c | 22 ++++----------------
 drivers/phy/samsung/phy-exynos5250-sata.c    | 20 ++++++------------
 drivers/phy/ti/phy-dm816x-usb.c              |  7 +------
 4 files changed, 15 insertions(+), 56 deletions(-)

-- 
2.39.0



From frank.li at vivo.com  Thu Aug 22 01:43:41 2024
From: frank.li at vivo.com (Yangtao Li)
Date: Thu, 22 Aug 2024 02:43:41 -0600
Subject: [PATCH 1/4] phy: ti: phy-dm816x-usb: Convert to devm_clk_get_prepared()
Message-ID: <20240822084342.1595239-1-frank.li@vivo.com>

Convert devm_clk_get(), clk_prepare() to a single
call to devm_clk_get_prepared(), as this is exactly
what this function does.

Signed-off-by: Yangtao Li <frank.li at vivo.com>
---
 drivers/phy/ti/phy-dm816x-usb.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/phy/ti/phy-dm816x-usb.c b/drivers/phy/ti/phy-dm816x-usb.c
index d5ae972a31fb..d47674ec5e96 100644
--- a/drivers/phy/ti/phy-dm816x-usb.c
+++ b/drivers/phy/ti/phy-dm816x-usb.c
@@ -215,12 +215,9 @@ static int dm816x_usb_phy_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, phy);
 
-	phy->refclk = devm_clk_get(phy->dev, "refclk");
+	phy->refclk = devm_clk_get_prepared(phy->dev, "refclk");
 	if (IS_ERR(phy->refclk))
 		return PTR_ERR(phy->refclk);
-	error = clk_prepare(phy->refclk);
-	if (error)
-		return error;
 
 	pm_runtime_enable(phy->dev);
 	generic_phy = devm_phy_create(phy->dev, NULL, &ops);
@@ -244,7 +241,6 @@ static int dm816x_usb_phy_probe(struct platform_device *pdev)
 
 clk_unprepare:
 	pm_runtime_disable(phy->dev);
-	clk_unprepare(phy->refclk);
 	return error;
 }
 
@@ -254,7 +250,6 @@ static void dm816x_usb_phy_remove(struct platform_device *pdev)
 
 	usb_remove_phy(&phy->phy);
 	pm_runtime_disable(phy->dev);
-	clk_unprepare(phy->refclk);
 }
 
 static struct platform_driver dm816x_usb_phy_driver = {
-- 
2.39.0



From frank.li at vivo.com  Thu Aug 22 01:44:00 2024
From: frank.li at vivo.com (Yangtao Li)
Date: Thu, 22 Aug 2024 02:44:00 -0600
Subject: [PATCH 2/4] phy: qualcomm: phy-qcom-apq8064-sata: Convert to devm_clk_get_enabled()
Message-ID: <20240822084400.1595426-1-frank.li@vivo.com>

Convert devm_clk_get(), clk_prepare_enable() to a single
call to devm_clk_get_enabled(), as this is exactly
what this function does.

Signed-off-by: Yangtao Li <frank.li at vivo.com>
---
 drivers/phy/qualcomm/phy-qcom-apq8064-sata.c | 22 ++++----------------
 1 file changed, 4 insertions(+), 18 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-apq8064-sata.c b/drivers/phy/qualcomm/phy-qcom-apq8064-sata.c
index 3642a5d4f2f3..18c0dbd8e707 100644
--- a/drivers/phy/qualcomm/phy-qcom-apq8064-sata.c
+++ b/drivers/phy/qualcomm/phy-qcom-apq8064-sata.c
@@ -68,7 +68,6 @@
 
 struct qcom_apq8064_sata_phy {
 	void __iomem *mmio;
-	struct clk *cfg_clk;
 	struct device *dev;
 };
 
@@ -203,7 +202,7 @@ static int qcom_apq8064_sata_phy_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct phy_provider *phy_provider;
 	struct phy *generic_phy;
-	int ret;
+	struct clk *cfg_clk;
 
 	phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
 	if (!phy)
@@ -223,19 +222,14 @@ static int qcom_apq8064_sata_phy_probe(struct platform_device *pdev)
 	phy_set_drvdata(generic_phy, phy);
 	platform_set_drvdata(pdev, phy);
 
-	phy->cfg_clk = devm_clk_get(dev, "cfg");
-	if (IS_ERR(phy->cfg_clk)) {
+	cfg_clk = devm_clk_get_enabled(dev, "cfg");
+	if (IS_ERR(cfg_clk)) {
 		dev_err(dev, "Failed to get sata cfg clock\n");
-		return PTR_ERR(phy->cfg_clk);
+		return PTR_ERR(cfg_clk);
 	}
 
-	ret = clk_prepare_enable(phy->cfg_clk);
-	if (ret)
-		return ret;
-
 	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
 	if (IS_ERR(phy_provider)) {
-		clk_disable_unprepare(phy->cfg_clk);
 		dev_err(dev, "%s: failed to register phy\n", __func__);
 		return PTR_ERR(phy_provider);
 	}
@@ -243,13 +237,6 @@ static int qcom_apq8064_sata_phy_probe(struct platform_device *pdev)
 	return 0;
 }
 
-static void qcom_apq8064_sata_phy_remove(struct platform_device *pdev)
-{
-	struct qcom_apq8064_sata_phy *phy = platform_get_drvdata(pdev);
-
-	clk_disable_unprepare(phy->cfg_clk);
-}
-
 static const struct of_device_id qcom_apq8064_sata_phy_of_match[] = {
 	{ .compatible = "qcom,apq8064-sata-phy" },
 	{ },
@@ -258,7 +245,6 @@ MODULE_DEVICE_TABLE(of, qcom_apq8064_sata_phy_of_match);
 
 static struct platform_driver qcom_apq8064_sata_phy_driver = {
 	.probe	= qcom_apq8064_sata_phy_probe,
-	.remove_new = qcom_apq8064_sata_phy_remove,
 	.driver = {
 		.name	= "qcom-apq8064-sata-phy",
 		.of_match_table	= qcom_apq8064_sata_phy_of_match,
-- 
2.39.0



From frank.li at vivo.com  Thu Aug 22 01:44:16 2024
From: frank.li at vivo.com (Yangtao Li)
Date: Thu, 22 Aug 2024 02:44:16 -0600
Subject: [PATCH 3/4] phy: qualcomm: phy-qcom-ipq806x-sata: Convert to devm_clk_get_enabled()
Message-ID: <20240822084417.1596110-1-frank.li@vivo.com>

Convert devm_clk_get(), clk_prepare_enable() to a single
call to devm_clk_get_enabled(), as this is exactly
what this function does.

Signed-off-by: Yangtao Li <frank.li at vivo.com>
---
 drivers/phy/qualcomm/phy-qcom-ipq806x-sata.c | 22 ++++----------------
 1 file changed, 4 insertions(+), 18 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-ipq806x-sata.c b/drivers/phy/qualcomm/phy-qcom-ipq806x-sata.c
index f0a72b82c770..bf2d91c00700 100644
--- a/drivers/phy/qualcomm/phy-qcom-ipq806x-sata.c
+++ b/drivers/phy/qualcomm/phy-qcom-ipq806x-sata.c
@@ -17,7 +17,6 @@
 
 struct qcom_ipq806x_sata_phy {
 	void __iomem *mmio;
-	struct clk *cfg_clk;
 	struct device *dev;
 };
 
@@ -130,7 +129,7 @@ static int qcom_ipq806x_sata_phy_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct phy_provider *phy_provider;
 	struct phy *generic_phy;
-	int ret;
+	struct clk *cfg_clk;
 
 	phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
 	if (!phy)
@@ -150,19 +149,14 @@ static int qcom_ipq806x_sata_phy_probe(struct platform_device *pdev)
 	phy_set_drvdata(generic_phy, phy);
 	platform_set_drvdata(pdev, phy);
 
-	phy->cfg_clk = devm_clk_get(dev, "cfg");
-	if (IS_ERR(phy->cfg_clk)) {
+	cfg_clk = devm_clk_get_enabled(dev, "cfg");
+	if (IS_ERR(cfg_clk)) {
 		dev_err(dev, "Failed to get sata cfg clock\n");
-		return PTR_ERR(phy->cfg_clk);
+		return PTR_ERR(cfg_clk);
 	}
 
-	ret = clk_prepare_enable(phy->cfg_clk);
-	if (ret)
-		return ret;
-
 	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
 	if (IS_ERR(phy_provider)) {
-		clk_disable_unprepare(phy->cfg_clk);
 		dev_err(dev, "%s: failed to register phy\n", __func__);
 		return PTR_ERR(phy_provider);
 	}
@@ -170,13 +164,6 @@ static int qcom_ipq806x_sata_phy_probe(struct platform_device *pdev)
 	return 0;
 }
 
-static void qcom_ipq806x_sata_phy_remove(struct platform_device *pdev)
-{
-	struct qcom_ipq806x_sata_phy *phy = platform_get_drvdata(pdev);
-
-	clk_disable_unprepare(phy->cfg_clk);
-}
-
 static const struct of_device_id qcom_ipq806x_sata_phy_of_match[] = {
 	{ .compatible = "qcom,ipq806x-sata-phy" },
 	{ },
@@ -185,7 +172,6 @@ MODULE_DEVICE_TABLE(of, qcom_ipq806x_sata_phy_of_match);
 
 static struct platform_driver qcom_ipq806x_sata_phy_driver = {
 	.probe	= qcom_ipq806x_sata_phy_probe,
-	.remove_new = qcom_ipq806x_sata_phy_remove,
 	.driver = {
 		.name	= "qcom-ipq806x-sata-phy",
 		.of_match_table	= qcom_ipq806x_sata_phy_of_match,
-- 
2.39.0



From frank.li at vivo.com  Thu Aug 22 01:44:33 2024
From: frank.li at vivo.com (Yangtao Li)
Date: Thu, 22 Aug 2024 02:44:33 -0600
Subject: [PATCH 4/4] phy: samsung: exynos5250-sata: fix missing clock disable in remove path
Message-ID: <20240822084433.1596209-1-frank.li@vivo.com>

Convert devm_clk_get(), clk_prepare_enable() to a single
call to devm_clk_get_enabled(), as this is exactly
what this function does.

The devm_clk_get_enabled() helpers avoids the calls to
clk_disable_unprepare().

Fixes: bcff4cba41bc ("PHY: Exynos: Add Exynos5250 SATA PHY driver")
Signed-off-by: Yangtao Li <frank.li at vivo.com>
---
 drivers/phy/samsung/phy-exynos5250-sata.c | 20 ++++++--------------
 1 file changed, 6 insertions(+), 14 deletions(-)

diff --git a/drivers/phy/samsung/phy-exynos5250-sata.c b/drivers/phy/samsung/phy-exynos5250-sata.c
index 595adba5fb8f..0452b236ea50 100644
--- a/drivers/phy/samsung/phy-exynos5250-sata.c
+++ b/drivers/phy/samsung/phy-exynos5250-sata.c
@@ -47,7 +47,6 @@
 
 struct exynos_sata_phy {
 	struct phy *phy;
-	struct clk *phyclk;
 	void __iomem *regs;
 	struct regmap *pmureg;
 	struct i2c_client *client;
@@ -164,6 +163,7 @@ static int exynos_sata_phy_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct phy_provider *phy_provider;
 	struct device_node *node;
+	struct clk *phyclk;
 	int ret = 0;
 
 	sata_phy = devm_kzalloc(dev, sizeof(*sata_phy), GFP_KERNEL);
@@ -193,16 +193,10 @@ static int exynos_sata_phy_probe(struct platform_device *pdev)
 
 	dev_set_drvdata(dev, sata_phy);
 
-	sata_phy->phyclk = devm_clk_get(dev, "sata_phyctrl");
-	if (IS_ERR(sata_phy->phyclk)) {
+	phyclk = devm_clk_get_enabled(dev, "sata_phyctrl");
+	if (IS_ERR(phyclk)) {
 		dev_err(dev, "failed to get clk for PHY\n");
-		ret = PTR_ERR(sata_phy->phyclk);
-		goto put_dev;
-	}
-
-	ret = clk_prepare_enable(sata_phy->phyclk);
-	if (ret < 0) {
-		dev_err(dev, "failed to enable source clk\n");
+		ret = PTR_ERR(phyclk);
 		goto put_dev;
 	}
 
@@ -210,7 +204,7 @@ static int exynos_sata_phy_probe(struct platform_device *pdev)
 	if (IS_ERR(sata_phy->phy)) {
 		dev_err(dev, "failed to create PHY\n");
 		ret = PTR_ERR(sata_phy->phy);
-		goto clk_disable;
+		goto put_dev;
 	}
 
 	phy_set_drvdata(sata_phy->phy, sata_phy);
@@ -219,13 +213,11 @@ static int exynos_sata_phy_probe(struct platform_device *pdev)
 					of_phy_simple_xlate);
 	if (IS_ERR(phy_provider)) {
 		ret = PTR_ERR(phy_provider);
-		goto clk_disable;
+		goto put_dev;
 	}
 
 	return 0;
 
-clk_disable:
-	clk_disable_unprepare(sata_phy->phyclk);
 put_dev:
 	put_device(&sata_phy->client->dev);
 
-- 
2.39.0



From ilordash02 at gmail.com  Thu Aug 22 03:35:37 2024
From: ilordash02 at gmail.com (Ilya Orazov)
Date: Thu, 22 Aug 2024 13:35:37 +0300
Subject: [PATCH v3 0/1] dt-bindings: phy: ti,tcan104x-can: Document Microchip
In-Reply-To: <thpryn4unrebkvx4a7jhqmxt5ntmog2gcw3ekh6h72jews4een@b43tsg7poegn>
References: <20240821215357.20224-1-ilordash02@gmail.com> <thpryn4unrebkvx4a7jhqmxt5ntmog2gcw3ekh6h72jews4een@b43tsg7poegn>
Message-ID: <CAGCz5H=vos9sh_ts_ExH8dQSnicFyN+=TfWmBbnqS8egdD+k=Q@mail.gmail.com>

On Thu, 22 Aug 2024 at 10:09, Krzysztof Kozlowski <krzk at kernel.org> wrote:
>
> On Thu, Aug 22, 2024 at 12:53:56AM +0300, Ilya Orazov wrote:
> > Hi all,
> >
> > As suggested in the previous email conversation on this patch, I am
> > sending this new version as a standalone email. I hope this approach
> > makes it easier to review and keeps the conversation history clearer.
>
> Where was it suggested?
>
> Best regards,
> Krzysztof
>

Hi Krzysztof,

Conor suggested that I should not send new versions of the patch as
replies in his mail [0]. So, I sent the new one as a separate email.

0- https://lore.kernel.org/all/20240809-guru-tassel-84a14486a596 at spud/

-- 
Best regards,
Ilya Orazov


From xu.yang_2 at nxp.com  Thu Aug 22 03:42:21 2024
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Thu, 22 Aug 2024 18:42:21 +0800
Subject: [PATCH v2 3/6] dt-bindings: phy: mxs-usb-phy: add nxp,sim
 property
In-Reply-To: <20240726113207.3393247-3-xu.yang_2@nxp.com>
References: <20240726113207.3393247-1-xu.yang_2@nxp.com>
 <20240726113207.3393247-3-xu.yang_2@nxp.com>
Message-ID: <20240822104221.no4xsxqu3l5mdbtu@hippo>

On Fri, Jul 26, 2024 at 07:32:04PM +0800, Xu Yang wrote:
> i.MX7ULP need properly set System Integration Module(SIM) module to make
> usb wakeup work well. This will add a "nxp,sim" property.
> 
> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> 
> ---
> Changes in v2:
>  - add else branch suggested by Rob
> ---
>  .../devicetree/bindings/phy/fsl,mxs-usbphy.yaml | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/phy/fsl,mxs-usbphy.yaml b/Documentation/devicetree/bindings/phy/fsl,mxs-usbphy.yaml
> index f4b1ca2fb562..ce665a2779b7 100644
> --- a/Documentation/devicetree/bindings/phy/fsl,mxs-usbphy.yaml
> +++ b/Documentation/devicetree/bindings/phy/fsl,mxs-usbphy.yaml
> @@ -87,6 +87,12 @@ properties:
>      maximum: 119
>      default: 100
>  
> +  nxp,sim:
> +    description:
> +      The system integration module (SIM) provides system control and chip
> +      configuration registers.
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +
>  required:
>    - compatible
>    - reg
> @@ -110,6 +116,17 @@ allOf:
>        required:
>          - fsl,anatop
>  
> +  - if:
> +      properties:
> +        compatible:
> +          const: fsl,imx7ulp-usbphy
> +    then:
> +      required:
> +        - nxp,sim
> +    else:
> +      properties:
> +        nxp,sim: false
> +
>  additionalProperties: false
>  
>  examples:

A gentle ping.

If it's fine, please add tag for this binding patch. The rest of the
patches (expect dts) are already merged to mainline.

Thanks,
Xu Yang


> -- 
> 2.34.1
> 


From ilordash02 at gmail.com  Thu Aug 22 03:52:37 2024
From: ilordash02 at gmail.com (Ilya Orazov)
Date: Thu, 22 Aug 2024 13:52:37 +0300
Subject: [PATCH v4 0/1] dt-bindings: phy: ti,tcan104x-can: Document Microchip
Message-ID: <20240822105238.213019-1-ilordash02@gmail.com>

Hi,

In this v4, I addressed Krzysztof's comments and incorporated the changelog
and tag received from Conor.

v3:
https://lore.kernel.org/r/20240808191735.1483572-1-ilordash02 at gmail.com/

v2:
https://lore.kernel.org/r/20240807180210.1334724-1-ilordash02 at gmail.com/

v1:
https://lore.kernel.org/r/20240718210322.37492-1-ilordash02 at gmail.com/

First of all, I want to apologize for the silly mistakes in my patch
preparation. I wasn?t aware of the need to include the changelog and
received tags in new versions. This is my first patch in the kernel,
and I am very excited about it. I am eager to gain experience in working
on FOSS.

I greatly appreciate all your feedback, and I will do my best to address
and fix any issues.

Ilya Orazov (1):
  dt-bindings: phy: ti,tcan104x-can: Document Microchip ATA6561

 .../devicetree/bindings/phy/ti,tcan104x-can.yaml    | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)


base-commit: 872cf28b8df9c5c3a1e71a88ee750df7c2513971
-- 
2.34.1



From ilordash02 at gmail.com  Thu Aug 22 03:52:38 2024
From: ilordash02 at gmail.com (Ilya Orazov)
Date: Thu, 22 Aug 2024 13:52:38 +0300
Subject: [PATCH v4 1/1] dt-bindings: phy: ti,tcan104x-can: Document Microchip ATA6561
In-Reply-To: <20240822105238.213019-1-ilordash02@gmail.com>
References: <20240822105238.213019-1-ilordash02@gmail.com>
Message-ID: <20240822105238.213019-2-ilordash02@gmail.com>

Microchip ATA6561 is High-Speed CAN Transceiver with Standby Mode.
It is pin-compatible with TI TCAN1042 and has a compatible programming
model, therefore use ti,tcan1042 as fallback compatible.

Acked-by: Conor Dooley <conor.dooley at microchip.com>
Signed-off-by: Ilya Orazov <ilordash02 at gmail.com>
---
 .../devicetree/bindings/phy/ti,tcan104x-can.yaml    | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
index 79dad3e89aa6..4a8c3829d85d 100644
--- a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
+++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
@@ -14,10 +14,15 @@ properties:
     pattern: "^can-phy"
 
   compatible:
-    enum:
-      - nxp,tjr1443
-      - ti,tcan1042
-      - ti,tcan1043
+    oneOf:
+      - items:
+          - enum:
+              - microchip,ata6561
+          - const: ti,tcan1042
+      - enum:
+          - ti,tcan1042
+          - ti,tcan1043
+          - nxp,tjr1443
 
   '#phy-cells':
     const: 0
-- 
2.34.1



From krzk at kernel.org  Thu Aug 22 04:02:13 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Thu, 22 Aug 2024 13:02:13 +0200
Subject: [PATCH v3 0/1] dt-bindings: phy: ti,tcan104x-can: Document
 Microchip
In-Reply-To: <CAGCz5H=vos9sh_ts_ExH8dQSnicFyN+=TfWmBbnqS8egdD+k=Q@mail.gmail.com>
References: <20240821215357.20224-1-ilordash02@gmail.com>
 <thpryn4unrebkvx4a7jhqmxt5ntmog2gcw3ekh6h72jews4een@b43tsg7poegn>
 <CAGCz5H=vos9sh_ts_ExH8dQSnicFyN+=TfWmBbnqS8egdD+k=Q@mail.gmail.com>
Message-ID: <a9e6fd12-345b-46a2-b5a4-d32a65ff456e@kernel.org>

On 22/08/2024 12:35, Ilya Orazov wrote:
> On Thu, 22 Aug 2024 at 10:09, Krzysztof Kozlowski <krzk at kernel.org> wrote:
>>
>> On Thu, Aug 22, 2024 at 12:53:56AM +0300, Ilya Orazov wrote:
>>> Hi all,
>>>
>>> As suggested in the previous email conversation on this patch, I am
>>> sending this new version as a standalone email. I hope this approach
>>> makes it easier to review and keeps the conversation history clearer.
>>
>> Where was it suggested?
>>
>> Best regards,
>> Krzysztof
>>
> 
> Hi Krzysztof,
> 
> Conor suggested that I should not send new versions of the patch as
> replies in his mail [0]. So, I sent the new one as a separate email.
> 
> 0- https://lore.kernel.org/all/20240809-guru-tassel-84a14486a596 at spud/

OK, I misunderstood what you mean by "standalone email". So this was
just resend? Then patch should be marked as RESEND.

Best regards,
Krzysztof



From krzk at kernel.org  Thu Aug 22 04:41:02 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Thu, 22 Aug 2024 13:41:02 +0200
Subject: [PATCH v2 3/6] dt-bindings: phy: mxs-usb-phy: add nxp,sim
 property
In-Reply-To: <20240726113207.3393247-3-xu.yang_2@nxp.com>
References: <20240726113207.3393247-1-xu.yang_2@nxp.com>
 <20240726113207.3393247-3-xu.yang_2@nxp.com>
Message-ID: <b95e461b-d3aa-41e4-bf93-f14f853f3f03@kernel.org>

On 26/07/2024 13:32, Xu Yang wrote:
> i.MX7ULP need properly set System Integration Module(SIM) module to make
> usb wakeup work well. This will add a "nxp,sim" property.
> 
> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> 

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From claudiu.beznea at tuxon.dev  Thu Aug 22 08:27:45 2024
From: claudiu.beznea at tuxon.dev (Claudiu)
Date: Thu, 22 Aug 2024 18:27:45 +0300
Subject: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
Message-ID: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>

From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>

Hi,

Series adds initial USB support for the Renesas RZ/G3S SoC.

Series is split as follows:

- patch 01/16		- add clock reset and power domain support for USB
- patch 02-04/16	- add reset control support for a USB signal
			  that need to be controlled before/after
			  the power to USB area is turned on/off.
			  
			  Philipp, Ulf, Geert, all,
			  
			  I detailed my approach for this in patch
			  04/16, please have a look and let me know
			  your input.
			  
			  Thank you!

- patch 05/16		- moves SoC identification to SYSC driver
- patch 06-08/16	- updates USB PHY control driver for USB
			  support
- patch 09/16		- update documentation for USBHS
- patch 10-12/16	- updates the USB PHY driver for USB support
- patch 13-15/16	- updates the device tree with USB support
- patch 16/16		- enables the reset control driver

Thank you,
Claudiu Beznea

Claudiu Beznea (16):
  clk: renesas: r9a08g045: Add clocks, resets and power domains for USB
  dt-bindings: soc: renesas: renesas,rzg2l-sysc: Add #reset-cells for
    RZ/G3S
  dt-bindings: reset: renesas,r9a08g045-sysc: Add reset IDs for RZ/G3S
    SYSC reset
  soc: renesas: Add SYSC driver for Renesas RZ/G3S
  soc: renesas: sysc: Move RZ/G3S SoC detection on SYSC driver
  dt-bindings: reset: renesas,rzg2l-usbphy-ctrl: Document RZ/G3S SoC
  reset: rzg2l-usbphy-ctrl: Get reset control array
  reset: rzg2l-usbphy-ctrl: Add support for RZ/G3S
  dt-bindings: usb: renesas,usbhs: Document RZ/G3S SoC
  phy: renesas: rcar-gen3-usb2: Add support to initialize the bus
  dt-bindings: phy: renesas,usb2-phy: Document RZ/G3S phy bindings
  phy: renesas: rcar-gen3-usb2: Add support for the RZ/G3S SoC
  arm64: dts: renesas: Add #reset-cells to system controller node
  arm64: dts: renesas: r9a08g045: Add USB support
  arm64: dts: renesas: rzg3s-smarc: Enable USB support
  arm64: defconfig: Enable RZ/G3S SYSC reset driver

 .../bindings/phy/renesas,usb2-phy.yaml        |   4 +-
 .../reset/renesas,rzg2l-usbphy-ctrl.yaml      |  35 +++-
 .../soc/renesas/renesas,rzg2l-sysc.yaml       |  16 ++
 .../bindings/usb/renesas,usbhs.yaml           |   2 +
 arch/arm64/boot/dts/renesas/r9a08g045.dtsi    | 120 +++++++++++++
 arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi  |  61 +++++++
 arch/arm64/configs/defconfig                  |   1 +
 drivers/clk/renesas/r9a08g045-cpg.c           |  17 ++
 drivers/phy/renesas/phy-rcar-gen3-usb2.c      |  60 ++++++-
 drivers/reset/Kconfig                         |   7 +
 drivers/reset/Makefile                        |   1 +
 drivers/reset/reset-rzg2l-usbphy-ctrl.c       |   3 +-
 drivers/reset/reset-rzg3s-sysc.c              | 140 ++++++++++++++++
 drivers/soc/renesas/Makefile                  |   1 +
 drivers/soc/renesas/renesas-soc.c             |  12 --
 drivers/soc/renesas/rzg3s-sysc.c              | 158 ++++++++++++++++++
 .../reset/renesas,r9a08g045-sysc.h            |  10 ++
 include/linux/soc/renesas/rzg3s-sysc-reset.h  |  24 +++
 18 files changed, 648 insertions(+), 24 deletions(-)
 create mode 100644 drivers/reset/reset-rzg3s-sysc.c
 create mode 100644 drivers/soc/renesas/rzg3s-sysc.c
 create mode 100644 include/dt-bindings/reset/renesas,r9a08g045-sysc.h
 create mode 100644 include/linux/soc/renesas/rzg3s-sysc-reset.h

-- 
2.39.2



From claudiu.beznea at tuxon.dev  Thu Aug 22 08:27:46 2024
From: claudiu.beznea at tuxon.dev (Claudiu)
Date: Thu, 22 Aug 2024 18:27:46 +0300
Subject: [PATCH 01/16] clk: renesas: r9a08g045: Add clocks, resets and power domains for USB
In-Reply-To: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <20240822152801.602318-2-claudiu.beznea.uj@bp.renesas.com>

From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>

Add clocks, resets and power domains for USB modules available on the
Renesas RZ/G3S SoC.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
---
 drivers/clk/renesas/r9a08g045-cpg.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/drivers/clk/renesas/r9a08g045-cpg.c b/drivers/clk/renesas/r9a08g045-cpg.c
index a891bfc3ab5a..6e9529678307 100644
--- a/drivers/clk/renesas/r9a08g045-cpg.c
+++ b/drivers/clk/renesas/r9a08g045-cpg.c
@@ -207,6 +207,10 @@ static const struct rzg2l_mod_clk r9a08g045_mod_clks[] = {
 	DEF_MOD("sdhi2_imclk2",		R9A08G045_SDHI2_IMCLK2, CLK_SD2_DIV4, 0x554, 9),
 	DEF_MOD("sdhi2_clk_hs",		R9A08G045_SDHI2_CLK_HS, R9A08G045_CLK_SD2, 0x554, 10),
 	DEF_MOD("sdhi2_aclk",		R9A08G045_SDHI2_ACLK, R9A08G045_CLK_P1, 0x554, 11),
+	DEF_MOD("usb0_host",		R9A08G045_USB_U2H0_HCLK, R9A08G045_CLK_P1, 0x578, 0),
+	DEF_MOD("usb1_host",		R9A08G045_USB_U2H1_HCLK, R9A08G045_CLK_P1, 0x578, 1),
+	DEF_MOD("usb0_func",		R9A08G045_USB_U2P_EXR_CPUCLK, R9A08G045_CLK_P1, 0x578, 2),
+	DEF_MOD("usb_pclk",		R9A08G045_USB_PCLK, R9A08G045_CLK_P1, 0x578, 3),
 	DEF_COUPLED("eth0_axi",		R9A08G045_ETH0_CLK_AXI, R9A08G045_CLK_M0, 0x57c, 0),
 	DEF_COUPLED("eth0_chi",		R9A08G045_ETH0_CLK_CHI, R9A08G045_CLK_ZT, 0x57c, 0),
 	DEF_MOD("eth0_refclk",		R9A08G045_ETH0_REFCLK, R9A08G045_CLK_HP, 0x57c, 8),
@@ -230,6 +234,10 @@ static const struct rzg2l_reset r9a08g045_resets[] = {
 	DEF_RST(R9A08G045_SDHI0_IXRST, 0x854, 0),
 	DEF_RST(R9A08G045_SDHI1_IXRST, 0x854, 1),
 	DEF_RST(R9A08G045_SDHI2_IXRST, 0x854, 2),
+	DEF_RST(R9A08G045_USB_U2H0_HRESETN, 0x878, 0),
+	DEF_RST(R9A08G045_USB_U2H1_HRESETN, 0x878, 1),
+	DEF_RST(R9A08G045_USB_U2P_EXL_SYSRST, 0x878, 2),
+	DEF_RST(R9A08G045_USB_PRESETN, 0x878, 3),
 	DEF_RST(R9A08G045_ETH0_RST_HW_N, 0x87c, 0),
 	DEF_RST(R9A08G045_ETH1_RST_HW_N, 0x87c, 1),
 	DEF_RST(R9A08G045_I2C0_MRST, 0x880, 0),
@@ -277,6 +285,15 @@ static const struct rzg2l_cpg_pm_domain_init_data r9a08g045_pm_domains[] = {
 	DEF_PD("sdhi2",		R9A08G045_PD_SDHI2,
 				DEF_REG_CONF(CPG_BUS_PERI_COM_MSTOP, BIT(11)),
 				RZG2L_PD_F_NONE),
+	DEF_PD("usb0",		R9A08G045_PD_USB0,
+				DEF_REG_CONF(CPG_BUS_PERI_COM_MSTOP, GENMASK(6, 5)),
+				RZG2L_PD_F_NONE),
+	DEF_PD("usb1",		R9A08G045_PD_USB1,
+				DEF_REG_CONF(CPG_BUS_PERI_COM_MSTOP, BIT(7)),
+				RZG2L_PD_F_NONE),
+	DEF_PD("usb-phy",	R9A08G045_PD_USB_PHY,
+				DEF_REG_CONF(CPG_BUS_PERI_COM_MSTOP, BIT(4)),
+				RZG2L_PD_F_NONE),
 	DEF_PD("eth0",		R9A08G045_PD_ETHER0,
 				DEF_REG_CONF(CPG_BUS_PERI_COM_MSTOP, BIT(2)),
 				RZG2L_PD_F_NONE),
-- 
2.39.2



From claudiu.beznea at tuxon.dev  Thu Aug 22 08:27:47 2024
From: claudiu.beznea at tuxon.dev (Claudiu)
Date: Thu, 22 Aug 2024 18:27:47 +0300
Subject: [PATCH 02/16] dt-bindings: soc: renesas: renesas,rzg2l-sysc: Add #reset-cells for RZ/G3S
In-Reply-To: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <20240822152801.602318-3-claudiu.beznea.uj@bp.renesas.com>

From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>

The RZ/G3S System controller has registers to control signals that need
to be de-asserted/asserted before/after different SoC areas are power
on/off. This signals are implemented as reset signals. For this document
the #reset-cells property.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
---
 .../bindings/soc/renesas/renesas,rzg2l-sysc.yaml | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
index 4386b2c3fa4d..6b0bb34485d9 100644
--- a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
+++ b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
@@ -42,12 +42,28 @@ properties:
       - const: cm33stbyr_int
       - const: ca55_deny
 
+  "#reset-cells":
+    const: 1
+
 required:
   - compatible
   - reg
 
 additionalProperties: false
 
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: renesas,r9a08g045-sysc
+    then:
+      required:
+        - "#reset-cells"
+    else:
+      properties:
+        "#reset-cells": false
+
 examples:
   - |
     #include <dt-bindings/interrupt-controller/arm-gic.h>
-- 
2.39.2



From claudiu.beznea at tuxon.dev  Thu Aug 22 08:27:48 2024
From: claudiu.beznea at tuxon.dev (Claudiu)
Date: Thu, 22 Aug 2024 18:27:48 +0300
Subject: [PATCH 03/16] dt-bindings: reset: renesas,r9a08g045-sysc: Add reset IDs for RZ/G3S SYSC reset
In-Reply-To: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <20240822152801.602318-4-claudiu.beznea.uj@bp.renesas.com>

From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>

Add reset IDs for the Renesas RZ/G3S SYSC reset controller driver.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
---
 include/dt-bindings/reset/renesas,r9a08g045-sysc.h | 10 ++++++++++
 1 file changed, 10 insertions(+)
 create mode 100644 include/dt-bindings/reset/renesas,r9a08g045-sysc.h

diff --git a/include/dt-bindings/reset/renesas,r9a08g045-sysc.h b/include/dt-bindings/reset/renesas,r9a08g045-sysc.h
new file mode 100644
index 000000000000..675872a32121
--- /dev/null
+++ b/include/dt-bindings/reset/renesas,r9a08g045-sysc.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+
+#ifndef __DT_BINDINGS_RESET_R9A08G045_SYSC_H
+#define __DT_BINDINGS_RESET_R9A08G045_SYSC_H
+
+#define R9A08G045_SYSC_RESET_USB	0
+#define R9A08G045_SYSC_RESET_PCIE	1
+
+#endif /* __DT_BINDINGS_RESET_SAMA7G5_H */
+
-- 
2.39.2



From claudiu.beznea at tuxon.dev  Thu Aug 22 08:27:49 2024
From: claudiu.beznea at tuxon.dev (Claudiu)
Date: Thu, 22 Aug 2024 18:27:49 +0300
Subject: [PATCH 04/16] soc: renesas: Add SYSC driver for Renesas RZ/G3S
In-Reply-To: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <20240822152801.602318-5-claudiu.beznea.uj@bp.renesas.com>

From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>

The RZ/G3S SYS Controller has 2 registers (one for PCIE one for USB) that
need to be configured before/after powering off/on the PCI or USB
ares. The bits in these registers control signals to PCIE and USB that
need to be de-asserted/asserted after/before power on/off event. For this
add SYSC controller driver that registers a reset controller driver on
auxiliary bus which allows USB, PCIE drivers to control these signals.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
---

Hi, Philipp, Ulf, Geert, all,

In this series the control of USB and PCIE signals was implemented
though a reset control driver. This approach was chosen as a result
of looking though the HW manual and trying to understand how these
signals behave. HW manual can be downloaded from [1] (download
manual hardware button -> confirm -> extract archive ->
Deliverables -> r01uh1014ej0110-rzg3s.pdf).

The description of the USB and PCIE control registers is as follows:

SYS_USB_PWRRDY Register (Signal is called PWRRDY), Chapter 6.3.83:

Controls PWRRDY terminal of USB:
0: PWRRDY
1: PWRRDY down
When turning off the USB region power, set this bit to 1.
When turning on the USB region power, set this bit to 0.

SYS_PCIE_RST_RSM_B (Signal is called RST_RSM_B), Chapter 6.3.84:

Controls RST_RSM_B terminal of PCIe
0: RST_RSM_B=0
1: RST_RSM_B=1
Set RST_RSM_B=1 after PCIe power is applied.
When the power in the PCIe region is turned off, set RST_RSM_B=0
before turning off the power supply.

>From this description I understood that the control of the USB PWRRDY,
PCIE RST_RSM_B signals and the power control for the domains
the USB, PCI belongs are different things [A].

As of Figure 41.1 (Power Domain and Power Supply) and Table 41.1 (Power
Domain to which Power Supply Pins Belong) the USB and PCIE belongs to
PD_ISOVCC power domain controlled though PMIC [B].

The USB, PCI signals are also reference in HW manual in the low power
consumption chapter describing the transition to different power
modes. E.g., chapter 41.6.1 (ALL_ON to VBATT), Table 41.8 (Example
Transition Flow Outline from ALL_ON Mode to VBATT Mode) says at
steps 6 and 7:

6. USB PHY PWRRDY signal control (if using USB) SYS_USB_PWRRDY
7. PCIe RST_RSM_B signal control (if using PCIe) SYS_PCIE_RST_RSM_B

Meaning these signals need to be controlled before going to VBATT
power mode (where the power supply to USB is turned off) [C].

Due to [A], [B] and [C] I chosed to have the implementation of these
signals though a reset control driver.

Other option I explored was though power domains as follows:
1/ registering one domain for USB, one of PCIE
2/ passed the domain ID to USB though device tree
3/ attach from USB PHY control driver to the USB power domain
   with dev_pm_domain_attach_by_name()
4/ and controlling the SYSC registers with
   pm_runtime_resume_and_get(usb_sysc_domain).

Please let me know what do you think about this!

Thank you,
Claudiu Beznea


[1] https://www.renesas.com/us/en/products/microcontrollers-microprocessors/rz-mpus/rzg3s-general-purpose-microprocessors-single-core-arm-cortex-a55-11-ghz-cpu-and-dual-core-cortex-m33-250

 drivers/reset/Kconfig                        |   7 +
 drivers/reset/Makefile                       |   1 +
 drivers/reset/reset-rzg3s-sysc.c             | 140 +++++++++++++++++++
 drivers/soc/renesas/Makefile                 |   1 +
 drivers/soc/renesas/rzg3s-sysc.c             | 113 +++++++++++++++
 include/linux/soc/renesas/rzg3s-sysc-reset.h |  24 ++++
 6 files changed, 286 insertions(+)
 create mode 100644 drivers/reset/reset-rzg3s-sysc.c
 create mode 100644 drivers/soc/renesas/rzg3s-sysc.c
 create mode 100644 include/linux/soc/renesas/rzg3s-sysc-reset.h

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 67bce340a87e..fbdf860b2293 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -218,6 +218,13 @@ config RESET_RZG2L_USBPHY_CTRL
 	  Support for USBPHY Control found on RZ/G2L family. It mainly
 	  controls reset and power down of the USB/PHY.
 
+config RESET_RZG3S_SYSC
+	tristate "Renesas RZ/G3S SYSC reset driver"
+	depends on ARCH_R9A08G045 || COMPILE_TEST
+	help
+	  Support for SYSC reset found on RZ/G3S family. It mainly
+	  controls reset on USB and PCIE.
+
 config RESET_SCMI
 	tristate "Reset driver controlled via ARM SCMI interface"
 	depends on ARM_SCMI_PROTOCOL || COMPILE_TEST
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 27b0bbdfcc04..ee5ca21acc44 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_RESET_QCOM_AOSS) += reset-qcom-aoss.o
 obj-$(CONFIG_RESET_QCOM_PDC) += reset-qcom-pdc.o
 obj-$(CONFIG_RESET_RASPBERRYPI) += reset-raspberrypi.o
 obj-$(CONFIG_RESET_RZG2L_USBPHY_CTRL) += reset-rzg2l-usbphy-ctrl.o
+obj-$(CONFIG_RESET_RZG3S_SYSC) += reset-rzg3s-sysc.o
 obj-$(CONFIG_RESET_SCMI) += reset-scmi.o
 obj-$(CONFIG_RESET_SIMPLE) += reset-simple.o
 obj-$(CONFIG_RESET_SOCFPGA) += reset-socfpga.o
diff --git a/drivers/reset/reset-rzg3s-sysc.c b/drivers/reset/reset-rzg3s-sysc.c
new file mode 100644
index 000000000000..56af03f1d8a2
--- /dev/null
+++ b/drivers/reset/reset-rzg3s-sysc.c
@@ -0,0 +1,140 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Renesas RZ/G3S SYSC reset driver
+ *
+ * Copyright (C) 2024 Renesas Electronics Corp.
+ */
+
+#include <linux/auxiliary_bus.h>
+#include <linux/io.h>
+#include <linux/mod_devicetable.h>
+#include <linux/platform_device.h>
+#include <linux/reset-controller.h>
+#include <linux/soc/renesas/rzg3s-sysc-reset.h>
+
+#include <dt-bindings/reset/renesas,r9a08g045-sysc.h>
+
+#define RZG3S_SYSC_USB_PWRRDY		0xd70
+#define RZG3S_SYSC_PCIE_RST_RSM_B	0xd74
+#define RZG3S_SYSC_RESET_MASK		0x1
+
+/**
+ * struct rzg3s_sysc_reset_info - SYSC reset information
+ * @offset: offset to configure the reset
+ * @assert_val: value to write to register on assert
+ * @deassert_val: value to write to register on de-assert
+ */
+struct rzg3s_sysc_reset_info {
+	u16 offset;
+	u8 assert_val;
+	u8 deassert_val;
+};
+
+/**
+ * struct rzg3s_sysc_reset - SYSC reset
+ * @info: SYSC reset information
+ * @radev: SYSC reset auxiliary device
+ * @rcdev: reset controller device
+ */
+struct rzg3s_sysc_reset {
+	const struct rzg3s_sysc_reset_info *info;
+	struct rzg3s_sysc_reset_adev *radev;
+	struct reset_controller_dev rcdev;
+};
+
+#define to_rzg3s_sysc_reset(r)	container_of(r, struct rzg3s_sysc_reset, rcdev)
+
+static int rzg3s_sysc_reset_set(struct reset_controller_dev *rcdev,
+				unsigned long id, bool assert)
+{
+	struct rzg3s_sysc_reset *reset = to_rzg3s_sysc_reset(rcdev);
+	struct rzg3s_sysc_reset_adev *radev = reset->radev;
+	struct rzg3s_sysc_reset_info info = reset->info[id];
+	unsigned long flags;
+	u32 tmp;
+
+	spin_lock_irqsave(radev->lock, flags);
+	tmp = readl(radev->base + info.offset);
+	tmp &= ~RZG3S_SYSC_RESET_MASK;
+	tmp |= assert ? info.assert_val : info.deassert_val;
+	writel(tmp, radev->base + info.offset);
+	spin_unlock_irqrestore(radev->lock, flags);
+
+	return 0;
+}
+
+static int rzg3s_sysc_reset_assert(struct reset_controller_dev *rcdev,
+				   unsigned long id)
+{
+	return rzg3s_sysc_reset_set(rcdev, id, true);
+}
+
+static int rzg3s_sysc_reset_deassert(struct reset_controller_dev *rcdev,
+				     unsigned long id)
+{
+	return rzg3s_sysc_reset_set(rcdev, id, false);
+}
+
+static int rzg3s_sysc_reset_status(struct reset_controller_dev *rcdev,
+				   unsigned long id)
+{
+	struct rzg3s_sysc_reset *reset = to_rzg3s_sysc_reset(rcdev);
+	const struct rzg3s_sysc_reset_info info = reset->info[id];
+	struct rzg3s_sysc_reset_adev *radev = reset->radev;
+	u32 tmp;
+
+	tmp = readl(radev->base + info.offset);
+	tmp = !!(tmp & RZG3S_SYSC_RESET_MASK);
+
+	return info.assert_val ? tmp : !tmp;
+}
+
+static const struct reset_control_ops rzg3s_sysc_reset_ops = {
+	.assert = rzg3s_sysc_reset_assert,
+	.deassert = rzg3s_sysc_reset_deassert,
+	.status = rzg3s_sysc_reset_status,
+};
+
+static const struct rzg3s_sysc_reset_info rzg3s_sysc_reset_info[] = {
+	[R9A08G045_SYSC_RESET_USB] = {
+		.offset = RZG3S_SYSC_USB_PWRRDY, .assert_val = 1, .deassert_val = 0
+	},
+	[R9A08G045_SYSC_RESET_PCIE] = {
+		.offset = RZG3S_SYSC_PCIE_RST_RSM_B, .assert_val = 0, .deassert_val = 1
+	},
+};
+
+static int rzg3s_sysc_reset_probe(struct auxiliary_device *adev,
+				  const struct auxiliary_device_id *id)
+{
+	struct rzg3s_sysc_reset_adev *reset_adev = to_rzg3s_sysc_reset_adev(adev);
+	struct device *dev = &adev->dev;
+	struct rzg3s_sysc_reset *reset;
+
+	reset = devm_kzalloc(dev, sizeof(*reset), GFP_KERNEL);
+	if (!reset)
+		return -ENOMEM;
+
+	reset->radev = reset_adev;
+	reset->info = rzg3s_sysc_reset_info;
+
+	reset->rcdev.ops = &rzg3s_sysc_reset_ops;
+	reset->rcdev.of_reset_n_cells = 1;
+	reset->rcdev.nr_resets = ARRAY_SIZE(rzg3s_sysc_reset_info);
+	reset->rcdev.of_node = dev->parent->of_node;
+	reset->rcdev.dev = dev;
+
+	return devm_reset_controller_register(dev, &reset->rcdev);
+}
+
+static const struct auxiliary_device_id rzg3s_sysc_reset_ids[] = {
+	{ .name = "rzg3s_sysc.reset" },
+	{ }
+};
+MODULE_DEVICE_TABLE(auxiliary, rzg3s_sysc_reset_ids);
+
+static struct auxiliary_driver rzg3s_sysc_reset_driver = {
+	.probe		= rzg3s_sysc_reset_probe,
+	.id_table	= rzg3s_sysc_reset_ids,
+};
+module_auxiliary_driver(rzg3s_sysc_reset_driver);
diff --git a/drivers/soc/renesas/Makefile b/drivers/soc/renesas/Makefile
index 734f8f8cefa4..74c72ac46f91 100644
--- a/drivers/soc/renesas/Makefile
+++ b/drivers/soc/renesas/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_SOC_RENESAS)	+= renesas-soc.o
 ifdef CONFIG_SMP
 obj-$(CONFIG_ARCH_R9A06G032)	+= r9a06g032-smp.o
 endif
+obj-$(CONFIG_ARCH_R9A08G045)	+= rzg3s-sysc.o
 
 # Family
 obj-$(CONFIG_PWC_RZV2M)		+= pwc-rzv2m.o
diff --git a/drivers/soc/renesas/rzg3s-sysc.c b/drivers/soc/renesas/rzg3s-sysc.c
new file mode 100644
index 000000000000..e664d29ce5c3
--- /dev/null
+++ b/drivers/soc/renesas/rzg3s-sysc.c
@@ -0,0 +1,113 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * RZ/G3S System controller driver
+ *
+ * Copyright (C) 2024 Renesas Electronics Corp.
+ */
+
+#include <linux/auxiliary_bus.h>
+#include <linux/platform_device.h>
+
+#include <linux/soc/renesas/rzg3s-sysc-reset.h>
+
+/**
+ * struct rzg3s_sysc - SYSC private data structure
+ * @base: base address
+ * @dev: device
+ * @lock: lock
+ */
+struct rzg3s_sysc {
+	void __iomem *base;
+	struct device *dev;
+	spinlock_t lock;
+};
+
+static void rzg3s_sysc_reset_adev_release(struct device *dev)
+{
+	struct auxiliary_device *adev = to_auxiliary_dev(dev);
+	struct rzg3s_sysc_reset_adev *reset_adev = to_rzg3s_sysc_reset_adev(adev);
+
+	kfree(reset_adev);
+}
+
+static void rzg3s_sysc_reset_unregister_adev(void *adev)
+{
+	auxiliary_device_delete(adev);
+	auxiliary_device_uninit(adev);
+}
+
+static int rzg3s_sysc_reset_probe(struct rzg3s_sysc *sysc, const char *adev_name,
+				  u32 adev_id)
+{
+	struct rzg3s_sysc_reset_adev *radev;
+	struct auxiliary_device *adev;
+	int ret;
+
+	radev = kzalloc(sizeof(*radev), GFP_KERNEL);
+	if (!radev)
+		return -ENOMEM;
+
+	radev->base = sysc->base;
+	radev->lock = &sysc->lock;
+
+	adev = &radev->adev;
+	adev->name = adev_name;
+	adev->dev.parent = sysc->dev;
+	adev->dev.release = rzg3s_sysc_reset_adev_release;
+	adev->id = adev_id;
+
+	ret = auxiliary_device_init(adev);
+	if (ret)
+		return ret;
+
+	ret = auxiliary_device_add(adev);
+	if (ret) {
+		auxiliary_device_uninit(adev);
+		return ret;
+	}
+
+	return devm_add_action_or_reset(sysc->dev, rzg3s_sysc_reset_unregister_adev, adev);
+}
+
+static int rzg3s_sysc_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct rzg3s_sysc *sysc;
+
+	sysc = devm_kzalloc(dev, sizeof(*sysc), GFP_KERNEL);
+	if (!sysc)
+		return -ENOMEM;
+
+	sysc->base = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(sysc->base))
+		return PTR_ERR(sysc->base);
+
+	sysc->dev = dev;
+	spin_lock_init(&sysc->lock);
+
+	return rzg3s_sysc_reset_probe(sysc, "reset", 0);
+}
+
+static const struct of_device_id rzg3s_sysc_match[] = {
+	{ .compatible = "renesas,r9a08g045-sysc" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, rzg3s_sysc_match);
+
+static struct platform_driver rzg3s_sysc_driver = {
+	.driver = {
+		.name = "renesas-rzg3s-sysc",
+		.of_match_table = rzg3s_sysc_match
+	},
+	.probe = rzg3s_sysc_probe
+};
+
+static int __init rzg3s_sysc_init(void)
+{
+	return platform_driver_register(&rzg3s_sysc_driver);
+}
+subsys_initcall(rzg3s_sysc_init);
+
+MODULE_DESCRIPTION("Renesas RZ/G3S System Controller Driver");
+MODULE_AUTHOR("Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/soc/renesas/rzg3s-sysc-reset.h b/include/linux/soc/renesas/rzg3s-sysc-reset.h
new file mode 100644
index 000000000000..813cbe82a68a
--- /dev/null
+++ b/include/linux/soc/renesas/rzg3s-sysc-reset.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef __SOC_RENESAS_SYSC_RESET_RZG3S_H
+#define __SOC_RENESAS_SYSC_RESET_RZG3S_H
+
+#include <linux/auxiliary_bus.h>
+#include <linux/spinlock_types.h>
+#include <linux/container_of.h>
+
+/**
+ * struct rzg3s_sysc_reset_adev - SYSC reset auxiliary device
+ * @base: base address
+ * @lock: lock
+ * @adev: auxiliary device
+ */
+struct rzg3s_sysc_reset_adev {
+	void __iomem *base;
+	spinlock_t *lock;
+	struct auxiliary_device adev;
+};
+
+#define to_rzg3s_sysc_reset_adev(a)	container_of(a, struct rzg3s_sysc_reset_adev, adev)
+
+#endif
-- 
2.39.2



From claudiu.beznea at tuxon.dev  Thu Aug 22 08:27:50 2024
From: claudiu.beznea at tuxon.dev (Claudiu)
Date: Thu, 22 Aug 2024 18:27:50 +0300
Subject: [PATCH 05/16] soc: renesas: sysc: Move RZ/G3S SoC detection on SYSC driver
In-Reply-To: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <20240822152801.602318-6-claudiu.beznea.uj@bp.renesas.com>

From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>

Now that we have a driver for SYSC driver for RZ/G3S move the SoC detection
for RZ/G3S in SYSC driver.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
---
 drivers/soc/renesas/renesas-soc.c | 12 ---------
 drivers/soc/renesas/rzg3s-sysc.c  | 45 +++++++++++++++++++++++++++++++
 2 files changed, 45 insertions(+), 12 deletions(-)

diff --git a/drivers/soc/renesas/renesas-soc.c b/drivers/soc/renesas/renesas-soc.c
index 172d59e6fbcf..425d9037dcd0 100644
--- a/drivers/soc/renesas/renesas-soc.c
+++ b/drivers/soc/renesas/renesas-soc.c
@@ -71,10 +71,6 @@ static const struct renesas_family fam_rzg2ul __initconst __maybe_unused = {
 	.name	= "RZ/G2UL",
 };
 
-static const struct renesas_family fam_rzg3s __initconst __maybe_unused = {
-	.name	= "RZ/G3S",
-};
-
 static const struct renesas_family fam_rzv2h __initconst __maybe_unused = {
 	.name	= "RZ/V2H",
 };
@@ -176,11 +172,6 @@ static const struct renesas_soc soc_rz_g2ul __initconst __maybe_unused = {
 	.id     = 0x8450447,
 };
 
-static const struct renesas_soc soc_rz_g3s __initconst __maybe_unused = {
-	.family = &fam_rzg3s,
-	.id	= 0x85e0447,
-};
-
 static const struct renesas_soc soc_rz_v2h __initconst __maybe_unused = {
 	.family = &fam_rzv2h,
 	.id     = 0x847a447,
@@ -410,9 +401,6 @@ static const struct of_device_id renesas_socs[] __initconst __maybe_unused = {
 #ifdef CONFIG_ARCH_R9A07G054
 	{ .compatible = "renesas,r9a07g054",	.data = &soc_rz_v2l },
 #endif
-#ifdef CONFIG_ARCH_R9A08G045
-	{ .compatible = "renesas,r9a08g045",	.data = &soc_rz_g3s },
-#endif
 #ifdef CONFIG_ARCH_R9A09G011
 	{ .compatible = "renesas,r9a09g011",	.data = &soc_rz_v2m },
 #endif
diff --git a/drivers/soc/renesas/rzg3s-sysc.c b/drivers/soc/renesas/rzg3s-sysc.c
index e664d29ce5c3..1dd48c7255d1 100644
--- a/drivers/soc/renesas/rzg3s-sysc.c
+++ b/drivers/soc/renesas/rzg3s-sysc.c
@@ -6,10 +6,16 @@
  */
 
 #include <linux/auxiliary_bus.h>
+#include <linux/io.h>
+#include <linux/of.h>
 #include <linux/platform_device.h>
+#include <linux/sys_soc.h>
 
 #include <linux/soc/renesas/rzg3s-sysc-reset.h>
 
+#define RZG3S_SYS_LSI_DEVID		0xa04
+#define RZG3S_SYS_LSI_DEVID_REV		GENMASK(31, 28)
+
 /**
  * struct rzg3s_sysc - SYSC private data structure
  * @base: base address
@@ -71,8 +77,14 @@ static int rzg3s_sysc_reset_probe(struct rzg3s_sysc *sysc, const char *adev_name
 
 static int rzg3s_sysc_probe(struct platform_device *pdev)
 {
+	const char *soc_id_start, *soc_id_end, *compatible;
+	struct soc_device_attribute *soc_dev_attr;
 	struct device *dev = &pdev->dev;
+	struct soc_device *soc_dev;
 	struct rzg3s_sysc *sysc;
+	char soc_id[32] = {0};
+	u32 devid, revision;
+	u8 size;
 
 	sysc = devm_kzalloc(dev, sizeof(*sysc), GFP_KERNEL);
 	if (!sysc)
@@ -85,6 +97,39 @@ static int rzg3s_sysc_probe(struct platform_device *pdev)
 	sysc->dev = dev;
 	spin_lock_init(&sysc->lock);
 
+	compatible = of_get_property(dev->of_node, "compatible", NULL);
+	if (!compatible)
+		return -ENODEV;
+
+	soc_id_start = strchr(compatible, ',') + 1;
+	soc_id_end = strchr(compatible, '-');
+	size = soc_id_end - soc_id_start;
+	if (size > 32)
+		size = 32;
+	strscpy(soc_id, soc_id_start, size);
+
+	soc_dev_attr = devm_kzalloc(dev, sizeof(*soc_dev_attr), GFP_KERNEL);
+	if (!soc_dev_attr)
+		return -ENOMEM;
+
+	soc_dev_attr->family = "RZ/G3S";
+	soc_dev_attr->soc_id = devm_kstrdup(dev, soc_id, GFP_KERNEL);
+	if (!soc_dev_attr->soc_id)
+		return -ENOMEM;
+
+	devid = readl(sysc->base + RZG3S_SYS_LSI_DEVID);
+	revision = FIELD_GET(RZG3S_SYS_LSI_DEVID_REV, devid);
+	soc_dev_attr->revision = devm_kasprintf(dev, GFP_KERNEL, "%u", revision);
+	if (!soc_dev_attr->revision)
+		return -ENOMEM;
+
+	dev_info(dev, "Detected Renesas %s %s Rev %s\n", soc_dev_attr->family,
+		 soc_dev_attr->soc_id, soc_dev_attr->revision);
+
+	soc_dev = soc_device_register(soc_dev_attr);
+	if (IS_ERR(soc_dev))
+		return PTR_ERR(soc_dev);
+
 	return rzg3s_sysc_reset_probe(sysc, "reset", 0);
 }
 
-- 
2.39.2



From claudiu.beznea at tuxon.dev  Thu Aug 22 08:27:51 2024
From: claudiu.beznea at tuxon.dev (Claudiu)
Date: Thu, 22 Aug 2024 18:27:51 +0300
Subject: [PATCH 06/16] dt-bindings: reset: renesas,rzg2l-usbphy-ctrl: Document RZ/G3S SoC
In-Reply-To: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <20240822152801.602318-7-claudiu.beznea.uj@bp.renesas.com>

From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>

Document the Renesas RZ/G3S USB PHY Control IP. This is similar with the
one found on the RZ/G2L SoC the exception being that the SYSC USB specific
signal need to be configured before accessing the USB area. This is
done though a reset signal.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
---
 .../reset/renesas,rzg2l-usbphy-ctrl.yaml      | 35 +++++++++++++++----
 1 file changed, 28 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml b/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml
index b0b20af15313..5f053981474e 100644
--- a/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml
+++ b/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml
@@ -15,12 +15,15 @@ description:
 
 properties:
   compatible:
-    items:
-      - enum:
-          - renesas,r9a07g043-usbphy-ctrl # RZ/G2UL and RZ/Five
-          - renesas,r9a07g044-usbphy-ctrl # RZ/G2{L,LC}
-          - renesas,r9a07g054-usbphy-ctrl # RZ/V2L
-      - const: renesas,rzg2l-usbphy-ctrl
+    oneOf:
+      - const: renesas,r9a08g045-usbphy-ctrl # RZ/G3S
+
+      - items:
+          - enum:
+              - renesas,r9a07g043-usbphy-ctrl # RZ/G2UL and RZ/Five
+              - renesas,r9a07g044-usbphy-ctrl # RZ/G2{L,LC}
+              - renesas,r9a07g054-usbphy-ctrl # RZ/V2L
+          - const: renesas,rzg2l-usbphy-ctrl
 
   reg:
     maxItems: 1
@@ -29,7 +32,8 @@ properties:
     maxItems: 1
 
   resets:
-    maxItems: 1
+    minItems: 1
+    maxItems: 2
 
   power-domains:
     maxItems: 1
@@ -59,6 +63,23 @@ required:
 
 additionalProperties: false
 
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: renesas,r9a08g045-usbphy-ctrl
+    then:
+      properties:
+        resets:
+          items:
+            - description: USB PHY Control module reset
+            - description: USB area reset
+    else:
+      properties:
+        resets:
+          maxItems: 1
+
 examples:
   - |
     #include <dt-bindings/clock/r9a07g044-cpg.h>
-- 
2.39.2



From claudiu.beznea at tuxon.dev  Thu Aug 22 08:27:52 2024
From: claudiu.beznea at tuxon.dev (Claudiu)
Date: Thu, 22 Aug 2024 18:27:52 +0300
Subject: [PATCH 07/16] reset: rzg2l-usbphy-ctrl: Get reset control array
In-Reply-To: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <20240822152801.602318-8-claudiu.beznea.uj@bp.renesas.com>

From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>

Before accessing the USB area of the RZ/G3S SoC the PWRRDY bit of the
SYS_USB_PWRRDY register need to be cleared. When USB area is not used the
PWRRDY bit of the SYS_USB_PWRRDY register need to be set. This register is
in the SYSC controller address space and the assert/de-assert of the
signal handled by SYSC_USB_PWRRDY was implemented as a reset signal.

The USB modules available on the RZ/G3S SoC that need this bit set are:
- USB ch0 (supporting host and peripheral mode)
- USB ch2 (supporting host mode)
- USBPHY control

As the USBPHY control is the root device for all the other USB channels
(USB ch0, USB ch1) add support to set the PWRRDY for the USB area when
initializing the USBPHY control. As this is done though reset signals
get the reset array in the USBPHY control driver.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
---
 drivers/reset/reset-rzg2l-usbphy-ctrl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/reset/reset-rzg2l-usbphy-ctrl.c b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
index 1cd157f4f03b..8b64c12f3bec 100644
--- a/drivers/reset/reset-rzg2l-usbphy-ctrl.c
+++ b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
@@ -132,7 +132,7 @@ static int rzg2l_usbphy_ctrl_probe(struct platform_device *pdev)
 	if (IS_ERR(regmap))
 		return PTR_ERR(regmap);
 
-	priv->rstc = devm_reset_control_get_exclusive(&pdev->dev, NULL);
+	priv->rstc = devm_reset_control_array_get_exclusive(&pdev->dev);
 	if (IS_ERR(priv->rstc))
 		return dev_err_probe(dev, PTR_ERR(priv->rstc),
 				     "failed to get reset\n");
-- 
2.39.2



From claudiu.beznea at tuxon.dev  Thu Aug 22 08:27:53 2024
From: claudiu.beznea at tuxon.dev (Claudiu)
Date: Thu, 22 Aug 2024 18:27:53 +0300
Subject: [PATCH 08/16] reset: rzg2l-usbphy-ctrl: Add support for RZ/G3S
In-Reply-To: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <20240822152801.602318-9-claudiu.beznea.uj@bp.renesas.com>

From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>

Add support for RZ/G3S SoC. It needs its own compatible as it uses 2
reset signals and it cannot work w/o both of them. To be able to
fully validate this on DT schema, too, the RZ/G3S uses it's own compatible
w/o a fallback (as if the fallback will be used the RZ/G3S will not work
anyway).

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
---
 drivers/reset/reset-rzg2l-usbphy-ctrl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/reset/reset-rzg2l-usbphy-ctrl.c b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
index 8b64c12f3bec..08b18d7de7ad 100644
--- a/drivers/reset/reset-rzg2l-usbphy-ctrl.c
+++ b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
@@ -93,6 +93,7 @@ static int rzg2l_usbphy_ctrl_status(struct reset_controller_dev *rcdev,
 
 static const struct of_device_id rzg2l_usbphy_ctrl_match_table[] = {
 	{ .compatible = "renesas,rzg2l-usbphy-ctrl" },
+	{ .compatible = "renesas,r9a08g045-usbphy-ctrl" },
 	{ /* Sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, rzg2l_usbphy_ctrl_match_table);
-- 
2.39.2



From claudiu.beznea at tuxon.dev  Thu Aug 22 08:27:54 2024
From: claudiu.beznea at tuxon.dev (Claudiu)
Date: Thu, 22 Aug 2024 18:27:54 +0300
Subject: [PATCH 09/16] dt-bindings: usb: renesas,usbhs: Document RZ/G3S SoC
In-Reply-To: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <20240822152801.602318-10-claudiu.beznea.uj@bp.renesas.com>

From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>

The USBHS IP block on RZ/G3S SoC is identitcal to the one found on the
RZ/G2L device. Document the RZ/G3S USBHS IP block.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
---
 Documentation/devicetree/bindings/usb/renesas,usbhs.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml
index c63db3ebd07b..0f84cba872ce 100644
--- a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml
+++ b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml
@@ -26,6 +26,7 @@ properties:
               - renesas,usbhs-r9a07g043 # RZ/G2UL and RZ/Five
               - renesas,usbhs-r9a07g044 # RZ/G2{L,LC}
               - renesas,usbhs-r9a07g054 # RZ/V2L
+              - renesas,usbhs-r9a08g045 # RZ/G3S
           - const: renesas,rzg2l-usbhs
 
       - items:
@@ -126,6 +127,7 @@ allOf:
               - renesas,usbhs-r9a07g043
               - renesas,usbhs-r9a07g044
               - renesas,usbhs-r9a07g054
+              - renesas,usbhs-r9a08g045
     then:
       properties:
         interrupts:
-- 
2.39.2



From claudiu.beznea at tuxon.dev  Thu Aug 22 08:27:55 2024
From: claudiu.beznea at tuxon.dev (Claudiu)
Date: Thu, 22 Aug 2024 18:27:55 +0300
Subject: [PATCH 10/16] phy: renesas: rcar-gen3-usb2: Add support to initialize the bus
In-Reply-To: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <20240822152801.602318-11-claudiu.beznea.uj@bp.renesas.com>

From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>

The Renesas RZ/G3S need to initialize the USB BUS before transferring data
due to hardware limitation. As the register that need to be touched for
this is in the address space of the USB PHY, and the UBS PHY need to be
initialized before any other USB drivers handling data transfer, add
support to initialize the USB BUS.

As the USB PHY is probed before any other USB drivers that enables
clocks and de-assert the reset signals and the BUS initialization is done
in the probe phase, we need to add code to de-assert reset signal and
runtime resume the device (which enables its clocks) before accessing
the registers.

As the reset signals are not required by the USB PHY driver for the other
USB PHY hardware variants, the reset signals and runtime PM was handled
only in the function that initialize the USB BUS.

The PHY initialization was done right after runtime PM enable to have
all in place when the PHYs are registered.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
---
 drivers/phy/renesas/phy-rcar-gen3-usb2.c | 50 ++++++++++++++++++++++--
 1 file changed, 47 insertions(+), 3 deletions(-)

diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
index 7594f64eb737..cf4299cea579 100644
--- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
@@ -19,12 +19,14 @@
 #include <linux/platform_device.h>
 #include <linux/pm_runtime.h>
 #include <linux/regulator/consumer.h>
+#include <linux/reset.h>
 #include <linux/string.h>
 #include <linux/usb/of.h>
 #include <linux/workqueue.h>
 
 /******* USB2.0 Host registers (original offset is +0x200) *******/
 #define USB2_INT_ENABLE		0x000
+#define USB2_AHB_BUS_CTR	0x008
 #define USB2_USBCTR		0x00c
 #define USB2_SPD_RSM_TIMSET	0x10c
 #define USB2_OC_TIMSET		0x110
@@ -40,6 +42,10 @@
 #define USB2_INT_ENABLE_USBH_INTB_EN	BIT(2)	/* For EHCI */
 #define USB2_INT_ENABLE_USBH_INTA_EN	BIT(1)	/* For OHCI */
 
+/* AHB_BUS_CTR */
+#define USB2_AHB_BUS_CTR_MBL_MASK	GENMASK(1, 0)
+#define USB2_AHB_BUS_CTR_MBL_INCR4	2
+
 /* USBCTR */
 #define USB2_USBCTR_DIRPD	BIT(2)
 #define USB2_USBCTR_PLL_RST	BIT(1)
@@ -111,6 +117,7 @@ struct rcar_gen3_chan {
 	struct extcon_dev *extcon;
 	struct rcar_gen3_phy rphys[NUM_OF_PHYS];
 	struct regulator *vbus;
+	struct reset_control *rstc;
 	struct work_struct work;
 	struct mutex lock;	/* protects rphys[...].powered */
 	enum usb_dr_mode dr_mode;
@@ -125,6 +132,7 @@ struct rcar_gen3_chan {
 struct rcar_gen3_phy_drv_data {
 	const struct phy_ops *phy_usb2_ops;
 	bool no_adp_ctrl;
+	bool init_bus;
 };
 
 /*
@@ -650,6 +658,35 @@ static enum usb_dr_mode rcar_gen3_get_dr_mode(struct device_node *np)
 	return candidate;
 }
 
+static int rcar_gen3_phy_usb2_init_bus(struct rcar_gen3_chan *channel)
+{
+	struct device *dev = channel->dev;
+	int ret;
+	u32 val;
+
+	channel->rstc = devm_reset_control_array_get_shared(dev);
+	if (IS_ERR(channel->rstc))
+		return PTR_ERR(channel->rstc);
+
+	ret = pm_runtime_resume_and_get(dev);
+	if (ret)
+		return ret;
+
+	ret = reset_control_deassert(channel->rstc);
+	if (ret)
+		goto rpm_put;
+
+	val = readl(channel->base + USB2_AHB_BUS_CTR);
+	val &= ~USB2_AHB_BUS_CTR_MBL_MASK;
+	val |= USB2_AHB_BUS_CTR_MBL_INCR4;
+	writel(val, channel->base + USB2_AHB_BUS_CTR);
+
+rpm_put:
+	pm_runtime_put(dev);
+
+	return ret;
+}
+
 static int rcar_gen3_phy_usb2_probe(struct platform_device *pdev)
 {
 	const struct rcar_gen3_phy_drv_data *phy_data;
@@ -703,6 +740,15 @@ static int rcar_gen3_phy_usb2_probe(struct platform_device *pdev)
 		goto error;
 	}
 
+	platform_set_drvdata(pdev, channel);
+	channel->dev = dev;
+
+	if (phy_data->init_bus) {
+		ret = rcar_gen3_phy_usb2_init_bus(channel);
+		if (ret)
+			goto error;
+	}
+
 	channel->soc_no_adp_ctrl = phy_data->no_adp_ctrl;
 	if (phy_data->no_adp_ctrl)
 		channel->obint_enable_bits = USB2_OBINT_IDCHG_EN;
@@ -733,9 +779,6 @@ static int rcar_gen3_phy_usb2_probe(struct platform_device *pdev)
 		channel->vbus = NULL;
 	}
 
-	platform_set_drvdata(pdev, channel);
-	channel->dev = dev;
-
 	provider = devm_of_phy_provider_register(dev, rcar_gen3_phy_usb2_xlate);
 	if (IS_ERR(provider)) {
 		dev_err(dev, "Failed to register PHY provider\n");
@@ -762,6 +805,7 @@ static void rcar_gen3_phy_usb2_remove(struct platform_device *pdev)
 	if (channel->is_otg_channel)
 		device_remove_file(&pdev->dev, &dev_attr_role);
 
+	reset_control_assert(channel->rstc);
 	pm_runtime_disable(&pdev->dev);
 };
 
-- 
2.39.2



From claudiu.beznea at tuxon.dev  Thu Aug 22 08:27:56 2024
From: claudiu.beznea at tuxon.dev (Claudiu)
Date: Thu, 22 Aug 2024 18:27:56 +0300
Subject: [PATCH 11/16] dt-bindings: phy: renesas,usb2-phy: Document RZ/G3S phy bindings
In-Reply-To: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <20240822152801.602318-12-claudiu.beznea.uj@bp.renesas.com>

From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>

Document the RZ/G3S PHY bindings. The RZ/G3S USB PHY is almost identical
with the RZ/G2L USB PHY. The difference is that there is a hardware
limitation on the max burst size used when the BUS master interface
issues a transfer request for RZ/G3S that is configured though PHY
registers.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
---
 Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml
index f82649a55e91..af275cea3456 100644
--- a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml
@@ -13,7 +13,9 @@ properties:
   compatible:
     oneOf:
       - items:
-          - const: renesas,usb2-phy-r8a77470 # RZ/G1C
+          - enum:
+              - renesas,usb2-phy-r8a77470  # RZ/G1C
+              - renesas,usb2-phy-r9a08g045 # RZ/G3S
 
       - items:
           - enum:
-- 
2.39.2



From claudiu.beznea at tuxon.dev  Thu Aug 22 08:27:57 2024
From: claudiu.beznea at tuxon.dev (Claudiu)
Date: Thu, 22 Aug 2024 18:27:57 +0300
Subject: [PATCH 12/16] phy: renesas: rcar-gen3-usb2: Add support for the RZ/G3S SoC
In-Reply-To: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <20240822152801.602318-13-claudiu.beznea.uj@bp.renesas.com>

From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>

Add support for the Renesas RZ/G3S SoC. The support is similar with the
rest of RZ/G2 devices with the except that the RZ/G3S needs bus
initialization due to hardware limitation.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
---
 drivers/phy/renesas/phy-rcar-gen3-usb2.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
index cf4299cea579..58e123305152 100644
--- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
@@ -583,6 +583,12 @@ static const struct rcar_gen3_phy_drv_data rz_g2l_phy_usb2_data = {
 	.no_adp_ctrl = true,
 };
 
+static const struct rcar_gen3_phy_drv_data rz_g3s_phy_usb2_data = {
+	.phy_usb2_ops = &rcar_gen3_phy_usb2_ops,
+	.no_adp_ctrl = true,
+	.init_bus = true,
+};
+
 static const struct of_device_id rcar_gen3_phy_usb2_match_table[] = {
 	{
 		.compatible = "renesas,usb2-phy-r8a77470",
@@ -604,6 +610,10 @@ static const struct of_device_id rcar_gen3_phy_usb2_match_table[] = {
 		.compatible = "renesas,rzg2l-usb2-phy",
 		.data = &rz_g2l_phy_usb2_data,
 	},
+	{
+		.compatible = "renesas,usb2-phy-r9a08g045",
+		.data = &rz_g3s_phy_usb2_data,
+	},
 	{
 		.compatible = "renesas,rcar-gen3-usb2-phy",
 		.data = &rcar_gen3_phy_usb2_data,
-- 
2.39.2



From claudiu.beznea at tuxon.dev  Thu Aug 22 08:27:58 2024
From: claudiu.beznea at tuxon.dev (Claudiu)
Date: Thu, 22 Aug 2024 18:27:58 +0300
Subject: [PATCH 13/16] arm64: dts: renesas: Add #reset-cells to system controller node
In-Reply-To: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <20240822152801.602318-14-claudiu.beznea.uj@bp.renesas.com>

From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>

System controller on RZ/G3S can act as a reset controller. Add #reset-cells
for it.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
---
 arch/arm64/boot/dts/renesas/r9a08g045.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/renesas/r9a08g045.dtsi b/arch/arm64/boot/dts/renesas/r9a08g045.dtsi
index 0d5c47a65e46..cd7cefdb2bab 100644
--- a/arch/arm64/boot/dts/renesas/r9a08g045.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a08g045.dtsi
@@ -91,6 +91,7 @@ sysc: system-controller at 11020000 {
 				     <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-names = "lpm_int", "ca55stbydone_int",
 					  "cm33stbyr_int", "ca55_deny";
+			#reset-cells = <1>;
 			status = "disabled";
 		};
 
-- 
2.39.2



From claudiu.beznea at tuxon.dev  Thu Aug 22 08:27:59 2024
From: claudiu.beznea at tuxon.dev (Claudiu)
Date: Thu, 22 Aug 2024 18:27:59 +0300
Subject: [PATCH 14/16] arm64: dts: renesas: r9a08g045: Add USB support
In-Reply-To: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <20240822152801.602318-15-claudiu.beznea.uj@bp.renesas.com>

From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>

Add USB nodes for the Renesas RZ/G3S SoC. This consists of PHY reset,
host and device support.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
---
 arch/arm64/boot/dts/renesas/r9a08g045.dtsi | 119 +++++++++++++++++++++
 1 file changed, 119 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r9a08g045.dtsi b/arch/arm64/boot/dts/renesas/r9a08g045.dtsi
index cd7cefdb2bab..c6c279dffccf 100644
--- a/arch/arm64/boot/dts/renesas/r9a08g045.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a08g045.dtsi
@@ -7,6 +7,7 @@
 
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/clock/r9a08g045-cpg.h>
+#include <dt-bindings/reset/renesas,r9a08g045-sysc.h>
 
 / {
 	compatible = "renesas,r9a08g045";
@@ -265,6 +266,124 @@ eth1: ethernet at 11c40000 {
 			status = "disabled";
 		};
 
+		phyrst: usbphy-ctrl at 11e00000 {
+			compatible = "renesas,r9a08g045-usbphy-ctrl";
+			reg = <0 0x11e00000 0 0x10000>;
+			clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>;
+			resets = <&cpg R9A08G045_USB_PRESETN>,
+				 <&sysc R9A08G045_SYSC_RESET_USB>;
+			power-domains = <&cpg>;
+			#reset-cells = <1>;
+			status = "disabled";
+
+			usb0_vbus_otg: regulator-vbus {
+				regulator-name = "vbus";
+			};
+		};
+
+		ohci0: usb at 11e10000 {
+			compatible = "generic-ohci";
+			reg = <0 0x11e10000 0 0x100>;
+			interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>,
+				 <&cpg CPG_MOD R9A08G045_USB_U2H0_HCLK>;
+			resets = <&phyrst 0>,
+				 <&cpg R9A08G045_USB_U2H0_HRESETN>;
+			phys = <&usb2_phy0 1>;
+			phy-names = "usb";
+			power-domains = <&cpg>;
+			status = "disabled";
+		};
+
+		ehci0: usb at 11e10100 {
+			compatible = "generic-ehci";
+			reg = <0 0x11e10100 0 0x100>;
+			interrupts = <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>,
+				 <&cpg CPG_MOD R9A08G045_USB_U2H0_HCLK>;
+			resets = <&phyrst 0>,
+				 <&cpg R9A08G045_USB_U2H0_HRESETN>;
+			phys = <&usb2_phy0 2>;
+			phy-names = "usb";
+			companion = <&ohci0>;
+			power-domains = <&cpg>;
+			status = "disabled";
+		};
+
+		usb2_phy0: usb-phy at 11e10200 {
+			compatible = "renesas,usb2-phy-r9a08g045";
+			reg = <0 0x11e10200 0 0x700>;
+			interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>,
+				 <&cpg CPG_MOD R9A08G045_USB_U2H0_HCLK>;
+			resets = <&phyrst 0>,
+				 <&cpg R9A08G045_USB_U2H0_HRESETN>;
+			#phy-cells = <1>;
+			power-domains = <&cpg>;
+			status = "disabled";
+		};
+
+		hsusb: usb at 11e20000 {
+			compatible = "renesas,usbhs-r9a08g045",
+				     "renesas,rzg2l-usbhs";
+			reg = <0 0x11e20000 0 0x10000>;
+			interrupts = <GIC_SPI 85 IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>,
+				 <&cpg CPG_MOD R9A08G045_USB_U2P_EXR_CPUCLK>;
+			resets = <&phyrst 0>,
+				 <&cpg R9A08G045_USB_U2P_EXL_SYSRST>;
+			renesas,buswait = <7>;
+			phys = <&usb2_phy0 3>;
+			phy-names = "usb";
+			power-domains = <&cpg>;
+			status = "disabled";
+		};
+
+		ohci1: usb at 11e30000 {
+			compatible = "generic-ohci";
+			reg = <0 0x11e30000 0 0x100>;
+			interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>,
+				 <&cpg CPG_MOD R9A08G045_USB_U2H1_HCLK>;
+			resets = <&phyrst 1>,
+				 <&cpg R9A08G045_USB_U2H1_HRESETN>;
+			phys = <&usb2_phy1 1>;
+			phy-names = "usb";
+			power-domains = <&cpg>;
+			status = "disabled";
+		};
+
+		ehci1: usb at 11e30100 {
+			compatible = "generic-ehci";
+			reg = <0 0x11e30100 0 0x100>;
+			interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>,
+				 <&cpg CPG_MOD R9A08G045_USB_U2H1_HCLK>;
+			resets = <&phyrst 1>,
+				 <&cpg R9A08G045_USB_U2H1_HRESETN>;
+			phys = <&usb2_phy1 2>;
+			phy-names = "usb";
+			companion = <&ohci1>;
+			power-domains = <&cpg>;
+			status = "disabled";
+		};
+
+		usb2_phy1: usb-phy at 11e30200 {
+			compatible = "renesas,usb2-phy-r9a08g045";
+			reg = <0 0x11e30200 0 0x700>;
+			interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>,
+				 <&cpg CPG_MOD R9A08G045_USB_U2H1_HCLK>;
+			resets = <&phyrst 1>,
+				 <&cpg R9A08G045_USB_U2H1_HRESETN>;
+			#phy-cells = <1>;
+			power-domains = <&cpg>;
+			status = "disabled";
+		};
+
 		gic: interrupt-controller at 12400000 {
 			compatible = "arm,gic-v3";
 			#interrupt-cells = <3>;
-- 
2.39.2



From claudiu.beznea at tuxon.dev  Thu Aug 22 08:28:00 2024
From: claudiu.beznea at tuxon.dev (Claudiu)
Date: Thu, 22 Aug 2024 18:28:00 +0300
Subject: [PATCH 15/16] arm64: dts: renesas: rzg3s-smarc: Enable USB support
In-Reply-To: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <20240822152801.602318-16-claudiu.beznea.uj@bp.renesas.com>

From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>

Enable USB support (host, device, USB PHYs and sysc).

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
---
 arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi | 61 ++++++++++++++++++++
 1 file changed, 61 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi b/arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi
index deb2ad37bb2e..fd9355936803 100644
--- a/arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi
+++ b/arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi
@@ -66,6 +66,29 @@ vccq_sdhi1: regulator-vccq-sdhi1 {
 	};
 };
 
+&ehci0 {
+	dr_mode = "otg";
+	status = "okay";
+};
+
+&ehci1 {
+	status = "okay";
+};
+
+&hsusb {
+	dr_mode = "otg";
+	status = "okay";
+};
+
+&ohci0 {
+	dr_mode = "otg";
+	status = "okay";
+};
+
+&ohci1 {
+	status = "okay";
+};
+
 &pinctrl {
 	key-1-gpio-hog {
 		gpio-hog;
@@ -124,6 +147,27 @@ cd {
 			pinmux = <RZG2L_PORT_PINMUX(0, 2, 1)>; /* SD1_CD */
 		};
 	};
+
+	usb0_pins: usb0 {
+		peri {
+			pinmux = <RZG2L_PORT_PINMUX(5, 0, 1)>, /* VBUS */
+				 <RZG2L_PORT_PINMUX(5, 2, 1)>; /* OVC */
+		};
+
+		otg {
+			pinmux = <RZG2L_PORT_PINMUX(5, 3, 1)>; /* OTG_ID */
+			bias-pull-up;
+		};
+	};
+
+	usb1_pins: usb1 {
+		pinmux = <RZG2L_PORT_PINMUX(5, 4, 5)>, /* OVC */
+			 <RZG2L_PORT_PINMUX(6, 0, 1)>; /* VBUS */
+	};
+};
+
+&phyrst {
+	status = "okay";
 };
 
 &scif0 {
@@ -144,3 +188,20 @@ &sdhi1 {
 	max-frequency = <125000000>;
 	status = "okay";
 };
+
+&sysc {
+	status = "okay";
+};
+
+&usb2_phy0 {
+	pinctrl-0 = <&usb0_pins>;
+	pinctrl-names = "default";
+	vbus-supply = <&usb0_vbus_otg>;
+	status = "okay";
+};
+
+&usb2_phy1 {
+	pinctrl-0 = <&usb1_pins>;
+	pinctrl-names = "default";
+	status = "okay";
+};
-- 
2.39.2



From claudiu.beznea at tuxon.dev  Thu Aug 22 08:28:01 2024
From: claudiu.beznea at tuxon.dev (Claudiu)
Date: Thu, 22 Aug 2024 18:28:01 +0300
Subject: [PATCH 16/16] arm64: defconfig: Enable RZ/G3S SYSC reset driver
In-Reply-To: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <20240822152801.602318-17-claudiu.beznea.uj@bp.renesas.com>

From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>

Enable RZ/G3S SYSC reset driver. This exports the control to 2 signals
(one for USB, one for PCI).

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 7d32fca64996..4720367a41ea 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1510,6 +1510,7 @@ CONFIG_RESET_IMX7=y
 CONFIG_RESET_QCOM_AOSS=y
 CONFIG_RESET_QCOM_PDC=m
 CONFIG_RESET_RZG2L_USBPHY_CTRL=y
+CONFIG_RESET_RZG3S_SYSC=y
 CONFIG_RESET_TI_SCI=y
 CONFIG_PHY_XGENE=y
 CONFIG_PHY_CAN_TRANSCEIVER=m
-- 
2.39.2



From conor at kernel.org  Thu Aug 22 09:42:57 2024
From: conor at kernel.org (Conor Dooley)
Date: Thu, 22 Aug 2024 17:42:57 +0100
Subject: [PATCH 02/16] dt-bindings: soc: renesas: renesas,rzg2l-sysc: Add
 #reset-cells for RZ/G3S
In-Reply-To: <20240822152801.602318-3-claudiu.beznea.uj@bp.renesas.com>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
 <20240822152801.602318-3-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <20240822-vanilla-enigmatic-f0b05ecca4b6@spud>

On Thu, Aug 22, 2024 at 06:27:47PM +0300, Claudiu wrote:
> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> 
> The RZ/G3S System controller has registers to control signals that need
> to be de-asserted/asserted before/after different SoC areas are power
> on/off. This signals are implemented as reset signals. For this document
> the #reset-cells property.
> 
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> ---
>  .../bindings/soc/renesas/renesas,rzg2l-sysc.yaml | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
> index 4386b2c3fa4d..6b0bb34485d9 100644
> --- a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
> +++ b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
> @@ -42,12 +42,28 @@ properties:
>        - const: cm33stbyr_int
>        - const: ca55_deny
>  
> +  "#reset-cells":
> +    const: 1
> +
>  required:
>    - compatible
>    - reg
>  
>  additionalProperties: false
>  
> +allOf:
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: renesas,r9a08g045-sysc
> +    then:
> +      required:
> +        - "#reset-cells"

Given this is new required property on an existing platform, I'd expect
some mention of why it used to be okay to not have this but is now
required. Did firmware or a bootloader stage take things out of reset?

> +    else:
> +      properties:
> +        "#reset-cells": false
> +
>  examples:
>    - |
>      #include <dt-bindings/interrupt-controller/arm-gic.h>
> -- 
> 2.39.2
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-phy/attachments/20240822/45b2eaac/attachment.sig>

From conor at kernel.org  Thu Aug 22 09:44:58 2024
From: conor at kernel.org (Conor Dooley)
Date: Thu, 22 Aug 2024 17:44:58 +0100
Subject: [PATCH 02/16] dt-bindings: soc: renesas: renesas,rzg2l-sysc: Add
 #reset-cells for RZ/G3S
In-Reply-To: <20240822-vanilla-enigmatic-f0b05ecca4b6@spud>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
 <20240822152801.602318-3-claudiu.beznea.uj@bp.renesas.com>
 <20240822-vanilla-enigmatic-f0b05ecca4b6@spud>
Message-ID: <20240822-mountain-hurdle-dd1f08b96f64@spud>

On Thu, Aug 22, 2024 at 05:42:57PM +0100, Conor Dooley wrote:
> On Thu, Aug 22, 2024 at 06:27:47PM +0300, Claudiu wrote:
> > From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> > 
> > The RZ/G3S System controller has registers to control signals that need
> > to be de-asserted/asserted before/after different SoC areas are power
> > on/off. This signals are implemented as reset signals. For this document
> > the #reset-cells property.
> > 
> > Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> > ---
> >  .../bindings/soc/renesas/renesas,rzg2l-sysc.yaml | 16 ++++++++++++++++
> >  1 file changed, 16 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
> > index 4386b2c3fa4d..6b0bb34485d9 100644
> > --- a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
> > +++ b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
> > @@ -42,12 +42,28 @@ properties:
> >        - const: cm33stbyr_int
> >        - const: ca55_deny
> >  
> > +  "#reset-cells":
> > +    const: 1
> > +
> >  required:
> >    - compatible
> >    - reg
> >  
> >  additionalProperties: false
> >  
> > +allOf:
> > +  - if:
> > +      properties:
> > +        compatible:
> > +          contains:
> > +            const: renesas,r9a08g045-sysc
> > +    then:
> > +      required:
> > +        - "#reset-cells"
> 
> Given this is new required property on an existing platform, I'd expect
> some mention of why it used to be okay to not have this but is now
> required. Did firmware or a bootloader stage take things out of reset?

Reading a bit more into the series, the peripherals in question were
just never used nor did a driver for the sysc exist, so there's neither
explanation of prior behaviour nor concerns about compatibility?

> 
> > +    else:
> > +      properties:
> > +        "#reset-cells": false
> > +
> >  examples:
> >    - |
> >      #include <dt-bindings/interrupt-controller/arm-gic.h>
> > -- 
> > 2.39.2
> > 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-phy/attachments/20240822/52c5731b/attachment-0001.sig>

From conor at kernel.org  Thu Aug 22 09:45:31 2024
From: conor at kernel.org (Conor Dooley)
Date: Thu, 22 Aug 2024 17:45:31 +0100
Subject: [PATCH 03/16] dt-bindings: reset: renesas,r9a08g045-sysc: Add
 reset IDs for RZ/G3S SYSC reset
In-Reply-To: <20240822152801.602318-4-claudiu.beznea.uj@bp.renesas.com>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
 <20240822152801.602318-4-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <20240822-antennae-mouth-b1d5e23425f0@spud>

On Thu, Aug 22, 2024 at 06:27:48PM +0300, Claudiu wrote:
> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> 
> Add reset IDs for the Renesas RZ/G3S SYSC reset controller driver.
> 
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>

Acked-by: Conor Dooley <conor.dooley at microchip.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-phy/attachments/20240822/65dec0f4/attachment-0001.sig>

From conor at kernel.org  Thu Aug 22 09:45:56 2024
From: conor at kernel.org (Conor Dooley)
Date: Thu, 22 Aug 2024 17:45:56 +0100
Subject: [PATCH 06/16] dt-bindings: reset: renesas,rzg2l-usbphy-ctrl:
 Document RZ/G3S SoC
In-Reply-To: <20240822152801.602318-7-claudiu.beznea.uj@bp.renesas.com>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
 <20240822152801.602318-7-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <20240822-emoticon-draw-0cf557c425f7@spud>

On Thu, Aug 22, 2024 at 06:27:51PM +0300, Claudiu wrote:
> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> 
> Document the Renesas RZ/G3S USB PHY Control IP. This is similar with the
> one found on the RZ/G2L SoC the exception being that the SYSC USB specific
> signal need to be configured before accessing the USB area. This is
> done though a reset signal.
> 
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>

Reviewed-by: Conor Dooley <conor.dooley at microchip.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-phy/attachments/20240822/890b609f/attachment.sig>

From conor at kernel.org  Thu Aug 22 09:46:15 2024
From: conor at kernel.org (Conor Dooley)
Date: Thu, 22 Aug 2024 17:46:15 +0100
Subject: [PATCH 09/16] dt-bindings: usb: renesas,usbhs: Document RZ/G3S
 SoC
In-Reply-To: <20240822152801.602318-10-claudiu.beznea.uj@bp.renesas.com>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
 <20240822152801.602318-10-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <20240822-encrypt-putdown-cc8770aa781d@spud>

On Thu, Aug 22, 2024 at 06:27:54PM +0300, Claudiu wrote:
> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> 
> The USBHS IP block on RZ/G3S SoC is identitcal to the one found on the
> RZ/G2L device. Document the RZ/G3S USBHS IP block.
> 
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>

Acked-by: Conor Dooley <conor.dooley at microchip.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-phy/attachments/20240822/f51708db/attachment.sig>

From conor at kernel.org  Thu Aug 22 09:46:34 2024
From: conor at kernel.org (Conor Dooley)
Date: Thu, 22 Aug 2024 17:46:34 +0100
Subject: [PATCH 11/16] dt-bindings: phy: renesas,usb2-phy: Document
 RZ/G3S phy bindings
In-Reply-To: <20240822152801.602318-12-claudiu.beznea.uj@bp.renesas.com>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
 <20240822152801.602318-12-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <20240822-idiom-parasite-1c025f81a399@spud>

On Thu, Aug 22, 2024 at 06:27:56PM +0300, Claudiu wrote:
> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> 
> Document the RZ/G3S PHY bindings. The RZ/G3S USB PHY is almost identical
> with the RZ/G2L USB PHY. The difference is that there is a hardware
> limitation on the max burst size used when the BUS master interface
> issues a transfer request for RZ/G3S that is configured though PHY
> registers.
> 
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>

Acked-by: Conor Dooley <conor.dooley at microchip.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-phy/attachments/20240822/1c2198d7/attachment.sig>

From biju.das.jz at bp.renesas.com  Thu Aug 22 09:59:27 2024
From: biju.das.jz at bp.renesas.com (Biju Das)
Date: Thu, 22 Aug 2024 16:59:27 +0000
Subject: [PATCH 08/16] reset: rzg2l-usbphy-ctrl: Add support for RZ/G3S
In-Reply-To: <20240822152801.602318-9-claudiu.beznea.uj@bp.renesas.com>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
 <20240822152801.602318-9-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <TY3PR01MB11346B5C5D9AA883B7736A5C3868F2@TY3PR01MB11346.jpnprd01.prod.outlook.com>

Hi Claudiu,

> -----Original Message-----
> From: Claudiu <claudiu.beznea at tuxon.dev>
> Sent: Thursday, August 22, 2024 4:28 PM
> Subject: [PATCH 08/16] reset: rzg2l-usbphy-ctrl: Add support for RZ/G3S
> 
> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> 
> Add support for RZ/G3S SoC. It needs its own compatible as it uses 2 reset signals and it cannot work
> w/o both of them. To be able to fully validate this on DT schema, too, the RZ/G3S uses it's own
> compatible w/o a fallback (as if the fallback will be used the RZ/G3S will not work anyway).

Other than reset/ power domain approach for handling USBPWRRDY signal

Can't USBPWRRDY signal handled in SYSC driver directly? Since SYSC driver init happens at very early boot stage
Check for USBPHY control device availability and handle USBPWRRDY signal there??

Cheers,
Biju

> 
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> ---
>  drivers/reset/reset-rzg2l-usbphy-ctrl.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/reset/reset-rzg2l-usbphy-ctrl.c b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> index 8b64c12f3bec..08b18d7de7ad 100644
> --- a/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> +++ b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> @@ -93,6 +93,7 @@ static int rzg2l_usbphy_ctrl_status(struct reset_controller_dev *rcdev,
> 
>  static const struct of_device_id rzg2l_usbphy_ctrl_match_table[] = {
>  	{ .compatible = "renesas,rzg2l-usbphy-ctrl" },
> +	{ .compatible = "renesas,r9a08g045-usbphy-ctrl" },
>  	{ /* Sentinel */ }
>  };
>  MODULE_DEVICE_TABLE(of, rzg2l_usbphy_ctrl_match_table);
> --
> 2.39.2



From abel.vesa at linaro.org  Fri Aug 23 00:04:15 2024
From: abel.vesa at linaro.org (Abel Vesa)
Date: Fri, 23 Aug 2024 10:04:15 +0300
Subject: [PATCH v3 1/2] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy:
 Document the X1E80100 QMP PCIe PHY Gen4 x4
In-Reply-To: <20240823-x1e80100-phy-add-gen4x4-v3-0-b7765631ca01@linaro.org>
References: <20240823-x1e80100-phy-add-gen4x4-v3-0-b7765631ca01@linaro.org>
Message-ID: <20240823-x1e80100-phy-add-gen4x4-v3-1-b7765631ca01@linaro.org>

The sixth PCIe instance on X1E80100 can be used in either 4-lane mode or
2-lane mode. Document the 4-lane mode as a separate compatible.

Reviewed-by: Krzysztof Kozlowski <krzk at kernel.org>
Reviewed-by: Johan Hovold <johan+linaro at kernel.org>
Signed-off-by: Abel Vesa <abel.vesa at linaro.org>
---
 Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
index 03dbd02cf9e7..dcf4fa55fbba 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
@@ -40,6 +40,7 @@ properties:
       - qcom,sm8650-qmp-gen4x2-pcie-phy
       - qcom,x1e80100-qmp-gen3x2-pcie-phy
       - qcom,x1e80100-qmp-gen4x2-pcie-phy
+      - qcom,x1e80100-qmp-gen4x4-pcie-phy
 
   reg:
     minItems: 1
@@ -118,6 +119,7 @@ allOf:
           contains:
             enum:
               - qcom,sc8280xp-qmp-gen3x4-pcie-phy
+              - qcom,x1e80100-qmp-gen4x4-pcie-phy
     then:
       properties:
         reg:
@@ -169,6 +171,7 @@ allOf:
               - qcom,sc8280xp-qmp-gen3x1-pcie-phy
               - qcom,sc8280xp-qmp-gen3x2-pcie-phy
               - qcom,sc8280xp-qmp-gen3x4-pcie-phy
+              - qcom,x1e80100-qmp-gen4x4-pcie-phy
     then:
       properties:
         clocks:

-- 
2.34.1



From abel.vesa at linaro.org  Fri Aug 23 00:04:14 2024
From: abel.vesa at linaro.org (Abel Vesa)
Date: Fri, 23 Aug 2024 10:04:14 +0300
Subject: [PATCH v3 0/2] phy: qcom: qmp-pcie: Add support for Gen4 4-lane
 mode for X1E80100
Message-ID: <20240823-x1e80100-phy-add-gen4x4-v3-0-b7765631ca01@linaro.org>

On all X Elite boards currently supported upstream, the NVMe sits
on the PCIe 6. Until now that has been configured in dual lane mode
only. The schematics reveal that the NVMe is actually using 4 lanes.
So add support for the 4-lane mode and document the compatible for it.

This patchset depends on:
https://lore.kernel.org/all/20240805-phy-qcom-qmp-pcie-write-all-tbls-second-port-v3-1-6967c6bf61d1 at linaro.org/

Signed-off-by: Abel Vesa <abel.vesa at linaro.org>
---
Changes in v3:
- Moved the x1e80100_qmp_gen4x4_pcie_serdes_4ln_tbl right after
  proper serdes table, like Johan suggested
- Picked Johan's R-b tags
- Link to v2: https://lore.kernel.org/r/20240821-x1e80100-phy-add-gen4x4-v2-0-c34db42230e9 at linaro.org

Changes in v2:
- Re-worded the commit message following Johan's suggestions.
- Picked up Krzysztof's R-b tag for the bindings patch
- Link to v1: https://lore.kernel.org/r/20240531-x1e80100-phy-add-gen4x4-v1-0-5c841dae7850 at linaro.org

---
Abel Vesa (2):
      dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Document the X1E80100 QMP PCIe PHY Gen4 x4
      phy: qcom: qmp-pcie: Add Gen4 4-lanes mode for X1E80100

 .../bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml   |  3 ++
 drivers/phy/qualcomm/phy-qcom-qmp-pcie.c           | 42 ++++++++++++++++++++++
 2 files changed, 45 insertions(+)
---
base-commit: 81528d2de965dafd6911a0f9a975fc30b25e7080
change-id: 20240531-x1e80100-phy-add-gen4x4-fa830a5505b6

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



From abel.vesa at linaro.org  Fri Aug 23 00:04:16 2024
From: abel.vesa at linaro.org (Abel Vesa)
Date: Fri, 23 Aug 2024 10:04:16 +0300
Subject: [PATCH v3 2/2] phy: qcom: qmp-pcie: Add Gen4 4-lanes mode for
 X1E80100
In-Reply-To: <20240823-x1e80100-phy-add-gen4x4-v3-0-b7765631ca01@linaro.org>
References: <20240823-x1e80100-phy-add-gen4x4-v3-0-b7765631ca01@linaro.org>
Message-ID: <20240823-x1e80100-phy-add-gen4x4-v3-2-b7765631ca01@linaro.org>

The sixth PCIe controller on X1E80100 can be used in either
4-lanes mode or 2-lanes mode. Add the configuration and compatible
for the 4-lane mode.

Reviewed-by: Johan Hovold <johan+linaro at kernel.org>
Signed-off-by: Abel Vesa <abel.vesa at linaro.org>
---
 drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 42 ++++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
index a7e2ce0c500d..f71787fb4d7e 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
@@ -1242,6 +1242,10 @@ static const struct qmp_phy_init_tbl x1e80100_qmp_gen4x2_pcie_serdes_tbl[] = {
 	QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_VCO_DC_LEVEL_CTRL, 0x0f),
 };
 
+static const struct qmp_phy_init_tbl x1e80100_qmp_gen4x4_pcie_serdes_4ln_tbl[] = {
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_BIAS_EN_CLK_BUFLR_EN, 0x1c),
+};
+
 static const struct qmp_phy_init_tbl x1e80100_qmp_gen4x2_pcie_ln_shrd_tbl[] = {
 	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RXCLK_DIV2_CTRL, 0x01),
 	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_DFE_DAC_ENABLE1, 0x88),
@@ -3654,6 +3658,41 @@ static const struct qmp_phy_cfg x1e80100_qmp_gen4x2_pciephy_cfg = {
 		.ln_shrd		= x1e80100_qmp_gen4x2_pcie_ln_shrd_tbl,
 		.ln_shrd_num		= ARRAY_SIZE(x1e80100_qmp_gen4x2_pcie_ln_shrd_tbl),
 	},
+
+	.reset_list		= sdm845_pciephy_reset_l,
+	.num_resets		= ARRAY_SIZE(sdm845_pciephy_reset_l),
+	.vreg_list		= sm8550_qmp_phy_vreg_l,
+	.num_vregs		= ARRAY_SIZE(sm8550_qmp_phy_vreg_l),
+	.regs			= pciephy_v6_regs_layout,
+
+	.pwrdn_ctrl		= SW_PWRDN | REFCLK_DRV_DSBL,
+	.phy_status		= PHYSTATUS_4_20,
+	.has_nocsr_reset	= true,
+};
+
+static const struct qmp_phy_cfg x1e80100_qmp_gen4x4_pciephy_cfg = {
+	.lanes = 4,
+
+	.offsets		= &qmp_pcie_offsets_v6_20,
+
+	.tbls = {
+		.serdes			= x1e80100_qmp_gen4x2_pcie_serdes_tbl,
+		.serdes_num		= ARRAY_SIZE(x1e80100_qmp_gen4x2_pcie_serdes_tbl),
+		.tx			= x1e80100_qmp_gen4x2_pcie_tx_tbl,
+		.tx_num			= ARRAY_SIZE(x1e80100_qmp_gen4x2_pcie_tx_tbl),
+		.rx			= x1e80100_qmp_gen4x2_pcie_rx_tbl,
+		.rx_num			= ARRAY_SIZE(x1e80100_qmp_gen4x2_pcie_rx_tbl),
+		.pcs			= x1e80100_qmp_gen4x2_pcie_pcs_tbl,
+		.pcs_num		= ARRAY_SIZE(x1e80100_qmp_gen4x2_pcie_pcs_tbl),
+		.pcs_misc		= x1e80100_qmp_gen4x2_pcie_pcs_misc_tbl,
+		.pcs_misc_num		= ARRAY_SIZE(x1e80100_qmp_gen4x2_pcie_pcs_misc_tbl),
+		.ln_shrd		= x1e80100_qmp_gen4x2_pcie_ln_shrd_tbl,
+		.ln_shrd_num		= ARRAY_SIZE(x1e80100_qmp_gen4x2_pcie_ln_shrd_tbl),
+	},
+
+	.serdes_4ln_tbl		= x1e80100_qmp_gen4x4_pcie_serdes_4ln_tbl,
+	.serdes_4ln_num		= ARRAY_SIZE(x1e80100_qmp_gen4x4_pcie_serdes_4ln_tbl),
+
 	.reset_list		= sdm845_pciephy_reset_l,
 	.num_resets		= ARRAY_SIZE(sdm845_pciephy_reset_l),
 	.vreg_list		= sm8550_qmp_phy_vreg_l,
@@ -4436,6 +4475,9 @@ static const struct of_device_id qmp_pcie_of_match_table[] = {
 	}, {
 		.compatible = "qcom,x1e80100-qmp-gen4x2-pcie-phy",
 		.data = &x1e80100_qmp_gen4x2_pciephy_cfg,
+	}, {
+		.compatible = "qcom,x1e80100-qmp-gen4x4-pcie-phy",
+		.data = &x1e80100_qmp_gen4x4_pciephy_cfg,
 	},
 	{ },
 };

-- 
2.34.1



From biju.das.jz at bp.renesas.com  Fri Aug 23 00:25:59 2024
From: biju.das.jz at bp.renesas.com (Biju Das)
Date: Fri, 23 Aug 2024 07:25:59 +0000
Subject: [PATCH 07/16] reset: rzg2l-usbphy-ctrl: Get reset control array
In-Reply-To: <20240822152801.602318-8-claudiu.beznea.uj@bp.renesas.com>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
 <20240822152801.602318-8-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <TY3PR01MB11346900BCCEB55580C2F912086882@TY3PR01MB11346.jpnprd01.prod.outlook.com>

Hi Claudiu,

> -----Original Message-----
> From: Claudiu <claudiu.beznea at tuxon.dev>
> Sent: Thursday, August 22, 2024 4:28 PM
> Subject: [PATCH 07/16] reset: rzg2l-usbphy-ctrl: Get reset control array
> 
> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> 
> Before accessing the USB area of the RZ/G3S SoC the PWRRDY bit of the SYS_USB_PWRRDY register need to
> be cleared. When USB area is not used the PWRRDY bit of the SYS_USB_PWRRDY register need to be set.
> This register is in the SYSC controller address space and the assert/de-assert of the signal handled
> by SYSC_USB_PWRRDY was implemented as a reset signal.
> 
> The USB modules available on the RZ/G3S SoC that need this bit set are:
> - USB ch0 (supporting host and peripheral mode)
> - USB ch2 (supporting host mode)
> - USBPHY control
> 
> As the USBPHY control is the root device for all the other USB channels (USB ch0, USB ch1) add support
> to set the PWRRDY for the USB area when initializing the USBPHY control. As this is done though reset
> signals get the reset array in the USBPHY control driver.
> 

Comment applicable, if the USB PWRRDY signal is modelled as reset signal.

There is no user for this patch. The first user is RZ/G3S and is there is no support yet.
I think you should merge this patch with next one so that there is a user(RZ/G3S)
for this patch.

Cheers,
Biju

> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> ---
>  drivers/reset/reset-rzg2l-usbphy-ctrl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/reset/reset-rzg2l-usbphy-ctrl.c b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> index 1cd157f4f03b..8b64c12f3bec 100644
> --- a/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> +++ b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> @@ -132,7 +132,7 @@ static int rzg2l_usbphy_ctrl_probe(struct platform_device *pdev)
>  	if (IS_ERR(regmap))
>  		return PTR_ERR(regmap);
> 
> -	priv->rstc = devm_reset_control_get_exclusive(&pdev->dev, NULL);
> +	priv->rstc = devm_reset_control_array_get_exclusive(&pdev->dev);
>  	if (IS_ERR(priv->rstc))
>  		return dev_err_probe(dev, PTR_ERR(priv->rstc),
>  				     "failed to get reset\n");
> --
> 2.39.2



From biju.das.jz at bp.renesas.com  Fri Aug 23 00:35:50 2024
From: biju.das.jz at bp.renesas.com (Biju Das)
Date: Fri, 23 Aug 2024 07:35:50 +0000
Subject: [PATCH 10/16] phy: renesas: rcar-gen3-usb2: Add support to
 initialize the bus
In-Reply-To: <20240822152801.602318-11-claudiu.beznea.uj@bp.renesas.com>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
 <20240822152801.602318-11-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <TY3PR01MB113468A6CA4ADBCA577670AD486882@TY3PR01MB11346.jpnprd01.prod.outlook.com>

Hi Claudiu,

> -----Original Message-----
> From: Claudiu <claudiu.beznea at tuxon.dev>
> Sent: Thursday, August 22, 2024 4:28 PM
> Subject: [PATCH 10/16] phy: renesas: rcar-gen3-usb2: Add support to initialize the bus
> 
> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> 
> The Renesas RZ/G3S need to initialize the USB BUS before transferring data due to hardware limitation.
> As the register that need to be touched for this is in the address space of the USB PHY, and the UBS
> PHY need to be initialized before any other USB drivers handling data transfer, add support to
> initialize the USB BUS.
> 
> As the USB PHY is probed before any other USB drivers that enables clocks and de-assert the reset
> signals and the BUS initialization is done in the probe phase, we need to add code to de-assert reset
> signal and runtime resume the device (which enables its clocks) before accessing the registers.
> 
> As the reset signals are not required by the USB PHY driver for the other USB PHY hardware variants,
> the reset signals and runtime PM was handled only in the function that initialize the USB BUS.
> 
> The PHY initialization was done right after runtime PM enable to have all in place when the PHYs are
> registered.

There is no user for this patch. The first user is RZ/G3S and you should merge this patch with
next one.

Cheers,
Biju

> 
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> ---
>  drivers/phy/renesas/phy-rcar-gen3-usb2.c | 50 ++++++++++++++++++++++--
>  1 file changed, 47 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> index 7594f64eb737..cf4299cea579 100644
> --- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> +++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> @@ -19,12 +19,14 @@
>  #include <linux/platform_device.h>
>  #include <linux/pm_runtime.h>
>  #include <linux/regulator/consumer.h>
> +#include <linux/reset.h>
>  #include <linux/string.h>
>  #include <linux/usb/of.h>
>  #include <linux/workqueue.h>
> 
>  /******* USB2.0 Host registers (original offset is +0x200) *******/
>  #define USB2_INT_ENABLE		0x000
> +#define USB2_AHB_BUS_CTR	0x008
>  #define USB2_USBCTR		0x00c
>  #define USB2_SPD_RSM_TIMSET	0x10c
>  #define USB2_OC_TIMSET		0x110
> @@ -40,6 +42,10 @@
>  #define USB2_INT_ENABLE_USBH_INTB_EN	BIT(2)	/* For EHCI */
>  #define USB2_INT_ENABLE_USBH_INTA_EN	BIT(1)	/* For OHCI */
> 
> +/* AHB_BUS_CTR */
> +#define USB2_AHB_BUS_CTR_MBL_MASK	GENMASK(1, 0)
> +#define USB2_AHB_BUS_CTR_MBL_INCR4	2
> +
>  /* USBCTR */
>  #define USB2_USBCTR_DIRPD	BIT(2)
>  #define USB2_USBCTR_PLL_RST	BIT(1)
> @@ -111,6 +117,7 @@ struct rcar_gen3_chan {
>  	struct extcon_dev *extcon;
>  	struct rcar_gen3_phy rphys[NUM_OF_PHYS];
>  	struct regulator *vbus;
> +	struct reset_control *rstc;
>  	struct work_struct work;
>  	struct mutex lock;	/* protects rphys[...].powered */
>  	enum usb_dr_mode dr_mode;
> @@ -125,6 +132,7 @@ struct rcar_gen3_chan {  struct rcar_gen3_phy_drv_data {
>  	const struct phy_ops *phy_usb2_ops;
>  	bool no_adp_ctrl;
> +	bool init_bus;
>  };
> 
>  /*
> @@ -650,6 +658,35 @@ static enum usb_dr_mode rcar_gen3_get_dr_mode(struct device_node *np)
>  	return candidate;
>  }
> 
> +static int rcar_gen3_phy_usb2_init_bus(struct rcar_gen3_chan *channel)
> +{
> +	struct device *dev = channel->dev;
> +	int ret;
> +	u32 val;
> +
> +	channel->rstc = devm_reset_control_array_get_shared(dev);
> +	if (IS_ERR(channel->rstc))
> +		return PTR_ERR(channel->rstc);
> +
> +	ret = pm_runtime_resume_and_get(dev);
> +	if (ret)
> +		return ret;
> +
> +	ret = reset_control_deassert(channel->rstc);
> +	if (ret)
> +		goto rpm_put;
> +
> +	val = readl(channel->base + USB2_AHB_BUS_CTR);
> +	val &= ~USB2_AHB_BUS_CTR_MBL_MASK;
> +	val |= USB2_AHB_BUS_CTR_MBL_INCR4;
> +	writel(val, channel->base + USB2_AHB_BUS_CTR);
> +
> +rpm_put:
> +	pm_runtime_put(dev);
> +
> +	return ret;
> +}
> +
>  static int rcar_gen3_phy_usb2_probe(struct platform_device *pdev)  {
>  	const struct rcar_gen3_phy_drv_data *phy_data; @@ -703,6 +740,15 @@ static int
> rcar_gen3_phy_usb2_probe(struct platform_device *pdev)
>  		goto error;
>  	}
> 
> +	platform_set_drvdata(pdev, channel);
> +	channel->dev = dev;
> +
> +	if (phy_data->init_bus) {
> +		ret = rcar_gen3_phy_usb2_init_bus(channel);
> +		if (ret)
> +			goto error;
> +	}
> +
>  	channel->soc_no_adp_ctrl = phy_data->no_adp_ctrl;
>  	if (phy_data->no_adp_ctrl)
>  		channel->obint_enable_bits = USB2_OBINT_IDCHG_EN; @@ -733,9 +779,6 @@ static int
> rcar_gen3_phy_usb2_probe(struct platform_device *pdev)
>  		channel->vbus = NULL;
>  	}
> 
> -	platform_set_drvdata(pdev, channel);
> -	channel->dev = dev;
> -
>  	provider = devm_of_phy_provider_register(dev, rcar_gen3_phy_usb2_xlate);
>  	if (IS_ERR(provider)) {
>  		dev_err(dev, "Failed to register PHY provider\n"); @@ -762,6 +805,7 @@ static void
> rcar_gen3_phy_usb2_remove(struct platform_device *pdev)
>  	if (channel->is_otg_channel)
>  		device_remove_file(&pdev->dev, &dev_attr_role);
> 
> +	reset_control_assert(channel->rstc);
>  	pm_runtime_disable(&pdev->dev);
>  };
> 
> --
> 2.39.2



From claudiu.beznea at tuxon.dev  Fri Aug 23 00:54:06 2024
From: claudiu.beznea at tuxon.dev (claudiu beznea)
Date: Fri, 23 Aug 2024 10:54:06 +0300
Subject: [PATCH 02/16] dt-bindings: soc: renesas: renesas,rzg2l-sysc: Add
 #reset-cells for RZ/G3S
In-Reply-To: <20240822-vanilla-enigmatic-f0b05ecca4b6@spud>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
 <20240822152801.602318-3-claudiu.beznea.uj@bp.renesas.com>
 <20240822-vanilla-enigmatic-f0b05ecca4b6@spud>
Message-ID: <0d8b1322-cf15-4ed9-b958-06516bbb64c7@tuxon.dev>

Hi, Conor,

On 22.08.2024 19:42, Conor Dooley wrote:
> On Thu, Aug 22, 2024 at 06:27:47PM +0300, Claudiu wrote:
>> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>>
>> The RZ/G3S System controller has registers to control signals that need
>> to be de-asserted/asserted before/after different SoC areas are power
>> on/off. This signals are implemented as reset signals. For this document
>> the #reset-cells property.
>>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>> ---
>>  .../bindings/soc/renesas/renesas,rzg2l-sysc.yaml | 16 ++++++++++++++++
>>  1 file changed, 16 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
>> index 4386b2c3fa4d..6b0bb34485d9 100644
>> --- a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
>> +++ b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
>> @@ -42,12 +42,28 @@ properties:
>>        - const: cm33stbyr_int
>>        - const: ca55_deny
>>  
>> +  "#reset-cells":
>> +    const: 1
>> +
>>  required:
>>    - compatible
>>    - reg
>>  
>>  additionalProperties: false
>>  
>> +allOf:
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            const: renesas,r9a08g045-sysc
>> +    then:
>> +      required:
>> +        - "#reset-cells"
> 
> Given this is new required property on an existing platform, I'd expect
> some mention of why it used to be okay to not have this but is now
> required. Did firmware or a bootloader stage take things out of reset?

On previous SoCs the SYS controller has no support for controlling the
signals going to different peripherals (USB, PCIE in case of RZ/G3S).
I'll add a note about this on next version.

Thank you,
Claudiu Beznea


> 
>> +    else:
>> +      properties:
>> +        "#reset-cells": false
>> +
>>  examples:
>>    - |
>>      #include <dt-bindings/interrupt-controller/arm-gic.h>
>> -- 
>> 2.39.2
>>


From claudiu.beznea at tuxon.dev  Fri Aug 23 00:59:39 2024
From: claudiu.beznea at tuxon.dev (claudiu beznea)
Date: Fri, 23 Aug 2024 10:59:39 +0300
Subject: [PATCH 02/16] dt-bindings: soc: renesas: renesas,rzg2l-sysc: Add
 #reset-cells for RZ/G3S
In-Reply-To: <20240822-mountain-hurdle-dd1f08b96f64@spud>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
 <20240822152801.602318-3-claudiu.beznea.uj@bp.renesas.com>
 <20240822-vanilla-enigmatic-f0b05ecca4b6@spud>
 <20240822-mountain-hurdle-dd1f08b96f64@spud>
Message-ID: <e0308678-c031-41e1-8d07-d2b78504180f@tuxon.dev>



On 22.08.2024 19:44, Conor Dooley wrote:
> On Thu, Aug 22, 2024 at 05:42:57PM +0100, Conor Dooley wrote:
>> On Thu, Aug 22, 2024 at 06:27:47PM +0300, Claudiu wrote:
>>> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>>>
>>> The RZ/G3S System controller has registers to control signals that need
>>> to be de-asserted/asserted before/after different SoC areas are power
>>> on/off. This signals are implemented as reset signals. For this document
>>> the #reset-cells property.
>>>
>>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>>> ---
>>>  .../bindings/soc/renesas/renesas,rzg2l-sysc.yaml | 16 ++++++++++++++++
>>>  1 file changed, 16 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
>>> index 4386b2c3fa4d..6b0bb34485d9 100644
>>> --- a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
>>> +++ b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
>>> @@ -42,12 +42,28 @@ properties:
>>>        - const: cm33stbyr_int
>>>        - const: ca55_deny
>>>  
>>> +  "#reset-cells":
>>> +    const: 1
>>> +
>>>  required:
>>>    - compatible
>>>    - reg
>>>  
>>>  additionalProperties: false
>>>  
>>> +allOf:
>>> +  - if:
>>> +      properties:
>>> +        compatible:
>>> +          contains:
>>> +            const: renesas,r9a08g045-sysc
>>> +    then:
>>> +      required:
>>> +        - "#reset-cells"
>>
>> Given this is new required property on an existing platform, I'd expect
>> some mention of why it used to be okay to not have this but is now
>> required. Did firmware or a bootloader stage take things out of reset?
> 
> Reading a bit more into the series, the peripherals in question were
> just never used nor did a driver for the sysc exist, so there's neither

Exactly.

> explanation of prior behaviour nor concerns about compatibility?

The newly introduced sysc driver is probed only for RZ/G3S and used to
control the USB, PCIe signals though reset control driver (registered by
sysc driver on auxiliary bus) and to identify the chip. The intention is to
later migrate the chip identification support for the rest of RZ/G2 devices
to this new driver and add more functionalities, when/if needed.

Thank you,
Claudiu Beznea

> 
>>
>>> +    else:
>>> +      properties:
>>> +        "#reset-cells": false
>>> +
>>>  examples:
>>>    - |
>>>      #include <dt-bindings/interrupt-controller/arm-gic.h>
>>> -- 
>>> 2.39.2
>>>
> 
> 


From claudiu.beznea at tuxon.dev  Fri Aug 23 01:05:10 2024
From: claudiu.beznea at tuxon.dev (claudiu beznea)
Date: Fri, 23 Aug 2024 11:05:10 +0300
Subject: [PATCH 07/16] reset: rzg2l-usbphy-ctrl: Get reset control array
In-Reply-To: <TY3PR01MB11346900BCCEB55580C2F912086882@TY3PR01MB11346.jpnprd01.prod.outlook.com>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
 <20240822152801.602318-8-claudiu.beznea.uj@bp.renesas.com>
 <TY3PR01MB11346900BCCEB55580C2F912086882@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Message-ID: <5f14dc3a-edff-45f3-a162-3f6fd567777f@tuxon.dev>

Hi, Biju,

On 23.08.2024 10:25, Biju Das wrote:
> Hi Claudiu,
> 
>> -----Original Message-----
>> From: Claudiu <claudiu.beznea at tuxon.dev>
>> Sent: Thursday, August 22, 2024 4:28 PM
>> Subject: [PATCH 07/16] reset: rzg2l-usbphy-ctrl: Get reset control array
>>
>> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>>
>> Before accessing the USB area of the RZ/G3S SoC the PWRRDY bit of the SYS_USB_PWRRDY register need to
>> be cleared. When USB area is not used the PWRRDY bit of the SYS_USB_PWRRDY register need to be set.
>> This register is in the SYSC controller address space and the assert/de-assert of the signal handled
>> by SYSC_USB_PWRRDY was implemented as a reset signal.
>>
>> The USB modules available on the RZ/G3S SoC that need this bit set are:
>> - USB ch0 (supporting host and peripheral mode)
>> - USB ch2 (supporting host mode)
>> - USBPHY control
>>
>> As the USBPHY control is the root device for all the other USB channels (USB ch0, USB ch1) add support
>> to set the PWRRDY for the USB area when initializing the USBPHY control. As this is done though reset
>> signals get the reset array in the USBPHY control driver.
>>
> 
> Comment applicable, if the USB PWRRDY signal is modelled as reset signal.
> 
> There is no user for this patch. The first user is RZ/G3S and is there is no support yet.
> I think you should merge this patch with next one so that there is a user(RZ/G3S)
> for this patch.

I have nothing against to squash it. I was seeing it differently:
- this patch prepares the ground for the addition of RZ/G3S
- the next patch just enables the support for RZ/G3S

It looks to me more modular like this, patches are simpler, easier for
review and each issue is described differently in patch description.

I can do it either ways.


Thank you,
Claudiu Beznea


> Cheers,
> Biju
> 
>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>> ---
>>  drivers/reset/reset-rzg2l-usbphy-ctrl.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/reset/reset-rzg2l-usbphy-ctrl.c b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
>> index 1cd157f4f03b..8b64c12f3bec 100644
>> --- a/drivers/reset/reset-rzg2l-usbphy-ctrl.c
>> +++ b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
>> @@ -132,7 +132,7 @@ static int rzg2l_usbphy_ctrl_probe(struct platform_device *pdev)
>>  	if (IS_ERR(regmap))
>>  		return PTR_ERR(regmap);
>>
>> -	priv->rstc = devm_reset_control_get_exclusive(&pdev->dev, NULL);
>> +	priv->rstc = devm_reset_control_array_get_exclusive(&pdev->dev);
>>  	if (IS_ERR(priv->rstc))
>>  		return dev_err_probe(dev, PTR_ERR(priv->rstc),
>>  				     "failed to get reset\n");
>> --
>> 2.39.2
> 


From biju.das.jz at bp.renesas.com  Fri Aug 23 01:17:51 2024
From: biju.das.jz at bp.renesas.com (Biju Das)
Date: Fri, 23 Aug 2024 08:17:51 +0000
Subject: [PATCH 07/16] reset: rzg2l-usbphy-ctrl: Get reset control array
In-Reply-To: <5f14dc3a-edff-45f3-a162-3f6fd567777f@tuxon.dev>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
 <20240822152801.602318-8-claudiu.beznea.uj@bp.renesas.com>
 <TY3PR01MB11346900BCCEB55580C2F912086882@TY3PR01MB11346.jpnprd01.prod.outlook.com>
 <5f14dc3a-edff-45f3-a162-3f6fd567777f@tuxon.dev>
Message-ID: <TY3PR01MB113467345E2DD50E165FFCC0086882@TY3PR01MB11346.jpnprd01.prod.outlook.com>

Hi Claudiu,

> -----Original Message-----
> From: claudiu beznea <claudiu.beznea at tuxon.dev>
> Sent: Friday, August 23, 2024 9:05 AM
> Subject: Re: [PATCH 07/16] reset: rzg2l-usbphy-ctrl: Get reset control array
> 
> Hi, Biju,
> 
> On 23.08.2024 10:25, Biju Das wrote:
> > Hi Claudiu,
> >
> >> -----Original Message-----
> >> From: Claudiu <claudiu.beznea at tuxon.dev>
> >> Sent: Thursday, August 22, 2024 4:28 PM
> >> Subject: [PATCH 07/16] reset: rzg2l-usbphy-ctrl: Get reset control
> >> array
> >>
> >> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> >>
> >> Before accessing the USB area of the RZ/G3S SoC the PWRRDY bit of the
> >> SYS_USB_PWRRDY register need to be cleared. When USB area is not used the PWRRDY bit of the
> SYS_USB_PWRRDY register need to be set.
> >> This register is in the SYSC controller address space and the
> >> assert/de-assert of the signal handled by SYSC_USB_PWRRDY was implemented as a reset signal.
> >>
> >> The USB modules available on the RZ/G3S SoC that need this bit set are:
> >> - USB ch0 (supporting host and peripheral mode)
> >> - USB ch2 (supporting host mode)
> >> - USBPHY control
> >>
> >> As the USBPHY control is the root device for all the other USB
> >> channels (USB ch0, USB ch1) add support to set the PWRRDY for the USB
> >> area when initializing the USBPHY control. As this is done though reset signals get the reset array
> in the USBPHY control driver.
> >>
> >
> > Comment applicable, if the USB PWRRDY signal is modelled as reset signal.
> >
> > There is no user for this patch. The first user is RZ/G3S and is there is no support yet.
> > I think you should merge this patch with next one so that there is a
> > user(RZ/G3S) for this patch.
> 
> I have nothing against to squash it. I was seeing it differently:
> - this patch prepares the ground for the addition of RZ/G3S
> - the next patch just enables the support for RZ/G3S
> 
> It looks to me more modular like this, patches are simpler, easier for review and each issue is
> described differently in patch description.
> 
> I can do it either ways.

If it is complicated restructuring for supporting new SoC then it make sense to split into
a number of patches.

This is straight forward. You need a device quirk to support RZ/G3S.
So this kind of changes can go in a single patch, as on second patch
you are just filling device entry.

Previously I got feedback from mainline to add a patch, if there is a user.

Cheers,
Biju


> >> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> >> ---
> >>  drivers/reset/reset-rzg2l-usbphy-ctrl.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> >> b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> >> index 1cd157f4f03b..8b64c12f3bec 100644
> >> --- a/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> >> +++ b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> >> @@ -132,7 +132,7 @@ static int rzg2l_usbphy_ctrl_probe(struct platform_device *pdev)
> >>  	if (IS_ERR(regmap))
> >>  		return PTR_ERR(regmap);
> >>
> >> -	priv->rstc = devm_reset_control_get_exclusive(&pdev->dev, NULL);
> >> +	priv->rstc = devm_reset_control_array_get_exclusive(&pdev->dev);
> >>  	if (IS_ERR(priv->rstc))
> >>  		return dev_err_probe(dev, PTR_ERR(priv->rstc),
> >>  				     "failed to get reset\n");
> >> --
> >> 2.39.2
> >

From claudiu.beznea at tuxon.dev  Fri Aug 23 01:40:37 2024
From: claudiu.beznea at tuxon.dev (claudiu beznea)
Date: Fri, 23 Aug 2024 11:40:37 +0300
Subject: [PATCH 08/16] reset: rzg2l-usbphy-ctrl: Add support for RZ/G3S
In-Reply-To: <TY3PR01MB11346B5C5D9AA883B7736A5C3868F2@TY3PR01MB11346.jpnprd01.prod.outlook.com>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
 <20240822152801.602318-9-claudiu.beznea.uj@bp.renesas.com>
 <TY3PR01MB11346B5C5D9AA883B7736A5C3868F2@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Message-ID: <59f4d28b-5b9b-427a-baca-739fc03a5cc1@tuxon.dev>

Hi, Biju,

On 22.08.2024 19:59, Biju Das wrote:
> Hi Claudiu,
> 
>> -----Original Message-----
>> From: Claudiu <claudiu.beznea at tuxon.dev>
>> Sent: Thursday, August 22, 2024 4:28 PM
>> Subject: [PATCH 08/16] reset: rzg2l-usbphy-ctrl: Add support for RZ/G3S
>>
>> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>>
>> Add support for RZ/G3S SoC. It needs its own compatible as it uses 2 reset signals and it cannot work
>> w/o both of them. To be able to fully validate this on DT schema, too, the RZ/G3S uses it's own
>> compatible w/o a fallback (as if the fallback will be used the RZ/G3S will not work anyway).
> 
> Other than reset/ power domain approach for handling USBPWRRDY signal
> 
> Can't USBPWRRDY signal handled in SYSC driver directly? Since SYSC driver init happens at very early boot stage
> Check for USBPHY control device availability and handle USBPWRRDY signal there??

In theory, it can be done this way, too.  The downside I see at the moment
with this approach would be that the USB, PCIe drivers will not be in
charge with handling their signals, there will be no direct dependency
available b/w SYSC and USB drivers.

The HW manual doesn't mention anything about the power consumption of the
USB, PCI areas based on the state of the signals from SYSC, so, I don't
know if there will be any implication on this if the signals will be just
de-asserted from the SYSC driver.


Thank you,
Claudiu Beznea


> Cheers,
> Biju
> 
>>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>> ---
>>  drivers/reset/reset-rzg2l-usbphy-ctrl.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/reset/reset-rzg2l-usbphy-ctrl.c b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
>> index 8b64c12f3bec..08b18d7de7ad 100644
>> --- a/drivers/reset/reset-rzg2l-usbphy-ctrl.c
>> +++ b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
>> @@ -93,6 +93,7 @@ static int rzg2l_usbphy_ctrl_status(struct reset_controller_dev *rcdev,
>>
>>  static const struct of_device_id rzg2l_usbphy_ctrl_match_table[] = {
>>  	{ .compatible = "renesas,rzg2l-usbphy-ctrl" },
>> +	{ .compatible = "renesas,r9a08g045-usbphy-ctrl" },
>>  	{ /* Sentinel */ }
>>  };
>>  MODULE_DEVICE_TABLE(of, rzg2l_usbphy_ctrl_match_table);
>> --
>> 2.39.2
> 


From biju.das.jz at bp.renesas.com  Fri Aug 23 01:46:08 2024
From: biju.das.jz at bp.renesas.com (Biju Das)
Date: Fri, 23 Aug 2024 08:46:08 +0000
Subject: [PATCH 08/16] reset: rzg2l-usbphy-ctrl: Add support for RZ/G3S
In-Reply-To: <59f4d28b-5b9b-427a-baca-739fc03a5cc1@tuxon.dev>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
 <20240822152801.602318-9-claudiu.beznea.uj@bp.renesas.com>
 <TY3PR01MB11346B5C5D9AA883B7736A5C3868F2@TY3PR01MB11346.jpnprd01.prod.outlook.com>
 <59f4d28b-5b9b-427a-baca-739fc03a5cc1@tuxon.dev>
Message-ID: <TY3PR01MB1134687634BB1B11B419C58E086882@TY3PR01MB11346.jpnprd01.prod.outlook.com>

Hi Claudiu,

> -----Original Message-----
> From: claudiu beznea <claudiu.beznea at tuxon.dev>
> Sent: Friday, August 23, 2024 9:41 AM
> Subject: Re: [PATCH 08/16] reset: rzg2l-usbphy-ctrl: Add support for RZ/G3S
> 
> Hi, Biju,
> 
> On 22.08.2024 19:59, Biju Das wrote:
> > Hi Claudiu,
> >
> >> -----Original Message-----
> >> From: Claudiu <claudiu.beznea at tuxon.dev>
> >> Sent: Thursday, August 22, 2024 4:28 PM
> >> Subject: [PATCH 08/16] reset: rzg2l-usbphy-ctrl: Add support for
> >> RZ/G3S
> >>
> >> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> >>
> >> Add support for RZ/G3S SoC. It needs its own compatible as it uses 2
> >> reset signals and it cannot work w/o both of them. To be able to
> >> fully validate this on DT schema, too, the RZ/G3S uses it's own compatible w/o a fallback (as if
> the fallback will be used the RZ/G3S will not work anyway).
> >
> > Other than reset/ power domain approach for handling USBPWRRDY signal
> >
> > Can't USBPWRRDY signal handled in SYSC driver directly? Since SYSC
> > driver init happens at very early boot stage Check for USBPHY control device availability and handle
> USBPWRRDY signal there??
> 
> In theory, it can be done this way, too.  The downside I see at the moment with this approach would be
> that the USB, PCIe drivers will not be in charge with handling their signals, there will be no direct
> dependency available b/w SYSC and USB drivers.

SYSC driver probe/init will happen before USB driver because of early init calls.
So, I don't think there will be a problem.

Cheers,
Biju



> >>
> >> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> >> ---
> >>  drivers/reset/reset-rzg2l-usbphy-ctrl.c | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> >> b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> >> index 8b64c12f3bec..08b18d7de7ad 100644
> >> --- a/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> >> +++ b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> >> @@ -93,6 +93,7 @@ static int rzg2l_usbphy_ctrl_status(struct
> >> reset_controller_dev *rcdev,
> >>
> >>  static const struct of_device_id rzg2l_usbphy_ctrl_match_table[] = {
> >>  	{ .compatible = "renesas,rzg2l-usbphy-ctrl" },
> >> +	{ .compatible = "renesas,r9a08g045-usbphy-ctrl" },
> >>  	{ /* Sentinel */ }
> >>  };
> >>  MODULE_DEVICE_TABLE(of, rzg2l_usbphy_ctrl_match_table);
> >> --
> >> 2.39.2
> >

From claudiu.beznea at tuxon.dev  Fri Aug 23 01:57:30 2024
From: claudiu.beznea at tuxon.dev (claudiu beznea)
Date: Fri, 23 Aug 2024 11:57:30 +0300
Subject: [PATCH 10/16] phy: renesas: rcar-gen3-usb2: Add support to
 initialize the bus
In-Reply-To: <TY3PR01MB113468A6CA4ADBCA577670AD486882@TY3PR01MB11346.jpnprd01.prod.outlook.com>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
 <20240822152801.602318-11-claudiu.beznea.uj@bp.renesas.com>
 <TY3PR01MB113468A6CA4ADBCA577670AD486882@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Message-ID: <8faa6b6d-a013-4a71-a8b7-af02ac92d94b@tuxon.dev>

Hi, Biju,

On 23.08.2024 10:35, Biju Das wrote:
> Hi Claudiu,
> 
>> -----Original Message-----
>> From: Claudiu <claudiu.beznea at tuxon.dev>
>> Sent: Thursday, August 22, 2024 4:28 PM
>> Subject: [PATCH 10/16] phy: renesas: rcar-gen3-usb2: Add support to initialize the bus
>>
>> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>>
>> The Renesas RZ/G3S need to initialize the USB BUS before transferring data due to hardware limitation.
>> As the register that need to be touched for this is in the address space of the USB PHY, and the UBS
>> PHY need to be initialized before any other USB drivers handling data transfer, add support to
>> initialize the USB BUS.
>>
>> As the USB PHY is probed before any other USB drivers that enables clocks and de-assert the reset
>> signals and the BUS initialization is done in the probe phase, we need to add code to de-assert reset
>> signal and runtime resume the device (which enables its clocks) before accessing the registers.
>>
>> As the reset signals are not required by the USB PHY driver for the other USB PHY hardware variants,
>> the reset signals and runtime PM was handled only in the function that initialize the USB BUS.
>>
>> The PHY initialization was done right after runtime PM enable to have all in place when the PHYs are
>> registered.
> 
> There is no user for this patch. The first user is RZ/G3S and you should merge this patch with
> next one.

I think this is a matter of taste... This is how I usually format the
patches (for scenarios like this) and got no request for squashing.

Anyway, I can do it your way, too.

Thank you,
Claudiu Beznea

> 
> Cheers,
> Biju
> 
>>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>> ---
>>  drivers/phy/renesas/phy-rcar-gen3-usb2.c | 50 ++++++++++++++++++++++--
>>  1 file changed, 47 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
>> index 7594f64eb737..cf4299cea579 100644
>> --- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
>> +++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
>> @@ -19,12 +19,14 @@
>>  #include <linux/platform_device.h>
>>  #include <linux/pm_runtime.h>
>>  #include <linux/regulator/consumer.h>
>> +#include <linux/reset.h>
>>  #include <linux/string.h>
>>  #include <linux/usb/of.h>
>>  #include <linux/workqueue.h>
>>
>>  /******* USB2.0 Host registers (original offset is +0x200) *******/
>>  #define USB2_INT_ENABLE		0x000
>> +#define USB2_AHB_BUS_CTR	0x008
>>  #define USB2_USBCTR		0x00c
>>  #define USB2_SPD_RSM_TIMSET	0x10c
>>  #define USB2_OC_TIMSET		0x110
>> @@ -40,6 +42,10 @@
>>  #define USB2_INT_ENABLE_USBH_INTB_EN	BIT(2)	/* For EHCI */
>>  #define USB2_INT_ENABLE_USBH_INTA_EN	BIT(1)	/* For OHCI */
>>
>> +/* AHB_BUS_CTR */
>> +#define USB2_AHB_BUS_CTR_MBL_MASK	GENMASK(1, 0)
>> +#define USB2_AHB_BUS_CTR_MBL_INCR4	2
>> +
>>  /* USBCTR */
>>  #define USB2_USBCTR_DIRPD	BIT(2)
>>  #define USB2_USBCTR_PLL_RST	BIT(1)
>> @@ -111,6 +117,7 @@ struct rcar_gen3_chan {
>>  	struct extcon_dev *extcon;
>>  	struct rcar_gen3_phy rphys[NUM_OF_PHYS];
>>  	struct regulator *vbus;
>> +	struct reset_control *rstc;
>>  	struct work_struct work;
>>  	struct mutex lock;	/* protects rphys[...].powered */
>>  	enum usb_dr_mode dr_mode;
>> @@ -125,6 +132,7 @@ struct rcar_gen3_chan {  struct rcar_gen3_phy_drv_data {
>>  	const struct phy_ops *phy_usb2_ops;
>>  	bool no_adp_ctrl;
>> +	bool init_bus;
>>  };
>>
>>  /*
>> @@ -650,6 +658,35 @@ static enum usb_dr_mode rcar_gen3_get_dr_mode(struct device_node *np)
>>  	return candidate;
>>  }
>>
>> +static int rcar_gen3_phy_usb2_init_bus(struct rcar_gen3_chan *channel)
>> +{
>> +	struct device *dev = channel->dev;
>> +	int ret;
>> +	u32 val;
>> +
>> +	channel->rstc = devm_reset_control_array_get_shared(dev);
>> +	if (IS_ERR(channel->rstc))
>> +		return PTR_ERR(channel->rstc);
>> +
>> +	ret = pm_runtime_resume_and_get(dev);
>> +	if (ret)
>> +		return ret;
>> +
>> +	ret = reset_control_deassert(channel->rstc);
>> +	if (ret)
>> +		goto rpm_put;
>> +
>> +	val = readl(channel->base + USB2_AHB_BUS_CTR);
>> +	val &= ~USB2_AHB_BUS_CTR_MBL_MASK;
>> +	val |= USB2_AHB_BUS_CTR_MBL_INCR4;
>> +	writel(val, channel->base + USB2_AHB_BUS_CTR);
>> +
>> +rpm_put:
>> +	pm_runtime_put(dev);
>> +
>> +	return ret;
>> +}
>> +
>>  static int rcar_gen3_phy_usb2_probe(struct platform_device *pdev)  {
>>  	const struct rcar_gen3_phy_drv_data *phy_data; @@ -703,6 +740,15 @@ static int
>> rcar_gen3_phy_usb2_probe(struct platform_device *pdev)
>>  		goto error;
>>  	}
>>
>> +	platform_set_drvdata(pdev, channel);
>> +	channel->dev = dev;
>> +
>> +	if (phy_data->init_bus) {
>> +		ret = rcar_gen3_phy_usb2_init_bus(channel);
>> +		if (ret)
>> +			goto error;
>> +	}
>> +
>>  	channel->soc_no_adp_ctrl = phy_data->no_adp_ctrl;
>>  	if (phy_data->no_adp_ctrl)
>>  		channel->obint_enable_bits = USB2_OBINT_IDCHG_EN; @@ -733,9 +779,6 @@ static int
>> rcar_gen3_phy_usb2_probe(struct platform_device *pdev)
>>  		channel->vbus = NULL;
>>  	}
>>
>> -	platform_set_drvdata(pdev, channel);
>> -	channel->dev = dev;
>> -
>>  	provider = devm_of_phy_provider_register(dev, rcar_gen3_phy_usb2_xlate);
>>  	if (IS_ERR(provider)) {
>>  		dev_err(dev, "Failed to register PHY provider\n"); @@ -762,6 +805,7 @@ static void
>> rcar_gen3_phy_usb2_remove(struct platform_device *pdev)
>>  	if (channel->is_otg_channel)
>>  		device_remove_file(&pdev->dev, &dev_attr_role);
>>
>> +	reset_control_assert(channel->rstc);
>>  	pm_runtime_disable(&pdev->dev);
>>  };
>>
>> --
>> 2.39.2
> 


From biju.das.jz at bp.renesas.com  Fri Aug 23 02:01:00 2024
From: biju.das.jz at bp.renesas.com (Biju Das)
Date: Fri, 23 Aug 2024 09:01:00 +0000
Subject: [PATCH 10/16] phy: renesas: rcar-gen3-usb2: Add support to
 initialize the bus
In-Reply-To: <8faa6b6d-a013-4a71-a8b7-af02ac92d94b@tuxon.dev>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
 <20240822152801.602318-11-claudiu.beznea.uj@bp.renesas.com>
 <TY3PR01MB113468A6CA4ADBCA577670AD486882@TY3PR01MB11346.jpnprd01.prod.outlook.com>
 <8faa6b6d-a013-4a71-a8b7-af02ac92d94b@tuxon.dev>
Message-ID: <TY3PR01MB11346FBA77256F2156D374ECF86882@TY3PR01MB11346.jpnprd01.prod.outlook.com>

Hi Claudiu,

> -----Original Message-----
> From: claudiu beznea <claudiu.beznea at tuxon.dev>
> Sent: Friday, August 23, 2024 9:58 AM
-
> clk at vger.kernel.org; linux-pm at vger.kernel.org; Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> Subject: Re: [PATCH 10/16] phy: renesas: rcar-gen3-usb2: Add support to initialize the bus
> 
> Hi, Biju,
> 
> On 23.08.2024 10:35, Biju Das wrote:
> > Hi Claudiu,
> >
> >> -----Original Message-----
> >> From: Claudiu <claudiu.beznea at tuxon.dev>
> >> Sent: Thursday, August 22, 2024 4:28 PM
> >> Subject: [PATCH 10/16] phy: renesas: rcar-gen3-usb2: Add support to
> >> initialize the bus
> >>
> >> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> >>
> >> The Renesas RZ/G3S need to initialize the USB BUS before transferring data due to hardware
> limitation.
> >> As the register that need to be touched for this is in the address
> >> space of the USB PHY, and the UBS PHY need to be initialized before
> >> any other USB drivers handling data transfer, add support to initialize the USB BUS.
> >>
> >> As the USB PHY is probed before any other USB drivers that enables
> >> clocks and de-assert the reset signals and the BUS initialization is
> >> done in the probe phase, we need to add code to de-assert reset signal and runtime resume the
> device (which enables its clocks) before accessing the registers.
> >>
> >> As the reset signals are not required by the USB PHY driver for the
> >> other USB PHY hardware variants, the reset signals and runtime PM was handled only in the function
> that initialize the USB BUS.
> >>
> >> The PHY initialization was done right after runtime PM enable to have
> >> all in place when the PHYs are registered.
> >
> > There is no user for this patch. The first user is RZ/G3S and you
> > should merge this patch with next one.
> 
> I think this is a matter of taste... This is how I usually format the patches (for scenarios like
> this) and got no request for squashing.

That is strange for trivial patches like this.

Cheers,
Biju



> >
> >>
> >> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> >> ---
> >>  drivers/phy/renesas/phy-rcar-gen3-usb2.c | 50
> >> ++++++++++++++++++++++--
> >>  1 file changed, 47 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> >> b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> >> index 7594f64eb737..cf4299cea579 100644
> >> --- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> >> +++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> >> @@ -19,12 +19,14 @@
> >>  #include <linux/platform_device.h>
> >>  #include <linux/pm_runtime.h>
> >>  #include <linux/regulator/consumer.h>
> >> +#include <linux/reset.h>
> >>  #include <linux/string.h>
> >>  #include <linux/usb/of.h>
> >>  #include <linux/workqueue.h>
> >>
> >>  /******* USB2.0 Host registers (original offset is +0x200) *******/
> >>  #define USB2_INT_ENABLE		0x000
> >> +#define USB2_AHB_BUS_CTR	0x008
> >>  #define USB2_USBCTR		0x00c
> >>  #define USB2_SPD_RSM_TIMSET	0x10c
> >>  #define USB2_OC_TIMSET		0x110
> >> @@ -40,6 +42,10 @@
> >>  #define USB2_INT_ENABLE_USBH_INTB_EN	BIT(2)	/* For EHCI */
> >>  #define USB2_INT_ENABLE_USBH_INTA_EN	BIT(1)	/* For OHCI */
> >>
> >> +/* AHB_BUS_CTR */
> >> +#define USB2_AHB_BUS_CTR_MBL_MASK	GENMASK(1, 0)
> >> +#define USB2_AHB_BUS_CTR_MBL_INCR4	2
> >> +
> >>  /* USBCTR */
> >>  #define USB2_USBCTR_DIRPD	BIT(2)
> >>  #define USB2_USBCTR_PLL_RST	BIT(1)
> >> @@ -111,6 +117,7 @@ struct rcar_gen3_chan {
> >>  	struct extcon_dev *extcon;
> >>  	struct rcar_gen3_phy rphys[NUM_OF_PHYS];
> >>  	struct regulator *vbus;
> >> +	struct reset_control *rstc;
> >>  	struct work_struct work;
> >>  	struct mutex lock;	/* protects rphys[...].powered */
> >>  	enum usb_dr_mode dr_mode;
> >> @@ -125,6 +132,7 @@ struct rcar_gen3_chan {  struct rcar_gen3_phy_drv_data {
> >>  	const struct phy_ops *phy_usb2_ops;
> >>  	bool no_adp_ctrl;
> >> +	bool init_bus;
> >>  };
> >>
> >>  /*
> >> @@ -650,6 +658,35 @@ static enum usb_dr_mode rcar_gen3_get_dr_mode(struct device_node *np)
> >>  	return candidate;
> >>  }
> >>
> >> +static int rcar_gen3_phy_usb2_init_bus(struct rcar_gen3_chan
> >> +*channel) {
> >> +	struct device *dev = channel->dev;
> >> +	int ret;
> >> +	u32 val;
> >> +
> >> +	channel->rstc = devm_reset_control_array_get_shared(dev);
> >> +	if (IS_ERR(channel->rstc))
> >> +		return PTR_ERR(channel->rstc);
> >> +
> >> +	ret = pm_runtime_resume_and_get(dev);
> >> +	if (ret)
> >> +		return ret;
> >> +
> >> +	ret = reset_control_deassert(channel->rstc);
> >> +	if (ret)
> >> +		goto rpm_put;
> >> +
> >> +	val = readl(channel->base + USB2_AHB_BUS_CTR);
> >> +	val &= ~USB2_AHB_BUS_CTR_MBL_MASK;
> >> +	val |= USB2_AHB_BUS_CTR_MBL_INCR4;
> >> +	writel(val, channel->base + USB2_AHB_BUS_CTR);
> >> +
> >> +rpm_put:
> >> +	pm_runtime_put(dev);
> >> +
> >> +	return ret;
> >> +}
> >> +
> >>  static int rcar_gen3_phy_usb2_probe(struct platform_device *pdev)  {
> >>  	const struct rcar_gen3_phy_drv_data *phy_data; @@ -703,6 +740,15 @@
> >> static int rcar_gen3_phy_usb2_probe(struct platform_device *pdev)
> >>  		goto error;
> >>  	}
> >>
> >> +	platform_set_drvdata(pdev, channel);
> >> +	channel->dev = dev;
> >> +
> >> +	if (phy_data->init_bus) {
> >> +		ret = rcar_gen3_phy_usb2_init_bus(channel);
> >> +		if (ret)
> >> +			goto error;
> >> +	}
> >> +
> >>  	channel->soc_no_adp_ctrl = phy_data->no_adp_ctrl;
> >>  	if (phy_data->no_adp_ctrl)
> >>  		channel->obint_enable_bits = USB2_OBINT_IDCHG_EN; @@ -733,9 +779,6
> >> @@ static int rcar_gen3_phy_usb2_probe(struct platform_device *pdev)
> >>  		channel->vbus = NULL;
> >>  	}
> >>
> >> -	platform_set_drvdata(pdev, channel);
> >> -	channel->dev = dev;
> >> -
> >>  	provider = devm_of_phy_provider_register(dev, rcar_gen3_phy_usb2_xlate);
> >>  	if (IS_ERR(provider)) {
> >>  		dev_err(dev, "Failed to register PHY provider\n"); @@ -762,6
> >> +805,7 @@ static void rcar_gen3_phy_usb2_remove(struct platform_device *pdev)
> >>  	if (channel->is_otg_channel)
> >>  		device_remove_file(&pdev->dev, &dev_attr_role);
> >>
> >> +	reset_control_assert(channel->rstc);
> >>  	pm_runtime_disable(&pdev->dev);
> >>  };
> >>
> >> --
> >> 2.39.2
> >

From johan at kernel.org  Fri Aug 23 04:29:33 2024
From: johan at kernel.org (Johan Hovold)
Date: Fri, 23 Aug 2024 13:29:33 +0200
Subject: [PATCH v3 2/2] phy: qcom: qmp-pcie: Add Gen4 4-lanes mode for
 X1E80100
In-Reply-To: <20240823-x1e80100-phy-add-gen4x4-v3-2-b7765631ca01@linaro.org>
References: <20240823-x1e80100-phy-add-gen4x4-v3-0-b7765631ca01@linaro.org>
 <20240823-x1e80100-phy-add-gen4x4-v3-2-b7765631ca01@linaro.org>
Message-ID: <Zshync9EgQJ_Kfqn@hovoldconsulting.com>

On Fri, Aug 23, 2024 at 10:04:16AM +0300, Abel Vesa wrote:
> The sixth PCIe controller on X1E80100 can be used in either
> 4-lanes mode or 2-lanes mode. Add the configuration and compatible
> for the 4-lane mode.
> 
> Reviewed-by: Johan Hovold <johan+linaro at kernel.org>
> Signed-off-by: Abel Vesa <abel.vesa at linaro.org>

Tested-by: Johan Hovold <johan+linaro at kernel.org>


From conor at kernel.org  Fri Aug 23 09:18:04 2024
From: conor at kernel.org (Conor Dooley)
Date: Fri, 23 Aug 2024 17:18:04 +0100
Subject: [PATCH 02/16] dt-bindings: soc: renesas: renesas,rzg2l-sysc: Add
 #reset-cells for RZ/G3S
In-Reply-To: <0d8b1322-cf15-4ed9-b958-06516bbb64c7@tuxon.dev>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
 <20240822152801.602318-3-claudiu.beznea.uj@bp.renesas.com>
 <20240822-vanilla-enigmatic-f0b05ecca4b6@spud>
 <0d8b1322-cf15-4ed9-b958-06516bbb64c7@tuxon.dev>
Message-ID: <20240823-plywood-unfixed-d8d8a2d93f14@spud>

On Fri, Aug 23, 2024 at 10:54:06AM +0300, claudiu beznea wrote:
> Hi, Conor,
> 
> On 22.08.2024 19:42, Conor Dooley wrote:
> > On Thu, Aug 22, 2024 at 06:27:47PM +0300, Claudiu wrote:
> >> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> >>
> >> The RZ/G3S System controller has registers to control signals that need
> >> to be de-asserted/asserted before/after different SoC areas are power
> >> on/off. This signals are implemented as reset signals. For this document
> >> the #reset-cells property.
> >>
> >> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> >> ---
> >>  .../bindings/soc/renesas/renesas,rzg2l-sysc.yaml | 16 ++++++++++++++++
> >>  1 file changed, 16 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
> >> index 4386b2c3fa4d..6b0bb34485d9 100644
> >> --- a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
> >> +++ b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
> >> @@ -42,12 +42,28 @@ properties:
> >>        - const: cm33stbyr_int
> >>        - const: ca55_deny
> >>  
> >> +  "#reset-cells":
> >> +    const: 1
> >> +
> >>  required:
> >>    - compatible
> >>    - reg
> >>  
> >>  additionalProperties: false
> >>  
> >> +allOf:
> >> +  - if:
> >> +      properties:
> >> +        compatible:
> >> +          contains:
> >> +            const: renesas,r9a08g045-sysc
> >> +    then:
> >> +      required:
> >> +        - "#reset-cells"
> > 
> > Given this is new required property on an existing platform, I'd expect
> > some mention of why it used to be okay to not have this but is now
> > required. Did firmware or a bootloader stage take things out of reset?
> 
> On previous SoCs the SYS controller has no support for controlling the
> signals going to different peripherals (USB, PCIE in case of RZ/G3S).
> I'll add a note about this on next version.

My initial thought here wasn't about previous SoCs though, it was
because you didn't add the compatible in this series for /this/ SoC.
What's worth noting isn't about the prior SoCs, it is about what makes
it okay for this one.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-phy/attachments/20240823/3c24a286/attachment.sig>

From claudiu.beznea at tuxon.dev  Fri Aug 23 09:26:42 2024
From: claudiu.beznea at tuxon.dev (claudiu beznea)
Date: Fri, 23 Aug 2024 19:26:42 +0300
Subject: [PATCH 02/16] dt-bindings: soc: renesas: renesas,rzg2l-sysc: Add
 #reset-cells for RZ/G3S
In-Reply-To: <20240823-plywood-unfixed-d8d8a2d93f14@spud>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
 <20240822152801.602318-3-claudiu.beznea.uj@bp.renesas.com>
 <20240822-vanilla-enigmatic-f0b05ecca4b6@spud>
 <0d8b1322-cf15-4ed9-b958-06516bbb64c7@tuxon.dev>
 <20240823-plywood-unfixed-d8d8a2d93f14@spud>
Message-ID: <5eae2ddb-2a7b-4c1d-a7f7-41fb39058de1@tuxon.dev>



On 23.08.2024 19:18, Conor Dooley wrote:
> On Fri, Aug 23, 2024 at 10:54:06AM +0300, claudiu beznea wrote:
>> Hi, Conor,
>>
>> On 22.08.2024 19:42, Conor Dooley wrote:
>>> On Thu, Aug 22, 2024 at 06:27:47PM +0300, Claudiu wrote:
>>>> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>>>>
>>>> The RZ/G3S System controller has registers to control signals that need
>>>> to be de-asserted/asserted before/after different SoC areas are power
>>>> on/off. This signals are implemented as reset signals. For this document
>>>> the #reset-cells property.
>>>>
>>>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>>>> ---
>>>>  .../bindings/soc/renesas/renesas,rzg2l-sysc.yaml | 16 ++++++++++++++++
>>>>  1 file changed, 16 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
>>>> index 4386b2c3fa4d..6b0bb34485d9 100644
>>>> --- a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
>>>> +++ b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
>>>> @@ -42,12 +42,28 @@ properties:
>>>>        - const: cm33stbyr_int
>>>>        - const: ca55_deny
>>>>  
>>>> +  "#reset-cells":
>>>> +    const: 1
>>>> +
>>>>  required:
>>>>    - compatible
>>>>    - reg
>>>>  
>>>>  additionalProperties: false
>>>>  
>>>> +allOf:
>>>> +  - if:
>>>> +      properties:
>>>> +        compatible:
>>>> +          contains:
>>>> +            const: renesas,r9a08g045-sysc
>>>> +    then:
>>>> +      required:
>>>> +        - "#reset-cells"
>>>
>>> Given this is new required property on an existing platform, I'd expect
>>> some mention of why it used to be okay to not have this but is now
>>> required. Did firmware or a bootloader stage take things out of reset?
>>
>> On previous SoCs the SYS controller has no support for controlling the
>> signals going to different peripherals (USB, PCIE in case of RZ/G3S).
>> I'll add a note about this on next version.
> 
> My initial thought here wasn't about previous SoCs though, it was
> because you didn't add the compatible in this series for /this/ SoC.

RZ/G3S compatible is already present in this file:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml#n26

Thank you,
Claudiu Beznea

> What's worth noting isn't about the prior SoCs, it is about what makes
> it okay for this one.


From conor at kernel.org  Fri Aug 23 09:33:33 2024
From: conor at kernel.org (Conor Dooley)
Date: Fri, 23 Aug 2024 17:33:33 +0100
Subject: [PATCH 02/16] dt-bindings: soc: renesas: renesas,rzg2l-sysc: Add
 #reset-cells for RZ/G3S
In-Reply-To: <5eae2ddb-2a7b-4c1d-a7f7-41fb39058de1@tuxon.dev>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
 <20240822152801.602318-3-claudiu.beznea.uj@bp.renesas.com>
 <20240822-vanilla-enigmatic-f0b05ecca4b6@spud>
 <0d8b1322-cf15-4ed9-b958-06516bbb64c7@tuxon.dev>
 <20240823-plywood-unfixed-d8d8a2d93f14@spud>
 <5eae2ddb-2a7b-4c1d-a7f7-41fb39058de1@tuxon.dev>
Message-ID: <20240823-dilute-juggle-7e2d43b8b630@spud>

On Fri, Aug 23, 2024 at 07:26:42PM +0300, claudiu beznea wrote:
> On 23.08.2024 19:18, Conor Dooley wrote:
> > On Fri, Aug 23, 2024 at 10:54:06AM +0300, claudiu beznea wrote:
> >> Hi, Conor,
> >>
> >> On 22.08.2024 19:42, Conor Dooley wrote:
> >>> On Thu, Aug 22, 2024 at 06:27:47PM +0300, Claudiu wrote:
> >>>> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> >>>>
> >>>> The RZ/G3S System controller has registers to control signals that need
> >>>> to be de-asserted/asserted before/after different SoC areas are power
> >>>> on/off. This signals are implemented as reset signals. For this document
> >>>> the #reset-cells property.
> >>>>
> >>>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> >>>> ---
> >>>>  .../bindings/soc/renesas/renesas,rzg2l-sysc.yaml | 16 ++++++++++++++++
> >>>>  1 file changed, 16 insertions(+)
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
> >>>> index 4386b2c3fa4d..6b0bb34485d9 100644
> >>>> --- a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
> >>>> +++ b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
> >>>> @@ -42,12 +42,28 @@ properties:
> >>>>        - const: cm33stbyr_int
> >>>>        - const: ca55_deny
> >>>>  
> >>>> +  "#reset-cells":
> >>>> +    const: 1
> >>>> +
> >>>>  required:
> >>>>    - compatible
> >>>>    - reg
> >>>>  
> >>>>  additionalProperties: false
> >>>>  
> >>>> +allOf:
> >>>> +  - if:
> >>>> +      properties:
> >>>> +        compatible:
> >>>> +          contains:
> >>>> +            const: renesas,r9a08g045-sysc
> >>>> +    then:
> >>>> +      required:
> >>>> +        - "#reset-cells"
> >>>
> >>> Given this is new required property on an existing platform, I'd expect
> >>> some mention of why it used to be okay to not have this but is now
> >>> required. Did firmware or a bootloader stage take things out of reset?
> >>
> >> On previous SoCs the SYS controller has no support for controlling the
> >> signals going to different peripherals (USB, PCIE in case of RZ/G3S).
> >> I'll add a note about this on next version.
> > 
> > My initial thought here wasn't about previous SoCs though, it was
> > because you didn't add the compatible in this series for /this/ SoC.
> 
> RZ/G3S compatible is already present in this file:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml#n26

I know, first thing I did when I read the original patch was open the
file ;)
I don't care about the old SoCs, cos you're not applying the property to
them, so what's changed between SoCs isn't really relevant. It's a mention
of why, on this SoC, it is safe to add new required properties that I want.

AFAIU the answer is that no consumer of the resets existed before, so
there's not some special state there, and I am guessing that the new
sysc driver you're adding isn't going to fail to probe if there are no
resets, it just won't register a reset controller? Which is fine, cos all
devicetrees that have the new peripherals will have #reset-cells etc.

> > What's worth noting isn't about the prior SoCs, it is about what makes
> > it okay for this one.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-phy/attachments/20240823/cac84528/attachment-0001.sig>

From xu.yang_2 at nxp.com  Mon Aug 26 00:08:50 2024
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Mon, 26 Aug 2024 15:08:50 +0800
Subject: [PATCH v3 1/5] dt-bindings: phy: imx8mq-usb: add compatible "fsl,imx95-usb-phy"
Message-ID: <20240826070854.1948347-1-xu.yang_2@nxp.com>

The usb phy in i.MX95 is compatible with i.MX8MP's, this will add a
compatible "fsl,imx95-usb-phy" for i.MX95. Also change reg maxItems
to 2 since i.MX95 needs another regmap to control Type-C Assist (TCA)
block. Since i.MX95 usb phy is able to switch SS lanes, this will also
add orientation-switch and port property to the file.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>

---
Changes in v2:
 - replace minItems with description in reg property
 - remove orientation-switch and port
 - refer to usb-switch.yaml
 - use unevaluatedProperties
Changes in v3:
 - add Rb tag
---
 .../bindings/phy/fsl,imx8mq-usb-phy.yaml      | 42 ++++++++++++++++---
 1 file changed, 37 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
index dc3a3f709fea..6d6d211883ae 100644
--- a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
@@ -11,12 +11,17 @@ maintainers:
 
 properties:
   compatible:
-    enum:
-      - fsl,imx8mq-usb-phy
-      - fsl,imx8mp-usb-phy
+    oneOf:
+      - enum:
+          - fsl,imx8mq-usb-phy
+          - fsl,imx8mp-usb-phy
+      - items:
+          - const: fsl,imx95-usb-phy
+          - const: fsl,imx8mp-usb-phy
 
   reg:
-    maxItems: 1
+    minItems: 1
+    maxItems: 2
 
   "#phy-cells":
     const: 0
@@ -89,7 +94,34 @@ required:
   - clocks
   - clock-names
 
-additionalProperties: false
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - fsl,imx95-usb-phy
+    then:
+      properties:
+        reg:
+          items:
+            - description: USB PHY Control range
+            - description: USB PHY TCA Block range
+    else:
+      properties:
+        reg:
+          maxItems: 1
+
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - fsl,imx95-usb-phy
+    then:
+      $ref: /schemas/usb/usb-switch.yaml#
+
+unevaluatedProperties: false
 
 examples:
   - |
-- 
2.34.1



From xu.yang_2 at nxp.com  Mon Aug 26 00:08:51 2024
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Mon, 26 Aug 2024 15:08:51 +0800
Subject: [PATCH v3 2/5] dt-bindings: usb: dwc3-imx8mp: add compatible string for imx95
In-Reply-To: <20240826070854.1948347-1-xu.yang_2@nxp.com>
References: <20240826070854.1948347-1-xu.yang_2@nxp.com>
Message-ID: <20240826070854.1948347-2-xu.yang_2@nxp.com>

The i.MX95 is compatible with i.MX8MP's usb controller. This will add a
compatible string "fsl,imx95-dwc3" for i.MX95.

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>

---
Changes in v2:
 - add Ack-by tag
Changes in v3:
 - no changes
---
 Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml b/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml
index 9ea1e4cd0709..baf130669c38 100644
--- a/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml
@@ -12,7 +12,11 @@ maintainers:
 
 properties:
   compatible:
-    const: fsl,imx8mp-dwc3
+    oneOf:
+      - items:
+          - const: fsl,imx95-dwc3
+          - const: fsl,imx8mp-dwc3
+      - const: fsl,imx8mp-dwc3
 
   reg:
     items:
-- 
2.34.1



From xu.yang_2 at nxp.com  Mon Aug 26 00:08:52 2024
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Mon, 26 Aug 2024 15:08:52 +0800
Subject: [PATCH v3 3/5] phy: fsl-imx8mq-usb: add tca function driver for imx95
In-Reply-To: <20240826070854.1948347-1-xu.yang_2@nxp.com>
References: <20240826070854.1948347-1-xu.yang_2@nxp.com>
Message-ID: <20240826070854.1948347-3-xu.yang_2@nxp.com>

The i.MX95 USB3 phy has a Type-C Assist block (TCA). This block consists
two functional blocks (XBar assist and VBus assist) and one system
access interface using APB.

The primary functionality of XBar assist is:
 - switching lane for flip
 - moving unused lanes into lower power states.

This info can be get from:
i.MX95 RM Chapter 163.3.8 Type-C assist (TCA) block.

This will add support for TCA block to achieve lane switching and tca
lower power functionality.

Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
Reviewed-by: Jun Li <jun.li at nxp.com>

---
Changes in v2:
 - return the value of imx95_usb_phy_get_tca()
Changes in v3:
 - no changes
---
 drivers/phy/freescale/Kconfig              |   1 +
 drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 240 +++++++++++++++++++++
 2 files changed, 241 insertions(+)

diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
index dcd9acff6d01..81f53564ee15 100644
--- a/drivers/phy/freescale/Kconfig
+++ b/drivers/phy/freescale/Kconfig
@@ -5,6 +5,7 @@ if (ARCH_MXC && ARM64) || COMPILE_TEST
 config PHY_FSL_IMX8MQ_USB
 	tristate "Freescale i.MX8M USB3 PHY"
 	depends on OF && HAS_IOMEM
+	depends on TYPEC || TYPEC=n
 	select GENERIC_PHY
 	default ARCH_MXC && ARM64
 
diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
index adc6394626ce..8bd6d91951a2 100644
--- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
+++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
@@ -10,6 +10,7 @@
 #include <linux/phy/phy.h>
 #include <linux/platform_device.h>
 #include <linux/regulator/consumer.h>
+#include <linux/usb/typec_mux.h>
 
 #define PHY_CTRL0			0x0
 #define PHY_CTRL0_REF_SSP_EN		BIT(2)
@@ -50,11 +51,66 @@
 
 #define PHY_TUNE_DEFAULT		0xffffffff
 
+#define TCA_CLK_RST			0x00
+#define TCA_CLK_RST_SW			BIT(9)
+#define TCA_CLK_RST_REF_CLK_EN		BIT(1)
+#define TCA_CLK_RST_SUSPEND_CLK_EN	BIT(0)
+
+#define TCA_INTR_EN			0x04
+#define TCA_INTR_STS			0x08
+
+#define TCA_GCFG			0x10
+#define TCA_GCFG_ROLE_HSTDEV		BIT(4)
+#define TCA_GCFG_OP_MODE		GENMASK(1, 0)
+#define TCA_GCFG_OP_MODE_SYSMODE	0
+#define TCA_GCFG_OP_MODE_SYNCMODE	1
+
+#define TCA_TCPC			0x14
+#define TCA_TCPC_VALID			BIT(4)
+#define TCA_TCPC_LOW_POWER_EN		BIT(3)
+#define TCA_TCPC_ORIENTATION_NORMAL	BIT(2)
+#define TCA_TCPC_MUX_CONTRL		GENMASK(1, 0)
+#define TCA_TCPC_MUX_CONTRL_NO_CONN	0
+#define TCA_TCPC_MUX_CONTRL_USB_CONN	1
+
+#define TCA_SYSMODE_CFG			0x18
+#define TCA_SYSMODE_TCPC_DISABLE	BIT(3)
+#define TCA_SYSMODE_TCPC_FLIP		BIT(2)
+
+#define TCA_CTRLSYNCMODE_CFG0		0x20
+#define TCA_CTRLSYNCMODE_CFG1           0x20
+
+#define TCA_PSTATE			0x30
+#define TCA_PSTATE_CM_STS		BIT(4)
+#define TCA_PSTATE_TX_STS		BIT(3)
+#define TCA_PSTATE_RX_PLL_STS		BIT(2)
+#define TCA_PSTATE_PIPE0_POWER_DOWN	GENMASK(1, 0)
+
+#define TCA_GEN_STATUS			0x34
+#define TCA_GEN_DEV_POR			BIT(12)
+#define TCA_GEN_REF_CLK_SEL		BIT(8)
+#define TCA_GEN_TYPEC_FLIP_INVERT	BIT(4)
+#define TCA_GEN_PHY_TYPEC_DISABLE	BIT(3)
+#define TCA_GEN_PHY_TYPEC_FLIP		BIT(2)
+
+#define TCA_VBUS_CTRL			0x40
+#define TCA_VBUS_STATUS			0x44
+
+#define TCA_INFO			0xFC
+
+struct tca_blk {
+	struct typec_switch_dev *sw;
+	void __iomem *base;
+	struct mutex mutex;
+	enum typec_orientation orientation;
+};
+
 struct imx8mq_usb_phy {
 	struct phy *phy;
 	struct clk *clk;
 	void __iomem *base;
 	struct regulator *vbus;
+	struct tca_blk *tca;
 	u32 pcs_tx_swing_full;
 	u32 pcs_tx_deemph_3p5db;
 	u32 tx_vref_tune;
@@ -64,6 +120,170 @@ struct imx8mq_usb_phy {
 	u32 comp_dis_tune;
 };
 
+
+static void tca_blk_orientation_set(struct tca_blk *tca,
+				enum typec_orientation orientation);
+
+#ifdef CONFIG_TYPEC
+
+static int tca_blk_typec_switch_set(struct typec_switch_dev *sw,
+				enum typec_orientation orientation)
+{
+	struct imx8mq_usb_phy *imx_phy = typec_switch_get_drvdata(sw);
+	struct tca_blk *tca = imx_phy->tca;
+	int ret;
+
+	if (tca->orientation == orientation)
+		return 0;
+
+	ret = clk_prepare_enable(imx_phy->clk);
+	if (ret)
+		return ret;
+
+	tca_blk_orientation_set(tca, orientation);
+	clk_disable_unprepare(imx_phy->clk);
+
+	return 0;
+}
+
+static struct typec_switch_dev *tca_blk_get_typec_switch(struct platform_device *pdev,
+					struct imx8mq_usb_phy *imx_phy)
+{
+	struct device *dev = &pdev->dev;
+	struct typec_switch_dev *sw;
+	struct typec_switch_desc sw_desc = { };
+
+	sw_desc.drvdata = imx_phy;
+	sw_desc.fwnode = dev->fwnode;
+	sw_desc.set = tca_blk_typec_switch_set;
+	sw_desc.name = NULL;
+
+	sw = typec_switch_register(dev, &sw_desc);
+	if (IS_ERR(sw)) {
+		dev_err(dev, "Error register tca orientation switch: %ld",
+				PTR_ERR(sw));
+		return NULL;
+	}
+
+	return sw;
+}
+
+static void tca_blk_put_typec_switch(struct typec_switch_dev *sw)
+{
+	typec_switch_unregister(sw);
+}
+
+#else
+
+static struct typec_switch_dev *tca_blk_get_typec_switch(struct platform_device *pdev,
+			struct imx8mq_usb_phy *imx_phy)
+{
+	return NULL;
+}
+
+static void tca_blk_put_typec_switch(struct typec_switch_dev *sw) {}
+
+#endif /* CONFIG_TYPEC */
+
+static void tca_blk_orientation_set(struct tca_blk *tca,
+				enum typec_orientation orientation)
+{
+	u32 val;
+
+	mutex_lock(&tca->mutex);
+
+	if (orientation == TYPEC_ORIENTATION_NONE) {
+		/*
+		 * use Controller Synced Mode for TCA low power enable and
+		 * put PHY to USB safe state.
+		 */
+		val = readl(tca->base + TCA_GCFG);
+		val = FIELD_PREP(TCA_GCFG_OP_MODE, TCA_GCFG_OP_MODE_SYNCMODE);
+		writel(val, tca->base + TCA_GCFG);
+
+		val = readl(tca->base + TCA_TCPC);
+		val = TCA_TCPC_VALID | TCA_TCPC_LOW_POWER_EN;
+		writel(val, tca->base + TCA_TCPC);
+
+		goto out;
+	}
+
+	/* use System Configuration Mode for TCA mux control. */
+	val = readl(tca->base + TCA_GCFG);
+	val = FIELD_PREP(TCA_GCFG_OP_MODE, TCA_GCFG_OP_MODE_SYSMODE);
+	writel(val, tca->base + TCA_GCFG);
+
+	/* Disable TCA module */
+	val = readl(tca->base + TCA_SYSMODE_CFG);
+	val |= TCA_SYSMODE_TCPC_DISABLE;
+	writel(val, tca->base + TCA_SYSMODE_CFG);
+
+	if (orientation == TYPEC_ORIENTATION_REVERSE)
+		val |= TCA_SYSMODE_TCPC_FLIP;
+	else if (orientation == TYPEC_ORIENTATION_NORMAL)
+		val &= ~TCA_SYSMODE_TCPC_FLIP;
+
+	writel(val, tca->base + TCA_SYSMODE_CFG);
+
+	/* Enable TCA module */
+	val &= ~TCA_SYSMODE_TCPC_DISABLE;
+	writel(val, tca->base + TCA_SYSMODE_CFG);
+
+out:
+	tca->orientation = orientation;
+	mutex_unlock(&tca->mutex);
+}
+
+static void tca_blk_init(struct tca_blk *tca)
+{
+	u32 val;
+
+	/* reset XBar block */
+	val = readl(tca->base + TCA_CLK_RST);
+	val &= ~TCA_CLK_RST_SW;
+	writel(val, tca->base + TCA_CLK_RST);
+
+	udelay(100);
+
+	/* clear reset */
+	val |= TCA_CLK_RST_SW;
+	writel(val, tca->base + TCA_CLK_RST);
+
+	tca_blk_orientation_set(tca, tca->orientation);
+}
+
+static struct tca_blk *imx95_usb_phy_get_tca(struct platform_device *pdev,
+				struct imx8mq_usb_phy *imx_phy)
+{
+	struct device *dev = &pdev->dev;
+	struct tca_blk *tca;
+
+	tca = devm_kzalloc(dev, sizeof(*tca), GFP_KERNEL);
+	if (!tca)
+		return ERR_PTR(-ENOMEM);
+
+	tca->base = devm_platform_ioremap_resource(pdev, 1);
+	if (IS_ERR(tca->base))
+		return tca->base;
+
+	mutex_init(&tca->mutex);
+
+	tca->orientation = TYPEC_ORIENTATION_NORMAL;
+	tca->sw = tca_blk_get_typec_switch(pdev, imx_phy);
+
+	return tca;
+}
+
+static void imx95_usb_phy_put_tca(struct imx8mq_usb_phy *imx_phy)
+{
+	struct tca_blk *tca = imx_phy->tca;
+
+	if (!tca)
+		return;
+
+	tca_blk_put_typec_switch(tca->sw);
+}
+
 static u32 phy_tx_vref_tune_from_property(u32 percent)
 {
 	percent = clamp(percent, 94U, 124U);
@@ -315,6 +535,9 @@ static int imx8mp_usb_phy_init(struct phy *phy)
 
 	imx8m_phy_tune(imx_phy);
 
+	if (imx_phy->tca)
+		tca_blk_init(imx_phy->tca);
+
 	return 0;
 }
 
@@ -359,6 +582,8 @@ static const struct of_device_id imx8mq_usb_phy_of_match[] = {
 	 .data = &imx8mq_usb_phy_ops,},
 	{.compatible = "fsl,imx8mp-usb-phy",
 	 .data = &imx8mp_usb_phy_ops,},
+	{.compatible = "fsl,imx95-usb-phy",
+	 .data = &imx8mp_usb_phy_ops,},
 	{ }
 };
 MODULE_DEVICE_TABLE(of, imx8mq_usb_phy_of_match);
@@ -398,6 +623,13 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
 
 	phy_set_drvdata(imx_phy->phy, imx_phy);
 
+	if (device_is_compatible(dev, "fsl,imx95-usb-phy")) {
+		imx_phy->tca = imx95_usb_phy_get_tca(pdev, imx_phy);
+		if (IS_ERR(imx_phy->tca))
+			return dev_err_probe(dev, PTR_ERR(imx_phy->tca),
+						"failed to get tca\n");
+	}
+
 	imx8m_get_phy_tuning_data(imx_phy);
 
 	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
@@ -405,8 +637,16 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
 	return PTR_ERR_OR_ZERO(phy_provider);
 }
 
+static void imx8mq_usb_phy_remove(struct platform_device *pdev)
+{
+	struct imx8mq_usb_phy *imx_phy = platform_get_drvdata(pdev);
+
+	imx95_usb_phy_put_tca(imx_phy);
+}
+
 static struct platform_driver imx8mq_usb_phy_driver = {
 	.probe	= imx8mq_usb_phy_probe,
+	.remove = imx8mq_usb_phy_remove,
 	.driver = {
 		.name	= "imx8mq-usb-phy",
 		.of_match_table	= imx8mq_usb_phy_of_match,
-- 
2.34.1



From xu.yang_2 at nxp.com  Mon Aug 26 00:08:53 2024
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Mon, 26 Aug 2024 15:08:53 +0800
Subject: [PATCH v3 4/5] arm64: dts: imx95: add usb3 related nodes
In-Reply-To: <20240826070854.1948347-1-xu.yang_2@nxp.com>
References: <20240826070854.1948347-1-xu.yang_2@nxp.com>
Message-ID: <20240826070854.1948347-4-xu.yang_2@nxp.com>

Add usb3 phy and controller nodes for imx95.

Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>

---
Changes in v2:
 - no changes
Changes in v3:
 - no changes
---
 arch/arm64/boot/dts/freescale/imx95.dtsi | 43 ++++++++++++++++++++++++
 1 file changed, 43 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
index 1bbf9a0468f6..06a7c2f1e211 100644
--- a/arch/arm64/boot/dts/freescale/imx95.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
@@ -1188,5 +1188,48 @@ pcie1_ep: pcie-ep at 4c380000 {
 			power-domains = <&scmi_devpd IMX95_PD_HSIO_TOP>;
 			status = "disabled";
 		};
+
+		usb3_phy: phy at 4c1f0040 {
+			compatible = "fsl,imx95-usb-phy", "fsl,imx8mp-usb-phy";
+			reg = <0x0 0x4c1f0040 0x0 0x40>,
+			      <0x0 0x4c1fc000 0x0 0x100>;
+			clocks = <&scmi_clk IMX95_CLK_HSIO>;
+			clock-names = "phy";
+			#phy-cells = <0>;
+			power-domains = <&scmi_devpd IMX95_PD_HSIO_TOP>;
+			orientation-switch;
+			status = "disabled";
+		};
+
+		usb3: usb at 4c010010 {
+			compatible = "fsl,imx95-dwc3", "fsl,imx8mp-dwc3";
+			reg = <0x0 0x4c010010 0x0 0x04>,
+			      <0x0 0x4c1f0000 0x0 0x20>;
+			clocks = <&scmi_clk IMX95_CLK_HSIO>,
+				 <&scmi_clk IMX95_CLK_32K>;
+			clock-names = "hsio", "suspend";
+			interrupts = <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>;
+			#address-cells = <2>;
+			#size-cells = <2>;
+			ranges;
+			power-domains = <&scmi_devpd IMX95_PD_HSIO_TOP>;
+			dma-ranges = <0x0 0x0 0x0 0x0 0x10 0x0>;
+			status = "disabled";
+
+			usb3_dwc3: usb at 4c100000 {
+				compatible = "snps,dwc3";
+				reg = <0x0 0x4c100000 0x0 0x10000>;
+				clocks = <&scmi_clk IMX95_CLK_HSIO>,
+					 <&scmi_clk IMX95_CLK_24M>,
+					 <&scmi_clk IMX95_CLK_32K>;
+				clock-names = "bus_early", "ref", "suspend";
+				interrupts = <GIC_SPI 175 IRQ_TYPE_LEVEL_HIGH>;
+				phys = <&usb3_phy>, <&usb3_phy>;
+				phy-names = "usb2-phy", "usb3-phy";
+				snps,gfladj-refclk-lpm-sel-quirk;
+				snps,parkmode-disable-ss-quirk;
+				iommus = <&smmu 0xe>;
+			};
+		};
 	};
 };
-- 
2.34.1



From xu.yang_2 at nxp.com  Mon Aug 26 00:08:54 2024
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Mon, 26 Aug 2024 15:08:54 +0800
Subject: [PATCH v3 5/5] arm64: dts: imx95-19x19-evk: add typec nodes and enable usb3 node
In-Reply-To: <20240826070854.1948347-1-xu.yang_2@nxp.com>
References: <20240826070854.1948347-1-xu.yang_2@nxp.com>
Message-ID: <20240826070854.1948347-5-xu.yang_2@nxp.com>

This board has one Type-C port which has USB3 capability. This will
add typec nodes and enable usb3 node.

Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>

---
Changes in v2:
 - no changes
Changes in v3:
 - no changes
---
 .../boot/dts/freescale/imx95-19x19-evk.dts    | 81 +++++++++++++++++++
 1 file changed, 81 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
index d14a54ab4fd4..46a9cd3d4403 100644
--- a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
@@ -5,6 +5,7 @@
 
 /dts-v1/;
 
+#include <dt-bindings/usb/pd.h>
 #include "imx95.dtsi"
 
 / {
@@ -99,6 +100,48 @@ i2c7_pcal6524: i2c7-gpio at 22 {
 		interrupt-parent = <&gpio5>;
 		interrupts = <16 IRQ_TYPE_LEVEL_LOW>;
 	};
+
+	ptn5110: tcpc at 50 {
+		compatible = "nxp,ptn5110", "tcpci";
+		reg = <0x50>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_typec>;
+		interrupt-parent = <&gpio5>;
+		interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
+
+		typec_con: connector {
+			compatible = "usb-c-connector";
+			label = "USB-C";
+			power-role = "dual";
+			data-role = "dual";
+			try-power-role = "sink";
+			source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+			sink-pdos = <PDO_FIXED(5000, 0, PDO_FIXED_USB_COMM)>;
+			op-sink-microwatt = <0>;
+			self-powered;
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				port at 0 {
+					reg = <0>;
+
+					typec_con_hs: endpoint {
+						remote-endpoint = <&usb3_data_hs>;
+					};
+				};
+
+				port at 1 {
+					reg = <1>;
+
+					typec_con_ss: endpoint {
+						remote-endpoint = <&usb3_data_ss>;
+					};
+				};
+			};
+		};
+	};
 };
 
 &lpuart1 {
@@ -128,6 +171,38 @@ &pcie1 {
 	status = "okay";
 };
 
+&usb3 {
+	status = "okay";
+};
+
+&usb3_phy {
+	status = "okay";
+
+	port {
+		usb3_data_ss: endpoint {
+			remote-endpoint = <&typec_con_ss>;
+		};
+	};
+};
+
+&usb3_dwc3 {
+	dr_mode = "otg";
+	hnp-disable;
+	srp-disable;
+	adp-disable;
+	usb-role-switch;
+	role-switch-default-mode = "peripheral";
+	snps,dis-u1-entry-quirk;
+	snps,dis-u2-entry-quirk;
+	status = "okay";
+
+	port {
+		usb3_data_hs: endpoint {
+			remote-endpoint = <&typec_con_hs>;
+		};
+	};
+};
+
 &usdhc1 {
 	pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
 	pinctrl-0 = <&pinctrl_usdhc1>;
@@ -245,6 +320,12 @@ IMX95_PAD_SD2_RESET_B__GPIO3_IO_BIT7		0x31e
 		>;
 	};
 
+	pinctrl_typec: typecgrp {
+		fsl,pins = <
+			IMX95_PAD_GPIO_IO34__GPIO5_IO_BIT14			0x31e
+		>;
+	};
+
 	pinctrl_usdhc2_gpio: usdhc2gpiogrp {
 		fsl,pins = <
 			IMX95_PAD_SD2_CD_B__GPIO3_IO_BIT0		0x31e
-- 
2.34.1



From xu.yang_2 at nxp.com  Sun Aug 25 23:56:12 2024
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Mon, 26 Aug 2024 14:56:12 +0800
Subject: [PATCH v2 6/6] ARM: dts: imx7ulp: add "nxp,sim" property for
 usbphy1
In-Reply-To: <20240726113207.3393247-6-xu.yang_2@nxp.com>
References: <20240726113207.3393247-1-xu.yang_2@nxp.com>
 <20240726113207.3393247-6-xu.yang_2@nxp.com>
Message-ID: <20240826065612.ol4fjib4g2jrvoy7@hippo>

Hi Shawn,

On Fri, Jul 26, 2024 at 07:32:07PM +0800, Xu Yang wrote:
> i.MX7ULP need properly set System Integration Module(SIM) module to make
> usb wakeup work well. This will add a "nxp,sim" property for usbphy1.
> 
> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> 
> ---
> Changes in v2:
>  - no changes
> ---
>  arch/arm/boot/dts/nxp/imx/imx7ulp.dtsi | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/boot/dts/nxp/imx/imx7ulp.dtsi b/arch/arm/boot/dts/nxp/imx/imx7ulp.dtsi
> index ac338320ac1d..b093f2a447ae 100644
> --- a/arch/arm/boot/dts/nxp/imx/imx7ulp.dtsi
> +++ b/arch/arm/boot/dts/nxp/imx/imx7ulp.dtsi
> @@ -214,6 +214,7 @@ usbphy1: usb-phy at 40350000 {
>  			interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
>  			clocks = <&pcc2 IMX7ULP_CLK_USB_PHY>;
>  			#phy-cells = <0>;
> +			nxp,sim = <&sim>;
>  		};
>  
>  		usdhc0: mmc at 40370000 {

Could you please pick up patch 3 and 6?

Thanks in advance!

Best Regards,
Xu Yang

> -- 
> 2.34.1
> 


From krzysztof.kozlowski at linaro.org  Mon Aug 26 03:07:16 2024
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 26 Aug 2024 12:07:16 +0200
Subject: [PATCH 00/11] phy: simplify with cleanup.h and few other ideas
Message-ID: <20240826-phy-of-node-scope-v1-0-5b4d82582644@linaro.org>

Make code simpler with scoped/cleanup.h/dev_err_probe.

Best regards,
Krzysztof

---
Krzysztof Kozlowski (11):
      phy: broadcom: bcm-cygnus-pcie: Simplify with scoped for each OF child loop
      phy: broadcom: brcm-sata: Simplify with scoped for each OF child loop
      phy: cadence: sierra: Simplify with scoped for each OF child loop
      phy: hisilicon: usb2: Simplify with scoped for each OF child loop
      phy: mediatek: tphy: Simplify with scoped for each OF child loop
      phy: mediatek: xsphy: Simplify with scoped for each OF child loop
      phy: qcom: qmp-pcie-msm8996: Simplify with scoped for each OF child loop
      phy: ti: am654-serdes: Use scoped device node handling to simplify error paths
      phy: ti: gmii-sel: Simplify with dev_err_probe()
      phy: ti: j721e-wiz: Drop OF node reference earlier for simpler code
      phy: ti: j721e-wiz: Simplify with scoped for each OF child loop

 drivers/phy/broadcom/phy-bcm-cygnus-pcie.c       | 20 +++-------
 drivers/phy/broadcom/phy-brcm-sata.c             | 21 ++++------
 drivers/phy/cadence/phy-cadence-sierra.c         |  7 +---
 drivers/phy/hisilicon/phy-hisi-inno-usb2.c       | 12 ++----
 drivers/phy/mediatek/phy-mtk-tphy.c              | 30 ++++++--------
 drivers/phy/mediatek/phy-mtk-xsphy.c             | 27 +++++--------
 drivers/phy/qualcomm/phy-qcom-qmp-pcie-msm8996.c | 11 ++----
 drivers/phy/ti/phy-am654-serdes.c                | 50 ++++++++----------------
 drivers/phy/ti/phy-gmii-sel.c                    | 16 +++-----
 drivers/phy/ti/phy-j721e-wiz.c                   | 12 ++----
 10 files changed, 68 insertions(+), 138 deletions(-)
---
base-commit: 834e84894a9d34ecc195d5db5386912bde3eefd7
change-id: 20240825-phy-of-node-scope-055ed0431743

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>



From krzysztof.kozlowski at linaro.org  Mon Aug 26 03:07:19 2024
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 26 Aug 2024 12:07:19 +0200
Subject: [PATCH 03/11] phy: cadence: sierra: Simplify with scoped for each
 OF child loop
In-Reply-To: <20240826-phy-of-node-scope-v1-0-5b4d82582644@linaro.org>
References: <20240826-phy-of-node-scope-v1-0-5b4d82582644@linaro.org>
Message-ID: <20240826-phy-of-node-scope-v1-3-5b4d82582644@linaro.org>

Use scoped for_each_available_child_of_node_scoped() when iterating over
device nodes to make code a bit simpler.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/phy/cadence/phy-cadence-sierra.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/phy/cadence/phy-cadence-sierra.c b/drivers/phy/cadence/phy-cadence-sierra.c
index 3010c9f24136..aeec6eb6be23 100644
--- a/drivers/phy/cadence/phy-cadence-sierra.c
+++ b/drivers/phy/cadence/phy-cadence-sierra.c
@@ -1366,7 +1366,7 @@ static int cdns_sierra_phy_probe(struct platform_device *pdev)
 	unsigned int id_value;
 	int ret, node = 0;
 	void __iomem *base;
-	struct device_node *dn = dev->of_node, *child;
+	struct device_node *dn = dev->of_node;
 
 	if (of_get_child_count(dn) == 0)
 		return -ENODEV;
@@ -1438,7 +1438,7 @@ static int cdns_sierra_phy_probe(struct platform_device *pdev)
 
 	sp->autoconf = of_property_read_bool(dn, "cdns,autoconf");
 
-	for_each_available_child_of_node(dn, child) {
+	for_each_available_child_of_node_scoped(dn, child) {
 		struct phy *gphy;
 
 		if (!(of_node_name_eq(child, "phy") ||
@@ -1452,7 +1452,6 @@ static int cdns_sierra_phy_probe(struct platform_device *pdev)
 			dev_err(dev, "failed to get reset %s\n",
 				child->full_name);
 			ret = PTR_ERR(sp->phys[node].lnk_rst);
-			of_node_put(child);
 			goto put_control;
 		}
 
@@ -1461,7 +1460,6 @@ static int cdns_sierra_phy_probe(struct platform_device *pdev)
 			if (ret) {
 				dev_err(dev, "missing property in node %s\n",
 					child->name);
-				of_node_put(child);
 				reset_control_put(sp->phys[node].lnk_rst);
 				goto put_control;
 			}
@@ -1475,7 +1473,6 @@ static int cdns_sierra_phy_probe(struct platform_device *pdev)
 			gphy = devm_phy_create(dev, child, &noop_ops);
 		if (IS_ERR(gphy)) {
 			ret = PTR_ERR(gphy);
-			of_node_put(child);
 			reset_control_put(sp->phys[node].lnk_rst);
 			goto put_control;
 		}

-- 
2.43.0



From krzysztof.kozlowski at linaro.org  Mon Aug 26 03:07:17 2024
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 26 Aug 2024 12:07:17 +0200
Subject: [PATCH 01/11] phy: broadcom: bcm-cygnus-pcie: Simplify with scoped
 for each OF child loop
In-Reply-To: <20240826-phy-of-node-scope-v1-0-5b4d82582644@linaro.org>
References: <20240826-phy-of-node-scope-v1-0-5b4d82582644@linaro.org>
Message-ID: <20240826-phy-of-node-scope-v1-1-5b4d82582644@linaro.org>

Use scoped for_each_available_child_of_node_scoped() when iterating over
device nodes to make code a bit simpler.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/phy/broadcom/phy-bcm-cygnus-pcie.c | 20 ++++++--------------
 1 file changed, 6 insertions(+), 14 deletions(-)

diff --git a/drivers/phy/broadcom/phy-bcm-cygnus-pcie.c b/drivers/phy/broadcom/phy-bcm-cygnus-pcie.c
index cc29b08e49eb..462c61a24ec5 100644
--- a/drivers/phy/broadcom/phy-bcm-cygnus-pcie.c
+++ b/drivers/phy/broadcom/phy-bcm-cygnus-pcie.c
@@ -113,11 +113,10 @@ static const struct phy_ops cygnus_pcie_phy_ops = {
 static int cygnus_pcie_phy_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
-	struct device_node *node = dev->of_node, *child;
+	struct device_node *node = dev->of_node;
 	struct cygnus_pcie_phy_core *core;
 	struct phy_provider *provider;
 	unsigned cnt = 0;
-	int ret;
 
 	if (of_get_child_count(node) == 0) {
 		dev_err(dev, "PHY no child node\n");
@@ -136,35 +135,31 @@ static int cygnus_pcie_phy_probe(struct platform_device *pdev)
 
 	mutex_init(&core->lock);
 
-	for_each_available_child_of_node(node, child) {
+	for_each_available_child_of_node_scoped(node, child) {
 		unsigned int id;
 		struct cygnus_pcie_phy *p;
 
 		if (of_property_read_u32(child, "reg", &id)) {
 			dev_err(dev, "missing reg property for %pOFn\n",
 				child);
-			ret = -EINVAL;
-			goto put_child;
+			return -EINVAL;
 		}
 
 		if (id >= MAX_NUM_PHYS) {
 			dev_err(dev, "invalid PHY id: %u\n", id);
-			ret = -EINVAL;
-			goto put_child;
+			return -EINVAL;
 		}
 
 		if (core->phys[id].phy) {
 			dev_err(dev, "duplicated PHY id: %u\n", id);
-			ret = -EINVAL;
-			goto put_child;
+			return -EINVAL;
 		}
 
 		p = &core->phys[id];
 		p->phy = devm_phy_create(dev, child, &cygnus_pcie_phy_ops);
 		if (IS_ERR(p->phy)) {
 			dev_err(dev, "failed to create PHY\n");
-			ret = PTR_ERR(p->phy);
-			goto put_child;
+			return PTR_ERR(p->phy);
 		}
 
 		p->core = core;
@@ -184,9 +179,6 @@ static int cygnus_pcie_phy_probe(struct platform_device *pdev)
 	dev_dbg(dev, "registered %u PCIe PHY(s)\n", cnt);
 
 	return 0;
-put_child:
-	of_node_put(child);
-	return ret;
 }
 
 static const struct of_device_id cygnus_pcie_phy_match_table[] = {

-- 
2.43.0



From krzysztof.kozlowski at linaro.org  Mon Aug 26 03:07:21 2024
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 26 Aug 2024 12:07:21 +0200
Subject: [PATCH 05/11] phy: mediatek: tphy: Simplify with scoped for each
 OF child loop
In-Reply-To: <20240826-phy-of-node-scope-v1-0-5b4d82582644@linaro.org>
References: <20240826-phy-of-node-scope-v1-0-5b4d82582644@linaro.org>
Message-ID: <20240826-phy-of-node-scope-v1-5-5b4d82582644@linaro.org>

Use scoped for_each_child_of_node_scoped() when iterating over device
nodes to make code a bit simpler.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/phy/mediatek/phy-mtk-tphy.c | 30 +++++++++++-------------------
 1 file changed, 11 insertions(+), 19 deletions(-)

diff --git a/drivers/phy/mediatek/phy-mtk-tphy.c b/drivers/phy/mediatek/phy-mtk-tphy.c
index 25b86bbb9cec..3f7095ec5978 100644
--- a/drivers/phy/mediatek/phy-mtk-tphy.c
+++ b/drivers/phy/mediatek/phy-mtk-tphy.c
@@ -1577,12 +1577,11 @@ static int mtk_tphy_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 	struct device_node *np = dev->of_node;
-	struct device_node *child_np;
 	struct phy_provider *provider;
 	struct resource *sif_res;
 	struct mtk_tphy *tphy;
 	struct resource res;
-	int port, retval;
+	int port;
 
 	tphy = devm_kzalloc(dev, sizeof(*tphy), GFP_KERNEL);
 	if (!tphy)
@@ -1623,25 +1622,23 @@ static int mtk_tphy_probe(struct platform_device *pdev)
 	}
 
 	port = 0;
-	for_each_child_of_node(np, child_np) {
+	for_each_child_of_node_scoped(np, child_np) {
 		struct mtk_phy_instance *instance;
 		struct clk_bulk_data *clks;
 		struct device *subdev;
 		struct phy *phy;
+		int retval;
 
 		instance = devm_kzalloc(dev, sizeof(*instance), GFP_KERNEL);
-		if (!instance) {
-			retval = -ENOMEM;
-			goto put_child;
-		}
+		if (!instance)
+			return -ENOMEM;
 
 		tphy->phys[port] = instance;
 
 		phy = devm_phy_create(dev, child_np, &mtk_tphy_ops);
 		if (IS_ERR(phy)) {
 			dev_err(dev, "failed to create phy\n");
-			retval = PTR_ERR(phy);
-			goto put_child;
+			return PTR_ERR(phy);
 		}
 
 		subdev = &phy->dev;
@@ -1649,14 +1646,12 @@ static int mtk_tphy_probe(struct platform_device *pdev)
 		if (retval) {
 			dev_err(subdev, "failed to get address resource(id-%d)\n",
 				port);
-			goto put_child;
+			return retval;
 		}
 
 		instance->port_base = devm_ioremap_resource(subdev, &res);
-		if (IS_ERR(instance->port_base)) {
-			retval = PTR_ERR(instance->port_base);
-			goto put_child;
-		}
+		if (IS_ERR(instance->port_base))
+			return PTR_ERR(instance->port_base);
 
 		instance->phy = phy;
 		instance->index = port;
@@ -1668,19 +1663,16 @@ static int mtk_tphy_probe(struct platform_device *pdev)
 		clks[1].id = "da_ref";  /* analog clock */
 		retval = devm_clk_bulk_get_optional(subdev, TPHY_CLKS_CNT, clks);
 		if (retval)
-			goto put_child;
+			return retval;
 
 		retval = phy_type_syscon_get(instance, child_np);
 		if (retval)
-			goto put_child;
+			return retval;
 	}
 
 	provider = devm_of_phy_provider_register(dev, mtk_phy_xlate);
 
 	return PTR_ERR_OR_ZERO(provider);
-put_child:
-	of_node_put(child_np);
-	return retval;
 }
 
 static struct platform_driver mtk_tphy_driver = {

-- 
2.43.0



From krzysztof.kozlowski at linaro.org  Mon Aug 26 03:07:18 2024
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 26 Aug 2024 12:07:18 +0200
Subject: [PATCH 02/11] phy: broadcom: brcm-sata: Simplify with scoped for
 each OF child loop
In-Reply-To: <20240826-phy-of-node-scope-v1-0-5b4d82582644@linaro.org>
References: <20240826-phy-of-node-scope-v1-0-5b4d82582644@linaro.org>
Message-ID: <20240826-phy-of-node-scope-v1-2-5b4d82582644@linaro.org>

Use scoped for_each_available_child_of_node_scoped() when iterating over
device nodes to make code a bit simpler.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/phy/broadcom/phy-brcm-sata.c | 21 +++++++--------------
 1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/drivers/phy/broadcom/phy-brcm-sata.c b/drivers/phy/broadcom/phy-brcm-sata.c
index ed9e18791ec9..228100357054 100644
--- a/drivers/phy/broadcom/phy-brcm-sata.c
+++ b/drivers/phy/broadcom/phy-brcm-sata.c
@@ -751,11 +751,11 @@ static int brcm_sata_phy_probe(struct platform_device *pdev)
 {
 	const char *rxaeq_mode;
 	struct device *dev = &pdev->dev;
-	struct device_node *dn = dev->of_node, *child;
+	struct device_node *dn = dev->of_node;
 	const struct of_device_id *of_id;
 	struct brcm_sata_phy *priv;
 	struct phy_provider *provider;
-	int ret, count = 0;
+	int count = 0;
 
 	if (of_get_child_count(dn) == 0)
 		return -ENODEV;
@@ -782,26 +782,23 @@ static int brcm_sata_phy_probe(struct platform_device *pdev)
 			return PTR_ERR(priv->ctrl_base);
 	}
 
-	for_each_available_child_of_node(dn, child) {
+	for_each_available_child_of_node_scoped(dn, child) {
 		unsigned int id;
 		struct brcm_sata_port *port;
 
 		if (of_property_read_u32(child, "reg", &id)) {
 			dev_err(dev, "missing reg property in node %pOFn\n",
 					child);
-			ret = -EINVAL;
-			goto put_child;
+			return -EINVAL;
 		}
 
 		if (id >= MAX_PORTS) {
 			dev_err(dev, "invalid reg: %u\n", id);
-			ret = -EINVAL;
-			goto put_child;
+			return -EINVAL;
 		}
 		if (priv->phys[id].phy) {
 			dev_err(dev, "already registered port %u\n", id);
-			ret = -EINVAL;
-			goto put_child;
+			return -EINVAL;
 		}
 
 		port = &priv->phys[id];
@@ -822,8 +819,7 @@ static int brcm_sata_phy_probe(struct platform_device *pdev)
 		port->ssc_en = of_property_read_bool(child, "brcm,enable-ssc");
 		if (IS_ERR(port->phy)) {
 			dev_err(dev, "failed to create PHY\n");
-			ret = PTR_ERR(port->phy);
-			goto put_child;
+			return PTR_ERR(port->phy);
 		}
 
 		phy_set_drvdata(port->phy, port);
@@ -839,9 +835,6 @@ static int brcm_sata_phy_probe(struct platform_device *pdev)
 	dev_info(dev, "registered %d port(s)\n", count);
 
 	return 0;
-put_child:
-	of_node_put(child);
-	return ret;
 }
 
 static struct platform_driver brcm_sata_phy_driver = {

-- 
2.43.0



From krzysztof.kozlowski at linaro.org  Mon Aug 26 03:07:22 2024
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 26 Aug 2024 12:07:22 +0200
Subject: [PATCH 06/11] phy: mediatek: xsphy: Simplify with scoped for each
 OF child loop
In-Reply-To: <20240826-phy-of-node-scope-v1-0-5b4d82582644@linaro.org>
References: <20240826-phy-of-node-scope-v1-0-5b4d82582644@linaro.org>
Message-ID: <20240826-phy-of-node-scope-v1-6-5b4d82582644@linaro.org>

Use scoped for_each_child_of_node_scoped() when iterating over device
nodes to make code a bit simpler.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/phy/mediatek/phy-mtk-xsphy.c | 27 +++++++++------------------
 1 file changed, 9 insertions(+), 18 deletions(-)

diff --git a/drivers/phy/mediatek/phy-mtk-xsphy.c b/drivers/phy/mediatek/phy-mtk-xsphy.c
index 064fd0941727..7c248f5cfca5 100644
--- a/drivers/phy/mediatek/phy-mtk-xsphy.c
+++ b/drivers/phy/mediatek/phy-mtk-xsphy.c
@@ -432,12 +432,11 @@ static int mtk_xsphy_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 	struct device_node *np = dev->of_node;
-	struct device_node *child_np;
 	struct phy_provider *provider;
 	struct resource *glb_res;
 	struct mtk_xsphy *xsphy;
 	struct resource res;
-	int port, retval;
+	int port;
 
 	xsphy = devm_kzalloc(dev, sizeof(*xsphy), GFP_KERNEL);
 	if (!xsphy)
@@ -471,37 +470,34 @@ static int mtk_xsphy_probe(struct platform_device *pdev)
 	device_property_read_u32(dev, "mediatek,src-coef", &xsphy->src_coef);
 
 	port = 0;
-	for_each_child_of_node(np, child_np) {
+	for_each_child_of_node_scoped(np, child_np) {
 		struct xsphy_instance *inst;
 		struct phy *phy;
+		int retval;
 
 		inst = devm_kzalloc(dev, sizeof(*inst), GFP_KERNEL);
-		if (!inst) {
-			retval = -ENOMEM;
-			goto put_child;
-		}
+		if (!inst)
+			return -ENOMEM;
 
 		xsphy->phys[port] = inst;
 
 		phy = devm_phy_create(dev, child_np, &mtk_xsphy_ops);
 		if (IS_ERR(phy)) {
 			dev_err(dev, "failed to create phy\n");
-			retval = PTR_ERR(phy);
-			goto put_child;
+			return PTR_ERR(phy);
 		}
 
 		retval = of_address_to_resource(child_np, 0, &res);
 		if (retval) {
 			dev_err(dev, "failed to get address resource(id-%d)\n",
 				port);
-			goto put_child;
+			return retval;
 		}
 
 		inst->port_base = devm_ioremap_resource(&phy->dev, &res);
 		if (IS_ERR(inst->port_base)) {
 			dev_err(dev, "failed to remap phy regs\n");
-			retval = PTR_ERR(inst->port_base);
-			goto put_child;
+			return PTR_ERR(inst->port_base);
 		}
 
 		inst->phy = phy;
@@ -512,17 +508,12 @@ static int mtk_xsphy_probe(struct platform_device *pdev)
 		inst->ref_clk = devm_clk_get(&phy->dev, "ref");
 		if (IS_ERR(inst->ref_clk)) {
 			dev_err(dev, "failed to get ref_clk(id-%d)\n", port);
-			retval = PTR_ERR(inst->ref_clk);
-			goto put_child;
+			return PTR_ERR(inst->ref_clk);
 		}
 	}
 
 	provider = devm_of_phy_provider_register(dev, mtk_phy_xlate);
 	return PTR_ERR_OR_ZERO(provider);
-
-put_child:
-	of_node_put(child_np);
-	return retval;
 }
 
 static struct platform_driver mtk_xsphy_driver = {

-- 
2.43.0



From krzysztof.kozlowski at linaro.org  Mon Aug 26 03:07:20 2024
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 26 Aug 2024 12:07:20 +0200
Subject: [PATCH 04/11] phy: hisilicon: usb2: Simplify with scoped for each
 OF child loop
In-Reply-To: <20240826-phy-of-node-scope-v1-0-5b4d82582644@linaro.org>
References: <20240826-phy-of-node-scope-v1-0-5b4d82582644@linaro.org>
Message-ID: <20240826-phy-of-node-scope-v1-4-5b4d82582644@linaro.org>

Use scoped for_each_child_of_node_scoped() when iterating over device
nodes to make code a bit simpler.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/phy/hisilicon/phy-hisi-inno-usb2.c | 12 +++---------
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/phy/hisilicon/phy-hisi-inno-usb2.c b/drivers/phy/hisilicon/phy-hisi-inno-usb2.c
index c138cd4807d6..c843923252aa 100644
--- a/drivers/phy/hisilicon/phy-hisi-inno-usb2.c
+++ b/drivers/phy/hisilicon/phy-hisi-inno-usb2.c
@@ -138,7 +138,6 @@ static int hisi_inno_phy_probe(struct platform_device *pdev)
 	struct device_node *np = dev->of_node;
 	struct hisi_inno_phy_priv *priv;
 	struct phy_provider *provider;
-	struct device_node *child;
 	int i = 0;
 	int ret;
 
@@ -162,24 +161,20 @@ static int hisi_inno_phy_probe(struct platform_device *pdev)
 
 	priv->type = (uintptr_t) of_device_get_match_data(dev);
 
-	for_each_child_of_node(np, child) {
+	for_each_child_of_node_scoped(np, child) {
 		struct reset_control *rst;
 		struct phy *phy;
 
 		rst = of_reset_control_get_exclusive(child, NULL);
-		if (IS_ERR(rst)) {
-			of_node_put(child);
+		if (IS_ERR(rst))
 			return PTR_ERR(rst);
-		}
 
 		priv->ports[i].utmi_rst = rst;
 		priv->ports[i].priv = priv;
 
 		phy = devm_phy_create(dev, child, &hisi_inno_phy_ops);
-		if (IS_ERR(phy)) {
-			of_node_put(child);
+		if (IS_ERR(phy))
 			return PTR_ERR(phy);
-		}
 
 		phy_set_bus_width(phy, 8);
 		phy_set_drvdata(phy, &priv->ports[i]);
@@ -187,7 +182,6 @@ static int hisi_inno_phy_probe(struct platform_device *pdev)
 
 		if (i >= INNO_PHY_PORT_NUM) {
 			dev_warn(dev, "Support %d ports in maximum\n", i);
-			of_node_put(child);
 			break;
 		}
 	}

-- 
2.43.0



From krzysztof.kozlowski at linaro.org  Mon Aug 26 03:07:25 2024
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 26 Aug 2024 12:07:25 +0200
Subject: [PATCH 09/11] phy: ti: gmii-sel: Simplify with dev_err_probe()
In-Reply-To: <20240826-phy-of-node-scope-v1-0-5b4d82582644@linaro.org>
References: <20240826-phy-of-node-scope-v1-0-5b4d82582644@linaro.org>
Message-ID: <20240826-phy-of-node-scope-v1-9-5b4d82582644@linaro.org>

Use dev_err_probe() to avoid dmesg flood on actual defer.  This makes
the code also simpler.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/phy/ti/phy-gmii-sel.c | 16 ++++++----------
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/phy/ti/phy-gmii-sel.c b/drivers/phy/ti/phy-gmii-sel.c
index b30bf740e2e0..103b266fec77 100644
--- a/drivers/phy/ti/phy-gmii-sel.c
+++ b/drivers/phy/ti/phy-gmii-sel.c
@@ -468,11 +468,9 @@ static int phy_gmii_sel_probe(struct platform_device *pdev)
 	priv->regmap = syscon_node_to_regmap(node->parent);
 	if (IS_ERR(priv->regmap)) {
 		priv->regmap = device_node_to_regmap(node);
-		if (IS_ERR(priv->regmap)) {
-			ret = PTR_ERR(priv->regmap);
-			dev_err(dev, "Failed to get syscon %d\n", ret);
-			return ret;
-		}
+		if (IS_ERR(priv->regmap))
+			return dev_err_probe(dev, PTR_ERR(priv->regmap),
+					     "Failed to get syscon\n");
 		priv->no_offset = true;
 	}
 
@@ -485,11 +483,9 @@ static int phy_gmii_sel_probe(struct platform_device *pdev)
 	priv->phy_provider =
 		devm_of_phy_provider_register(dev,
 					      phy_gmii_sel_of_xlate);
-	if (IS_ERR(priv->phy_provider)) {
-		ret = PTR_ERR(priv->phy_provider);
-		dev_err(dev, "Failed to create phy provider %d\n", ret);
-		return ret;
-	}
+	if (IS_ERR(priv->phy_provider))
+		return dev_err_probe(dev, PTR_ERR(priv->phy_provider),
+				     "Failed to create phy provider\n");
 
 	return 0;
 }

-- 
2.43.0



From krzysztof.kozlowski at linaro.org  Mon Aug 26 03:07:24 2024
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 26 Aug 2024 12:07:24 +0200
Subject: [PATCH 08/11] phy: ti: am654-serdes: Use scoped device node
 handling to simplify error paths
In-Reply-To: <20240826-phy-of-node-scope-v1-0-5b4d82582644@linaro.org>
References: <20240826-phy-of-node-scope-v1-0-5b4d82582644@linaro.org>
Message-ID: <20240826-phy-of-node-scope-v1-8-5b4d82582644@linaro.org>

Obtain the device node reference with scoped/cleanup.h to reduce error
handling and make the code a bit simpler.

Unlike in other typical of_node_get+syscon_node_to_regmap cases, the
reference cannot be dropped immediately after syscon_node_to_regmap(),
because further part of probe() uses it.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/phy/ti/phy-am654-serdes.c | 50 +++++++++++++--------------------------
 1 file changed, 17 insertions(+), 33 deletions(-)

diff --git a/drivers/phy/ti/phy-am654-serdes.c b/drivers/phy/ti/phy-am654-serdes.c
index 673449607c02..3bf3aff4b1c7 100644
--- a/drivers/phy/ti/phy-am654-serdes.c
+++ b/drivers/phy/ti/phy-am654-serdes.c
@@ -7,6 +7,7 @@
  */
 
 #include <dt-bindings/phy/phy.h>
+#include <linux/cleanup.h>
 #include <linux/clk.h>
 #include <linux/clk-provider.h>
 #include <linux/delay.h>
@@ -644,7 +645,6 @@ static int serdes_am654_clk_register(struct serdes_am654 *am654_phy,
 	struct device_node *node = am654_phy->of_node;
 	struct device *dev = am654_phy->dev;
 	struct serdes_am654_clk_mux *mux;
-	struct device_node *regmap_node;
 	const char **parent_names;
 	struct clk_init_data *init;
 	unsigned int num_parents;
@@ -652,7 +652,6 @@ static int serdes_am654_clk_register(struct serdes_am654 *am654_phy,
 	const __be32 *addr;
 	unsigned int reg;
 	struct clk *clk;
-	int ret = 0;
 
 	mux = devm_kzalloc(dev, sizeof(*mux), GFP_KERNEL);
 	if (!mux)
@@ -660,41 +659,30 @@ static int serdes_am654_clk_register(struct serdes_am654 *am654_phy,
 
 	init = &mux->clk_data;
 
-	regmap_node = of_parse_phandle(node, "ti,serdes-clk", 0);
-	if (!regmap_node) {
-		dev_err(dev, "Fail to get serdes-clk node\n");
-		ret = -ENODEV;
-		goto out_put_node;
-	}
+	struct device_node *regmap_node __free(device_node) =
+		of_parse_phandle(node, "ti,serdes-clk", 0);
+	if (!regmap_node)
+		return dev_err_probe(dev, -ENODEV, "Fail to get serdes-clk node\n");
 
 	regmap = syscon_node_to_regmap(regmap_node->parent);
-	if (IS_ERR(regmap)) {
-		dev_err(dev, "Fail to get Syscon regmap\n");
-		ret = PTR_ERR(regmap);
-		goto out_put_node;
-	}
+	if (IS_ERR(regmap))
+		return dev_err_probe(dev, PTR_ERR(regmap),
+				     "Fail to get Syscon regmap\n");
 
 	num_parents = of_clk_get_parent_count(node);
-	if (num_parents < 2) {
-		dev_err(dev, "SERDES clock must have parents\n");
-		ret = -EINVAL;
-		goto out_put_node;
-	}
+	if (num_parents < 2)
+		return dev_err_probe(dev, -EINVAL, "SERDES clock must have parents\n");
 
 	parent_names = devm_kzalloc(dev, (sizeof(char *) * num_parents),
 				    GFP_KERNEL);
-	if (!parent_names) {
-		ret = -ENOMEM;
-		goto out_put_node;
-	}
+	if (!parent_names)
+		return -ENOMEM;
 
 	of_clk_parent_fill(node, parent_names, num_parents);
 
 	addr = of_get_address(regmap_node, 0, NULL, NULL);
-	if (!addr) {
-		ret = -EINVAL;
-		goto out_put_node;
-	}
+	if (!addr)
+		return -EINVAL;
 
 	reg = be32_to_cpu(*addr);
 
@@ -710,16 +698,12 @@ static int serdes_am654_clk_register(struct serdes_am654 *am654_phy,
 	mux->hw.init = init;
 
 	clk = devm_clk_register(dev, &mux->hw);
-	if (IS_ERR(clk)) {
-		ret = PTR_ERR(clk);
-		goto out_put_node;
-	}
+	if (IS_ERR(clk))
+		return PTR_ERR(clk);
 
 	am654_phy->clks[clock_num] = clk;
 
-out_put_node:
-	of_node_put(regmap_node);
-	return ret;
+	return 0;
 }
 
 static const struct of_device_id serdes_am654_id_table[] = {

-- 
2.43.0



From krzysztof.kozlowski at linaro.org  Mon Aug 26 03:07:23 2024
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 26 Aug 2024 12:07:23 +0200
Subject: [PATCH 07/11] phy: qcom: qmp-pcie-msm8996: Simplify with scoped
 for each OF child loop
In-Reply-To: <20240826-phy-of-node-scope-v1-0-5b4d82582644@linaro.org>
References: <20240826-phy-of-node-scope-v1-0-5b4d82582644@linaro.org>
Message-ID: <20240826-phy-of-node-scope-v1-7-5b4d82582644@linaro.org>

Use scoped for_each_available_child_of_node_scoped() when iterating over
device nodes to make code a bit simpler.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/phy/qualcomm/phy-qcom-qmp-pcie-msm8996.c | 11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie-msm8996.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie-msm8996.c
index 5f89e3a3e54f..a7c65cfe31df 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie-msm8996.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie-msm8996.c
@@ -725,7 +725,6 @@ static int qmp_pcie_msm8996_probe(struct platform_device *pdev)
 {
 	struct qcom_qmp *qmp;
 	struct device *dev = &pdev->dev;
-	struct device_node *child;
 	struct phy_provider *phy_provider;
 	void __iomem *serdes;
 	const struct qmp_phy_cfg *cfg = NULL;
@@ -773,13 +772,13 @@ static int qmp_pcie_msm8996_probe(struct platform_device *pdev)
 		return -ENOMEM;
 
 	id = 0;
-	for_each_available_child_of_node(dev->of_node, child) {
+	for_each_available_child_of_node_scoped(dev->of_node, child) {
 		/* Create per-lane phy */
 		ret = qmp_pcie_msm8996_create(dev, child, id, serdes, cfg);
 		if (ret) {
 			dev_err(dev, "failed to create lane%d phy, %d\n",
 				id, ret);
-			goto err_node_put;
+			return ret;
 		}
 
 		/*
@@ -790,7 +789,7 @@ static int qmp_pcie_msm8996_probe(struct platform_device *pdev)
 		if (ret) {
 			dev_err(qmp->dev,
 				"failed to register pipe clock source\n");
-			goto err_node_put;
+			return ret;
 		}
 
 		id++;
@@ -799,10 +798,6 @@ static int qmp_pcie_msm8996_probe(struct platform_device *pdev)
 	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
 
 	return PTR_ERR_OR_ZERO(phy_provider);
-
-err_node_put:
-	of_node_put(child);
-	return ret;
 }
 
 static struct platform_driver qmp_pcie_msm8996_driver = {

-- 
2.43.0



From krzysztof.kozlowski at linaro.org  Mon Aug 26 03:07:27 2024
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 26 Aug 2024 12:07:27 +0200
Subject: [PATCH 11/11] phy: ti: j721e-wiz: Simplify with scoped for each OF
 child loop
In-Reply-To: <20240826-phy-of-node-scope-v1-0-5b4d82582644@linaro.org>
References: <20240826-phy-of-node-scope-v1-0-5b4d82582644@linaro.org>
Message-ID: <20240826-phy-of-node-scope-v1-11-5b4d82582644@linaro.org>

Use scoped for_each_child_of_node_scoped() when iterating over device
nodes to make code a bit simpler.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/phy/ti/phy-j721e-wiz.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
index d0f3ead3fc80..a6c0c5607ffd 100644
--- a/drivers/phy/ti/phy-j721e-wiz.c
+++ b/drivers/phy/ti/phy-j721e-wiz.c
@@ -1404,7 +1404,7 @@ MODULE_DEVICE_TABLE(of, wiz_id_table);
 
 static int wiz_get_lane_phy_types(struct device *dev, struct wiz *wiz)
 {
-	struct device_node *serdes, *subnode;
+	struct device_node *serdes;
 
 	serdes = of_get_child_by_name(dev->of_node, "serdes");
 	if (!serdes) {
@@ -1412,7 +1412,7 @@ static int wiz_get_lane_phy_types(struct device *dev, struct wiz *wiz)
 		return -EINVAL;
 	}
 
-	for_each_child_of_node(serdes, subnode) {
+	for_each_child_of_node_scoped(serdes, subnode) {
 		u32 reg, num_lanes = 1, phy_type = PHY_NONE;
 		int ret, i;
 
@@ -1422,7 +1422,6 @@ static int wiz_get_lane_phy_types(struct device *dev, struct wiz *wiz)
 
 		ret = of_property_read_u32(subnode, "reg", &reg);
 		if (ret) {
-			of_node_put(subnode);
 			dev_err(dev,
 				"%s: Reading \"reg\" from \"%s\" failed: %d\n",
 				__func__, subnode->name, ret);

-- 
2.43.0



From krzysztof.kozlowski at linaro.org  Mon Aug 26 03:07:26 2024
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 26 Aug 2024 12:07:26 +0200
Subject: [PATCH 10/11] phy: ti: j721e-wiz: Drop OF node reference earlier
 for simpler code
In-Reply-To: <20240826-phy-of-node-scope-v1-0-5b4d82582644@linaro.org>
References: <20240826-phy-of-node-scope-v1-0-5b4d82582644@linaro.org>
Message-ID: <20240826-phy-of-node-scope-v1-10-5b4d82582644@linaro.org>

Drop OF node reference immediately after using it in
syscon_node_to_regmap(), which is both simpler and typical/expected
code pattern.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/phy/ti/phy-j721e-wiz.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
index bb16fdfe63df..d0f3ead3fc80 100644
--- a/drivers/phy/ti/phy-j721e-wiz.c
+++ b/drivers/phy/ti/phy-j721e-wiz.c
@@ -1179,14 +1179,13 @@ static int wiz_clock_probe(struct wiz *wiz, struct device_node *node)
 
 		ret = wiz_mux_of_clk_register(wiz, clk_node, wiz->mux_sel_field[i],
 					      clk_mux_sel[i].table);
+		of_node_put(clk_node);
 		if (ret) {
 			dev_err_probe(dev, ret, "Failed to register %s clock\n",
 				      node_name);
-			of_node_put(clk_node);
 			goto err;
 		}
 
-		of_node_put(clk_node);
 	}
 
 	for (i = 0; i < wiz->clk_div_sel_num; i++) {
@@ -1199,14 +1198,12 @@ static int wiz_clock_probe(struct wiz *wiz, struct device_node *node)
 
 		ret = wiz_div_clk_register(wiz, clk_node, wiz->div_sel_field[i],
 					   clk_div_sel[i].table);
+		of_node_put(clk_node);
 		if (ret) {
 			dev_err_probe(dev, ret, "Failed to register %s clock\n",
 				      node_name);
-			of_node_put(clk_node);
 			goto err;
 		}
-
-		of_node_put(clk_node);
 	}
 
 	return 0;

-- 
2.43.0



From claudiu.beznea at tuxon.dev  Mon Aug 26 03:15:43 2024
From: claudiu.beznea at tuxon.dev (claudiu beznea)
Date: Mon, 26 Aug 2024 13:15:43 +0300
Subject: [PATCH 02/16] dt-bindings: soc: renesas: renesas,rzg2l-sysc: Add
 #reset-cells for RZ/G3S
In-Reply-To: <20240823-dilute-juggle-7e2d43b8b630@spud>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
 <20240822152801.602318-3-claudiu.beznea.uj@bp.renesas.com>
 <20240822-vanilla-enigmatic-f0b05ecca4b6@spud>
 <0d8b1322-cf15-4ed9-b958-06516bbb64c7@tuxon.dev>
 <20240823-plywood-unfixed-d8d8a2d93f14@spud>
 <5eae2ddb-2a7b-4c1d-a7f7-41fb39058de1@tuxon.dev>
 <20240823-dilute-juggle-7e2d43b8b630@spud>
Message-ID: <7b16791b-0d7b-49a1-82aa-c4db99ff2bfd@tuxon.dev>



On 23.08.2024 19:33, Conor Dooley wrote:
> On Fri, Aug 23, 2024 at 07:26:42PM +0300, claudiu beznea wrote:
>> On 23.08.2024 19:18, Conor Dooley wrote:
>>> On Fri, Aug 23, 2024 at 10:54:06AM +0300, claudiu beznea wrote:
>>>> Hi, Conor,
>>>>
>>>> On 22.08.2024 19:42, Conor Dooley wrote:
>>>>> On Thu, Aug 22, 2024 at 06:27:47PM +0300, Claudiu wrote:
>>>>>> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>>>>>>
>>>>>> The RZ/G3S System controller has registers to control signals that need
>>>>>> to be de-asserted/asserted before/after different SoC areas are power
>>>>>> on/off. This signals are implemented as reset signals. For this document
>>>>>> the #reset-cells property.
>>>>>>
>>>>>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>>>>>> ---
>>>>>>  .../bindings/soc/renesas/renesas,rzg2l-sysc.yaml | 16 ++++++++++++++++
>>>>>>  1 file changed, 16 insertions(+)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
>>>>>> index 4386b2c3fa4d..6b0bb34485d9 100644
>>>>>> --- a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
>>>>>> +++ b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
>>>>>> @@ -42,12 +42,28 @@ properties:
>>>>>>        - const: cm33stbyr_int
>>>>>>        - const: ca55_deny
>>>>>>  
>>>>>> +  "#reset-cells":
>>>>>> +    const: 1
>>>>>> +
>>>>>>  required:
>>>>>>    - compatible
>>>>>>    - reg
>>>>>>  
>>>>>>  additionalProperties: false
>>>>>>  
>>>>>> +allOf:
>>>>>> +  - if:
>>>>>> +      properties:
>>>>>> +        compatible:
>>>>>> +          contains:
>>>>>> +            const: renesas,r9a08g045-sysc
>>>>>> +    then:
>>>>>> +      required:
>>>>>> +        - "#reset-cells"
>>>>>
>>>>> Given this is new required property on an existing platform, I'd expect
>>>>> some mention of why it used to be okay to not have this but is now
>>>>> required. Did firmware or a bootloader stage take things out of reset?
>>>>
>>>> On previous SoCs the SYS controller has no support for controlling the
>>>> signals going to different peripherals (USB, PCIE in case of RZ/G3S).
>>>> I'll add a note about this on next version.
>>>
>>> My initial thought here wasn't about previous SoCs though, it was
>>> because you didn't add the compatible in this series for /this/ SoC.
>>
>> RZ/G3S compatible is already present in this file:
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml#n26
> 
> I know, first thing I did when I read the original patch was open the
> file ;)
> I don't care about the old SoCs, cos you're not applying the property to
> them, so what's changed between SoCs isn't really relevant. It's a mention
> of why, on this SoC, it is safe to add new required properties that I want.


> 
> AFAIU the answer is that no consumer of the resets existed before, so

That's true.

> there's not some special state there, and I am guessing that the new
> sysc driver you're adding isn't going to fail to probe if there are no
> resets, 

That's true.

it just won't register a reset controller?

It will register it but,

the new sysc driver is going to probe only for this SoC (RZ/G3S). On RZ/G3S
we have 2 resets. These well be registered unconditionally, currently, only
for RZ/G3S. If there will be no DT users for it then it should be no
problem, AFAICT.

SYSC variants have common features b/w different SoC variants (one of them
being chip identification). The feature implemented though reset controller
in this series is not common but particular to RZ/G3S.

When the SYSC will be extended for other SoCs the reset driver registration
would have to be adapted to not be registered. At the moment, as the SYC is
compatible only with RZ/G3S and the reset driver is registered on auxiliary
bus though SYSC there is no restriction, reset is registered all the time,
but SYSC is only compatible with RZ/G3S.

> Which is fine, cos all
> devicetrees that have the new peripherals will have #reset-cells etc.
> 
>>> What's worth noting isn't about the prior SoCs, it is about what makes
>>> it okay for this one.


From conor at kernel.org  Mon Aug 26 10:09:09 2024
From: conor at kernel.org (Conor Dooley)
Date: Mon, 26 Aug 2024 18:09:09 +0100
Subject: [PATCH 02/16] dt-bindings: soc: renesas: renesas,rzg2l-sysc: Add
 #reset-cells for RZ/G3S
In-Reply-To: <7b16791b-0d7b-49a1-82aa-c4db99ff2bfd@tuxon.dev>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
 <20240822152801.602318-3-claudiu.beznea.uj@bp.renesas.com>
 <20240822-vanilla-enigmatic-f0b05ecca4b6@spud>
 <0d8b1322-cf15-4ed9-b958-06516bbb64c7@tuxon.dev>
 <20240823-plywood-unfixed-d8d8a2d93f14@spud>
 <5eae2ddb-2a7b-4c1d-a7f7-41fb39058de1@tuxon.dev>
 <20240823-dilute-juggle-7e2d43b8b630@spud>
 <7b16791b-0d7b-49a1-82aa-c4db99ff2bfd@tuxon.dev>
Message-ID: <20240826-daycare-freewill-c0e1400bf255@spud>

On Mon, Aug 26, 2024 at 01:15:43PM +0300, claudiu beznea wrote:
> 
> 
> On 23.08.2024 19:33, Conor Dooley wrote:
> > On Fri, Aug 23, 2024 at 07:26:42PM +0300, claudiu beznea wrote:
> >> On 23.08.2024 19:18, Conor Dooley wrote:
> >>> On Fri, Aug 23, 2024 at 10:54:06AM +0300, claudiu beznea wrote:
> >>>> Hi, Conor,
> >>>>
> >>>> On 22.08.2024 19:42, Conor Dooley wrote:
> >>>>> On Thu, Aug 22, 2024 at 06:27:47PM +0300, Claudiu wrote:
> >>>>>> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> >>>>>>
> >>>>>> The RZ/G3S System controller has registers to control signals that need
> >>>>>> to be de-asserted/asserted before/after different SoC areas are power
> >>>>>> on/off. This signals are implemented as reset signals. For this document
> >>>>>> the #reset-cells property.
> >>>>>>
> >>>>>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> >>>>>> ---
> >>>>>>  .../bindings/soc/renesas/renesas,rzg2l-sysc.yaml | 16 ++++++++++++++++
> >>>>>>  1 file changed, 16 insertions(+)
> >>>>>>
> >>>>>> diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
> >>>>>> index 4386b2c3fa4d..6b0bb34485d9 100644
> >>>>>> --- a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
> >>>>>> +++ b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
> >>>>>> @@ -42,12 +42,28 @@ properties:
> >>>>>>        - const: cm33stbyr_int
> >>>>>>        - const: ca55_deny
> >>>>>>  
> >>>>>> +  "#reset-cells":
> >>>>>> +    const: 1
> >>>>>> +
> >>>>>>  required:
> >>>>>>    - compatible
> >>>>>>    - reg
> >>>>>>  
> >>>>>>  additionalProperties: false
> >>>>>>  
> >>>>>> +allOf:
> >>>>>> +  - if:
> >>>>>> +      properties:
> >>>>>> +        compatible:
> >>>>>> +          contains:
> >>>>>> +            const: renesas,r9a08g045-sysc
> >>>>>> +    then:
> >>>>>> +      required:
> >>>>>> +        - "#reset-cells"
> >>>>>
> >>>>> Given this is new required property on an existing platform, I'd expect
> >>>>> some mention of why it used to be okay to not have this but is now
> >>>>> required. Did firmware or a bootloader stage take things out of reset?
> >>>>
> >>>> On previous SoCs the SYS controller has no support for controlling the
> >>>> signals going to different peripherals (USB, PCIE in case of RZ/G3S).
> >>>> I'll add a note about this on next version.
> >>>
> >>> My initial thought here wasn't about previous SoCs though, it was
> >>> because you didn't add the compatible in this series for /this/ SoC.
> >>
> >> RZ/G3S compatible is already present in this file:
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml#n26
> > 
> > I know, first thing I did when I read the original patch was open the
> > file ;)
> > I don't care about the old SoCs, cos you're not applying the property to
> > them, so what's changed between SoCs isn't really relevant. It's a mention
> > of why, on this SoC, it is safe to add new required properties that I want.
> 
> 
> > 
> > AFAIU the answer is that no consumer of the resets existed before, so
> 
> That's true.
> 
> > there's not some special state there, and I am guessing that the new
> > sysc driver you're adding isn't going to fail to probe if there are no
> > resets, 
> 
> That's true.
> 
> it just won't register a reset controller?
> 
> It will register it but,
> 
> the new sysc driver is going to probe only for this SoC (RZ/G3S). On RZ/G3S
> we have 2 resets. These well be registered unconditionally, currently, only
> for RZ/G3S. If there will be no DT users for it then it should be no
> problem, AFAICT.

Okay, sounds it doesn't break for existing devicetrees.
Acked-by: Conor Dooley <conor.dooley at microchip.com>

Thanks,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-phy/attachments/20240826/ef09dafc/attachment-0001.sig>

From aford173 at gmail.com  Mon Aug 26 17:25:48 2024
From: aford173 at gmail.com (Adam Ford)
Date: Mon, 26 Aug 2024 19:25:48 -0500
Subject: drm/bridge/imx8mp-hdmi-tx: Allow inexact pixel clock frequencies
 (Was: [PATCH V8 10/12] drm/bridge: imx: add bridge wrapper driver for i.MX8MP
 DWC HDMI)
In-Reply-To: <CAHCN7xKgpqfRf_2p1z5NyKiOYubbcDA7YE5ML8G56pVmcV+1xA@mail.gmail.com>
References: <20240203165307.7806-1-aford173@gmail.com> <20240203165307.7806-11-aford173@gmail.com>
 <Zm_UzO4Jmm7Aykcm@atmark-techno.com> <22a3f5266260dd3915269ae3eec7724f7537eb55.camel@pengutronix.de>
 <cd03ecb1-100e-4699-95ed-d837a2802dc7@kontron.de> <CAHCN7x+bh_ka250hOCenO3Et6re4EJ=5TG8=kpG1hs-PV0dQxQ@mail.gmail.com>
 <ZsVluV50NvuGGHFX@atmark-techno.com> <CAHCN7xJnjfjr7HfKF+4pwbENP+p2=vvMXWW1AQShNy87vfQ=-A@mail.gmail.com>
 <CAHCN7xKgpqfRf_2p1z5NyKiOYubbcDA7YE5ML8G56pVmcV+1xA@mail.gmail.com>
Message-ID: <CAHCN7x+HgasGG_v-PdtmRszhJn5odHzfV6ddeeT10_1yCOS+DQ@mail.gmail.com>

On Wed, Aug 21, 2024 at 8:59?PM Adam Ford <aford173 at gmail.com> wrote:
>
> On Wed, Aug 21, 2024 at 7:45?AM Adam Ford <aford173 at gmail.com> wrote:
> >
> > On Tue, Aug 20, 2024 at 10:58?PM Dominique MARTINET
> > <dominique.martinet at atmark-techno.com> wrote:
> > >
> > > Adam Ford wrote on Tue, Aug 20, 2024 at 09:49:03PM -0500:
> > > > > > However, this check is a bit overcautious in that it only allows exact
> > > > > > rate matches. IIRC HDMI allows a rate mismatch of +- 0.5%, so this
> > > > > > check could be relaxed quite a bit to allow for that.
> > > > >
> > > > > I checked with a 1080p display that reports 23 possible modes via EDID.
> > > > > Out of these 15 are accepted by the driver with the strict check.
> > > > >
> > > > > Two more would be accepted with a relaxed check that allows a 0.5% margin.
> > > > >
> > > > > For the remaining six modes, the pixel clock would deviate up to ~5%
> > > > > from what the display expects. Still, if I remove the check altogether,
> > > > > all 23 modes seem to work just fine.
> > >
> > > I can confirm the displays I tested also seem pretty tolerant in
> > > practice (up to ~3-4% at least), but I agree with Lucas that this isn't
> > > something we can rely on for a general purpose driver as having examples
> > > of things being tolerant doesn't mean all hardware will be as flexible..
> > >
> > > > > I'd really like to be able to add more PHY PLL setpoints for displays
> > > > > that use non-CEA-861 modes. Unfortunately I didn't manage to figure out
> > > > > the fractional-n PLL parameter calculation so far.
> > > > >
> > > > > The i.MX8MP Reference Manual provides formulas to calculate the
> > > > > parameters based on the register values and I tried to make sense of it
> > > > > using the existing register values in the driver. But somehow it doesn't
> > > > > add up for me.
> > > > >
> > > > > Lucas, did you already work with the PLL parameters? By any chance, do
> > > > > you now how the math behind them works?
> > > >
> > > > I spent a little time trying to understand it a bit.  I created a PMS
> > > > calculator similar to the one used on the DSI controller,
> > >
> > > Great! I'll admit this also flies over my head and I don't have the
> > > time to study this, so this is much appreciated.
> > >
> > > > except that
> > > > the M seems to be fixed at a value of 62 per the data sheet, so it's
> > > > more of a PS calculator.
> > >
> > > Hmm... PHY_REG2 in the datasheet only lists '0011_1110b - 62' as
> > > example(?) values, but it doesn't say other values are reserved either,
> > > I'm not sure what to make of it.
> > > In the current driver PHY_REG_02 (driver macro) is assigned the first
> > > field of .pll_div_regs, which goes anywhere from 0x4b to 0x7b -- pretty
> > > far from 62(0x3e)...
> >
> > OK.  I will experiment with increasing the range of M from being fixed
> > at 3e to a range of 3b to 7b to see if my PMS integer calculator can
> > get more accurate.
> >
> > >
> > > Since other frequencies have been adjusting this main diviser ratio we
> > > actually tried copying neighboring values and adjusting only that reg 2
> > > (so the M if I get this right?), but the end result ended up not
> > > synchronizing properly every time... We didn't have time to check with a
> > > scope if the generated signal was ugly or if it just didn't lock
> > > properly, but the display worked when we just re-used the neighboring
> > > values without changing anything despite being ~3-4% off, so we took the
> > > easy way out here and didn't dig much further.
> > >
> > > > Anyway, When I run my P-S calculator to generate the 'best rate' I get
> > > > a value that's usually 0.2% variance from nominal, but I only verified
> > > > a handful of values:
> > > >
> > > > Several which were +0.2%
> > > > 297600000 vs 297000000 (4k at 30)
> > > > 148800000 vs 148500000 (1080p60)
> > > > 74400 vs 74200
> > > >
> > > > One value was -0.16%
> > > > 24800000 vs 25200000
> > > >
> > > > If the M value was a bit more flexible, we might be able to reduce
> > > > that variance more.
> > >
> > > Yes, I think the M value could be more flexible, but that'd require
> > > checking if it actually works, whereas having slightly off frequencies
> > > will most likely be OK so I don't think it's worth the effort -- happy
> > > to stick to what the datasheet describes.
> > >
> > > > If / when I get some time, I might play with trying to disable the
> > > > fractional mode and just use the PMS calculator for simplicity despite
> > > > the inaccuracy.  Maybe we could fall back to using the PMS calculator
> > > > if the desired frequency isn't in the look-up-table.
> > >
> > > That'd be greatly appreciated, I don't have any strong opinion on
> > > whether that should completely replace the table, or only be used if
> > > there is no exact match in the table as these are values we know will
> > > work; but we can definitely test any patch you can throw at us here.
> >
> > I can't promise it'll be quick.  I am not fully certain I understand
> > how the whole thing works, but as a rule, I don't generally like look
> > up tables if they can be calculated dynamically.
>
> I updated my PMS calculator, and I randomly selected 5 resolutions and
> they all returned an exact clock match, so I'll attempt to use the PMS
> integer clock instead of the fractional one.
>
> It'll be a little while longer before I can do anything with it.

Frieder,

Using my PMS calculator and Rev 2 of the Tech Ref Manual, I think I
can generate you a table entry for 51.2MHz.  I don't have the ability
to test it.  I am still working on figuring out an algorithm to
calculate the fractional divider, but 51.2MHz x 5 does not' appear to
need the fractional clock divider, so I think I can just get away with
the standard PMS calculations.

My algorithm showed:
HDMI PHY Best P = 1
HDMI PHY Best M = 64
HDMI PHY Best S = 6
HDMI PHY Best freq = 256000000

I'll try to generate a patch to get these values into the table if
you're willing to test it.

All,

I still think it's a good idea to fall back to the PMS calculator if
the fractional stuff isn't found.  We could then determine which clock
frequency is closer between the nearest table entry or the PMS
calculator until someone can come up with an algorithm for it.


adam


>
> adam
> >
> > adam
> > >
> > >
> > > Cheers,
> > > --
> > > Dominique
> > >
> > >


From quic_srichara at quicinc.com  Mon Aug 26 21:57:51 2024
From: quic_srichara at quicinc.com (Sricharan R)
Date: Tue, 27 Aug 2024 10:27:51 +0530
Subject: [PATCH V2 0/6] Enable IPQ5018 PCI support
Message-ID: <20240827045757.1101194-1-quic_srichara@quicinc.com>

From: Sricharan Ramabadhran <quic_srichara at quicinc.com>

This patch series adds the relevant phy and controller
DT configurations for enabling PCI gen2 support
on IPQ5018.

v2:
  Fixed all review comments from Krzysztof, Robert Marko,
  Dmitry Baryshkov, Manivannan Sadhasivam, Konrad Dybcio.
  Updated the respective patches for their changes.

v1:
 https://lore.kernel.org/lkml/32389b66-48f3-8ee8-e2f1-1613feed3cc7 at gmail.com/T/

Nitheesh Sekar (5):
  dt-bindings: phy: qcom,uniphy-pcie: Document PCIe uniphy
  dt-bindings: PCI: qcom: Add IPQ5108 SoC
  phy: qcom: Introduce PCIe UNIPHY 28LP driver
  arm64: dts: qcom: ipq5018: Add PCIe related nodes
  arm64: dts: qcom: ipq5018: Enable PCIe

Sricharan R (1):
  PCI: qcom: Add support for IPQ5018

 .../devicetree/bindings/pci/qcom,pcie.yaml    |  35 ++
 .../phy/qcom,ipq5018-uniphy-pcie.yaml         |  70 ++++
 .../arm64/boot/dts/qcom/ipq5018-rdp432-c2.dts |   9 +
 arch/arm64/boot/dts/qcom/ipq5018.dtsi         | 166 ++++++++-
 drivers/pci/controller/dwc/pcie-qcom.c        |   1 +
 drivers/phy/qualcomm/Kconfig                  |  12 +
 drivers/phy/qualcomm/Makefile                 |   1 +
 .../phy/qualcomm/phy-qcom-uniphy-pcie-28lp.c  | 341 ++++++++++++++++++
 8 files changed, 633 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom,ipq5018-uniphy-pcie.yaml
 create mode 100644 drivers/phy/qualcomm/phy-qcom-uniphy-pcie-28lp.c

-- 
2.34.1



From quic_srichara at quicinc.com  Mon Aug 26 21:57:53 2024
From: quic_srichara at quicinc.com (Sricharan R)
Date: Tue, 27 Aug 2024 10:27:53 +0530
Subject: [PATCH V2 2/6] dt-bindings: PCI: qcom: Add IPQ5108 SoC
In-Reply-To: <20240827045757.1101194-1-quic_srichara@quicinc.com>
References: <20240827045757.1101194-1-quic_srichara@quicinc.com>
Message-ID: <20240827045757.1101194-3-quic_srichara@quicinc.com>

From: Nitheesh Sekar <quic_nsekar at quicinc.com>

Add support for the PCIe controller on the Qualcomm
IPQ5108 SoC to the bindings.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Nitheesh Sekar <quic_nsekar at quicinc.com>
Signed-off-by: Sricharan Ramabadhran <quic_srichara at quicinc.com>
---
 [v2] Added reviewed by tag

 .../devicetree/bindings/pci/qcom,pcie.yaml    | 35 +++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
index f867746b1ae5..c12efa27b8d8 100644
--- a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
@@ -21,6 +21,7 @@ properties:
           - qcom,pcie-apq8064
           - qcom,pcie-apq8084
           - qcom,pcie-ipq4019
+          - qcom,pcie-ipq5018
           - qcom,pcie-ipq6018
           - qcom,pcie-ipq8064
           - qcom,pcie-ipq8064-v2
@@ -312,6 +313,39 @@ allOf:
             - const: ahb # AHB reset
             - const: phy_ahb # PHY AHB reset
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - qcom,pcie-ipq5018
+    then:
+      properties:
+        clocks:
+          minItems: 6
+          maxItems: 6
+        clock-names:
+          items:
+            - const: iface # PCIe to SysNOC BIU clock
+            - const: axi_m # AXI Master clock
+            - const: axi_s # AXI Slave clock
+            - const: ahb # AHB clock
+            - const: aux # Auxiliary clock
+            - const: axi_bridge # AXI bridge clock
+        resets:
+          minItems: 8
+          maxItems: 8
+        reset-names:
+          items:
+            - const: pipe # PIPE reset
+            - const: sleep # Sleep reset
+            - const: sticky # Core sticky reset
+            - const: axi_m # AXI master reset
+            - const: axi_s # AXI slave reset
+            - const: ahb # AHB reset
+            - const: axi_m_sticky # AXI master sticky reset
+            - const: axi_s_sticky # AXI slave sticky reset
+
   - if:
       properties:
         compatible:
@@ -503,6 +537,7 @@ allOf:
               enum:
                 - qcom,pcie-apq8064
                 - qcom,pcie-ipq4019
+                - qcom,pcie-ipq5018
                 - qcom,pcie-ipq8064
                 - qcom,pcie-ipq8064v2
                 - qcom,pcie-ipq8074
-- 
2.34.1



From quic_srichara at quicinc.com  Mon Aug 26 21:57:52 2024
From: quic_srichara at quicinc.com (Sricharan R)
Date: Tue, 27 Aug 2024 10:27:52 +0530
Subject: [PATCH V2 1/6] dt-bindings: phy: qcom,uniphy-pcie: Document PCIe uniphy
In-Reply-To: <20240827045757.1101194-1-quic_srichara@quicinc.com>
References: <20240827045757.1101194-1-quic_srichara@quicinc.com>
Message-ID: <20240827045757.1101194-2-quic_srichara@quicinc.com>

From: Nitheesh Sekar <quic_nsekar at quicinc.com>

Document the Qualcomm UNIPHY PCIe 28LP present in IPQ5018.

Signed-off-by: Nitheesh Sekar <quic_nsekar at quicinc.com>
Signed-off-by: Sricharan Ramabadhran <quic_srichara at quicinc.com>
---
[v2]  Fixed filename, title, fixed clock-name, reset-names

 .../phy/qcom,ipq5018-uniphy-pcie.yaml         | 70 +++++++++++++++++++
 1 file changed, 70 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom,ipq5018-uniphy-pcie.yaml

diff --git a/Documentation/devicetree/bindings/phy/qcom,ipq5018-uniphy-pcie.yaml b/Documentation/devicetree/bindings/phy/qcom,ipq5018-uniphy-pcie.yaml
new file mode 100644
index 000000000000..c04dd179eb8b
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,ipq5018-uniphy-pcie.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/qcom,ipq5018-uniphy-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm UNIPHY PCIe 28LP PHY controller for genx1, genx2
+
+maintainers:
+  - Nitheesh Sekar <quic_nsekar at quicinc.com>
+  - Sricharan Ramabadhran <quic_srichara at quicinc.com>
+
+properties:
+  compatible:
+    enum:
+      - qcom,ipq5018-uniphy-pcie-gen2x1
+      - qcom,ipq5018-uniphy-pcie-gen2x2
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+  clock-names:
+    items:
+      - const: pipe
+
+  resets:
+    maxItems: 2
+
+  reset-names:
+    items:
+      - const: phy
+      - const: common
+
+  "#phy-cells":
+    const: 0
+
+  "#clock-cells":
+    const: 0
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - resets
+  - reset-names
+  - "#phy-cells"
+  - "#clock-cells"
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/qcom,gcc-ipq5018.h>
+    #include <dt-bindings/reset/qcom,gcc-ipq5018.h>
+
+    phy at 86000 {
+        compatible = "qcom,ipq5018-uniphy-pcie-gen2x2";
+        reg = <0x86000 0x1000>;
+        clocks = <&gcc GCC_PCIE0_PIPE_CLK>;
+        clock-names = "pipe";
+        resets = <&gcc GCC_PCIE0_PHY_BCR>,
+                 <&gcc GCC_PCIE0PHY_PHY_BCR>;
+        reset-names = "phy", "common";
+        #phy-cells = <0>;
+        #clock-cells = <0>;
+    };
-- 
2.34.1



From quic_srichara at quicinc.com  Mon Aug 26 21:57:54 2024
From: quic_srichara at quicinc.com (Sricharan R)
Date: Tue, 27 Aug 2024 10:27:54 +0530
Subject: [PATCH V2 3/6] phy: qcom: Introduce PCIe UNIPHY 28LP driver
In-Reply-To: <20240827045757.1101194-1-quic_srichara@quicinc.com>
References: <20240827045757.1101194-1-quic_srichara@quicinc.com>
Message-ID: <20240827045757.1101194-4-quic_srichara@quicinc.com>

From: Nitheesh Sekar <quic_nsekar at quicinc.com>

Add Qualcomm PCIe UNIPHY 28LP driver support present
in Qualcomm IPQ5018 SoC and the phy init sequence.

Signed-off-by: Nitheesh Sekar <quic_nsekar at quicinc.com>
Signed-off-by: Sricharan Ramabadhran <quic_srichara at quicinc.com>
---
 [v2] Added the single lane compatible
      Added dev_err_probe, removed .owner, MODULE_ALIAS.
      Used for() instead of while in qcom_uniphy_pcie_init
      Used devm_platform_get_and_ioremap_resource
      Dropped usage of clock-output-name
      Fixed init order to enable clks first, then reset

 drivers/phy/qualcomm/Kconfig                  |  12 +
 drivers/phy/qualcomm/Makefile                 |   1 +
 .../phy/qualcomm/phy-qcom-uniphy-pcie-28lp.c  | 341 ++++++++++++++++++
 3 files changed, 354 insertions(+)
 create mode 100644 drivers/phy/qualcomm/phy-qcom-uniphy-pcie-28lp.c

diff --git a/drivers/phy/qualcomm/Kconfig b/drivers/phy/qualcomm/Kconfig
index 846f8c99547f..8f043e8cb71c 100644
--- a/drivers/phy/qualcomm/Kconfig
+++ b/drivers/phy/qualcomm/Kconfig
@@ -154,6 +154,18 @@ config PHY_QCOM_M31_USB
 	  management. This driver is required even for peripheral only or
 	  host only mode configurations.
 
+config PHY_QCOM_UNIPHY_PCIE_28LP
+	bool "PCIE UNIPHY 28LP PHY driver"
+	depends on ARCH_QCOM
+	depends on HAS_IOMEM
+	depends on OF
+	select GENERIC_PHY
+	help
+	  Enable this to support the PCIe UNIPHY 28LP phy transceiver that
+	  is used with PCIe controllers on Qualcomm IPQ5018 chips. It
+	  handles PHY initialization, clock management required after
+	  resetting the hardware and power management.
+
 config PHY_QCOM_USB_HS
 	tristate "Qualcomm USB HS PHY module"
 	depends on USB_ULPI_BUS
diff --git a/drivers/phy/qualcomm/Makefile b/drivers/phy/qualcomm/Makefile
index eb60e950ad53..42038bc30974 100644
--- a/drivers/phy/qualcomm/Makefile
+++ b/drivers/phy/qualcomm/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_PHY_QCOM_QMP_USB_LEGACY)	+= phy-qcom-qmp-usb-legacy.o
 obj-$(CONFIG_PHY_QCOM_QUSB2)		+= phy-qcom-qusb2.o
 obj-$(CONFIG_PHY_QCOM_SNPS_EUSB2)	+= phy-qcom-snps-eusb2.o
 obj-$(CONFIG_PHY_QCOM_EUSB2_REPEATER)	+= phy-qcom-eusb2-repeater.o
+obj-$(CONFIG_PHY_QCOM_UNIPHY_PCIE_28LP)	+= phy-qcom-uniphy-pcie-28lp.o
 obj-$(CONFIG_PHY_QCOM_USB_HS) 		+= phy-qcom-usb-hs.o
 obj-$(CONFIG_PHY_QCOM_USB_HSIC) 	+= phy-qcom-usb-hsic.o
 obj-$(CONFIG_PHY_QCOM_USB_HS_28NM)	+= phy-qcom-usb-hs-28nm.o
diff --git a/drivers/phy/qualcomm/phy-qcom-uniphy-pcie-28lp.c b/drivers/phy/qualcomm/phy-qcom-uniphy-pcie-28lp.c
new file mode 100644
index 000000000000..877e1f0f8927
--- /dev/null
+++ b/drivers/phy/qualcomm/phy-qcom-uniphy-pcie-28lp.c
@@ -0,0 +1,341 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2024, The Linux Foundation. All rights reserved.
+ */
+
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/phy/phy.h>
+#include <linux/reset.h>
+#include <linux/of_device.h>
+#include <linux/delay.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+
+#define CDR_CTRL_REG_1		0x80
+#define CDR_CTRL_REG_2		0x84
+#define CDR_CTRL_REG_3		0x88
+#define CDR_CTRL_REG_4		0x8C
+#define CDR_CTRL_REG_5		0x90
+#define CDR_CTRL_REG_6		0x94
+#define CDR_CTRL_REG_7		0x98
+#define SSCG_CTRL_REG_1		0x9c
+#define SSCG_CTRL_REG_2		0xa0
+#define SSCG_CTRL_REG_3		0xa4
+#define SSCG_CTRL_REG_4		0xa8
+#define SSCG_CTRL_REG_5		0xac
+#define SSCG_CTRL_REG_6		0xb0
+#define PCS_INTERNAL_CONTROL_2	0x2d8
+
+#define PHY_MODE_FIXED		0x1
+
+enum qcom_uniphy_pcie_type {
+	PHY_TYPE_PCIE = 1,
+	PHY_TYPE_PCIE_GEN2,
+	PHY_TYPE_PCIE_GEN3,
+};
+
+struct qcom_uniphy_regs {
+	unsigned int offset;
+	unsigned int val;
+};
+
+struct qcom_uniphy_pcie_data {
+	int lanes;
+	/* 2nd lane offset */
+	int lane_offset;
+	unsigned int phy_type;
+	const struct qcom_uniphy_regs *init_seq;
+	unsigned int init_seq_num;
+};
+
+struct qcom_uniphy_pcie {
+	struct phy phy;
+	struct device *dev;
+	const struct qcom_uniphy_pcie_data *data;
+	struct clk_bulk_data *clks;
+	int num_clks;
+	struct reset_control *resets;
+	void __iomem *base;
+};
+
+#define	phy_to_dw_phy(x)	container_of((x), struct qca_uni_pcie_phy, phy)
+
+static const struct qcom_uniphy_regs ipq5018_regs[] = {
+	{
+		.offset = SSCG_CTRL_REG_4,
+		.val = 0x1cb9,
+	},
+	{
+		.offset = SSCG_CTRL_REG_5,
+		.val = 0x023a,
+	},
+	{
+		.offset = SSCG_CTRL_REG_3,
+		.val = 0xd360,
+	},
+	{
+		.offset = SSCG_CTRL_REG_1,
+		.val = 0x1,
+	},
+	{
+		.offset = SSCG_CTRL_REG_2,
+		.val = 0xeb,
+	},
+	{
+		.offset = CDR_CTRL_REG_4,
+		.val = 0x3f9,
+	},
+	{
+		.offset = CDR_CTRL_REG_5,
+		.val = 0x1c9,
+	},
+	{
+		.offset = CDR_CTRL_REG_2,
+		.val = 0x419,
+	},
+	{
+		.offset = CDR_CTRL_REG_1,
+		.val = 0x200,
+	},
+	{
+		.offset = PCS_INTERNAL_CONTROL_2,
+		.val = 0xf101,
+	},
+};
+
+static const struct qcom_uniphy_pcie_data ipq5018_2x1_data = {
+	.lanes		= 1,
+	.lane_offset	= 0x800,
+	.phy_type	= PHY_TYPE_PCIE_GEN2,
+	.init_seq	= ipq5018_regs,
+	.init_seq_num	= ARRAY_SIZE(ipq5018_regs),
+};
+
+static const struct qcom_uniphy_pcie_data ipq5018_2x2_data = {
+	.lanes		= 2,
+	.lane_offset	= 0x800,
+	.phy_type	= PHY_TYPE_PCIE_GEN2,
+	.init_seq	= ipq5018_regs,
+	.init_seq_num	= ARRAY_SIZE(ipq5018_regs),
+};
+
+static void qcom_uniphy_pcie_init(struct qcom_uniphy_pcie *phy)
+{
+	const struct qcom_uniphy_pcie_data *data = phy->data;
+	const struct qcom_uniphy_regs *init_seq;
+	void __iomem *base = phy->base;
+	int lane = 0;
+	int i;
+
+	for (lane = 0; lane < data->lanes; lane++) {
+		init_seq = data->init_seq;
+
+		for (i = 0; i < data->init_seq_num; i++, init_seq++)
+			writel(init_seq->val, base + init_seq->offset);
+
+		base += data->lane_offset;
+	}
+}
+
+static int qcom_uniphy_pcie_power_off(struct phy *x)
+{
+	struct qcom_uniphy_pcie *phy = phy_get_drvdata(x);
+
+	reset_control_assert(phy->resets);
+
+	clk_bulk_disable_unprepare(phy->num_clks, phy->clks);
+
+	return 0;
+}
+
+static int qcom_uniphy_pcie_power_on(struct phy *x)
+{
+	int ret;
+	struct qcom_uniphy_pcie *phy = phy_get_drvdata(x);
+
+	ret = clk_bulk_prepare_enable(phy->num_clks, phy->clks);
+	if (ret) {
+		dev_err(phy->dev, "clk prepare and enable failed %d\n", ret);
+		return ret;
+	}
+
+	usleep_range(30, 50);
+
+	ret = reset_control_assert(phy->resets);
+	if (ret) {
+		dev_err(phy->dev, "reset assert failed (%d)\n", ret);
+		return ret;
+	}
+
+	/*
+	 * Delay periods before and after reset deassert are working values
+	 * from downstream Codeaurora kernel
+	 */
+	usleep_range(100, 150);
+
+	ret = reset_control_deassert(phy->resets);
+	if (ret) {
+		dev_err(phy->dev, "reset deassert failed (%d)\n", ret);
+		return ret;
+	}
+
+	usleep_range(5000, 5100);
+
+	qcom_uniphy_pcie_init(phy);
+
+	return 0;
+}
+
+static inline int qcom_uniphy_pcie_get_resources(struct platform_device *pdev,
+						 struct qcom_uniphy_pcie *phy)
+{
+	struct resource *res;
+
+	phy->base = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
+	if (IS_ERR(phy->base)) {
+		dev_err(phy->dev, "cannot get phy registers\n");
+		return PTR_ERR(phy->base);
+	}
+
+	phy->num_clks = devm_clk_bulk_get_all(phy->dev, &phy->clks);
+	if (phy->num_clks < 0)
+		return phy->num_clks;
+
+	phy->resets = devm_reset_control_array_get_exclusive(phy->dev);
+	if (IS_ERR(phy->resets))
+		return PTR_ERR(phy->resets);
+
+	return 0;
+}
+
+/*
+ * Register a fixed rate pipe clock.
+ *
+ * The <s>_pipe_clksrc generated by PHY goes to the GCC that gate
+ * controls it. The <s>_pipe_clk coming out of the GCC is requested
+ * by the PHY driver for its operations.
+ * We register the <s>_pipe_clksrc here. The gcc driver takes care
+ * of assigning this <s>_pipe_clksrc as parent to <s>_pipe_clk.
+ * Below picture shows this relationship.
+ *
+ *         +---------------+
+ *         |   PHY block   |<<---------------------------------------+
+ *         |               |                                         |
+ *         |   +-------+   |                   +-----+               |
+ *   I/P---^-->|  PLL  |---^--->pipe_clksrc--->| GCC |--->pipe_clk---+
+ *    clk  |   +-------+   |                   +-----+
+ *         +---------------+
+ */
+static inline int phy_pipe_clk_register(struct qcom_uniphy_pcie  *phy,
+					struct device_node *np)
+{
+	struct clk_init_data init = { };
+	struct clk_fixed_rate *fixed;
+	struct clk_hw *hw;
+	char name[64];
+	int ret;
+
+	snprintf(name, sizeof(name), "%s::pipe_clk", dev_name(phy->dev));
+
+	fixed = devm_kzalloc(phy->dev, sizeof(*fixed), GFP_KERNEL);
+	if (!fixed)
+		return -ENOMEM;
+
+	init.ops = &clk_fixed_rate_ops;
+	fixed->fixed_rate = 125000000;
+	fixed->hw.init = &init;
+	hw = &fixed->hw;
+
+	hw = devm_clk_hw_register_fixed_rate(phy->dev, name, NULL,
+					     0, 125000000);
+	if (IS_ERR(hw))
+		return PTR_ERR(hw);
+
+	ret = devm_of_clk_add_hw_provider(phy->dev, of_clk_hw_simple_get, hw);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static const struct of_device_id qcom_uniphy_pcie_id_table[] = {
+	{
+		.compatible = "qcom,ipq5018-uniphy-pcie-gen2x2",
+		.data = &ipq5018_2x2_data,
+	},
+	{
+		.compatible = "qcom,ipq5018-uniphy-pcie-gen2x1",
+		.data = &ipq5018_2x1_data,
+	},
+
+	{ /* Sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, qcom_uniphy_pcie_id_table);
+
+static const struct phy_ops pcie_ops = {
+	.power_on	= qcom_uniphy_pcie_power_on,
+	.power_off	= qcom_uniphy_pcie_power_off,
+	.owner          = THIS_MODULE,
+};
+
+static int qcom_uniphy_pcie_probe(struct platform_device *pdev)
+{
+	struct qcom_uniphy_pcie *phy;
+	int ret;
+	struct phy *generic_phy;
+	struct phy_provider *phy_provider;
+	struct device *dev = &pdev->dev;
+	struct device_node *np = of_node_get(dev->of_node);
+
+	phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
+	if (!phy)
+		return -ENOMEM;
+
+	platform_set_drvdata(pdev, phy);
+	phy->dev = &pdev->dev;
+
+	phy->data = of_device_get_match_data(dev);
+	if (!phy->data)
+		return -EINVAL;
+
+	ret = qcom_uniphy_pcie_get_resources(pdev, phy);
+	if (ret < 0)
+		dev_err_probe(&pdev->dev, ret, "Failed to get resources:\n");
+
+	ret = phy_pipe_clk_register(phy, np);
+	if (ret)
+		dev_err_probe(&pdev->dev, ret, "pipe clk register failed\n");
+
+	generic_phy = devm_phy_create(phy->dev, NULL, &pcie_ops);
+	if (IS_ERR(generic_phy))
+		dev_err_probe(&pdev->dev, PTR_ERR(generic_phy),
+			      "phy create failed\n");
+
+	phy_set_drvdata(generic_phy, phy);
+	phy_provider = devm_of_phy_provider_register(phy->dev,
+						     of_phy_simple_xlate);
+	if (IS_ERR(phy_provider))
+		dev_err_probe(&pdev->dev, PTR_ERR(phy_provider),
+			      "phy register failed\n");
+
+	return 0;
+}
+
+static struct platform_driver qcom_uniphy_pcie_driver = {
+	.probe		= qcom_uniphy_pcie_probe,
+	.driver		= {
+		.name	= "qcom-uniphy-pcie",
+		.of_match_table = qcom_uniphy_pcie_id_table,
+	},
+};
+
+module_platform_driver(qcom_uniphy_pcie_driver);
+
+MODULE_LICENSE("Dual BSD/GPL");
+MODULE_DESCRIPTION("PCIE QCOM UNIPHY driver");
-- 
2.34.1



From quic_srichara at quicinc.com  Mon Aug 26 21:57:55 2024
From: quic_srichara at quicinc.com (Sricharan R)
Date: Tue, 27 Aug 2024 10:27:55 +0530
Subject: [PATCH V2 4/6] PCI: qcom: Add support for IPQ5018
In-Reply-To: <20240827045757.1101194-1-quic_srichara@quicinc.com>
References: <20240827045757.1101194-1-quic_srichara@quicinc.com>
Message-ID: <20240827045757.1101194-5-quic_srichara@quicinc.com>

Introduce a new compatible and re-use 2_9_0 ops.

Signed-off-by: Nitheesh Sekar <quic_nsekar at quicinc.com>
Signed-off-by: Sricharan R <quic_srichara at quicinc.com>
---
 [v2] Rebased on top of latest tip and only compatiable addition is required

 drivers/pci/controller/dwc/pcie-qcom.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
index 6f953e32d990..e814d6cc062d 100644
--- a/drivers/pci/controller/dwc/pcie-qcom.c
+++ b/drivers/pci/controller/dwc/pcie-qcom.c
@@ -1722,6 +1722,7 @@ static const struct of_device_id qcom_pcie_match[] = {
 	{ .compatible = "qcom,pcie-apq8064", .data = &cfg_2_1_0 },
 	{ .compatible = "qcom,pcie-apq8084", .data = &cfg_1_0_0 },
 	{ .compatible = "qcom,pcie-ipq4019", .data = &cfg_2_4_0 },
+	{ .compatible = "qcom,pcie-ipq5018", .data = &cfg_2_9_0 },
 	{ .compatible = "qcom,pcie-ipq6018", .data = &cfg_2_9_0 },
 	{ .compatible = "qcom,pcie-ipq8064", .data = &cfg_2_1_0 },
 	{ .compatible = "qcom,pcie-ipq8064-v2", .data = &cfg_2_1_0 },
-- 
2.34.1



From quic_srichara at quicinc.com  Mon Aug 26 21:57:57 2024
From: quic_srichara at quicinc.com (Sricharan R)
Date: Tue, 27 Aug 2024 10:27:57 +0530
Subject: [PATCH V2 6/6] arm64: dts: qcom: ipq5018: Enable PCIe
In-Reply-To: <20240827045757.1101194-1-quic_srichara@quicinc.com>
References: <20240827045757.1101194-1-quic_srichara@quicinc.com>
Message-ID: <20240827045757.1101194-7-quic_srichara@quicinc.com>

From: Nitheesh Sekar <quic_nsekar at quicinc.com>

Enable the PCIe controller and PHY nodes for RDP 432-c2.

Signed-off-by: Nitheesh Sekar <quic_nsekar at quicinc.com>
Signed-off-by: Sricharan Ramabadhran <quic_srichara at quicinc.com>
---
 [v2] Moved status as last property

 arch/arm64/boot/dts/qcom/ipq5018-rdp432-c2.dts | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/ipq5018-rdp432-c2.dts b/arch/arm64/boot/dts/qcom/ipq5018-rdp432-c2.dts
index 8460b538eb6a..2b253da7f776 100644
--- a/arch/arm64/boot/dts/qcom/ipq5018-rdp432-c2.dts
+++ b/arch/arm64/boot/dts/qcom/ipq5018-rdp432-c2.dts
@@ -28,6 +28,15 @@ &blsp1_uart1 {
 	status = "okay";
 };
 
+&pcie1 {
+	perst-gpios = <&tlmm 15 GPIO_ACTIVE_LOW>;
+	status = "okay";
+};
+
+&pcie_x2phy {
+	status = "okay";
+};
+
 &sdhc_1 {
 	pinctrl-0 = <&sdc_default_state>;
 	pinctrl-names = "default";
-- 
2.34.1



From quic_srichara at quicinc.com  Mon Aug 26 21:57:56 2024
From: quic_srichara at quicinc.com (Sricharan R)
Date: Tue, 27 Aug 2024 10:27:56 +0530
Subject: [PATCH V2 5/6] arm64: dts: qcom: ipq5018: Add PCIe related nodes
In-Reply-To: <20240827045757.1101194-1-quic_srichara@quicinc.com>
References: <20240827045757.1101194-1-quic_srichara@quicinc.com>
Message-ID: <20240827045757.1101194-6-quic_srichara@quicinc.com>

From: Nitheesh Sekar <quic_nsekar at quicinc.com>

Add phy and controller nodes for a 2-lane Gen2 and
1-lane Gen2 PCIe buses.

Signed-off-by: Nitheesh Sekar <quic_nsekar at quicinc.com>
Signed-off-by: Sricharan R <quic_srichara at quicinc.com>
---
 [v2] Removed relocatable flags,  removed assigned-clock-rates,
      fixed rest of the cosmetic comments.

 arch/arm64/boot/dts/qcom/ipq5018.dtsi | 168 +++++++++++++++++++++++++-
 1 file changed, 166 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/ipq5018.dtsi b/arch/arm64/boot/dts/qcom/ipq5018.dtsi
index 7e6e2c121979..dd5d6b7ff094 100644
--- a/arch/arm64/boot/dts/qcom/ipq5018.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq5018.dtsi
@@ -9,6 +9,7 @@
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/clock/qcom,gcc-ipq5018.h>
 #include <dt-bindings/reset/qcom,gcc-ipq5018.h>
+#include <dt-bindings/gpio/gpio.h>
 
 / {
 	interrupt-parent = <&intc>;
@@ -143,7 +144,33 @@ usbphy0: phy at 5b000 {
 			resets = <&gcc GCC_QUSB2_0_PHY_BCR>;
 
 			#phy-cells = <0>;
+		};
+
+		pcie_x1phy: phy at 7e000{
+			compatible = "qcom,ipq5018-uniphy-pcie-gen2x1";
+			reg = <0x0007e000 0x800>;
+			#phy-cells = <0>;
+			#clock-cells = <0>;
+			clocks = <&gcc GCC_PCIE1_PIPE_CLK>;
+			clock-names = "pipe";
+			assigned-clocks = <&gcc GCC_PCIE1_PIPE_CLK>;
+			resets = <&gcc GCC_PCIE1_PHY_BCR>,
+				 <&gcc GCC_PCIE1PHY_PHY_BCR>;
+			reset-names = "phy", "common";
+			status = "disabled";
+		};
 
+		pcie_x2phy: phy at 86000{
+			compatible = "qcom,ipq5018-uniphy-pcie-gen2x2";
+			reg = <0x00086000 0x1000>;
+			#phy-cells = <0>;
+			#clock-cells = <0>;
+			clocks = <&gcc GCC_PCIE0_PIPE_CLK>;
+			clock-names = "pipe";
+			assigned-clocks = <&gcc GCC_PCIE0_PIPE_CLK>;
+			resets = <&gcc GCC_PCIE0_PHY_BCR>,
+				 <&gcc GCC_PCIE0PHY_PHY_BCR>;
+			reset-names = "phy", "common";
 			status = "disabled";
 		};
 
@@ -170,8 +197,8 @@ gcc: clock-controller at 1800000 {
 			reg = <0x01800000 0x80000>;
 			clocks = <&xo_board_clk>,
 				 <&sleep_clk>,
-				 <0>,
-				 <0>,
+				 <&pcie_x2phy>,
+				 <&pcie_x1phy>,
 				 <0>,
 				 <0>,
 				 <0>,
@@ -387,6 +414,143 @@ frame at b128000 {
 				status = "disabled";
 			};
 		};
+
+		pcie0: pci at 80000000 {
+			compatible = "qcom,pcie-ipq5018";
+			reg =  <0x80000000 0xf1d>,
+			       <0x80000f20 0xa8>,
+			       <0x80001000 0x1000>,
+			       <0x00078000 0x3000>,
+			       <0x80100000 0x1000>;
+			reg-names = "dbi", "elbi", "atu", "parf", "config";
+			device_type = "pci";
+			linux,pci-domain = <0>;
+			bus-range = <0x00 0xff>;
+			num-lanes = <1>;
+			max-link-speed = <2>;
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			phys = <&pcie_x1phy>;
+			phy-names ="pciephy";
+
+			ranges = <0x01000000 0 0x80200000 0x80200000 0 0x00100000
+				  0x02000000 0 0x80300000 0x80300000 0 0x10000000>;
+
+			#interrupt-cells = <1>;
+			interrupt-map-mask = <0 0 0 0x7>;
+			interrupt-map = <0 0 0 1 &intc 0 0 142 IRQ_TYPE_LEVEL_HIGH>,
+					<0 0 0 2 &intc 0 0 143 IRQ_TYPE_LEVEL_HIGH>,
+					<0 0 0 3 &intc 0 0 144 IRQ_TYPE_LEVEL_HIGH>,
+					<0 0 0 4 &intc 0 0 145 IRQ_TYPE_LEVEL_HIGH>;
+
+			interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "global_irq";
+
+			clocks = <&gcc GCC_SYS_NOC_PCIE1_AXI_CLK>,
+				 <&gcc GCC_PCIE1_AXI_M_CLK>,
+				 <&gcc GCC_PCIE1_AXI_S_CLK>,
+				 <&gcc GCC_PCIE1_AHB_CLK>,
+				 <&gcc GCC_PCIE1_AUX_CLK>,
+				 <&gcc GCC_PCIE1_AXI_S_BRIDGE_CLK>;
+
+			clock-names = "iface",
+				      "axi_m",
+				      "axi_s",
+				      "ahb",
+				      "aux",
+				      "axi_bridge";
+
+			resets = <&gcc GCC_PCIE1_PIPE_ARES>,
+				 <&gcc GCC_PCIE1_SLEEP_ARES>,
+				 <&gcc GCC_PCIE1_CORE_STICKY_ARES>,
+				 <&gcc GCC_PCIE1_AXI_MASTER_ARES>,
+				 <&gcc GCC_PCIE1_AXI_SLAVE_ARES>,
+				 <&gcc GCC_PCIE1_AHB_ARES>,
+				 <&gcc GCC_PCIE1_AXI_MASTER_STICKY_ARES>,
+				 <&gcc GCC_PCIE1_AXI_SLAVE_STICKY_ARES>;
+
+			reset-names = "pipe",
+				      "sleep",
+				      "sticky",
+				      "axi_m",
+				      "axi_s",
+				      "ahb",
+				      "axi_m_sticky",
+				      "axi_s_sticky";
+
+			msi-map = <0x0 &v2m0 0x0 0xff8>;
+			status = "disabled";
+		};
+
+		pcie1: pci at a0000000 {
+			compatible = "qcom,pcie-ipq5018";
+			reg =  <0xa0000000 0xf1d>,
+			       <0xa0000f20 0xa8>,
+			       <0xa0001000 0x1000>,
+			       <0x00080000 0x3000>,
+			       <0xa0100000 0x1000>;
+			reg-names = "dbi", "elbi", "atu", "parf", "config";
+			device_type = "pci";
+			linux,pci-domain = <1>;
+			bus-range = <0x00 0xff>;
+			num-lanes = <2>;
+			max-link-speed = <2>;
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			phys = <&pcie_x2phy>;
+			phy-names ="pciephy";
+
+			ranges = <0x01000000 0 0xa0200000 0xa0200000 0 0x00100000
+				  0x02000000 0 0xa0300000 0xa0300000 0 0x10000000>;
+
+			#interrupt-cells = <1>;
+			interrupt-map-mask = <0 0 0 0x7>;
+			interrupt-map = <0 0 0 1 &intc 0 0 75 IRQ_TYPE_LEVEL_HIGH>,
+					<0 0 0 2 &intc 0 0 78 IRQ_TYPE_LEVEL_HIGH>,
+					<0 0 0 3 &intc 0 0 79 IRQ_TYPE_LEVEL_HIGH>,
+					<0 0 0 4 &intc 0 0 83 IRQ_TYPE_LEVEL_HIGH>;
+
+			interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "global_irq";
+
+			clocks = <&gcc GCC_SYS_NOC_PCIE0_AXI_CLK>,
+				 <&gcc GCC_PCIE0_AXI_M_CLK>,
+				 <&gcc GCC_PCIE0_AXI_S_CLK>,
+				 <&gcc GCC_PCIE0_AHB_CLK>,
+				 <&gcc GCC_PCIE0_AUX_CLK>,
+				 <&gcc GCC_PCIE0_AXI_S_BRIDGE_CLK>;
+
+			clock-names = "iface",
+				      "axi_m",
+				      "axi_s",
+				      "ahb",
+				      "aux",
+				      "axi_bridge";
+
+			resets = <&gcc GCC_PCIE0_PIPE_ARES>,
+				 <&gcc GCC_PCIE0_SLEEP_ARES>,
+				 <&gcc GCC_PCIE0_CORE_STICKY_ARES>,
+				 <&gcc GCC_PCIE0_AXI_MASTER_ARES>,
+				 <&gcc GCC_PCIE0_AXI_SLAVE_ARES>,
+				 <&gcc GCC_PCIE0_AHB_ARES>,
+				 <&gcc GCC_PCIE0_AXI_MASTER_STICKY_ARES>,
+				 <&gcc GCC_PCIE0_AXI_SLAVE_STICKY_ARES>;
+
+			reset-names = "pipe",
+				      "sleep",
+				      "sticky",
+				      "axi_m",
+				      "axi_s",
+				      "ahb",
+				      "axi_m_sticky",
+				      "axi_s_sticky";
+
+			msi-map = <0x0 &v2m0 0x0 0xff8>;
+			status = "disabled";
+		};
+
 	};
 
 	timer {
-- 
2.34.1



From krzk at kernel.org  Mon Aug 26 23:27:38 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Tue, 27 Aug 2024 08:27:38 +0200
Subject: [PATCH V2 1/6] dt-bindings: phy: qcom,uniphy-pcie: Document PCIe
 uniphy
In-Reply-To: <20240827045757.1101194-2-quic_srichara@quicinc.com>
References: <20240827045757.1101194-1-quic_srichara@quicinc.com>
 <20240827045757.1101194-2-quic_srichara@quicinc.com>
Message-ID: <q7s3iv5plsfbk75d3ecjjpcqc7ywwc2ygekfozty52lejvui4z@dpyhwken7a6y>

On Tue, Aug 27, 2024 at 10:27:52AM +0530, Sricharan R wrote:
> From: Nitheesh Sekar <quic_nsekar at quicinc.com>
> 
> Document the Qualcomm UNIPHY PCIe 28LP present in IPQ5018.
> 
> Signed-off-by: Nitheesh Sekar <quic_nsekar at quicinc.com>
> Signed-off-by: Sricharan Ramabadhran <quic_srichara at quicinc.com>
> ---
> [v2]  Fixed filename, title, fixed clock-name, reset-names

OK, I see detailed changelog in commit, not in cover letter, so this
solves my previous comment.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From quic_qianyu at quicinc.com  Mon Aug 26 23:36:24 2024
From: quic_qianyu at quicinc.com (Qiang Yu)
Date: Mon, 26 Aug 2024 23:36:24 -0700
Subject: [PATCH 1/8] phy: qcom-qmp: pcs-pcie: Add v6.30 register offsets
In-Reply-To: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
References: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
Message-ID: <20240827063631.3932971-2-quic_qianyu@quicinc.com>

x1e80100 SoC uses QMP phy with version v6.30 for PCIe Gen4 x8. Add the new
PCS PCIE specific offsets in a dedicated header file.

Signed-off-by: Qiang Yu <quic_qianyu at quicinc.com>
---
 .../qualcomm/phy-qcom-qmp-pcs-pcie-v6_30.h    | 25 +++++++++++++++++++
 1 file changed, 25 insertions(+)
 create mode 100644 drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v6_30.h

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v6_30.h b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v6_30.h
new file mode 100644
index 000000000000..5a58ff197e6e
--- /dev/null
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v6_30.h
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2024 Qualcomm Innovation Center. All rights reserved.
+ */
+
+#ifndef QCOM_PHY_QMP_PCS_PCIE_V6_30_H_
+#define QCOM_PHY_QMP_PCS_PCIE_V6_30_H_
+
+/* Only for QMP V6_30 PHY - PCIE have different offsets than V6 */
+#define QPHY_PCIE_V6_30_PCS_POWER_STATE_CONFIG2		0x014
+#define QPHY_PCIE_V6_30_PCS_TX_RX_CONFIG		0x020
+#define QPHY_PCIE_V6_30_PCS_ENDPOINT_REFCLK_DRIVE	0x024
+#define QPHY_PCIE_V6_30_PCS_OSC_DTCT_ACTIONS		0x098
+#define QPHY_PCIE_V6_30_PCS_EQ_CONFIG1			0x0a8
+#define QPHY_PCIE_V6_30_PCS_G3_RXEQEVAL_TIME		0x0f8
+#define QPHY_PCIE_V6_30_PCS_G4_RXEQEVAL_TIME		0x0fc
+#define QPHY_PCIE_V6_30_PCS_G4_EQ_CONFIG5		0x110
+#define QPHY_PCIE_V6_30_PCS_G4_PRE_GAIN			0x164
+#define QPHY_PCIE_V6_30_PCS_RX_MARGINING_CONFIG1	0x184
+#define QPHY_PCIE_V6_30_PCS_RX_MARGINING_CONFIG3	0x18c
+#define QPHY_PCIE_V6_30_PCS_RX_MARGINING_CONFIG5	0x194
+#define QPHY_PCIE_V6_30_PCS_G3_FOM_EQ_CONFIG5		0x1b4
+#define QPHY_PCIE_V6_30_PCS_G4_FOM_EQ_CONFIG5		0x1c8
+
+#endif
-- 
2.34.1



From quic_qianyu at quicinc.com  Mon Aug 26 23:36:25 2024
From: quic_qianyu at quicinc.com (Qiang Yu)
Date: Mon, 26 Aug 2024 23:36:25 -0700
Subject: [PATCH 2/8] phy: qcom-qmp: pcs: Add v6.30 register offsets
In-Reply-To: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
References: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
Message-ID: <20240827063631.3932971-3-quic_qianyu@quicinc.com>

x1e80100 SoC uses QMP phy with version v6.30 for PCIe Gen4 x8. Add the new
PCS offsets in a dedicated header file.

Signed-off-by: Qiang Yu <quic_qianyu at quicinc.com>
---
 drivers/phy/qualcomm/phy-qcom-qmp-pcs-v6_30.h | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 drivers/phy/qualcomm/phy-qcom-qmp-pcs-v6_30.h

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcs-v6_30.h b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-v6_30.h
new file mode 100644
index 000000000000..9aa6d3622c24
--- /dev/null
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-v6_30.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2024 Qualcomm Innovation Center. All rights reserved.
+ */
+
+#ifndef QCOM_PHY_QMP_PCS_V6_30_H_
+#define QCOM_PHY_QMP_PCS_V6_30_H_
+
+/* Only for QMP V6_30 PHY - PCIe PCS registers */
+#define	QPHY_V6_30_PCS_LOCK_DETECT_CONFIG2		0x0cc
+#define	QPHY_V6_30_PCS_G3S2_PRE_GAIN			0x17c
+#define	QPHY_V6_30_PCS_RX_SIGDET_LVL			0x194
+#define	QPHY_V6_30_PCS_ALIGN_DETECT_CONFIG7		0x1dc
+#define	QPHY_V6_30_PCS_TX_RX_CONFIG			0x1e0
+#define	QPHY_V6_30_PCS_TX_RX_CONFIG2			0x1e4
+#define	QPHY_V6_30_PCS_EQ_CONFIG4			0x1fc
+#define	QPHY_V6_30_PCS_EQ_CONFIG5			0x200
+
+#endif
-- 
2.34.1



From quic_qianyu at quicinc.com  Mon Aug 26 23:36:23 2024
From: quic_qianyu at quicinc.com (Qiang Yu)
Date: Mon, 26 Aug 2024 23:36:23 -0700
Subject: [PATCH 0/8] Add support for PCIe3 on x1e80100
Message-ID: <20240827063631.3932971-1-quic_qianyu@quicinc.com>

This series add support for PCIe3 on x1e80100.

PCIe3 needs additional set of clocks, regulators and new set of PCIe QMP
PHY configuration compare other PCIe instances on x1e80100. Hence add
required resource configuration and usage for PCIe3.

Qiang Yu (8):
  phy: qcom-qmp: pcs-pcie: Add v6.30 register offsets
  phy: qcom-qmp: pcs: Add v6.30 register offsets
  phy: qcom: qmp: Add phy register and clk setting for x1e80100 PCIe3
  arm64: dts: qcom: x1e80100: Add support for PCIe3 on x1e80100
  dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Document the X1E80100
    QMP PCIe PHY Gen4 x8
  clk: qcom: gcc-x1e80100: Fix halt_check for pipediv2 clocks
  arm64: dts: qcom: x1e80100-qcp: Add power supply and sideband signal
    for pcie3
  PCI: qcom: Add support to PCIe slot power supplies

 .../phy/qcom,sc8280xp-qmp-pcie-phy.yaml       |  18 +-
 arch/arm64/boot/dts/qcom/x1e80100-qcp.dts     | 116 +++++++++
 arch/arm64/boot/dts/qcom/x1e80100.dtsi        | 205 +++++++++++++++-
 drivers/clk/qcom/gcc-x1e80100.c               |  10 +-
 drivers/pci/controller/dwc/pcie-qcom.c        |  52 +++-
 drivers/phy/qualcomm/phy-qcom-qmp-pcie.c      | 222 +++++++++++++++++-
 .../qualcomm/phy-qcom-qmp-pcs-pcie-v6_30.h    |  25 ++
 drivers/phy/qualcomm/phy-qcom-qmp-pcs-v6_30.h |  19 ++
 8 files changed, 657 insertions(+), 10 deletions(-)
 create mode 100644 drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v6_30.h
 create mode 100644 drivers/phy/qualcomm/phy-qcom-qmp-pcs-v6_30.h

-- 
2.34.1



From quic_qianyu at quicinc.com  Mon Aug 26 23:36:28 2024
From: quic_qianyu at quicinc.com (Qiang Yu)
Date: Mon, 26 Aug 2024 23:36:28 -0700
Subject: [PATCH 5/8] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Document the X1E80100 QMP PCIe PHY Gen4 x8
In-Reply-To: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
References: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
Message-ID: <20240827063631.3932971-6-quic_qianyu@quicinc.com>

PCIe 3rd instance of X1E80100 support Gen 4x8 which needs different 8 lane
capable QMP PCIe PHY. Document Gen 4x8 PHY as separate module.

Signed-off-by: Qiang Yu <quic_qianyu at quicinc.com>
---
 .../phy/qcom,sc8280xp-qmp-pcie-phy.yaml        | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
index 03dbd02cf9e7..e122657490b1 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
@@ -40,6 +40,7 @@ properties:
       - qcom,sm8650-qmp-gen4x2-pcie-phy
       - qcom,x1e80100-qmp-gen3x2-pcie-phy
       - qcom,x1e80100-qmp-gen4x2-pcie-phy
+      - qcom,x1e80100-qmp-gen4x8-pcie-phy
 
   reg:
     minItems: 1
@@ -47,7 +48,7 @@ properties:
 
   clocks:
     minItems: 5
-    maxItems: 7
+    maxItems: 8
 
   clock-names:
     minItems: 5
@@ -59,6 +60,7 @@ properties:
       - const: pipe
       - const: pipediv2
       - const: phy_aux
+      - const: clkref_en
 
   power-domains:
     maxItems: 1
@@ -190,6 +192,19 @@ allOf:
         clock-names:
           minItems: 7
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - qcom,x1e80100-qmp-gen4x8-pcie-phy
+    then:
+      properties:
+        clocks:
+          minItems: 8
+        clock-names:
+          minItems: 8
+
   - if:
       properties:
         compatible:
@@ -198,6 +213,7 @@ allOf:
               - qcom,sm8550-qmp-gen4x2-pcie-phy
               - qcom,sm8650-qmp-gen4x2-pcie-phy
               - qcom,x1e80100-qmp-gen4x2-pcie-phy
+              - qcom,x1e80100-qmp-gen4x8-pcie-phy
     then:
       properties:
         resets:
-- 
2.34.1



From quic_qianyu at quicinc.com  Mon Aug 26 23:36:31 2024
From: quic_qianyu at quicinc.com (Qiang Yu)
Date: Mon, 26 Aug 2024 23:36:31 -0700
Subject: [PATCH 8/8] PCI: qcom: Add support to PCIe slot power supplies
In-Reply-To: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
References: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
Message-ID: <20240827063631.3932971-9-quic_qianyu@quicinc.com>

On platform x1e80100 QCP, PCIe3 is a standard x8 form factor. Hence, add
support to use 3.3v, 3.3v aux and 12v regulators.

Signed-off-by: Qiang Yu <quic_qianyu at quicinc.com>
---
 drivers/pci/controller/dwc/pcie-qcom.c | 52 +++++++++++++++++++++++++-
 1 file changed, 50 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
index 6f953e32d990..59fb415dfeeb 100644
--- a/drivers/pci/controller/dwc/pcie-qcom.c
+++ b/drivers/pci/controller/dwc/pcie-qcom.c
@@ -248,6 +248,8 @@ struct qcom_pcie_cfg {
 	bool no_l0s;
 };
 
+#define QCOM_PCIE_SLOT_MAX_SUPPLIES			3
+
 struct qcom_pcie {
 	struct dw_pcie *pci;
 	void __iomem *parf;			/* DT parf */
@@ -260,6 +262,7 @@ struct qcom_pcie {
 	struct icc_path *icc_cpu;
 	const struct qcom_pcie_cfg *cfg;
 	struct dentry *debugfs;
+	struct regulator_bulk_data slot_supplies[QCOM_PCIE_SLOT_MAX_SUPPLIES];
 	bool suspended;
 	bool use_pm_opp;
 };
@@ -1174,6 +1177,41 @@ static int qcom_pcie_link_up(struct dw_pcie *pci)
 	return !!(val & PCI_EXP_LNKSTA_DLLLA);
 }
 
+static int qcom_pcie_enable_slot_supplies(struct qcom_pcie *pcie)
+{
+	struct dw_pcie *pci = pcie->pci;
+	int ret;
+
+	ret = regulator_bulk_enable(ARRAY_SIZE(pcie->slot_supplies),
+				    pcie->slot_supplies);
+	if (ret < 0)
+		dev_err(pci->dev, "Failed to enable slot regulators\n");
+
+	return ret;
+}
+
+static void qcom_pcie_disable_slot_supplies(struct qcom_pcie *pcie)
+{
+	regulator_bulk_disable(ARRAY_SIZE(pcie->slot_supplies),
+			       pcie->slot_supplies);
+}
+
+static int qcom_pcie_get_slot_supplies(struct qcom_pcie *pcie)
+{
+	struct dw_pcie *pci = pcie->pci;
+	int ret;
+
+	pcie->slot_supplies[0].supply = "vpcie12v";
+	pcie->slot_supplies[1].supply = "vpcie3v3";
+	pcie->slot_supplies[2].supply = "vpcie3v3aux";
+	ret = devm_regulator_bulk_get(pci->dev, ARRAY_SIZE(pcie->slot_supplies),
+				      pcie->slot_supplies);
+	if (ret < 0)
+		dev_err(pci->dev, "Failed to get slot regulators\n");
+
+	return ret;
+}
+
 static int qcom_pcie_host_init(struct dw_pcie_rp *pp)
 {
 	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
@@ -1182,10 +1220,14 @@ static int qcom_pcie_host_init(struct dw_pcie_rp *pp)
 
 	qcom_ep_reset_assert(pcie);
 
-	ret = pcie->cfg->ops->init(pcie);
+	ret = qcom_pcie_enable_slot_supplies(pcie);
 	if (ret)
 		return ret;
 
+	ret = pcie->cfg->ops->init(pcie);
+	if (ret)
+		goto err_disable_slot;
+
 	ret = phy_set_mode_ext(pcie->phy, PHY_MODE_PCIE, PHY_MODE_PCIE_RC);
 	if (ret)
 		goto err_deinit;
@@ -1216,7 +1258,8 @@ static int qcom_pcie_host_init(struct dw_pcie_rp *pp)
 	phy_power_off(pcie->phy);
 err_deinit:
 	pcie->cfg->ops->deinit(pcie);
-
+err_disable_slot:
+	qcom_pcie_disable_slot_supplies(pcie);
 	return ret;
 }
 
@@ -1228,6 +1271,7 @@ static void qcom_pcie_host_deinit(struct dw_pcie_rp *pp)
 	qcom_ep_reset_assert(pcie);
 	phy_power_off(pcie->phy);
 	pcie->cfg->ops->deinit(pcie);
+	qcom_pcie_disable_slot_supplies(pcie);
 }
 
 static void qcom_pcie_host_post_init(struct dw_pcie_rp *pp)
@@ -1602,6 +1646,10 @@ static int qcom_pcie_probe(struct platform_device *pdev)
 			goto err_pm_runtime_put;
 	}
 
+	ret = qcom_pcie_get_slot_supplies(pcie);
+	if (ret)
+		goto err_pm_runtime_put;
+
 	ret = pcie->cfg->ops->get_resources(pcie);
 	if (ret)
 		goto err_pm_runtime_put;
-- 
2.34.1



From quic_qianyu at quicinc.com  Mon Aug 26 23:36:26 2024
From: quic_qianyu at quicinc.com (Qiang Yu)
Date: Mon, 26 Aug 2024 23:36:26 -0700
Subject: [PATCH 3/8] phy: qcom: qmp: Add phy register and clk setting for x1e80100 PCIe3
In-Reply-To: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
References: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
Message-ID: <20240827063631.3932971-4-quic_qianyu@quicinc.com>

Currently driver supports only x4 lane based functionality using tx/rx and
tx2/rx2 pair of register sets. To support 8 lane functionality with PCIe3,
PCIe3 related QMP PHY provides additional programming which are available
as txz and rxz based register set. Hence adds txz and rxz based registers
usage and programming sequences. Phy register setting for txz and rxz will
be applied to all 8 lanes. Some lanes may have different settings on
several registers than txz/rxz, these registers should be programmed after
txz/rxz programming sequences completing.

Besides, PCIe3 related QMP PHY also requires addtional clk, which is named
as clkref_en. Hence, add this clk into qmp_pciephy_clk_l so that it can be
easily parsed from devicetree during init.

Signed-off-by: Qiang Yu <quic_qianyu at quicinc.com>
---
 drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 222 ++++++++++++++++++++++-
 1 file changed, 221 insertions(+), 1 deletion(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
index 4b4a10f7f6d6..17ee30e04aea 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
@@ -34,6 +34,8 @@
 #include "phy-qcom-qmp-pcs-pcie-v5_20.h"
 #include "phy-qcom-qmp-pcs-pcie-v6.h"
 #include "phy-qcom-qmp-pcs-pcie-v6_20.h"
+#include "phy-qcom-qmp-pcs-pcie-v6_30.h"
+#include "phy-qcom-qmp-pcs-v6_30.h"
 #include "phy-qcom-qmp-pcie-qhp.h"
 
 #define PHY_INIT_COMPLETE_TIMEOUT		10000
@@ -1340,6 +1342,155 @@ static const struct qmp_phy_init_tbl x1e80100_qmp_gen4x2_pcie_pcs_misc_tbl[] = {
 	QMP_PHY_INIT_CFG(QPHY_PCIE_V6_20_PCS_G4_FOM_EQ_CONFIG5, 0x8a),
 };
 
+static const struct qmp_phy_init_tbl x1e80100_qmp_gen4x8_pcie_txz_tbl[] = {
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_TX_RES_CODE_LANE_OFFSET_TX, 0x1a),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_TX_RES_CODE_LANE_OFFSET_RX, 0x05),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_TX_LANE_MODE_1, 0x01),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_TX_LANE_MODE_2, 0x10),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_TX_LANE_MODE_3, 0x51),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_TX_TRAN_DRVR_EMP_EN, 0x34),
+};
+
+static const struct qmp_phy_init_tbl x1e80100_qmp_gen4x8_pcie_rxz_tbl[] = {
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_UCDR_FO_GAIN_RATE_2, 0x0c),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_UCDR_SO_GAIN_RATE_2, 0x04),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_UCDR_FO_GAIN_RATE_3, 0x0a),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_UCDR_PI_CONTROLS, 0x16),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_UCDR_SO_ACC_DEFAULT_VAL_RATE3, 0x00),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_IVCM_CAL_CTRL2, 0x80),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_IVCM_POSTCAL_OFFSET, 0x00),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_BKUP_CTRL1, 0x15),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_DFE_3, 0x45),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_VGA_CAL_MAN_VAL, 0x0c),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_VGA_CAL_CNTRL1, 0x00),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_GM_CAL, 0x0d),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_EQU_ADAPTOR_CNTRL4, 0x0b),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_SIGDET_ENABLES, 0x1c),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_PHPRE_CTRL, 0x20),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_DFE_CTLE_POST_CAL_OFFSET, 0x38),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_Q_PI_INTRINSIC_BIAS_RATE32, 0x39),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_MODE_RATE2_B0, 0xd4),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_MODE_RATE2_B1, 0x23),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_MODE_RATE2_B2, 0x58),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_MODE_RATE2_B3, 0x9a),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_MODE_RATE2_B4, 0x38),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_MODE_RATE2_B5, 0xb6),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_MODE_RATE2_B6, 0xee),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_MODE_RATE3_B0, 0x1c),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_MODE_RATE3_B1, 0xe4),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_MODE_RATE3_B2, 0x60),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_MODE_RATE3_B3, 0xdf),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_MODE_RATE3_B4, 0x69),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_MODE_RATE3_B5, 0x76),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_MODE_RATE3_B6, 0xff),
+	QMP_PHY_INIT_CFG(QSERDES_V6_20_RX_TX_ADPT_CTRL, 0x10),
+};
+
+static const struct qmp_phy_init_tbl x1e80100_qmp_gen4x8_pcie_rx_tbl[] = {
+	QMP_PHY_INIT_CFG_LANE(QSERDES_V6_20_RX_DFE_CTLE_POST_CAL_OFFSET, 0x3a, 1),
+};
+
+static const struct qmp_phy_init_tbl x1e80100_qmp_gen4x8_pcie_ln_shrd_tbl[] = {
+	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RXCLK_DIV2_CTRL, 0x01),
+	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_SUMMER_CAL_SPD_MODE, 0x5b),
+	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_DFE_DAC_ENABLE1, 0x88),
+	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_TX_ADAPT_POST_THRESH1, 0x02),
+	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_TX_ADAPT_POST_THRESH2, 0x0d),
+	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MODE_RATE_0_1_B0, 0x12),
+	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MODE_RATE_0_1_B1, 0x12),
+	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MODE_RATE_0_1_B2, 0xdb),
+	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MODE_RATE_0_1_B3, 0x9a),
+	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MODE_RATE_0_1_B4, 0x38),
+	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MODE_RATE_0_1_B5, 0xb6),
+	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MODE_RATE_0_1_B6, 0x64),
+	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MARG_COARSE_THRESH1_RATE210, 0x1f),
+	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MARG_COARSE_THRESH1_RATE3, 0x1f),
+	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MARG_COARSE_THRESH2_RATE210, 0x1f),
+	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MARG_COARSE_THRESH2_RATE3, 0x1f),
+	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MARG_COARSE_THRESH3_RATE210, 0x1f),
+	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MARG_COARSE_THRESH3_RATE3, 0x1f),
+	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MARG_COARSE_THRESH4_RATE3, 0x1f),
+	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MARG_COARSE_THRESH5_RATE3, 0x1f),
+	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MARG_COARSE_THRESH6_RATE3, 0x1f),
+};
+
+static const struct qmp_phy_init_tbl x1e80100_qmp_gen4x8_pcie_serdes_tbl[] = {
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_SSC_STEP_SIZE1_MODE1, 0x26),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_SSC_STEP_SIZE2_MODE1, 0x03),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_CP_CTRL_MODE1, 0x06),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_RCTRL_MODE1, 0x16),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_CCTRL_MODE1, 0x36),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_CORECLK_DIV_MODE1, 0x08),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP1_MODE1, 0x04),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP2_MODE1, 0x0d),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_DEC_START_MODE1, 0x68),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_DIV_FRAC_START1_MODE1, 0xab),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_DIV_FRAC_START2_MODE1, 0xaa),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_DIV_FRAC_START3_MODE1, 0x02),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_HSCLK_SEL_1, 0x12),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_SSC_STEP_SIZE1_MODE0, 0xf8),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_SSC_STEP_SIZE2_MODE0, 0x01),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_CP_CTRL_MODE0, 0x06),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_RCTRL_MODE0, 0x16),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_CCTRL_MODE0, 0x36),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_CORE_CLK_DIV_MODE0, 0x0a),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP1_MODE0, 0x04),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP2_MODE0, 0x0d),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_DEC_START_MODE0, 0x41),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_DIV_FRAC_START1_MODE0, 0xab),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_DIV_FRAC_START2_MODE0, 0xaa),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_DIV_FRAC_START3_MODE0, 0x01),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_HSCLK_HS_SWITCH_SEL_1, 0x00),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_BG_TIMER, 0x0a),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_SSC_EN_CENTER, 0x01),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_SSC_PER1, 0x62),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_SSC_PER2, 0x02),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_POST_DIV_MUX, 0x40),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_BIAS_EN_CLK_BUFLR_EN, 0x1c),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_CLK_ENABLE1, 0x90),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_SYS_CLK_CTRL, 0x82),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_IVCO, 0x0f),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_SYSCLK_EN_SEL, 0x08),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP_EN, 0x46),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP_CFG, 0x04),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_VCO_TUNE_MAP, 0x14),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_CLK_SELECT, 0x34),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_CORE_CLK_EN, 0x20),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_CMN_CONFIG_1, 0x06),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_CMN_MISC_1, 0x88),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_CMN_MODE, 0x14),
+	QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_VCO_DC_LEVEL_CTRL, 0x0f),
+};
+
+static const struct qmp_phy_init_tbl x1e80100_qmp_gen4x8_pcie_pcs_tbl[] = {
+	QMP_PHY_INIT_CFG(QPHY_V6_30_PCS_LOCK_DETECT_CONFIG2, 0x00),
+	QMP_PHY_INIT_CFG(QPHY_V6_30_PCS_G3S2_PRE_GAIN, 0x2e),
+	QMP_PHY_INIT_CFG(QPHY_V6_30_PCS_RX_SIGDET_LVL, 0x99),
+	QMP_PHY_INIT_CFG(QPHY_V6_30_PCS_ALIGN_DETECT_CONFIG7, 0x00),
+	QMP_PHY_INIT_CFG(QPHY_V6_30_PCS_EQ_CONFIG4, 0x00),
+	QMP_PHY_INIT_CFG(QPHY_V6_30_PCS_EQ_CONFIG5, 0x22),
+	QMP_PHY_INIT_CFG(QPHY_V6_30_PCS_TX_RX_CONFIG, 0x04),
+	QMP_PHY_INIT_CFG(QPHY_V6_30_PCS_TX_RX_CONFIG2, 0x02),
+};
+
+static const struct qmp_phy_init_tbl x1e80100_qmp_gen4x8_pcie_pcs_misc_tbl[] = {
+	QMP_PHY_INIT_CFG(QPHY_PCIE_V6_30_PCS_ENDPOINT_REFCLK_DRIVE, 0xc1),
+	QMP_PHY_INIT_CFG(QPHY_PCIE_V6_30_PCS_OSC_DTCT_ACTIONS, 0x00),
+	QMP_PHY_INIT_CFG(QPHY_PCIE_V6_30_PCS_EQ_CONFIG1, 0x16),
+	QMP_PHY_INIT_CFG(QPHY_PCIE_V6_30_PCS_G4_EQ_CONFIG5, 0x02),
+	QMP_PHY_INIT_CFG(QPHY_PCIE_V6_30_PCS_G4_PRE_GAIN, 0x2e),
+	QMP_PHY_INIT_CFG(QPHY_PCIE_V6_30_PCS_RX_MARGINING_CONFIG1, 0x03),
+	QMP_PHY_INIT_CFG(QPHY_PCIE_V6_30_PCS_RX_MARGINING_CONFIG3, 0x28),
+	QMP_PHY_INIT_CFG(QPHY_PCIE_V6_30_PCS_RX_MARGINING_CONFIG5, 0x18),
+	QMP_PHY_INIT_CFG(QPHY_PCIE_V6_30_PCS_G3_FOM_EQ_CONFIG5, 0x7a),
+	QMP_PHY_INIT_CFG(QPHY_PCIE_V6_30_PCS_G4_FOM_EQ_CONFIG5, 0x8a),
+	QMP_PHY_INIT_CFG(QPHY_PCIE_V6_30_PCS_G3_RXEQEVAL_TIME, 0x27),
+	QMP_PHY_INIT_CFG(QPHY_PCIE_V6_30_PCS_G4_RXEQEVAL_TIME, 0x27),
+	QMP_PHY_INIT_CFG(QPHY_PCIE_V6_30_PCS_TX_RX_CONFIG, 0xc0),
+	QMP_PHY_INIT_CFG(QPHY_PCIE_V6_30_PCS_POWER_STATE_CONFIG2, 0x1d),
+
+};
+
 static const struct qmp_phy_init_tbl sm8250_qmp_pcie_serdes_tbl[] = {
 	QMP_PHY_INIT_CFG(QSERDES_V4_COM_SYSCLK_EN_SEL, 0x08),
 	QMP_PHY_INIT_CFG(QSERDES_V4_COM_CLK_SELECT, 0x34),
@@ -2578,6 +2729,8 @@ struct qmp_pcie_offsets {
 	u16 rx;
 	u16 tx2;
 	u16 rx2;
+	u16 txz;
+	u16 rxz;
 	u16 ln_shrd;
 };
 
@@ -2588,6 +2741,10 @@ struct qmp_phy_cfg_tbls {
 	int tx_num;
 	const struct qmp_phy_init_tbl *rx;
 	int rx_num;
+	const struct qmp_phy_init_tbl *txz;
+	int txz_num;
+	const struct qmp_phy_init_tbl *rxz;
+	int rxz_num;
 	const struct qmp_phy_init_tbl *pcs;
 	int pcs_num;
 	const struct qmp_phy_init_tbl *pcs_misc;
@@ -2617,6 +2774,9 @@ struct qmp_phy_cfg {
 	const struct qmp_phy_init_tbl *serdes_4ln_tbl;
 	int serdes_4ln_num;
 
+	/* Set to true for programming all 8 lanes using txz/rxz registers */
+	bool lane_broadcasting;
+
 	/* resets to be requested */
 	const char * const *reset_list;
 	int num_resets;
@@ -2655,6 +2815,8 @@ struct qmp_pcie {
 	void __iomem *rx;
 	void __iomem *tx2;
 	void __iomem *rx2;
+	void __iomem *txz;
+	void __iomem *rxz;
 	void __iomem *ln_shrd;
 
 	void __iomem *port_b;
@@ -2700,7 +2862,7 @@ static inline void qphy_clrbits(void __iomem *base, u32 offset, u32 val)
 
 /* list of clocks required by phy */
 static const char * const qmp_pciephy_clk_l[] = {
-	"aux", "cfg_ahb", "ref", "refgen", "rchng", "phy_aux",
+	"aux", "cfg_ahb", "ref", "refgen", "rchng", "phy_aux", "clkref_en",
 };
 
 /* list of regulators */
@@ -2822,6 +2984,17 @@ static const struct qmp_pcie_offsets qmp_pcie_offsets_v6_20 = {
 	.ln_shrd	= 0x0e00,
 };
 
+static const struct qmp_pcie_offsets qmp_pcie_offsets_v6_30 = {
+	.serdes		= 0x8800,
+	.pcs		= 0x9000,
+	.pcs_misc	= 0x9800,
+	.tx		= 0x0000,
+	.rx		= 0x0200,
+	.txz		= 0xe000,
+	.rxz		= 0xe200,
+	.ln_shrd	= 0x8000,
+};
+
 static const struct qmp_phy_cfg ipq8074_pciephy_cfg = {
 	.lanes			= 1,
 
@@ -3665,6 +3838,40 @@ static const struct qmp_phy_cfg x1e80100_qmp_gen4x2_pciephy_cfg = {
 	.has_nocsr_reset	= true,
 };
 
+static const struct qmp_phy_cfg x1e80100_qmp_gen4x8_pciephy_cfg = {
+	.lanes = 8,
+
+	.offsets		= &qmp_pcie_offsets_v6_30,
+	.tbls = {
+		.serdes			= x1e80100_qmp_gen4x8_pcie_serdes_tbl,
+		.serdes_num		= ARRAY_SIZE(x1e80100_qmp_gen4x8_pcie_serdes_tbl),
+		.rx			= x1e80100_qmp_gen4x8_pcie_rx_tbl,
+		.rx_num			= ARRAY_SIZE(x1e80100_qmp_gen4x8_pcie_rx_tbl),
+		.pcs			= x1e80100_qmp_gen4x8_pcie_pcs_tbl,
+		.pcs_num		= ARRAY_SIZE(x1e80100_qmp_gen4x8_pcie_pcs_tbl),
+		.pcs_misc		= x1e80100_qmp_gen4x8_pcie_pcs_misc_tbl,
+		.pcs_misc_num		= ARRAY_SIZE(x1e80100_qmp_gen4x8_pcie_pcs_misc_tbl),
+		.ln_shrd		= x1e80100_qmp_gen4x8_pcie_ln_shrd_tbl,
+		.ln_shrd_num		= ARRAY_SIZE(x1e80100_qmp_gen4x8_pcie_ln_shrd_tbl),
+		.txz			= x1e80100_qmp_gen4x8_pcie_txz_tbl,
+		.txz_num		= ARRAY_SIZE(x1e80100_qmp_gen4x8_pcie_txz_tbl),
+		.rxz			= x1e80100_qmp_gen4x8_pcie_rxz_tbl,
+		.rxz_num		= ARRAY_SIZE(x1e80100_qmp_gen4x8_pcie_rxz_tbl),
+	},
+
+	.lane_broadcasting      = true,
+
+	.reset_list		= sdm845_pciephy_reset_l,
+	.num_resets		= ARRAY_SIZE(sdm845_pciephy_reset_l),
+	.vreg_list		= sm8550_qmp_phy_vreg_l,
+	.num_vregs		= ARRAY_SIZE(sm8550_qmp_phy_vreg_l),
+	.regs			= pciephy_v6_regs_layout,
+
+	.pwrdn_ctrl		= SW_PWRDN | REFCLK_DRV_DSBL,
+	.phy_status		= PHYSTATUS_4_20,
+	.has_nocsr_reset	= true,
+};
+
 static void qmp_pcie_init_port_b(struct qmp_pcie *qmp, const struct qmp_phy_cfg_tbls *tbls)
 {
 	const struct qmp_phy_cfg *cfg = qmp->cfg;
@@ -3700,6 +3907,11 @@ static void qmp_pcie_init_registers(struct qmp_pcie *qmp, const struct qmp_phy_c
 
 	qmp_configure(qmp->dev, serdes, tbls->serdes, tbls->serdes_num);
 
+	if (cfg->lane_broadcasting) {
+		qmp_configure(qmp->dev, qmp->txz, tbls->txz, tbls->txz_num);
+		qmp_configure(qmp->dev, qmp->rxz, tbls->rxz, tbls->rxz_num);
+	}
+
 	qmp_configure_lane(qmp->dev, tx, tbls->tx, tbls->tx_num, 1);
 	qmp_configure_lane(qmp->dev, rx, tbls->rx, tbls->rx_num, 1);
 
@@ -4242,6 +4454,11 @@ static int qmp_pcie_parse_dt(struct qmp_pcie *qmp)
 			return PTR_ERR(qmp->port_b);
 	}
 
+	if (cfg->lane_broadcasting) {
+		qmp->txz = base + offs->txz;
+		qmp->rxz = base + offs->rxz;
+	}
+
 	if (cfg->tbls.ln_shrd)
 		qmp->ln_shrd = base + offs->ln_shrd;
 
@@ -4424,6 +4641,9 @@ static const struct of_device_id qmp_pcie_of_match_table[] = {
 	}, {
 		.compatible = "qcom,x1e80100-qmp-gen4x2-pcie-phy",
 		.data = &x1e80100_qmp_gen4x2_pciephy_cfg,
+	}, {
+		.compatible = "qcom,x1e80100-qmp-gen4x8-pcie-phy",
+		.data = &x1e80100_qmp_gen4x8_pciephy_cfg,
 	},
 	{ },
 };
-- 
2.34.1



From quic_qianyu at quicinc.com  Mon Aug 26 23:36:29 2024
From: quic_qianyu at quicinc.com (Qiang Yu)
Date: Mon, 26 Aug 2024 23:36:29 -0700
Subject: [PATCH 6/8] clk: qcom: gcc-x1e80100: Fix halt_check for pipediv2 clocks
In-Reply-To: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
References: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
Message-ID: <20240827063631.3932971-7-quic_qianyu@quicinc.com>

The pipediv2_clk's source from the same mux as pipe clock. So they have
same limitation, which is that the PHY sequence requires to enable these
local CBCs before the PHY is actually outputting a clock to them. This
means the clock won't actually turn on when we vote them. Hence, let's
skip the halt bit check of the pipediv2_clk, otherwise pipediv2_clk may
stuck at off state during bootup.

Suggested-by: Mike Tipton <quic_mdtipton at quicinc.com>
Signed-off-by: Qiang Yu <quic_qianyu at quicinc.com>
---
 drivers/clk/qcom/gcc-x1e80100.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/qcom/gcc-x1e80100.c b/drivers/clk/qcom/gcc-x1e80100.c
index 80e90e31be33..ad35a8c37ca8 100644
--- a/drivers/clk/qcom/gcc-x1e80100.c
+++ b/drivers/clk/qcom/gcc-x1e80100.c
@@ -3123,7 +3123,7 @@ static struct clk_branch gcc_pcie_3_pipe_clk = {
 
 static struct clk_branch gcc_pcie_3_pipediv2_clk = {
 	.halt_reg = 0x58060,
-	.halt_check = BRANCH_HALT_VOTED,
+	.halt_check = BRANCH_HALT_SKIP,
 	.clkr = {
 		.enable_reg = 0x52020,
 		.enable_mask = BIT(5),
@@ -3248,7 +3248,7 @@ static struct clk_branch gcc_pcie_4_pipe_clk = {
 
 static struct clk_branch gcc_pcie_4_pipediv2_clk = {
 	.halt_reg = 0x6b054,
-	.halt_check = BRANCH_HALT_VOTED,
+	.halt_check = BRANCH_HALT_SKIP,
 	.clkr = {
 		.enable_reg = 0x52010,
 		.enable_mask = BIT(27),
@@ -3373,7 +3373,7 @@ static struct clk_branch gcc_pcie_5_pipe_clk = {
 
 static struct clk_branch gcc_pcie_5_pipediv2_clk = {
 	.halt_reg = 0x2f054,
-	.halt_check = BRANCH_HALT_VOTED,
+	.halt_check = BRANCH_HALT_SKIP,
 	.clkr = {
 		.enable_reg = 0x52018,
 		.enable_mask = BIT(19),
@@ -3511,7 +3511,7 @@ static struct clk_branch gcc_pcie_6a_pipe_clk = {
 
 static struct clk_branch gcc_pcie_6a_pipediv2_clk = {
 	.halt_reg = 0x31060,
-	.halt_check = BRANCH_HALT_VOTED,
+	.halt_check = BRANCH_HALT_SKIP,
 	.clkr = {
 		.enable_reg = 0x52018,
 		.enable_mask = BIT(28),
@@ -3649,7 +3649,7 @@ static struct clk_branch gcc_pcie_6b_pipe_clk = {
 
 static struct clk_branch gcc_pcie_6b_pipediv2_clk = {
 	.halt_reg = 0x8d060,
-	.halt_check = BRANCH_HALT_VOTED,
+	.halt_check = BRANCH_HALT_SKIP,
 	.clkr = {
 		.enable_reg = 0x52010,
 		.enable_mask = BIT(28),
-- 
2.34.1



From quic_qianyu at quicinc.com  Mon Aug 26 23:36:27 2024
From: quic_qianyu at quicinc.com (Qiang Yu)
Date: Mon, 26 Aug 2024 23:36:27 -0700
Subject: [PATCH 4/8] arm64: dts: qcom: x1e80100: Add support for PCIe3 on x1e80100
In-Reply-To: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
References: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
Message-ID: <20240827063631.3932971-5-quic_qianyu@quicinc.com>

Describe PCIe3 controller and PHY. Also add required system resources like
regulators, clocks, interrupts and registers configuration for PCIe3.

Signed-off-by: Qiang Yu <quic_qianyu at quicinc.com>
---
 arch/arm64/boot/dts/qcom/x1e80100.dtsi | 205 ++++++++++++++++++++++++-
 1 file changed, 204 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
index 74b694e74705..55b81e7de1c7 100644
--- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
@@ -744,7 +744,7 @@ gcc: clock-controller at 100000 {
 
 			clocks = <&bi_tcxo_div2>,
 				 <&sleep_clk>,
-				 <0>,
+				 <&pcie3_phy>,
 				 <&pcie4_phy>,
 				 <&pcie5_phy>,
 				 <&pcie6a_phy>,
@@ -2879,6 +2879,209 @@ mmss_noc: interconnect at 1780000 {
 			#interconnect-cells = <2>;
 		};
 
+		pcie3: pci at 1bd0000 {
+			device_type = "pci";
+			compatible = "qcom,pcie-x1e80100";
+			reg = <0 0x01bd0000 0 0x3000>,
+			      <0 0x78000000 0 0xf1d>,
+			      <0 0x78000f40 0 0xa8>,
+			      <0 0x78001000 0 0x1000>,
+			      <0 0x78100000 0 0x100000>;
+			reg-names = "parf",
+				    "dbi",
+				    "elbi",
+				    "atu",
+				    "config";
+			#address-cells = <3>;
+			#size-cells = <2>;
+			ranges = <0x01000000 0 0x00000000 0 0x78200000 0 0x100000>,
+				 <0x02000000 0 0x78300000 0 0x78300000 0 0x3d00000>;
+			bus-range = <0 0xff>;
+
+			dma-coherent;
+
+			linux,pci-domain = <3>;
+			num-lanes = <8>;
+
+			interrupts = <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 769 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 836 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 671 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "msi0",
+					  "msi1",
+					  "msi2",
+					  "msi3",
+					  "msi4",
+					  "msi5",
+					  "msi6",
+					  "msi7";
+
+			#interrupt-cells = <1>;
+			interrupt-map-mask = <0 0 0 0x7>;
+			interrupt-map = <0 0 0 1 &intc 0 0 0 220 IRQ_TYPE_LEVEL_HIGH>,
+					<0 0 0 2 &intc 0 0 0 221 IRQ_TYPE_LEVEL_HIGH>,
+					<0 0 0 3 &intc 0 0 0 237 IRQ_TYPE_LEVEL_HIGH>,
+					<0 0 0 4 &intc 0 0 0 238 IRQ_TYPE_LEVEL_HIGH>;
+
+			clocks = <&gcc GCC_PCIE_3_PIPE_CLK_SRC>,
+				 <&gcc GCC_PCIE_3_AUX_CLK>,
+				 <&gcc GCC_PCIE_3_CFG_AHB_CLK>,
+				 <&gcc GCC_PCIE_3_MSTR_AXI_CLK>,
+				 <&gcc GCC_PCIE_3_SLV_AXI_CLK>,
+				 <&gcc GCC_PCIE_3_SLV_Q2A_AXI_CLK>,
+				 <&gcc GCC_CFG_NOC_PCIE_ANOC_SOUTH_AHB_CLK>,
+				 <&gcc GCC_CNOC_PCIE_NORTH_SF_AXI_CLK>;
+			clock-names = "pipe_clk_src",
+				      "aux",
+				      "cfg",
+				      "bus_master",
+				      "bus_slave",
+				      "slave_q2a",
+				      "noc_aggr",
+				      "cnoc_sf_axi";
+
+			assigned-clocks = <&gcc GCC_PCIE_3_AUX_CLK>;
+			assigned-clock-rates = <19200000>;
+
+			interconnects = <&pcie_south_anoc MASTER_PCIE_3 QCOM_ICC_TAG_ALWAYS
+					 &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
+					<&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ALWAYS
+					 &cnoc_main SLAVE_PCIE_3 QCOM_ICC_TAG_ALWAYS>;
+			interconnect-names = "pcie-mem",
+					     "cpu-pcie";
+
+			resets = <&gcc GCC_PCIE_3_BCR>,
+				 <&gcc GCC_PCIE_3_LINK_DOWN_BCR>;
+			reset-names = "pci",
+				      "link_down";
+
+			power-domains = <&gcc GCC_PCIE_3_GDSC>;
+
+			phys = <&pcie3_phy>;
+			phy-names = "pciephy";
+
+			operating-points-v2 = <&pcie3_opp_table>;
+
+			status = "disabled";
+
+			pcie3_opp_table: opp-table {
+				compatible = "operating-points-v2";
+
+				/* GEN 1 x1 */
+				opp-2500000 {
+					opp-hz = /bits/ 64 <2500000>;
+					required-opps = <&rpmhpd_opp_low_svs>;
+					opp-peak-kBps = <250000 1>;
+				};
+
+				/* GEN 1 x2 and GEN 2 x1 */
+				opp-5000000 {
+					opp-hz = /bits/ 64 <5000000>;
+					required-opps = <&rpmhpd_opp_low_svs>;
+					opp-peak-kBps = <500000 1>;
+				};
+
+				/* GEN 1 x4 and GEN 2 x2*/
+				opp-10000000 {
+					opp-hz = /bits/ 64 <10000000>;
+					required-opps = <&rpmhpd_opp_low_svs>;
+					opp-peak-kBps = <1000000 1>;
+				};
+
+				/* GEN 1 x8 and GEN 2 X4 */
+				opp-20000000 {
+					opp-hz = /bits/ 64 <20000000>;
+					required-opps = <&rpmhpd_opp_low_svs>;
+					opp-peak-kBps = <2000000 1>;
+				};
+
+				/* GEN 2 x8 */
+				opp-40000000 {
+					opp-hz = /bits/ 64 <40000000>;
+					required-opps = <&rpmhpd_opp_low_svs>;
+					opp-peak-kBps = <4000000 1>;
+				};
+
+				/* GEN 3 x1 */
+				opp-8000000 {
+					opp-hz = /bits/ 64 <8000000>;
+					required-opps = <&rpmhpd_opp_svs>;
+					opp-peak-kBps = <984500 1>;
+				};
+
+				/* GEN 3 x2 and GEN 4 x1 */
+				opp-16000000 {
+					opp-hz = /bits/ 64 <16000000>;
+					required-opps = <&rpmhpd_opp_svs>;
+					opp-peak-kBps = <1969000 1>;
+				};
+
+				/* GEN 3 x4 and GEN 4 x2 */
+				opp-32000000 {
+					opp-hz = /bits/ 64 <32000000>;
+					required-opps = <&rpmhpd_opp_svs>;
+					opp-peak-kBps = <3938000 1>;
+				};
+
+				/* GEN 3 x8 and GEN 4 x4 */
+				opp-64000000 {
+					opp-hz = /bits/ 64 <64000000>;
+					required-opps = <&rpmhpd_opp_svs>;
+					opp-peak-kBps = <7876000 1>;
+				};
+
+				/* GEN 4 x8 */
+				opp-128000000 {
+					opp-hz = /bits/ 64 <128000000>;
+					required-opps = <&rpmhpd_opp_svs>;
+					opp-peak-kBps = <15753000 1>;
+				};
+			};
+		};
+
+		pcie3_phy: phy at 1be0000 {
+			compatible = "qcom,x1e80100-qmp-gen4x8-pcie-phy";
+			reg = <0 0x01be0000 0 0x10000>;
+
+			clocks = <&gcc GCC_PCIE_3_AUX_CLK>,
+				 <&gcc GCC_PCIE_3_CFG_AHB_CLK>,
+				 <&rpmhcc RPMH_CXO_CLK>,
+				 <&gcc GCC_PCIE_3_PHY_RCHNG_CLK>,
+				 <&gcc GCC_PCIE_3_PHY_AUX_CLK>,
+				 <&gcc GCC_PCIE_3_PIPE_CLK>,
+				 <&gcc GCC_PCIE_3_PIPEDIV2_CLK>,
+				 <&tcsr TCSR_PCIE_8L_CLKREF_EN>;
+			clock-names = "aux",
+				      "cfg_ahb",
+				      "ref",
+				      "rchng",
+				      "phy_aux",
+				      "pipe",
+				      "pipediv2",
+				      "clkref_en";
+
+			resets = <&gcc GCC_PCIE_3_PHY_BCR>,
+				 <&gcc GCC_PCIE_3_NOCSR_COM_PHY_BCR>;
+			reset-names = "phy",
+				      "phy_nocsr";
+
+			assigned-clocks = <&gcc GCC_PCIE_3_PHY_RCHNG_CLK>;
+			assigned-clock-rates = <100000000>;
+
+			power-domains = <&gcc GCC_PCIE_3_PHY_GDSC>;
+
+			#clock-cells = <0>;
+			clock-output-names = "pcie3_pipe_clk";
+
+			#phy-cells = <0>;
+
+			status = "disabled";
+		};
+
 		pcie6a: pci at 1bf8000 {
 			device_type = "pci";
 			compatible = "qcom,pcie-x1e80100";
-- 
2.34.1



From quic_qianyu at quicinc.com  Mon Aug 26 23:36:30 2024
From: quic_qianyu at quicinc.com (Qiang Yu)
Date: Mon, 26 Aug 2024 23:36:30 -0700
Subject: [PATCH 7/8] arm64: dts: qcom: x1e80100-qcp: Add power supply and sideband signal for pcie3
In-Reply-To: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
References: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
Message-ID: <20240827063631.3932971-8-quic_qianyu@quicinc.com>

Add perst, wake and clkreq gpio config. Add required power supply.

Signed-off-by: Qiang Yu <quic_qianyu at quicinc.com>
---
 arch/arm64/boot/dts/qcom/x1e80100-qcp.dts | 116 ++++++++++++++++++++++
 1 file changed, 116 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/x1e80100-qcp.dts b/arch/arm64/boot/dts/qcom/x1e80100-qcp.dts
index 1c3a6a7b3ed6..0deb0c4bfea9 100644
--- a/arch/arm64/boot/dts/qcom/x1e80100-qcp.dts
+++ b/arch/arm64/boot/dts/qcom/x1e80100-qcp.dts
@@ -254,6 +254,48 @@ vreg_nvme: regulator-nvme {
 		pinctrl-names = "default";
 		pinctrl-0 = <&nvme_reg_en>;
 	};
+
+	vreg_pcie_12v: regulator-pcie_12v {
+		compatible = "regulator-fixed";
+
+		regulator-name = "VREG_PCIE_12V";
+		regulator-min-microvolt = <12000000>;
+		regulator-max-microvolt = <12000000>;
+
+		gpio = <&pm8550ve_8_gpios 8 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&pcie_x8_12v>;
+	};
+
+	vreg_pcie_3v3_aux: regulator-pcie_3v3_aux {
+		compatible = "regulator-fixed";
+
+		regulator-name = "VREG_PCIE_3P3_AUX";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+
+		gpio = <&pmc8380_3_gpios 8 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&pm_sde7_aux_3p3_en>;
+	};
+
+	vreg_pcie_3v3: regulator-pcie_3v3 {
+		compatible = "regulator-fixed";
+
+		regulator-name = "VREG_PCIE_3P3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+
+		gpio = <&pmc8380_3_gpios 6 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&pm_sde7_main_3p3_en>;
+	};
 };
 
 &apps_rsc {
@@ -667,6 +709,57 @@ &mdss_dp3_phy {
 	status = "okay";
 };
 
+&pm8550ve_8_gpios {
+	pcie_x8_12v: pcie_x8_12v_on {
+		pins = "gpio8";
+		function = "normal";
+		output-enable;
+		output-high;
+		bias-pull-down;
+		power-source = <0>;
+	};
+};
+
+&pmc8380_3_gpios {
+	pm_sde7_aux_3p3_en: pm_sde7_aux_3p3 {
+		pins = "gpio8";
+		function = "normal";
+		output-enable;
+		output-high;
+		bias-pull-down;
+		power-source = <0>;
+	};
+
+	pm_sde7_main_3p3_en: pm_sde7_main_3p3 {
+		pins = "gpio6";
+		function = "normal";
+		output-enable;
+		output-high;
+		bias-pull-down;
+		power-source = <0>;
+	};
+};
+
+&pcie3 {
+	vpcie12v-supply = <&vreg_pcie_12v>;
+	vpcie3v3-supply = <&vreg_pcie_3v3>;
+	vpcie3v3aux-supply = <&vreg_pcie_3v3_aux>;
+
+	pinctrl-names = "default";
+	pinctrl-0 = <&pcie3_default>;
+	perst-gpios = <&tlmm 143 GPIO_ACTIVE_LOW>;
+	wake-gpios = <&tlmm 145 GPIO_ACTIVE_LOW>;
+	status = "okay";
+};
+
+&pcie3_phy {
+	vdda-phy-supply = <&vreg_l3j_0p8>;
+	vdda-pll-supply = <&vreg_l3e_1p2>;
+	vdda-qref-supply = <&vreg_l3c_0p8>;
+
+	status = "okay";
+};
+
 &pcie4 {
 	perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
 	wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
@@ -824,6 +917,29 @@ nvme_reg_en: nvme-reg-en-state {
 		bias-disable;
 	};
 
+	pcie3_default: pcie3-default-state {
+		clkreq-n-pins {
+			pins = "gpio144";
+			function = "pcie3_clk";
+			drive-strength = <2>;
+			bias-pull-up;
+		};
+
+		perst-n-pins {
+			pins = "gpio143";
+			function = "gpio";
+			drive-strength = <2>;
+			bias-pull-down;
+		};
+
+		wake-n-pins {
+		       pins = "gpio145";
+		       function = "gpio";
+		       drive-strength = <2>;
+		       bias-pull-up;
+		};
+	};
+
 	pcie4_default: pcie4-default-state {
 		clkreq-n-pins {
 			pins = "gpio147";
-- 
2.34.1



From krzk at kernel.org  Mon Aug 26 23:25:47 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Tue, 27 Aug 2024 08:25:47 +0200
Subject: [PATCH V2 3/6] phy: qcom: Introduce PCIe UNIPHY 28LP driver
In-Reply-To: <20240827045757.1101194-4-quic_srichara@quicinc.com>
References: <20240827045757.1101194-1-quic_srichara@quicinc.com>
 <20240827045757.1101194-4-quic_srichara@quicinc.com>
Message-ID: <svraqyrvmyfvezj6zuzsoc5cy3lqklwxkmjdloquj2v4r5ik72@xnbaoigiikeu>

On Tue, Aug 27, 2024 at 10:27:54AM +0530, Sricharan R wrote:
> From: Nitheesh Sekar <quic_nsekar at quicinc.com>
> 
> Add Qualcomm PCIe UNIPHY 28LP driver support present
> in Qualcomm IPQ5018 SoC and the phy init sequence.
> 
> Signed-off-by: Nitheesh Sekar <quic_nsekar at quicinc.com>
> Signed-off-by: Sricharan Ramabadhran <quic_srichara at quicinc.com>

...

> +static int qcom_uniphy_pcie_probe(struct platform_device *pdev)
> +{
> +	struct qcom_uniphy_pcie *phy;
> +	int ret;
> +	struct phy *generic_phy;
> +	struct phy_provider *phy_provider;
> +	struct device *dev = &pdev->dev;
> +	struct device_node *np = of_node_get(dev->of_node);
> +
> +	phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
> +	if (!phy)
> +		return -ENOMEM;
> +
> +	platform_set_drvdata(pdev, phy);
> +	phy->dev = &pdev->dev;
> +
> +	phy->data = of_device_get_match_data(dev);
> +	if (!phy->data)
> +		return -EINVAL;
> +
> +	ret = qcom_uniphy_pcie_get_resources(pdev, phy);
> +	if (ret < 0)
> +		dev_err_probe(&pdev->dev, ret, "Failed to get resources:\n");

What the hell happened here? Read my review one more time and then git
grep for usage of dev_err_probe.

NAK.

Best regards,
Krzysztof



From krzk at kernel.org  Mon Aug 26 23:24:30 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Tue, 27 Aug 2024 08:24:30 +0200
Subject: [PATCH V2 0/6] Enable IPQ5018 PCI support
In-Reply-To: <20240827045757.1101194-1-quic_srichara@quicinc.com>
References: <20240827045757.1101194-1-quic_srichara@quicinc.com>
Message-ID: <wq5mfkqvvclubmacu5ogptdeaahxr77hk73dpmcvcelno5ylpv@4q4hfuolzky7>

On Tue, Aug 27, 2024 at 10:27:51AM +0530, Sricharan R wrote:
> From: Sricharan Ramabadhran <quic_srichara at quicinc.com>
> 
> This patch series adds the relevant phy and controller
> DT configurations for enabling PCI gen2 support
> on IPQ5018.
> 
> v2:
>   Fixed all review comments from Krzysztof, Robert Marko,
>   Dmitry Baryshkov, Manivannan Sadhasivam, Konrad Dybcio.

That's not specific. What exactly did you do? You must list the
changes.

Best regards,
Krzysztof



From quic_srichara at quicinc.com  Mon Aug 26 23:51:51 2024
From: quic_srichara at quicinc.com (Sricharan Ramabadhran)
Date: Tue, 27 Aug 2024 12:21:51 +0530
Subject: [PATCH V2 3/6] phy: qcom: Introduce PCIe UNIPHY 28LP driver
In-Reply-To: <svraqyrvmyfvezj6zuzsoc5cy3lqklwxkmjdloquj2v4r5ik72@xnbaoigiikeu>
References: <20240827045757.1101194-1-quic_srichara@quicinc.com>
 <20240827045757.1101194-4-quic_srichara@quicinc.com>
 <svraqyrvmyfvezj6zuzsoc5cy3lqklwxkmjdloquj2v4r5ik72@xnbaoigiikeu>
Message-ID: <20d38311-ce10-4d4e-996b-24f79c051f69@quicinc.com>



On 8/27/2024 11:55 AM, Krzysztof Kozlowski wrote:
> On Tue, Aug 27, 2024 at 10:27:54AM +0530, Sricharan R wrote:
>> From: Nitheesh Sekar <quic_nsekar at quicinc.com>
>>
>> Add Qualcomm PCIe UNIPHY 28LP driver support present
>> in Qualcomm IPQ5018 SoC and the phy init sequence.
>>
>> Signed-off-by: Nitheesh Sekar <quic_nsekar at quicinc.com>
>> Signed-off-by: Sricharan Ramabadhran <quic_srichara at quicinc.com>
> 
> ...
> 
>> +static int qcom_uniphy_pcie_probe(struct platform_device *pdev)
>> +{
>> +	struct qcom_uniphy_pcie *phy;
>> +	int ret;
>> +	struct phy *generic_phy;
>> +	struct phy_provider *phy_provider;
>> +	struct device *dev = &pdev->dev;
>> +	struct device_node *np = of_node_get(dev->of_node);
>> +
>> +	phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
>> +	if (!phy)
>> +		return -ENOMEM;
>> +
>> +	platform_set_drvdata(pdev, phy);
>> +	phy->dev = &pdev->dev;
>> +
>> +	phy->data = of_device_get_match_data(dev);
>> +	if (!phy->data)
>> +		return -EINVAL;
>> +
>> +	ret = qcom_uniphy_pcie_get_resources(pdev, phy);
>> +	if (ret < 0)
>> +		dev_err_probe(&pdev->dev, ret, "Failed to get resources:\n");
> 
> What the hell happened here? Read my review one more time and then git
> grep for usage of dev_err_probe.
> 
  Ho ok, understood, missed it, will fix and resend.

Regards,
   Sricharan

> NAK.
> 
> Best regards,
> Krzysztof
> 
> 


From frieder.schrempf at kontron.de  Tue Aug 27 00:00:34 2024
From: frieder.schrempf at kontron.de (Frieder Schrempf)
Date: Tue, 27 Aug 2024 09:00:34 +0200
Subject: drm/bridge/imx8mp-hdmi-tx: Allow inexact pixel clock frequencies
 (Was: [PATCH V8 10/12] drm/bridge: imx: add bridge wrapper driver for i.MX8MP
 DWC HDMI)
In-Reply-To: <CAHCN7x+HgasGG_v-PdtmRszhJn5odHzfV6ddeeT10_1yCOS+DQ@mail.gmail.com>
References: <20240203165307.7806-1-aford173@gmail.com>
 <20240203165307.7806-11-aford173@gmail.com>
 <Zm_UzO4Jmm7Aykcm@atmark-techno.com>
 <22a3f5266260dd3915269ae3eec7724f7537eb55.camel@pengutronix.de>
 <cd03ecb1-100e-4699-95ed-d837a2802dc7@kontron.de>
 <CAHCN7x+bh_ka250hOCenO3Et6re4EJ=5TG8=kpG1hs-PV0dQxQ@mail.gmail.com>
 <ZsVluV50NvuGGHFX@atmark-techno.com>
 <CAHCN7xJnjfjr7HfKF+4pwbENP+p2=vvMXWW1AQShNy87vfQ=-A@mail.gmail.com>
 <CAHCN7xKgpqfRf_2p1z5NyKiOYubbcDA7YE5ML8G56pVmcV+1xA@mail.gmail.com>
 <CAHCN7x+HgasGG_v-PdtmRszhJn5odHzfV6ddeeT10_1yCOS+DQ@mail.gmail.com>
Message-ID: <2d877963-e2be-4090-a86f-aadccf8f5e69@kontron.de>

Hi Adam,

On 27.08.24 2:25 AM, Adam Ford wrote:
> On Wed, Aug 21, 2024 at 8:59?PM Adam Ford <aford173 at gmail.com> wrote:
>>
>> On Wed, Aug 21, 2024 at 7:45?AM Adam Ford <aford173 at gmail.com> wrote:
>>>
>>> On Tue, Aug 20, 2024 at 10:58?PM Dominique MARTINET
>>> <dominique.martinet at atmark-techno.com> wrote:
>>>>
>>>> Adam Ford wrote on Tue, Aug 20, 2024 at 09:49:03PM -0500:
>>>>>>> However, this check is a bit overcautious in that it only allows exact
>>>>>>> rate matches. IIRC HDMI allows a rate mismatch of +- 0.5%, so this
>>>>>>> check could be relaxed quite a bit to allow for that.
>>>>>>
>>>>>> I checked with a 1080p display that reports 23 possible modes via EDID.
>>>>>> Out of these 15 are accepted by the driver with the strict check.
>>>>>>
>>>>>> Two more would be accepted with a relaxed check that allows a 0.5% margin.
>>>>>>
>>>>>> For the remaining six modes, the pixel clock would deviate up to ~5%
>>>>>> from what the display expects. Still, if I remove the check altogether,
>>>>>> all 23 modes seem to work just fine.
>>>>
>>>> I can confirm the displays I tested also seem pretty tolerant in
>>>> practice (up to ~3-4% at least), but I agree with Lucas that this isn't
>>>> something we can rely on for a general purpose driver as having examples
>>>> of things being tolerant doesn't mean all hardware will be as flexible..
>>>>
>>>>>> I'd really like to be able to add more PHY PLL setpoints for displays
>>>>>> that use non-CEA-861 modes. Unfortunately I didn't manage to figure out
>>>>>> the fractional-n PLL parameter calculation so far.
>>>>>>
>>>>>> The i.MX8MP Reference Manual provides formulas to calculate the
>>>>>> parameters based on the register values and I tried to make sense of it
>>>>>> using the existing register values in the driver. But somehow it doesn't
>>>>>> add up for me.
>>>>>>
>>>>>> Lucas, did you already work with the PLL parameters? By any chance, do
>>>>>> you now how the math behind them works?
>>>>>
>>>>> I spent a little time trying to understand it a bit.  I created a PMS
>>>>> calculator similar to the one used on the DSI controller,
>>>>
>>>> Great! I'll admit this also flies over my head and I don't have the
>>>> time to study this, so this is much appreciated.
>>>>
>>>>> except that
>>>>> the M seems to be fixed at a value of 62 per the data sheet, so it's
>>>>> more of a PS calculator.
>>>>
>>>> Hmm... PHY_REG2 in the datasheet only lists '0011_1110b - 62' as
>>>> example(?) values, but it doesn't say other values are reserved either,
>>>> I'm not sure what to make of it.
>>>> In the current driver PHY_REG_02 (driver macro) is assigned the first
>>>> field of .pll_div_regs, which goes anywhere from 0x4b to 0x7b -- pretty
>>>> far from 62(0x3e)...
>>>
>>> OK.  I will experiment with increasing the range of M from being fixed
>>> at 3e to a range of 3b to 7b to see if my PMS integer calculator can
>>> get more accurate.
>>>
>>>>
>>>> Since other frequencies have been adjusting this main diviser ratio we
>>>> actually tried copying neighboring values and adjusting only that reg 2
>>>> (so the M if I get this right?), but the end result ended up not
>>>> synchronizing properly every time... We didn't have time to check with a
>>>> scope if the generated signal was ugly or if it just didn't lock
>>>> properly, but the display worked when we just re-used the neighboring
>>>> values without changing anything despite being ~3-4% off, so we took the
>>>> easy way out here and didn't dig much further.
>>>>
>>>>> Anyway, When I run my P-S calculator to generate the 'best rate' I get
>>>>> a value that's usually 0.2% variance from nominal, but I only verified
>>>>> a handful of values:
>>>>>
>>>>> Several which were +0.2%
>>>>> 297600000 vs 297000000 (4k at 30)
>>>>> 148800000 vs 148500000 (1080p60)
>>>>> 74400 vs 74200
>>>>>
>>>>> One value was -0.16%
>>>>> 24800000 vs 25200000
>>>>>
>>>>> If the M value was a bit more flexible, we might be able to reduce
>>>>> that variance more.
>>>>
>>>> Yes, I think the M value could be more flexible, but that'd require
>>>> checking if it actually works, whereas having slightly off frequencies
>>>> will most likely be OK so I don't think it's worth the effort -- happy
>>>> to stick to what the datasheet describes.
>>>>
>>>>> If / when I get some time, I might play with trying to disable the
>>>>> fractional mode and just use the PMS calculator for simplicity despite
>>>>> the inaccuracy.  Maybe we could fall back to using the PMS calculator
>>>>> if the desired frequency isn't in the look-up-table.
>>>>
>>>> That'd be greatly appreciated, I don't have any strong opinion on
>>>> whether that should completely replace the table, or only be used if
>>>> there is no exact match in the table as these are values we know will
>>>> work; but we can definitely test any patch you can throw at us here.
>>>
>>> I can't promise it'll be quick.  I am not fully certain I understand
>>> how the whole thing works, but as a rule, I don't generally like look
>>> up tables if they can be calculated dynamically.
>>
>> I updated my PMS calculator, and I randomly selected 5 resolutions and
>> they all returned an exact clock match, so I'll attempt to use the PMS
>> integer clock instead of the fractional one.
>>
>> It'll be a little while longer before I can do anything with it.
> 
> Frieder,
> 
> Using my PMS calculator and Rev 2 of the Tech Ref Manual, I think I
> can generate you a table entry for 51.2MHz.  I don't have the ability
> to test it.  I am still working on figuring out an algorithm to
> calculate the fractional divider, but 51.2MHz x 5 does not' appear to
> need the fractional clock divider, so I think I can just get away with
> the standard PMS calculations.

Thanks Adam for all the efforts. The initial request for the 51.2 MHz
clock was from Dominique, not me. I was just jumping onto the bandwagon
with my own use-cases.

> 
> My algorithm showed:
> HDMI PHY Best P = 1
> HDMI PHY Best M = 64
> HDMI PHY Best S = 6
> HDMI PHY Best freq = 256000000
> 
> I'll try to generate a patch to get these values into the table if
> you're willing to test it.

Any chance you can share your algorithm, so I can try to generate some
table entries for the missing frequencies I encounter?

If we could figure out the calculation of the fractional divider, we
could generate table entries for arbitrary frequencies, which would be
an easy way to add support for any strange displays out there.

> 
> All,
> 
> I still think it's a good idea to fall back to the PMS calculator if
> the fractional stuff isn't found.  We could then determine which clock
> frequency is closer between the nearest table entry or the PMS
> calculator until someone can come up with an algorithm for it.

Yes, I think that's a good idea.

Thanks
Frieder


From dominique.martinet at atmark-techno.com  Tue Aug 27 00:26:22 2024
From: dominique.martinet at atmark-techno.com (Dominique MARTINET)
Date: Tue, 27 Aug 2024 16:26:22 +0900
Subject: drm/bridge/imx8mp-hdmi-tx: Allow inexact pixel clock frequencies
 (Was: [PATCH V8 10/12] drm/bridge: imx: add bridge wrapper driver for
 i.MX8MP DWC HDMI)
In-Reply-To: <2d877963-e2be-4090-a86f-aadccf8f5e69@kontron.de>
References: <20240203165307.7806-11-aford173@gmail.com>
 <Zm_UzO4Jmm7Aykcm@atmark-techno.com>
 <22a3f5266260dd3915269ae3eec7724f7537eb55.camel@pengutronix.de>
 <cd03ecb1-100e-4699-95ed-d837a2802dc7@kontron.de>
 <CAHCN7x+bh_ka250hOCenO3Et6re4EJ=5TG8=kpG1hs-PV0dQxQ@mail.gmail.com>
 <ZsVluV50NvuGGHFX@atmark-techno.com>
 <CAHCN7xJnjfjr7HfKF+4pwbENP+p2=vvMXWW1AQShNy87vfQ=-A@mail.gmail.com>
 <CAHCN7xKgpqfRf_2p1z5NyKiOYubbcDA7YE5ML8G56pVmcV+1xA@mail.gmail.com>
 <CAHCN7x+HgasGG_v-PdtmRszhJn5odHzfV6ddeeT10_1yCOS+DQ@mail.gmail.com>
 <2d877963-e2be-4090-a86f-aadccf8f5e69@kontron.de>
Message-ID: <Zs1_nnjtRKWUtBat@atmark-techno.com>

Frieder Schrempf wrote on Tue, Aug 27, 2024 at 09:00:34AM +0200:
> > Using my PMS calculator and Rev 2 of the Tech Ref Manual, I think I
> > can generate you a table entry for 51.2MHz.  I don't have the ability
> > to test it.  I am still working on figuring out an algorithm to
> > calculate the fractional divider, but 51.2MHz x 5 does not' appear to
> > need the fractional clock divider, so I think I can just get away with
> > the standard PMS calculations.
> 
> Thanks Adam for all the efforts. The initial request for the 51.2 MHz
> clock was from Dominique, not me. I was just jumping onto the bandwagon
> with my own use-cases.

We still have that 51.2 MHz display around, so happy to test -- might
take a little bit of time as this already has a workaround but it's
definitely something I'd like to clean up so more than happy to help.

> > I still think it's a good idea to fall back to the PMS calculator if
> > the fractional stuff isn't found.  We could then determine which clock
> > frequency is closer between the nearest table entry or the PMS
> > calculator until someone can come up with an algorithm for it.
> 
> Yes, I think that's a good idea.

Seconded; we can keep the code as fallback of the table at first and if
it works well maybe even remove the table altogether later, but just
having fallback first would be great.

-- 
Dominique




From konradybcio at kernel.org  Tue Aug 27 03:10:04 2024
From: konradybcio at kernel.org (Konrad Dybcio)
Date: Tue, 27 Aug 2024 12:10:04 +0200
Subject: [PATCH 6/8] clk: qcom: gcc-x1e80100: Fix halt_check for pipediv2
 clocks
In-Reply-To: <20240827063631.3932971-7-quic_qianyu@quicinc.com>
References: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
 <20240827063631.3932971-7-quic_qianyu@quicinc.com>
Message-ID: <9ae8b751-a6df-4775-a207-0d203f7415de@kernel.org>

On 27.08.2024 8:36 AM, Qiang Yu wrote:
> The pipediv2_clk's source from the same mux as pipe clock. So they have
> same limitation, which is that the PHY sequence requires to enable these
> local CBCs before the PHY is actually outputting a clock to them. This
> means the clock won't actually turn on when we vote them. Hence, let's
> skip the halt bit check of the pipediv2_clk, otherwise pipediv2_clk may
> stuck at off state during bootup.
> 
> Suggested-by: Mike Tipton <quic_mdtipton at quicinc.com>
> Signed-off-by: Qiang Yu <quic_qianyu at quicinc.com>
> ---


Reviewed-by: Konrad Dybcio <konradybcio at kernel.org>

Konrad


From konradybcio at kernel.org  Tue Aug 27 03:13:21 2024
From: konradybcio at kernel.org (Konrad Dybcio)
Date: Tue, 27 Aug 2024 12:13:21 +0200
Subject: [PATCH 2/8] phy: qcom-qmp: pcs: Add v6.30 register offsets
In-Reply-To: <20240827063631.3932971-3-quic_qianyu@quicinc.com>
References: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
 <20240827063631.3932971-3-quic_qianyu@quicinc.com>
Message-ID: <a16b2ae5-43bf-41a5-9a6c-9acbddde36e2@kernel.org>

On 27.08.2024 8:36 AM, Qiang Yu wrote:
> x1e80100 SoC uses QMP phy with version v6.30 for PCIe Gen4 x8. Add the new
> PCS offsets in a dedicated header file.
> 
> Signed-off-by: Qiang Yu <quic_qianyu at quicinc.com>
> ---
>  drivers/phy/qualcomm/phy-qcom-qmp-pcs-v6_30.h | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
>  create mode 100644 drivers/phy/qualcomm/phy-qcom-qmp-pcs-v6_30.h
> 
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcs-v6_30.h b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-v6_30.h
> new file mode 100644
> index 000000000000..9aa6d3622c24
> --- /dev/null
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-v6_30.h
> @@ -0,0 +1,19 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (c) 2024 Qualcomm Innovation Center. All rights reserved.
> + */
> +
> +#ifndef QCOM_PHY_QMP_PCS_V6_30_H_
> +#define QCOM_PHY_QMP_PCS_V6_30_H_
> +
> +/* Only for QMP V6_30 PHY - PCIe PCS registers */
> +#define	QPHY_V6_30_PCS_LOCK_DETECT_CONFIG2		0x0cc
> +#define	QPHY_V6_30_PCS_G3S2_PRE_GAIN			0x17c
> +#define	QPHY_V6_30_PCS_RX_SIGDET_LVL			0x194
> +#define	QPHY_V6_30_PCS_ALIGN_DETECT_CONFIG7		0x1dc
> +#define	QPHY_V6_30_PCS_TX_RX_CONFIG			0x1e0
> +#define	QPHY_V6_30_PCS_TX_RX_CONFIG2			0x1e4
> +#define	QPHY_V6_30_PCS_EQ_CONFIG4			0x1fc
> +#define	QPHY_V6_30_PCS_EQ_CONFIG5			0x200

Squash with the previous one and the next one, and please make the
indentation consistent

Konrad


From konradybcio at kernel.org  Tue Aug 27 03:33:02 2024
From: konradybcio at kernel.org (Konrad Dybcio)
Date: Tue, 27 Aug 2024 12:33:02 +0200
Subject: [PATCH 3/8] phy: qcom: qmp: Add phy register and clk setting for
 x1e80100 PCIe3
In-Reply-To: <20240827063631.3932971-4-quic_qianyu@quicinc.com>
References: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
 <20240827063631.3932971-4-quic_qianyu@quicinc.com>
Message-ID: <2d3f3da1-713e-4378-b87d-11f10f0f9590@kernel.org>

On 27.08.2024 8:36 AM, Qiang Yu wrote:
> Currently driver supports only x4 lane based functionality using tx/rx and
> tx2/rx2 pair of register sets. To support 8 lane functionality with PCIe3,
> PCIe3 related QMP PHY provides additional programming which are available
> as txz and rxz based register set. Hence adds txz and rxz based registers
> usage and programming sequences. Phy register setting for txz and rxz will
> be applied to all 8 lanes. Some lanes may have different settings on
> several registers than txz/rxz, these registers should be programmed after
> txz/rxz programming sequences completing.
> 
> Besides, PCIe3 related QMP PHY also requires addtional clk, which is named
> as clkref_en. Hence, add this clk into qmp_pciephy_clk_l so that it can be
> easily parsed from devicetree during init.
> 
> Signed-off-by: Qiang Yu <quic_qianyu at quicinc.com>
> ---

[...]

> +static const struct qmp_phy_init_tbl x1e80100_qmp_gen4x8_pcie_rx_tbl[] = {
> +	QMP_PHY_INIT_CFG_LANE(QSERDES_V6_20_RX_DFE_CTLE_POST_CAL_OFFSET, 0x3a, 1),

1 -> BIT(0)

[...]

> +	/* Set to true for programming all 8 lanes using txz/rxz registers */
> +	bool lane_broadcasting;

This is unnecessary because you call qmp_configure_lane conditionally,
but that function has a nullcheck built in

> +
>  	/* resets to be requested */
>  	const char * const *reset_list;
>  	int num_resets;
> @@ -2655,6 +2815,8 @@ struct qmp_pcie {
>  	void __iomem *rx;
>  	void __iomem *tx2;
>  	void __iomem *rx2;
> +	void __iomem *txz;
> +	void __iomem *rxz;
>  	void __iomem *ln_shrd;
>  
>  	void __iomem *port_b;
> @@ -2700,7 +2862,7 @@ static inline void qphy_clrbits(void __iomem *base, u32 offset, u32 val)
>  
>  /* list of clocks required by phy */
>  static const char * const qmp_pciephy_clk_l[] = {
> -	"aux", "cfg_ahb", "ref", "refgen", "rchng", "phy_aux",
> +	"aux", "cfg_ahb", "ref", "refgen", "rchng", "phy_aux", "clkref_en",

Why not just put in TCSR_PCIE_8L_CLKREF_EN as "ref"? It's downstream
of the XO anyway.

[...]

>  	const struct qmp_phy_cfg *cfg = qmp->cfg;
> @@ -3700,6 +3907,11 @@ static void qmp_pcie_init_registers(struct qmp_pcie *qmp, const struct qmp_phy_c
>  
>  	qmp_configure(qmp->dev, serdes, tbls->serdes, tbls->serdes_num);
>  
> +	if (cfg->lane_broadcasting) {

All these ifs can be unconditional

Konrad


From konradybcio at kernel.org  Tue Aug 27 03:42:21 2024
From: konradybcio at kernel.org (Konrad Dybcio)
Date: Tue, 27 Aug 2024 12:42:21 +0200
Subject: [PATCH 4/8] arm64: dts: qcom: x1e80100: Add support for PCIe3 on
 x1e80100
In-Reply-To: <20240827063631.3932971-5-quic_qianyu@quicinc.com>
References: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
 <20240827063631.3932971-5-quic_qianyu@quicinc.com>
Message-ID: <41d4bc67-e47c-4b6e-a620-b83f48f43103@kernel.org>

On 27.08.2024 8:36 AM, Qiang Yu wrote:
> Describe PCIe3 controller and PHY. Also add required system resources like
> regulators, clocks, interrupts and registers configuration for PCIe3.
> 
> Signed-off-by: Qiang Yu <quic_qianyu at quicinc.com>
> ---
>  arch/arm64/boot/dts/qcom/x1e80100.dtsi | 205 ++++++++++++++++++++++++-
>  1 file changed, 204 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
> index 74b694e74705..55b81e7de1c7 100644
> --- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi
> +++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
> @@ -744,7 +744,7 @@ gcc: clock-controller at 100000 {
>  
>  			clocks = <&bi_tcxo_div2>,
>  				 <&sleep_clk>,
> -				 <0>,
> +				 <&pcie3_phy>,
>  				 <&pcie4_phy>,
>  				 <&pcie5_phy>,
>  				 <&pcie6a_phy>,
> @@ -2879,6 +2879,209 @@ mmss_noc: interconnect at 1780000 {
>  			#interconnect-cells = <2>;
>  		};
>  
> +		pcie3: pci at 1bd0000 {
> +			device_type = "pci";
> +			compatible = "qcom,pcie-x1e80100";
> +			reg = <0 0x01bd0000 0 0x3000>,
> +			      <0 0x78000000 0 0xf1d>,
> +			      <0 0x78000f40 0 0xa8>,
> +			      <0 0x78001000 0 0x1000>,
> +			      <0 0x78100000 0 0x100000>;
> +			reg-names = "parf",
> +				    "dbi",
> +				    "elbi",
> +				    "atu",
> +				    "config";

There's a "mhi" region at 0x01bd3000, 0x1000-wide too, please add it

> +			#address-cells = <3>;
> +			#size-cells = <2>;
> +			ranges = <0x01000000 0 0x00000000 0 0x78200000 0 0x100000>,
> +				 <0x02000000 0 0x78300000 0 0x78300000 0 0x3d00000>;

There's 64bit BAR space as well:

<0x03000000 0x7 0x40000000 0x7 0x40000000 0x0 0x40000000>;

> +			bus-range = <0 0xff>;

0x00 please

> +
> +			dma-coherent;
> +
> +			linux,pci-domain = <3>;
> +			num-lanes = <8>;
> +
> +			interrupts = <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 769 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 836 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 671 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH>;
> +			interrupt-names = "msi0",
> +					  "msi1",
> +					  "msi2",
> +					  "msi3",
> +					  "msi4",
> +					  "msi5",
> +					  "msi6",
> +					  "msi7";
> +
> +			#interrupt-cells = <1>;
> +			interrupt-map-mask = <0 0 0 0x7>;
> +			interrupt-map = <0 0 0 1 &intc 0 0 0 220 IRQ_TYPE_LEVEL_HIGH>,
> +					<0 0 0 2 &intc 0 0 0 221 IRQ_TYPE_LEVEL_HIGH>,
> +					<0 0 0 3 &intc 0 0 0 237 IRQ_TYPE_LEVEL_HIGH>,
> +					<0 0 0 4 &intc 0 0 0 238 IRQ_TYPE_LEVEL_HIGH>;
> +
> +			clocks = <&gcc GCC_PCIE_3_PIPE_CLK_SRC>,

We don't toggle source clocks from dt, this is upstream of the pipe
div clocks and is taken care of by the common clock framework,
please drop.

> +				 <&gcc GCC_PCIE_3_AUX_CLK>,
> +				 <&gcc GCC_PCIE_3_CFG_AHB_CLK>,
> +				 <&gcc GCC_PCIE_3_MSTR_AXI_CLK>,
> +				 <&gcc GCC_PCIE_3_SLV_AXI_CLK>,
> +				 <&gcc GCC_PCIE_3_SLV_Q2A_AXI_CLK>,
> +				 <&gcc GCC_CFG_NOC_PCIE_ANOC_SOUTH_AHB_CLK>,

GCC_CFG_NOC_PCIE_ANOC_NORTH_AHB_CLK

> +				 <&gcc GCC_CNOC_PCIE_NORTH_SF_AXI_CLK>;
> +			clock-names = "pipe_clk_src",
> +				      "aux",
> +				      "cfg",
> +				      "bus_master",
> +				      "bus_slave",
> +				      "slave_q2a",
> +				      "noc_aggr",
> +				      "cnoc_sf_axi";
> +
> +			assigned-clocks = <&gcc GCC_PCIE_3_AUX_CLK>;
> +			assigned-clock-rates = <19200000>;
> +
> +			interconnects = <&pcie_south_anoc MASTER_PCIE_3 QCOM_ICC_TAG_ALWAYS
> +					 &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
> +					<&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ALWAYS
> +					 &cnoc_main SLAVE_PCIE_3 QCOM_ICC_TAG_ALWAYS>;
> +			interconnect-names = "pcie-mem",
> +					     "cpu-pcie";
> +
> +			resets = <&gcc GCC_PCIE_3_BCR>,
> +				 <&gcc GCC_PCIE_3_LINK_DOWN_BCR>;
> +			reset-names = "pci",
> +				      "link_down";
> +
> +			power-domains = <&gcc GCC_PCIE_3_GDSC>;
> +
> +			phys = <&pcie3_phy>;
> +			phy-names = "pciephy";
> +
> +			operating-points-v2 = <&pcie3_opp_table>;
> +
> +			status = "disabled";
> +
> +			pcie3_opp_table: opp-table {
> +				compatible = "operating-points-v2";
> +
> +				/* GEN 1 x1 */
> +				opp-2500000 {
> +					opp-hz = /bits/ 64 <2500000>;
> +					required-opps = <&rpmhpd_opp_low_svs>;
> +					opp-peak-kBps = <250000 1>;
> +				};
> +
> +				/* GEN 1 x2 and GEN 2 x1 */
> +				opp-5000000 {
> +					opp-hz = /bits/ 64 <5000000>;
> +					required-opps = <&rpmhpd_opp_low_svs>;
> +					opp-peak-kBps = <500000 1>;
> +				};
> +
> +				/* GEN 1 x4 and GEN 2 x2*/

Missing ' '

> +				opp-10000000 {
> +					opp-hz = /bits/ 64 <10000000>;
> +					required-opps = <&rpmhpd_opp_low_svs>;
> +					opp-peak-kBps = <1000000 1>;
> +				};
> +
> +				/* GEN 1 x8 and GEN 2 X4 */

Inconsistent capitalization, please use lowercase 'x'

[...]

> +		pcie3_phy: phy at 1be0000 {
> +			compatible = "qcom,x1e80100-qmp-gen4x8-pcie-phy";
> +			reg = <0 0x01be0000 0 0x10000>;
> +
> +			clocks = <&gcc GCC_PCIE_3_AUX_CLK>,

This clock doesn't belong here, the PHY is clocked by PHY_AUX

> +				 <&gcc GCC_PCIE_3_CFG_AHB_CLK>,
> +				 <&rpmhcc RPMH_CXO_CLK>,

This is unnecessary as commented before

> +				 <&gcc GCC_PCIE_3_PHY_RCHNG_CLK>,
> +				 <&gcc GCC_PCIE_3_PHY_AUX_CLK>,
> +				 <&gcc GCC_PCIE_3_PIPE_CLK>,
> +				 <&gcc GCC_PCIE_3_PIPEDIV2_CLK>,
> +				 <&tcsr TCSR_PCIE_8L_CLKREF_EN>;

This should be the 'ref' here

Konrad


From konradybcio at kernel.org  Tue Aug 27 04:02:29 2024
From: konradybcio at kernel.org (Konrad Dybcio)
Date: Tue, 27 Aug 2024 13:02:29 +0200
Subject: [PATCH 8/8] PCI: qcom: Add support to PCIe slot power supplies
In-Reply-To: <20240827063631.3932971-9-quic_qianyu@quicinc.com>
References: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
 <20240827063631.3932971-9-quic_qianyu@quicinc.com>
Message-ID: <52b32254-8468-4fba-8357-0edc54dee129@kernel.org>

On 27.08.2024 8:36 AM, Qiang Yu wrote:
> On platform x1e80100 QCP, PCIe3 is a standard x8 form factor. Hence, add
> support to use 3.3v, 3.3v aux and 12v regulators.
> 
> Signed-off-by: Qiang Yu <quic_qianyu at quicinc.com>
> ---
>  drivers/pci/controller/dwc/pcie-qcom.c | 52 +++++++++++++++++++++++++-
>  1 file changed, 50 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
> index 6f953e32d990..59fb415dfeeb 100644
> --- a/drivers/pci/controller/dwc/pcie-qcom.c
> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> @@ -248,6 +248,8 @@ struct qcom_pcie_cfg {
>  	bool no_l0s;
>  };
>  
> +#define QCOM_PCIE_SLOT_MAX_SUPPLIES			3
> +
>  struct qcom_pcie {
>  	struct dw_pcie *pci;
>  	void __iomem *parf;			/* DT parf */
> @@ -260,6 +262,7 @@ struct qcom_pcie {
>  	struct icc_path *icc_cpu;
>  	const struct qcom_pcie_cfg *cfg;
>  	struct dentry *debugfs;
> +	struct regulator_bulk_data slot_supplies[QCOM_PCIE_SLOT_MAX_SUPPLIES];
>  	bool suspended;
>  	bool use_pm_opp;
>  };
> @@ -1174,6 +1177,41 @@ static int qcom_pcie_link_up(struct dw_pcie *pci)
>  	return !!(val & PCI_EXP_LNKSTA_DLLLA);
>  }
>  
> +static int qcom_pcie_enable_slot_supplies(struct qcom_pcie *pcie)
> +{
> +	struct dw_pcie *pci = pcie->pci;
> +	int ret;
> +
> +	ret = regulator_bulk_enable(ARRAY_SIZE(pcie->slot_supplies),
> +				    pcie->slot_supplies);
> +	if (ret < 0)
> +		dev_err(pci->dev, "Failed to enable slot regulators\n");

return dev_err_probe would be a good call.. probably more so below,
but won't hurt to use here too

> +
> +	return ret;
> +}
> +
> +static void qcom_pcie_disable_slot_supplies(struct qcom_pcie *pcie)
> +{
> +	regulator_bulk_disable(ARRAY_SIZE(pcie->slot_supplies),
> +			       pcie->slot_supplies);
> +}

This I feel like is overly abstracted

Konrad


From dmitry.baryshkov at linaro.org  Tue Aug 27 04:44:09 2024
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Tue, 27 Aug 2024 14:44:09 +0300
Subject: [PATCH 8/8] PCI: qcom: Add support to PCIe slot power supplies
In-Reply-To: <20240827063631.3932971-9-quic_qianyu@quicinc.com>
References: <20240827063631.3932971-1-quic_qianyu@quicinc.com> <20240827063631.3932971-9-quic_qianyu@quicinc.com>
Message-ID: <CAA8EJpq5KergZ8czg4F=EYMLANoOeBsiSVoO-zAgfG0ezQrKCQ@mail.gmail.com>

On Tue, 27 Aug 2024 at 09:36, Qiang Yu <quic_qianyu at quicinc.com> wrote:
>
> On platform x1e80100 QCP, PCIe3 is a standard x8 form factor. Hence, add
> support to use 3.3v, 3.3v aux and 12v regulators.

First of all, I don't see corresponding bindings change.

Second, these supplies power up the slot, not the host controller
itself. As such these supplies do not belong to the host controller
entry. Please consider using the pwrseq framework instead.

>
> Signed-off-by: Qiang Yu <quic_qianyu at quicinc.com>
> ---
>  drivers/pci/controller/dwc/pcie-qcom.c | 52 +++++++++++++++++++++++++-
>  1 file changed, 50 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
> index 6f953e32d990..59fb415dfeeb 100644
> --- a/drivers/pci/controller/dwc/pcie-qcom.c
> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> @@ -248,6 +248,8 @@ struct qcom_pcie_cfg {
>         bool no_l0s;
>  };
>
> +#define QCOM_PCIE_SLOT_MAX_SUPPLIES                    3
> +
>  struct qcom_pcie {
>         struct dw_pcie *pci;
>         void __iomem *parf;                     /* DT parf */
> @@ -260,6 +262,7 @@ struct qcom_pcie {
>         struct icc_path *icc_cpu;
>         const struct qcom_pcie_cfg *cfg;
>         struct dentry *debugfs;
> +       struct regulator_bulk_data slot_supplies[QCOM_PCIE_SLOT_MAX_SUPPLIES];
>         bool suspended;
>         bool use_pm_opp;
>  };
> @@ -1174,6 +1177,41 @@ static int qcom_pcie_link_up(struct dw_pcie *pci)
>         return !!(val & PCI_EXP_LNKSTA_DLLLA);
>  }
>
> +static int qcom_pcie_enable_slot_supplies(struct qcom_pcie *pcie)
> +{
> +       struct dw_pcie *pci = pcie->pci;
> +       int ret;
> +
> +       ret = regulator_bulk_enable(ARRAY_SIZE(pcie->slot_supplies),
> +                                   pcie->slot_supplies);
> +       if (ret < 0)
> +               dev_err(pci->dev, "Failed to enable slot regulators\n");
> +
> +       return ret;
> +}
> +
> +static void qcom_pcie_disable_slot_supplies(struct qcom_pcie *pcie)
> +{
> +       regulator_bulk_disable(ARRAY_SIZE(pcie->slot_supplies),
> +                              pcie->slot_supplies);
> +}
> +
> +static int qcom_pcie_get_slot_supplies(struct qcom_pcie *pcie)
> +{
> +       struct dw_pcie *pci = pcie->pci;
> +       int ret;
> +
> +       pcie->slot_supplies[0].supply = "vpcie12v";
> +       pcie->slot_supplies[1].supply = "vpcie3v3";
> +       pcie->slot_supplies[2].supply = "vpcie3v3aux";
> +       ret = devm_regulator_bulk_get(pci->dev, ARRAY_SIZE(pcie->slot_supplies),
> +                                     pcie->slot_supplies);
> +       if (ret < 0)
> +               dev_err(pci->dev, "Failed to get slot regulators\n");
> +
> +       return ret;
> +}
> +
>  static int qcom_pcie_host_init(struct dw_pcie_rp *pp)
>  {
>         struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> @@ -1182,10 +1220,14 @@ static int qcom_pcie_host_init(struct dw_pcie_rp *pp)
>
>         qcom_ep_reset_assert(pcie);
>
> -       ret = pcie->cfg->ops->init(pcie);
> +       ret = qcom_pcie_enable_slot_supplies(pcie);
>         if (ret)
>                 return ret;
>
> +       ret = pcie->cfg->ops->init(pcie);
> +       if (ret)
> +               goto err_disable_slot;
> +
>         ret = phy_set_mode_ext(pcie->phy, PHY_MODE_PCIE, PHY_MODE_PCIE_RC);
>         if (ret)
>                 goto err_deinit;
> @@ -1216,7 +1258,8 @@ static int qcom_pcie_host_init(struct dw_pcie_rp *pp)
>         phy_power_off(pcie->phy);
>  err_deinit:
>         pcie->cfg->ops->deinit(pcie);
> -
> +err_disable_slot:
> +       qcom_pcie_disable_slot_supplies(pcie);
>         return ret;
>  }
>
> @@ -1228,6 +1271,7 @@ static void qcom_pcie_host_deinit(struct dw_pcie_rp *pp)
>         qcom_ep_reset_assert(pcie);
>         phy_power_off(pcie->phy);
>         pcie->cfg->ops->deinit(pcie);
> +       qcom_pcie_disable_slot_supplies(pcie);
>  }
>
>  static void qcom_pcie_host_post_init(struct dw_pcie_rp *pp)
> @@ -1602,6 +1646,10 @@ static int qcom_pcie_probe(struct platform_device *pdev)
>                         goto err_pm_runtime_put;
>         }
>
> +       ret = qcom_pcie_get_slot_supplies(pcie);
> +       if (ret)
> +               goto err_pm_runtime_put;
> +
>         ret = pcie->cfg->ops->get_resources(pcie);
>         if (ret)
>                 goto err_pm_runtime_put;
> --
> 2.34.1
>


-- 
With best wishes
Dmitry


From krzk at kernel.org  Tue Aug 27 04:39:49 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Tue, 27 Aug 2024 13:39:49 +0200
Subject: [PATCH 4/8] arm64: dts: qcom: x1e80100: Add support for PCIe3 on
 x1e80100
In-Reply-To: <20240827063631.3932971-5-quic_qianyu@quicinc.com>
References: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
 <20240827063631.3932971-5-quic_qianyu@quicinc.com>
Message-ID: <ag3h77zczj5ttuz4bjhtqxpllyt4di77gwaavdcdlhr5anv6yk@ygzb756hcwvm>

On Mon, Aug 26, 2024 at 11:36:27PM -0700, Qiang Yu wrote:
> Describe PCIe3 controller and PHY. Also add required system resources like
> regulators, clocks, interrupts and registers configuration for PCIe3.
> 
> Signed-off-by: Qiang Yu <quic_qianyu at quicinc.com>
> ---
>  arch/arm64/boot/dts/qcom/x1e80100.dtsi | 205 ++++++++++++++++++++++++-

Why DTS is mixed with the drivers? This patchset is organized in
confusing way. Please use standard upstream submission process - DTS is
always the last in the patchset (or separate).


Best regards,
Krzysztof



From krzk at kernel.org  Tue Aug 27 04:38:17 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Tue, 27 Aug 2024 13:38:17 +0200
Subject: [PATCH 3/8] phy: qcom: qmp: Add phy register and clk setting for
 x1e80100 PCIe3
In-Reply-To: <20240827063631.3932971-4-quic_qianyu@quicinc.com>
References: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
 <20240827063631.3932971-4-quic_qianyu@quicinc.com>
Message-ID: <3rwkr4tqyki7umt75bgy6wcs2whchw2vb5ckrkqffaizxm3ssp@glkarq76vl4f>

On Mon, Aug 26, 2024 at 11:36:26PM -0700, Qiang Yu wrote:
>  	if (cfg->tbls.ln_shrd)
>  		qmp->ln_shrd = base + offs->ln_shrd;
>  
> @@ -4424,6 +4641,9 @@ static const struct of_device_id qmp_pcie_of_match_table[] = {
>  	}, {
>  		.compatible = "qcom,x1e80100-qmp-gen4x2-pcie-phy",
>  		.data = &x1e80100_qmp_gen4x2_pciephy_cfg,
> +	}, {
> +		.compatible = "qcom,x1e80100-qmp-gen4x8-pcie-phy",

Undocumented compatible or your patch order is wrong.

> +		.data = &x1e80100_qmp_gen4x8_pciephy_cfg,
>  	},

Best regards,
Krzysztof



From krzk at kernel.org  Tue Aug 27 04:41:18 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Tue, 27 Aug 2024 13:41:18 +0200
Subject: [PATCH 7/8] arm64: dts: qcom: x1e80100-qcp: Add power supply and
 sideband signal for pcie3
In-Reply-To: <20240827063631.3932971-8-quic_qianyu@quicinc.com>
References: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
 <20240827063631.3932971-8-quic_qianyu@quicinc.com>
Message-ID: <haj2zmdk7raz4zcwaizzeyxoetrb5rcxwwkhjesuejphixgogb@gueq5pq7srcx>

On Mon, Aug 26, 2024 at 11:36:30PM -0700, Qiang Yu wrote:
> Add perst, wake and clkreq gpio config. Add required power supply.
> 
> Signed-off-by: Qiang Yu <quic_qianyu at quicinc.com>
> ---
>  arch/arm64/boot/dts/qcom/x1e80100-qcp.dts | 116 ++++++++++++++++++++++
>  1 file changed, 116 insertions(+)
> 

Really, driver cannot depend on this patch. That's a no go.

> diff --git a/arch/arm64/boot/dts/qcom/x1e80100-qcp.dts b/arch/arm64/boot/dts/qcom/x1e80100-qcp.dts
> index 1c3a6a7b3ed6..0deb0c4bfea9 100644
> --- a/arch/arm64/boot/dts/qcom/x1e80100-qcp.dts
> +++ b/arch/arm64/boot/dts/qcom/x1e80100-qcp.dts
> @@ -254,6 +254,48 @@ vreg_nvme: regulator-nvme {
>  		pinctrl-names = "default";
>  		pinctrl-0 = <&nvme_reg_en>;
>  	};
> +
> +	vreg_pcie_12v: regulator-pcie_12v {
> +		compatible = "regulator-fixed";
> +
> +		regulator-name = "VREG_PCIE_12V";
> +		regulator-min-microvolt = <12000000>;
> +		regulator-max-microvolt = <12000000>;
> +
> +		gpio = <&pm8550ve_8_gpios 8 GPIO_ACTIVE_HIGH>;
> +		enable-active-high;
> +
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pcie_x8_12v>;
> +	};
> +
> +	vreg_pcie_3v3_aux: regulator-pcie_3v3_aux {

Please follow DTS coding style.

> +		compatible = "regulator-fixed";
> +
> +		regulator-name = "VREG_PCIE_3P3_AUX";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +
> +		gpio = <&pmc8380_3_gpios 8 GPIO_ACTIVE_HIGH>;
> +		enable-active-high;
> +
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pm_sde7_aux_3p3_en>;
> +	};
> +
> +	vreg_pcie_3v3: regulator-pcie_3v3 {
> +		compatible = "regulator-fixed";
> +
> +		regulator-name = "VREG_PCIE_3P3";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +
> +		gpio = <&pmc8380_3_gpios 6 GPIO_ACTIVE_HIGH>;
> +		enable-active-high;
> +
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pm_sde7_main_3p3_en>;
> +	};
>  };
>  
>  &apps_rsc {
> @@ -667,6 +709,57 @@ &mdss_dp3_phy {
>  	status = "okay";
>  };
>  
> +&pm8550ve_8_gpios {
> +	pcie_x8_12v: pcie_x8_12v_on {

Never tested.

Best regards,
Krzysztof



From krzk at kernel.org  Tue Aug 27 04:37:08 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Tue, 27 Aug 2024 13:37:08 +0200
Subject: [PATCH 1/8] phy: qcom-qmp: pcs-pcie: Add v6.30 register offsets
In-Reply-To: <20240827063631.3932971-2-quic_qianyu@quicinc.com>
References: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
 <20240827063631.3932971-2-quic_qianyu@quicinc.com>
Message-ID: <2ojutgxk4kplxwrxxcq5zorejuohbow7dr6lhl4cwndkwzvxf6@lxg4um6krdnh>

On Mon, Aug 26, 2024 at 11:36:24PM -0700, Qiang Yu wrote:
> x1e80100 SoC uses QMP phy with version v6.30 for PCIe Gen4 x8. Add the new
> PCS PCIE specific offsets in a dedicated header file.
> 
> Signed-off-by: Qiang Yu <quic_qianyu at quicinc.com>
> ---
>  .../qualcomm/phy-qcom-qmp-pcs-pcie-v6_30.h    | 25 +++++++++++++++++++
>  1 file changed, 25 insertions(+)
>  create mode 100644 drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v6_30.h
> 
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v6_30.h b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v6_30.h
> new file mode 100644
> index 000000000000..5a58ff197e6e
> --- /dev/null
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v6_30.h
> @@ -0,0 +1,25 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (c) 2024 Qualcomm Innovation Center. All rights reserved.
> + */
> +
> +#ifndef QCOM_PHY_QMP_PCS_PCIE_V6_30_H_
> +#define QCOM_PHY_QMP_PCS_PCIE_V6_30_H_
> +
> +/* Only for QMP V6_30 PHY - PCIE have different offsets than V6 */
> +#define QPHY_PCIE_V6_30_PCS_POWER_STATE_CONFIG2		0x014
> +#define QPHY_PCIE_V6_30_PCS_TX_RX_CONFIG		0x020
> +#define QPHY_PCIE_V6_30_PCS_ENDPOINT_REFCLK_DRIVE	0x024
> +#define QPHY_PCIE_V6_30_PCS_OSC_DTCT_ACTIONS		0x098
> +#define QPHY_PCIE_V6_30_PCS_EQ_CONFIG1			0x0a8
> +#define QPHY_PCIE_V6_30_PCS_G3_RXEQEVAL_TIME		0x0f8
> +#define QPHY_PCIE_V6_30_PCS_G4_RXEQEVAL_TIME		0x0fc
> +#define QPHY_PCIE_V6_30_PCS_G4_EQ_CONFIG5		0x110
> +#define QPHY_PCIE_V6_30_PCS_G4_PRE_GAIN			0x164
> +#define QPHY_PCIE_V6_30_PCS_RX_MARGINING_CONFIG1	0x184
> +#define QPHY_PCIE_V6_30_PCS_RX_MARGINING_CONFIG3	0x18c
> +#define QPHY_PCIE_V6_30_PCS_RX_MARGINING_CONFIG5	0x194
> +#define QPHY_PCIE_V6_30_PCS_G3_FOM_EQ_CONFIG5		0x1b4
> +#define QPHY_PCIE_V6_30_PCS_G4_FOM_EQ_CONFIG5		0x1c8

There is no user of these. Squash it with the user, because there is
little point in adding dead code.

Best regards,
Krzysztof



From krzk at kernel.org  Tue Aug 27 04:36:30 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Tue, 27 Aug 2024 13:36:30 +0200
Subject: [PATCH 5/8] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy:
 Document the X1E80100 QMP PCIe PHY Gen4 x8
In-Reply-To: <20240827063631.3932971-6-quic_qianyu@quicinc.com>
References: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
 <20240827063631.3932971-6-quic_qianyu@quicinc.com>
Message-ID: <jqzbpgqrbazf3rbdhag56rks74r2h3sjm6mr3tp7v2hb6pxamy@qhksqzsygttt>

On Mon, Aug 26, 2024 at 11:36:28PM -0700, Qiang Yu wrote:
> PCIe 3rd instance of X1E80100 support Gen 4x8 which needs different 8 lane
> capable QMP PCIe PHY. Document Gen 4x8 PHY as separate module.
> 
> Signed-off-by: Qiang Yu <quic_qianyu at quicinc.com>
> ---
>  .../phy/qcom,sc8280xp-qmp-pcie-phy.yaml        | 18 +++++++++++++++++-
>  1 file changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> index 03dbd02cf9e7..e122657490b1 100644
> --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> @@ -40,6 +40,7 @@ properties:
>        - qcom,sm8650-qmp-gen4x2-pcie-phy
>        - qcom,x1e80100-qmp-gen3x2-pcie-phy
>        - qcom,x1e80100-qmp-gen4x2-pcie-phy
> +      - qcom,x1e80100-qmp-gen4x8-pcie-phy
>  
>    reg:
>      minItems: 1
> @@ -47,7 +48,7 @@ properties:
>  
>    clocks:
>      minItems: 5
> -    maxItems: 7
> +    maxItems: 8
>  
>    clock-names:
>      minItems: 5
> @@ -59,6 +60,7 @@ properties:
>        - const: pipe
>        - const: pipediv2
>        - const: phy_aux
> +      - const: clkref_en

That sounds like enabling clock ref, not the reference clock.

>  
>    power-domains:
>      maxItems: 1
> @@ -190,6 +192,19 @@ allOf:
>          clock-names:
>            minItems: 7

You need to now constrain other cases. Missing maxItems.

Best regards,
Krzysztof



From christian.bruel at foss.st.com  Tue Aug 27 05:24:54 2024
From: christian.bruel at foss.st.com (Christian Bruel)
Date: Tue, 27 Aug 2024 14:24:54 +0200
Subject: [PATCH v3 0/5] Add STM32MP25 USB3/PCIE COMBOPHY driver 
Message-ID: <20240827122459.1102889-1-christian.bruel@foss.st.com>

This patch series adds USB3/PCIE COMBOPHY driver for the STM32MP25 SoC from
STMicrolectronics, respective yaml schema and enable for the stm32mp257f-ev1
device into which it is used for PCIe.

Changes in v3:
Address comments from Rob and Krzysztof:
   - Reorder MAINTAINERS patch
   - Drop wakeup-source from bindings (should be generic)

Changes in v2:
   - Reorder entries
   - Rename clock_names and reset_names bindings
   - Rename and clarify rx-equalizer binding 

Christian Bruel (5):
  dt-bindings: phy: Add STM32MP25 COMBOPHY bindings
  phy: stm32: Add support for STM32MP25 COMBOPHY.
  MAINTAINERS: add entry for ST STM32MP25 COMBOPHY driver
  arm64: dts: st: Add combophy node on stm32mp251
  arm64: dts: st: Enable COMBOPHY on the stm32mp257f-ev1 board

 .../bindings/phy/st,stm32-combophy.yaml       | 144 +++++
 MAINTAINERS                                   |   6 +
 arch/arm64/boot/dts/st/stm32mp251.dtsi        |  17 +
 arch/arm64/boot/dts/st/stm32mp257f-ev1.dts    |  14 +
 drivers/phy/st/Kconfig                        |  11 +
 drivers/phy/st/Makefile                       |   1 +
 drivers/phy/st/phy-stm32-combophy.c           | 607 ++++++++++++++++++
 7 files changed, 800 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml
 create mode 100644 drivers/phy/st/phy-stm32-combophy.c

-- 
2.34.1



From christian.bruel at foss.st.com  Tue Aug 27 05:24:57 2024
From: christian.bruel at foss.st.com (Christian Bruel)
Date: Tue, 27 Aug 2024 14:24:57 +0200
Subject: [PATCH 3/5] MAINTAINERS: add entry for ST STM32MP25 COMBOPHY driver
In-Reply-To: <20240827122459.1102889-1-christian.bruel@foss.st.com>
References: <20240827122459.1102889-1-christian.bruel@foss.st.com>
Message-ID: <20240827122459.1102889-4-christian.bruel@foss.st.com>

Add myself as STM32MP25 COMBOPHY maintainer

Signed-off-by: Christian Bruel <christian.bruel at foss.st.com>
---
 MAINTAINERS | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f328373463b0..258fb57ccff5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -21910,6 +21910,12 @@ F:	arch/m68k/kernel/*sun3*
 F:	arch/m68k/sun3*/
 F:	drivers/net/ethernet/i825xx/sun3*
 
+STMICROELECTRONICS STMP32MP25 USB3/PCIE COMBOPHY DRIVER
+M:	Christian Bruel <christian.bruel at foss.st.com>
+S:	Maintained
+F:	Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml
+F:	drivers/phy/st/phy-stm32-combophy.c
+
 SUN4I LOW RES ADC ATTACHED TABLET KEYS DRIVER
 M:	Hans de Goede <hdegoede at redhat.com>
 L:	linux-input at vger.kernel.org
-- 
2.34.1



From christian.bruel at foss.st.com  Tue Aug 27 05:24:58 2024
From: christian.bruel at foss.st.com (Christian Bruel)
Date: Tue, 27 Aug 2024 14:24:58 +0200
Subject: [PATCH 4/5] arm64: dts: st: Add combophy node on stm32mp251
In-Reply-To: <20240827122459.1102889-1-christian.bruel@foss.st.com>
References: <20240827122459.1102889-1-christian.bruel@foss.st.com>
Message-ID: <20240827122459.1102889-5-christian.bruel@foss.st.com>

Add support for COMBOPHY which is used either by the USB3 and PCIe
controller.
USB3 or PCIe mode is done with phy_set_mode().
PCIe internal reference clock can be generated from the internal clock
source or optionnaly from an external 100Mhz pad.

Signed-off-by: Christian Bruel <christian.bruel at foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp251.dtsi | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
index 1167cf63d7e8..0d38763d9317 100644
--- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
@@ -7,6 +7,7 @@
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/reset/st,stm32mp25-rcc.h>
 #include <dt-bindings/regulator/st,stm32mp25-regulator.h>
+#include <dt-bindings/phy/phy.h>
 
 / {
 	#address-cells = <2>;
@@ -518,6 +519,22 @@ i2c8: i2c at 46040000 {
 				status = "disabled";
 			};
 
+			combophy: phy at 480c0000 {
+				compatible = "st,stm32mp25-combophy";
+				reg = <0x480c0000 0x1000>;
+				#phy-cells = <1>;
+				clocks = <&rcc CK_BUS_USB3PCIEPHY>, <&rcc CK_KER_USB3PCIEPHY>;
+				clock-names = "apb", "ker";
+				resets = <&rcc USB3PCIEPHY_R>;
+				reset-names = "phy";
+				st,syscfg = <&syscfg>;
+				access-controllers = <&rifsc 67>;
+				power-domains = <&CLUSTER_PD>;
+				wakeup-source;
+				interrupts-extended = <&exti1 45 IRQ_TYPE_EDGE_FALLING>;
+				status = "disabled";
+			};
+
 			sdmmc1: mmc at 48220000 {
 				compatible = "st,stm32mp25-sdmmc2", "arm,pl18x", "arm,primecell";
 				arm,primecell-periphid = <0x00353180>;
-- 
2.34.1



From christian.bruel at foss.st.com  Tue Aug 27 05:24:55 2024
From: christian.bruel at foss.st.com (Christian Bruel)
Date: Tue, 27 Aug 2024 14:24:55 +0200
Subject: [PATCH 1/5] dt-bindings: phy: Add STM32MP25 COMBOPHY bindings
In-Reply-To: <20240827122459.1102889-1-christian.bruel@foss.st.com>
References: <20240827122459.1102889-1-christian.bruel@foss.st.com>
Message-ID: <20240827122459.1102889-2-christian.bruel@foss.st.com>

Document the bindings for STM32 COMBOPHY interface, used to support
the PCIe and USB3 stm32mp25 drivers.
Following entries can be used to tune caracterisation parameters
 - st,output-micro-ohms and st,output-vswing-microvolt bindings entries
to tune the impedance and voltage swing using discrete simulation results
 - st,rx-equalizer register to set the internal rx equalizer filter value.

Reviewed-by: Rob Herring (Arm) <robh at kernel.org>
Signed-off-by: Christian Bruel <christian.bruel at foss.st.com>
---
 .../bindings/phy/st,stm32-combophy.yaml       | 144 ++++++++++++++++++
 1 file changed, 144 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml

diff --git a/Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml b/Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml
new file mode 100644
index 000000000000..c33a843b83a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml
@@ -0,0 +1,144 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/st,stm32-combophy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STM32MP25 USB3/PCIe COMBOPHY
+
+maintainers:
+  - Christian Bruel <christian.bruel at foss.st.com>
+
+description:
+  Single lane PHY shared (exclusive) between the USB3 and PCIe controllers.
+  Supports 5Gbit/s for USB3 and PCIe gen2 or 2.5Gbit/s for PCIe gen1.
+
+properties:
+  compatible:
+    const: st,stm32mp25-combophy
+
+  reg:
+    maxItems: 1
+
+  "#phy-cells":
+    const: 1
+    description: |
+      The cells contain the following arguments.
+
+      - description: The PHY type
+          enum:
+            - PHY_TYPE_USB3
+            - PHY_TYPE_PCIE
+
+  clocks:
+    minItems: 2
+    items:
+      - description: apb Bus clock mandatory to access registers.
+      - description: ker Internal RCC reference clock for USB3 or PCIe
+      - description: pad Optional on board clock input for PCIe only. Typically an
+                     external 100Mhz oscillator wired on dedicated CLKIN pad. Used as reference
+                     clock input instead of the ker
+
+  clock-names:
+    minItems: 2
+    items:
+      - const: apb
+      - const: ker
+      - const: pad
+
+  resets:
+    maxItems: 1
+
+  reset-names:
+    const: phy
+
+  power-domains:
+    maxItems: 1
+
+  wakeup-source: true
+
+  interrupts:
+    maxItems: 1
+    description: interrupt used for wakeup
+
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
+  st,syscfg:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description: Phandle to the SYSCON entry required for configuring PCIe
+      or USB3.
+
+  st,ssc-on:
+    type: boolean
+    description:
+      A boolean property whose presence indicates that the SSC for common clock
+      needs to be set.
+
+  st,rx-equalizer:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    minimum: 0
+    maximum: 7
+    default: 2
+    description:
+      A 3 bit value to tune the RX fixed equalizer setting for optimal eye compliance
+
+  st,output-micro-ohms:
+    minimum: 3999000
+    maximum: 6090000
+    default: 4968000
+    description:
+      A value property to tune the Single Ended Output Impedance, simulations results
+      at 25C for a VDDP=0.8V. The hardware accepts discrete values in this range.
+
+  st,output-vswing-microvolt:
+    minimum: 442000
+    maximum: 803000
+    default: 803000
+    description:
+      A value property in microvolt to tune the Single Ended Output Voltage Swing to change the
+      Vlo, Vhi for a VDDP = 0.8V. The hardware accepts discrete values in this range.
+
+required:
+  - compatible
+  - reg
+  - st,syscfg
+  - '#phy-cells'
+  - resets
+  - reset-names
+  - clocks
+  - clock-names
+
+allOf:
+  - if:
+      required:
+        - wakeup-source
+    then:
+      anyOf:
+        - required: [interrupts]
+        - required: [interrupts-extended]
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/st,stm32mp25-rcc.h>
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/reset/st,stm32mp25-rcc.h>
+
+    combophy: phy at 480c0000 {
+        compatible = "st,stm32mp25-combophy";
+        reg = <0x480c0000 0x1000>;
+        #phy-cells = <1>;
+        clocks = <&rcc CK_BUS_USB3PCIEPHY>, <&rcc CK_KER_USB3PCIEPHY>;
+        clock-names = "apb", "ker";
+        resets = <&rcc USB3PCIEPHY_R>;
+        reset-names = "phy";
+        st,syscfg = <&syscfg>;
+        access-controllers = <&rifsc 67>;
+        power-domains = <&CLUSTER_PD>;
+        wakeup-source;
+        interrupts-extended = <&exti1 45 IRQ_TYPE_EDGE_FALLING>;
+    };
+...
-- 
2.34.1



From christian.bruel at foss.st.com  Tue Aug 27 05:24:56 2024
From: christian.bruel at foss.st.com (Christian Bruel)
Date: Tue, 27 Aug 2024 14:24:56 +0200
Subject: [PATCH 2/5] phy: stm32: Add support for STM32MP25 COMBOPHY.
In-Reply-To: <20240827122459.1102889-1-christian.bruel@foss.st.com>
References: <20240827122459.1102889-1-christian.bruel@foss.st.com>
Message-ID: <20240827122459.1102889-3-christian.bruel@foss.st.com>

Addition of the COMBOPHY driver found on STM32MP25 platforms

This single lane PHY is shared (exclusive) between the USB3 and PCIE
controllers.
Supports 5Gbit/s for PCIE gen2 or 2.5Gbit/s for PCIE gen1.

Supports wakeup-source capability to wakeup system using remote-wakeup
capable USB device

Signed-off-by: Christian Bruel <christian.bruel at foss.st.com>
---
 drivers/phy/st/Kconfig              |  11 +
 drivers/phy/st/Makefile             |   1 +
 drivers/phy/st/phy-stm32-combophy.c | 607 ++++++++++++++++++++++++++++
 3 files changed, 619 insertions(+)
 create mode 100644 drivers/phy/st/phy-stm32-combophy.c

diff --git a/drivers/phy/st/Kconfig b/drivers/phy/st/Kconfig
index 3fc3d0781fb8..304614b6dabf 100644
--- a/drivers/phy/st/Kconfig
+++ b/drivers/phy/st/Kconfig
@@ -33,6 +33,17 @@ config PHY_STIH407_USB
 	  Enable this support to enable the picoPHY device used by USB2
 	  and USB3 controllers on STMicroelectronics STiH407 SoC families.
 
+config PHY_STM32_COMBOPHY
+	tristate "STMicroelectronics COMBOPHY driver for STM32MP25"
+	depends on ARCH_STM32 || COMPILE_TEST
+	select GENERIC_PHY
+	help
+	  Enable this to support the COMBOPHY device used by USB3 or PCIe
+	  controllers on STMicroelectronics STM32MP25 SoC.
+	  This driver controls the COMBOPHY block to generate the PCIe 100Mhz
+	  reference clock from either the external clock generator or HSE
+	  internal SoC clock source.
+
 config PHY_STM32_USBPHYC
 	tristate "STMicroelectronics STM32 USB HS PHY Controller driver"
 	depends on ARCH_STM32 || COMPILE_TEST
diff --git a/drivers/phy/st/Makefile b/drivers/phy/st/Makefile
index c862dd937b64..cb80e954ea9f 100644
--- a/drivers/phy/st/Makefile
+++ b/drivers/phy/st/Makefile
@@ -3,4 +3,5 @@ obj-$(CONFIG_PHY_MIPHY28LP) 		+= phy-miphy28lp.o
 obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)	+= phy-spear1310-miphy.o
 obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)	+= phy-spear1340-miphy.o
 obj-$(CONFIG_PHY_STIH407_USB)		+= phy-stih407-usb.o
+obj-$(CONFIG_PHY_STM32_COMBOPHY)	+= phy-stm32-combophy.o
 obj-$(CONFIG_PHY_STM32_USBPHYC) 	+= phy-stm32-usbphyc.o
diff --git a/drivers/phy/st/phy-stm32-combophy.c b/drivers/phy/st/phy-stm32-combophy.c
new file mode 100644
index 000000000000..7cd4193b0277
--- /dev/null
+++ b/drivers/phy/st/phy-stm32-combophy.c
@@ -0,0 +1,607 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * STMicroelectronics COMBOPHY STM32MP25 Controller driver.
+ *
+ * Copyright (C) 2024 STMicroelectronics
+ * Author: Christian Bruel <christian.bruel at foss.st.com>
+ */
+
+#include <linux/clk.h>
+#include <linux/mfd/syscon.h>
+#include <linux/platform_device.h>
+#include <linux/phy/phy.h>
+#include <linux/pm_runtime.h>
+#include <linux/regmap.h>
+#include <linux/reset.h>
+#include <dt-bindings/phy/phy.h>
+
+#define SYSCFG_COMBOPHY_CR1 0x4C00
+#define SYSCFG_COMBOPHY_CR2 0x4C04
+#define SYSCFG_COMBOPHY_CR4 0x4C0C
+#define SYSCFG_COMBOPHY_CR5 0x4C10
+#define SYSCFG_COMBOPHY_SR  0x4C14
+#define SYSCFG_PCIEPRGCR    0x6080
+
+/* SYSCFG PCIEPRGCR */
+#define STM32MP25_PCIEPRGCR_EN	  BIT(0)
+#define STM32MP25_PCIEPRG_IMPCTRL_OHM     GENMASK(3, 1)
+#define STM32MP25_PCIEPRG_IMPCTRL_VSWING  GENMASK(5, 4)
+
+/* SYSCFG SYSCFG_COMBOPHY_SR */
+#define STM32MP25_PIPE0_PHYSTATUS BIT(1)
+
+/* SYSCFG CR1 */
+#define SYSCFG_COMBOPHY_CR1_REFUSEPAD BIT(0)
+#define SYSCFG_COMBOPHY_CR1_MPLLMULT GENMASK(7, 1)
+#define SYSCFG_COMBOPHY_CR1_REFCLKSEL GENMASK(16, 8)
+#define SYSCFG_COMBOPHY_CR1_REFCLKDIV2 BIT(17)
+#define SYSCFG_COMBOPHY_CR1_REFSSPEN BIT(18)
+#define SYSCFG_COMBOPHY_CR1_SSCEN BIT(19)
+
+/* SYSCFG CR4 */
+#define SYSCFG_COMBOPHY_CR4_RX0_EQ GENMASK(2, 0)
+
+#define MPLLMULT_19_2 (0x02u << 1)
+#define MPLLMULT_20   (0x7Du << 1)
+#define MPLLMULT_24   (0x68u << 1)
+#define MPLLMULT_25   (0x64u << 1)
+#define MPLLMULT_26   (0x60u << 1)
+#define MPLLMULT_38_4 (0x41u << 1)
+#define MPLLMULT_48   (0x6Cu << 1)
+#define MPLLMULT_50   (0x32u << 1)
+#define MPLLMULT_52   (0x30u << 1)
+#define MPLLMULT_100  (0x19u << 1)
+
+#define REFCLKSEL_0   0
+#define REFCLKSEL_1   (0x108u << 8)
+
+#define REFCLDIV_0    0
+
+/* SYSCFG CR2 */
+#define SYSCFG_COMBOPHY_CR2_MODESEL GENMASK(1, 0)
+#define SYSCFG_COMBOPHY_CR2_ISO_DIS BIT(15)
+
+#define COMBOPHY_MODESEL_PCIE 0
+#define COMBOPHY_MODESEL_USB  3
+
+/* SYSCFG CR5 */
+#define SYSCFG_COMBOPHY_CR5_COMMON_CLOCKS BIT(12)
+
+#define COMBOPHY_SUP_ANA_MPLL_LOOP_CTL 0xC0
+#define COMBOPHY_PROP_CNTRL GENMASK(7, 4)
+
+struct stm32_combophy {
+	struct phy *phy;
+	struct regmap *regmap;
+	struct device *dev;
+	void __iomem *base;
+	struct reset_control *phy_reset;
+	struct clk *phy_clk;
+	struct clk *pad_clk;
+	struct clk *ker_clk;
+	unsigned int type;
+	bool is_init;
+	int irq_wakeup;
+};
+
+struct clk_impedance  {
+	u32 microohm;
+	u32 vswing[4];
+};
+
+/*
+ * lookup table to hold the settings needed for a ref clock frequency
+ * impedance, the offset is used to set the IMP_CTL and DE_EMP bit of the
+ * PRG_IMP_CTRL register
+ */
+static const struct clk_impedance imp_lookup[] = {
+	{ 6090000, { 442000, 564000, 684000, 802000 } },
+	{ 5662000, { 528000, 621000, 712000, 803000 } },
+	{ 5292000, { 491000, 596000, 700000, 802000 } },
+	{ 4968000, { 558000, 640000, 722000, 803000 } },
+	{ 4684000, { 468000, 581000, 692000, 802000 } },
+	{ 4429000, { 554000, 613000, 717000, 803000 } },
+	{ 4204000, { 511000, 609000, 706000, 802000 } },
+	{ 3999000, { 571000, 648000, 726000, 803000 } }
+};
+
+static int stm32_impedance_tune(struct stm32_combophy *combophy)
+{
+	u8 imp_size = ARRAY_SIZE(imp_lookup);
+	u8 vswing_size = ARRAY_SIZE(imp_lookup[0].vswing);
+	u8 imp_of, vswing_of;
+	u32 max_imp = imp_lookup[0].microohm;
+	u32 min_imp = imp_lookup[imp_size - 1].microohm;
+	u32 max_vswing = imp_lookup[imp_size - 1].vswing[vswing_size - 1];
+	u32 min_vswing = imp_lookup[0].vswing[0];
+	u32 val;
+
+	if (!of_property_read_u32(combophy->dev->of_node, "st,output-micro-ohms", &val)) {
+		if (val < min_imp || val > max_imp) {
+			dev_err(combophy->dev, "Invalid value %u for output ohm\n", val);
+			return -EINVAL;
+		}
+
+		for (imp_of = 0 ; imp_of < ARRAY_SIZE(imp_lookup); imp_of++)
+			if (imp_lookup[imp_of].microohm <= val)
+				break;
+
+		dev_dbg(combophy->dev, "Set %u micro-ohms output impedance\n",
+			imp_lookup[imp_of].microohm);
+
+		regmap_update_bits(combophy->regmap, SYSCFG_PCIEPRGCR,
+				   STM32MP25_PCIEPRG_IMPCTRL_OHM,
+				   FIELD_PREP(STM32MP25_PCIEPRG_IMPCTRL_OHM, imp_of));
+	} else {
+		regmap_read(combophy->regmap, SYSCFG_PCIEPRGCR, &val);
+		imp_of = FIELD_GET(STM32MP25_PCIEPRG_IMPCTRL_OHM, val);
+	}
+
+	if (!of_property_read_u32(combophy->dev->of_node, "st,output-vswing-microvolt", &val)) {
+		if (val < min_vswing || val > max_vswing) {
+			dev_err(combophy->dev, "Invalid value %u for output vswing\n", val);
+			return -EINVAL;
+		}
+
+		for (vswing_of = 0 ; vswing_of < ARRAY_SIZE(imp_lookup[imp_of].vswing); vswing_of++)
+			if (imp_lookup[imp_of].vswing[vswing_of] >= val)
+				break;
+
+		dev_dbg(combophy->dev, "Set %u microvolt swing\n",
+			 imp_lookup[imp_of].vswing[vswing_of]);
+
+		regmap_update_bits(combophy->regmap, SYSCFG_PCIEPRGCR,
+				   STM32MP25_PCIEPRG_IMPCTRL_VSWING,
+				   FIELD_PREP(STM32MP25_PCIEPRG_IMPCTRL_VSWING, vswing_of));
+	}
+
+	return 0;
+}
+
+static int stm32_combophy_pll_init(struct stm32_combophy *combophy)
+{
+	int ret;
+	u32 refclksel, pllmult, propcntrl, val;
+	u32 clk_rate;
+
+	if (combophy->pad_clk)
+		clk_rate = clk_get_rate(combophy->pad_clk);
+	else
+		clk_rate = clk_get_rate(combophy->ker_clk);
+
+	reset_control_assert(combophy->phy_reset);
+
+	dev_dbg(combophy->dev, "%s pll init rate %d\n",
+		combophy->pad_clk ? "External" : "Ker", clk_rate);
+
+	/*
+	 * vddcombophy is interconnected with vddcore. Isolation bit should be unset
+	 * before using the ComboPHY.
+	 */
+	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR2,
+			   SYSCFG_COMBOPHY_CR2_ISO_DIS, SYSCFG_COMBOPHY_CR2_ISO_DIS);
+
+	if (combophy->type != PHY_TYPE_PCIE)
+		regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
+				   SYSCFG_COMBOPHY_CR1_REFSSPEN, SYSCFG_COMBOPHY_CR1_REFSSPEN);
+
+	if (combophy->type == PHY_TYPE_PCIE && !combophy->pad_clk)
+		regmap_update_bits(combophy->regmap, SYSCFG_PCIEPRGCR,
+				   STM32MP25_PCIEPRGCR_EN, STM32MP25_PCIEPRGCR_EN);
+
+	if (of_property_read_bool(combophy->dev->of_node, "st,ssc-on")) {
+		dev_dbg(combophy->dev, "Enabling clock with SSC\n");
+		regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
+				   SYSCFG_COMBOPHY_CR1_SSCEN, SYSCFG_COMBOPHY_CR1_SSCEN);
+	}
+
+	if (!of_property_read_u32(combophy->dev->of_node, "st,rx-equalizer", &val)) {
+		dev_dbg(combophy->dev, "Set RX equalizer %u\n", val);
+		if (val > SYSCFG_COMBOPHY_CR4_RX0_EQ) {
+			dev_err(combophy->dev, "Invalid value %u for rx0 equalizer\n", val);
+			return -EINVAL;
+		}
+
+		regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR4,
+			   SYSCFG_COMBOPHY_CR4_RX0_EQ, val);
+	}
+
+	if (combophy->type == PHY_TYPE_PCIE) {
+		ret = stm32_impedance_tune(combophy);
+		if (ret) {
+			reset_control_deassert(combophy->phy_reset);
+			goto out;
+		}
+
+		regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
+				   SYSCFG_COMBOPHY_CR1_REFUSEPAD,
+				   combophy->pad_clk ? SYSCFG_COMBOPHY_CR1_REFUSEPAD : 0);
+	}
+
+	switch (clk_rate) {
+	case 100000000:
+		pllmult = MPLLMULT_100;
+		refclksel = REFCLKSEL_0;
+		propcntrl = 0x8u << 4;
+		break;
+	case 19200000:
+		pllmult = MPLLMULT_19_2;
+		refclksel = REFCLKSEL_1;
+		propcntrl = 0x8u << 4;
+		break;
+	case 25000000:
+		pllmult = MPLLMULT_25;
+		refclksel = REFCLKSEL_0;
+		propcntrl = 0xEu << 4;
+		break;
+	case 24000000:
+		pllmult = MPLLMULT_24;
+		refclksel = REFCLKSEL_1;
+		propcntrl = 0xEu << 4;
+		break;
+	case 20000000:
+		pllmult = MPLLMULT_20;
+		refclksel = REFCLKSEL_0;
+		propcntrl = 0xEu << 4;
+		break;
+	default:
+		dev_err(combophy->dev, "Invalid rate 0x%x\n", clk_rate);
+		reset_control_deassert(combophy->phy_reset);
+		ret = -EINVAL;
+		goto out;
+	};
+
+	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
+			   SYSCFG_COMBOPHY_CR1_REFCLKDIV2, REFCLDIV_0);
+	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
+			   SYSCFG_COMBOPHY_CR1_REFCLKSEL, refclksel);
+	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
+			   SYSCFG_COMBOPHY_CR1_MPLLMULT, pllmult);
+
+	/*
+	 * Force elasticity buffer to be tuned for the reference clock as
+	 * the separated clock model is not supported
+	 */
+	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR5,
+			   SYSCFG_COMBOPHY_CR5_COMMON_CLOCKS, SYSCFG_COMBOPHY_CR5_COMMON_CLOCKS);
+
+	reset_control_deassert(combophy->phy_reset);
+
+	ret = regmap_read_poll_timeout(combophy->regmap, SYSCFG_COMBOPHY_SR, val,
+				       !(val & STM32MP25_PIPE0_PHYSTATUS),
+				       10, 1000);
+	if (ret) {
+		dev_err(combophy->dev, "timeout, cannot lock PLL\n");
+		goto out;
+	}
+
+	if (combophy->type == PHY_TYPE_PCIE) {
+		val = readl_relaxed(combophy->base + COMBOPHY_SUP_ANA_MPLL_LOOP_CTL);
+		val &= ~COMBOPHY_PROP_CNTRL;
+		val |= propcntrl;
+		writel_relaxed(val, combophy->base + COMBOPHY_SUP_ANA_MPLL_LOOP_CTL);
+	}
+
+	return 0;
+
+out:
+	if (combophy->type == PHY_TYPE_PCIE && !combophy->pad_clk)
+		regmap_update_bits(combophy->regmap, SYSCFG_PCIEPRGCR,
+				   STM32MP25_PCIEPRGCR_EN, 0);
+
+	if (combophy->type != PHY_TYPE_PCIE)
+		regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
+				   SYSCFG_COMBOPHY_CR1_REFSSPEN, 0);
+
+	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR2,
+			   SYSCFG_COMBOPHY_CR2_ISO_DIS, 0);
+
+	return ret;
+}
+
+static struct phy *stm32_combophy_xlate(struct device *dev,
+					const struct of_phandle_args *args)
+{
+	struct stm32_combophy *combophy = dev_get_drvdata(dev);
+	unsigned int type;
+
+	if (args->args_count != 1) {
+		dev_err(dev, "invalid number of cells in 'phy' property\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	type = args->args[0];
+	if (type != PHY_TYPE_USB3 && type != PHY_TYPE_PCIE) {
+		dev_err(dev, "unsupported device type: %d\n", type);
+		return ERR_PTR(-EINVAL);
+	}
+
+	if (combophy->pad_clk && type != PHY_TYPE_PCIE) {
+		dev_err(dev, "Invalid use of clk_pad for USB3 mode\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	combophy->type = type;
+
+	return combophy->phy;
+}
+
+static int stm32_combophy_set_mode(struct stm32_combophy *combophy)
+{
+	int type = combophy->type;
+	u32 val;
+
+	switch (type) {
+	case PHY_TYPE_PCIE:
+		dev_dbg(combophy->dev, "setting PCIe ComboPHY\n");
+		val = COMBOPHY_MODESEL_PCIE;
+		break;
+	case PHY_TYPE_USB3:
+		dev_dbg(combophy->dev, "setting USB3 ComboPHY\n");
+		val = COMBOPHY_MODESEL_USB;
+		break;
+	default:
+		dev_err(combophy->dev, "Invalid PHY mode %d\n", type);
+		return -EINVAL;
+	}
+
+	return regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR2,
+				  SYSCFG_COMBOPHY_CR2_MODESEL, val);
+}
+
+static int stm32_combophy_enable_clocks(struct stm32_combophy *combophy)
+{
+	int ret;
+
+	ret = clk_prepare_enable(combophy->phy_clk);
+	if (ret) {
+		dev_err(combophy->dev, "Core clock enable failed %d\n", ret);
+		return ret;
+	}
+
+	ret = clk_prepare_enable(combophy->ker_clk);
+	if (ret) {
+		dev_err(combophy->dev, "ker_usb3pcie clock enable failed %d\n", ret);
+		clk_disable_unprepare(combophy->phy_clk);
+		return ret;
+	}
+
+	if (combophy->pad_clk) {
+		ret = clk_prepare_enable(combophy->pad_clk);
+		if (ret) {
+			dev_err(combophy->dev, "External clock enable failed %d\n", ret);
+			clk_disable_unprepare(combophy->ker_clk);
+			clk_disable_unprepare(combophy->phy_clk);
+			return ret;
+		}
+	}
+
+	return 0;
+}
+
+static void stm32_combophy_disable_clocks(struct stm32_combophy *combophy)
+{
+	if (combophy->pad_clk)
+		clk_disable_unprepare(combophy->pad_clk);
+	clk_disable_unprepare(combophy->ker_clk);
+	clk_disable_unprepare(combophy->phy_clk);
+}
+
+static int stm32_combophy_suspend_noirq(struct device *dev)
+{
+	struct stm32_combophy *combophy = dev_get_drvdata(dev);
+
+	/*
+	 * Clocks should be turned off since it is not needed for
+	 * wakeup capability. In case usb-remote wakeup is not enabled,
+	 * combo-phy is already turned off by HCD driver using exit callback
+	 */
+	if (combophy->is_init) {
+		stm32_combophy_disable_clocks(combophy);
+
+		/* since wakeup is enabled for ctrl */
+		enable_irq_wake(combophy->irq_wakeup);
+	}
+
+	return 0;
+}
+
+static int stm32_combophy_resume_noirq(struct device *dev)
+{
+	struct stm32_combophy *combophy = dev_get_drvdata(dev);
+	int ret;
+
+	/*
+	 * If clocks was turned off by suspend call for wakeup then needs
+	 * to be turned back ON in resume. In case usb-remote wakeup is not
+	 * enabled, clocks already turned ON by HCD driver using init callback
+	 */
+	if (combophy->is_init) {
+		/* since wakeup was enabled for ctrl */
+		disable_irq_wake(combophy->irq_wakeup);
+
+		ret = stm32_combophy_enable_clocks(combophy);
+		if (ret) {
+			dev_err(dev, "can't enable clocks (%d)\n", ret);
+			return ret;
+		}
+	}
+
+	return 0;
+}
+
+static int stm32_combophy_exit(struct phy *phy)
+{
+	struct stm32_combophy *combophy = phy_get_drvdata(phy);
+	struct device *dev = combophy->dev;
+
+	combophy->is_init = false;
+
+	if (combophy->type == PHY_TYPE_PCIE && !combophy->pad_clk)
+		regmap_update_bits(combophy->regmap, SYSCFG_PCIEPRGCR,
+				   STM32MP25_PCIEPRGCR_EN, 0);
+
+	if (combophy->type != PHY_TYPE_PCIE)
+		regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
+				   SYSCFG_COMBOPHY_CR1_REFSSPEN, 0);
+
+	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR2,
+			   SYSCFG_COMBOPHY_CR2_ISO_DIS, 0);
+
+	stm32_combophy_disable_clocks(combophy);
+
+	pm_runtime_put_noidle(dev);
+
+	return 0;
+}
+
+static int stm32_combophy_init(struct phy *phy)
+{
+	struct stm32_combophy *combophy = phy_get_drvdata(phy);
+	struct device *dev = combophy->dev;
+	int ret;
+
+	pm_runtime_get_noresume(dev);
+
+	ret = stm32_combophy_enable_clocks(combophy);
+	if (ret) {
+		dev_err(dev, "Clock enable failed %d\n", ret);
+		pm_runtime_put_noidle(dev);
+		return ret;
+	}
+
+	ret = stm32_combophy_set_mode(combophy);
+	if (ret) {
+		dev_err(dev, "combophy mode not set\n");
+		stm32_combophy_disable_clocks(combophy);
+		pm_runtime_put_noidle(dev);
+		return ret;
+	}
+
+	ret = stm32_combophy_pll_init(combophy);
+	if (ret) {
+		stm32_combophy_disable_clocks(combophy);
+		pm_runtime_put_noidle(dev);
+		return ret;
+	}
+
+	pm_runtime_disable(dev);
+	pm_runtime_set_active(dev);
+	pm_runtime_enable(dev);
+
+	combophy->is_init = true;
+
+	return ret;
+}
+
+static const struct phy_ops stm32_combophy_phy_data = {
+	.init = stm32_combophy_init,
+	.exit = stm32_combophy_exit,
+	.owner = THIS_MODULE
+};
+
+static irqreturn_t stm32_combophy_irq_wakeup_handler(int irq, void *dev_id)
+{
+	return IRQ_HANDLED;
+}
+
+static int stm32_combophy_probe(struct platform_device *pdev)
+{
+	struct stm32_combophy *combophy;
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct phy_provider *phy_provider;
+	int ret, irq;
+
+	combophy = devm_kzalloc(dev, sizeof(*combophy), GFP_KERNEL);
+	if (!combophy)
+		return -ENOMEM;
+
+	combophy->dev = dev;
+
+	dev_set_drvdata(dev, combophy);
+
+	combophy->base = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(combophy->base))
+		return PTR_ERR(combophy->base);
+
+	combophy->phy_clk = devm_clk_get(dev, "apb");
+	if (IS_ERR(combophy->phy_clk))
+		return dev_err_probe(dev, PTR_ERR(combophy->phy_clk),
+				     "Failed to get PHY clock source\n");
+
+	combophy->ker_clk = devm_clk_get(dev, "ker");
+	if (IS_ERR(combophy->ker_clk))
+		return dev_err_probe(dev, PTR_ERR(combophy->ker_clk),
+				     "Failed to get PHY internal clock source\n");
+
+	combophy->pad_clk = devm_clk_get_optional(dev, "pad");
+	if (IS_ERR(combophy->pad_clk))
+		return dev_err_probe(dev, PTR_ERR(combophy->pad_clk),
+				     "Failed to get PHY external clock source\n");
+
+	combophy->phy_reset = devm_reset_control_get(dev, "phy");
+	if (IS_ERR(combophy->phy_reset))
+		return dev_err_probe(dev, PTR_ERR(combophy->phy_reset),
+				     "Failed to get PHY reset\n");
+
+	combophy->regmap = syscon_regmap_lookup_by_phandle(np, "st,syscfg");
+	if (IS_ERR(combophy->regmap))
+		return dev_err_probe(dev, PTR_ERR(combophy->regmap),
+				     "No syscfg phandle specified\n");
+
+	combophy->phy = devm_phy_create(dev, NULL, &stm32_combophy_phy_data);
+	if (IS_ERR(combophy->phy))
+		return dev_err_probe(dev, PTR_ERR(combophy->phy),
+				     "failed to create PCIe/USB3 ComboPHY\n");
+
+	if (device_property_read_bool(dev, "wakeup-source")) {
+		irq = platform_get_irq(pdev, 0);
+		if (irq < 0)
+			return dev_err_probe(dev, irq, "failed to get IRQ\n");
+		combophy->irq_wakeup = irq;
+
+		ret = devm_request_threaded_irq(dev, combophy->irq_wakeup, NULL,
+						stm32_combophy_irq_wakeup_handler, IRQF_ONESHOT,
+						NULL, NULL);
+		if (ret)
+			return dev_err_probe(dev, ret, "unable to request wake IRQ %d\n",
+						 combophy->irq_wakeup);
+	}
+
+	ret = devm_pm_runtime_enable(dev);
+	if (ret)
+		return dev_err_probe(dev, ret, "Failed to enable pm runtime\n");
+
+	phy_set_drvdata(combophy->phy, combophy);
+
+	phy_provider = devm_of_phy_provider_register(dev, stm32_combophy_xlate);
+
+	return PTR_ERR_OR_ZERO(phy_provider);
+}
+
+static const struct dev_pm_ops stm32_combophy_pm_ops = {
+	NOIRQ_SYSTEM_SLEEP_PM_OPS(stm32_combophy_suspend_noirq,
+				  stm32_combophy_resume_noirq)
+};
+
+static const struct of_device_id stm32_combophy_of_match[] = {
+	{ .compatible = "st,stm32mp25-combophy", },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, stm32_combophy_of_match);
+
+static struct platform_driver stm32_combophy_driver = {
+	.probe = stm32_combophy_probe,
+	.driver = {
+		   .name = "stm32-combophy",
+		   .of_match_table = stm32_combophy_of_match,
+		   .pm = pm_sleep_ptr(&stm32_combophy_pm_ops)
+	}
+};
+
+module_platform_driver(stm32_combophy_driver);
+
+MODULE_AUTHOR("Christian Bruel <christian.bruel at foss.st.com>");
+MODULE_DESCRIPTION("STM32MP25 Combophy USB3/PCIe controller driver");
+MODULE_LICENSE("GPL");
-- 
2.34.1



From christian.bruel at foss.st.com  Tue Aug 27 05:24:59 2024
From: christian.bruel at foss.st.com (Christian Bruel)
Date: Tue, 27 Aug 2024 14:24:59 +0200
Subject: [PATCH 5/5] arm64: dts: st: Enable COMBOPHY on the stm32mp257f-ev1 board
In-Reply-To: <20240827122459.1102889-1-christian.bruel@foss.st.com>
References: <20240827122459.1102889-1-christian.bruel@foss.st.com>
Message-ID: <20240827122459.1102889-6-christian.bruel@foss.st.com>

Enable the COMBOPHY with external pad clock on stm32mp257f-ev1
board, to be used for the PCIe clock provider.

Signed-off-by: Christian Bruel <christian.bruel at foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp257f-ev1.dts | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts b/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
index 214191a8322b..bcf84d533cb2 100644
--- a/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
+++ b/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
@@ -27,6 +27,14 @@ chosen {
 		stdout-path = "serial0:115200n8";
 	};
 
+	clocks {
+		pad_clk: pad-clk {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <100000000>;
+		};
+	};
+
 	memory at 80000000 {
 		device_type = "memory";
 		reg = <0x0 0x80000000 0x1 0x0>;
@@ -50,6 +58,12 @@ &arm_wdt {
 	status = "okay";
 };
 
+&combophy {
+	clocks = <&rcc CK_BUS_USB3PCIEPHY>, <&rcc CK_KER_USB3PCIEPHY>, <&pad_clk>;
+	clock-names = "apb", "ker", "pad";
+	status = "okay";
+};
+
 &ethernet2 {
 	pinctrl-names = "default", "sleep";
 	pinctrl-0 = <&eth2_rgmii_pins_a>;
-- 
2.34.1



From robh at kernel.org  Tue Aug 27 05:31:41 2024
From: robh at kernel.org (Rob Herring (Arm))
Date: Tue, 27 Aug 2024 07:31:41 -0500
Subject: [PATCH 0/8] Add support for PCIe3 on x1e80100
In-Reply-To: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
References: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
Message-ID: <172476183902.3553327.3757950028426438486.robh@kernel.org>


On Mon, 26 Aug 2024 23:36:23 -0700, Qiang Yu wrote:
> This series add support for PCIe3 on x1e80100.
> 
> PCIe3 needs additional set of clocks, regulators and new set of PCIe QMP
> PHY configuration compare other PCIe instances on x1e80100. Hence add
> required resource configuration and usage for PCIe3.
> 
> Qiang Yu (8):
>   phy: qcom-qmp: pcs-pcie: Add v6.30 register offsets
>   phy: qcom-qmp: pcs: Add v6.30 register offsets
>   phy: qcom: qmp: Add phy register and clk setting for x1e80100 PCIe3
>   arm64: dts: qcom: x1e80100: Add support for PCIe3 on x1e80100
>   dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Document the X1E80100
>     QMP PCIe PHY Gen4 x8
>   clk: qcom: gcc-x1e80100: Fix halt_check for pipediv2 clocks
>   arm64: dts: qcom: x1e80100-qcp: Add power supply and sideband signal
>     for pcie3
>   PCI: qcom: Add support to PCIe slot power supplies
> 
>  .../phy/qcom,sc8280xp-qmp-pcie-phy.yaml       |  18 +-
>  arch/arm64/boot/dts/qcom/x1e80100-qcp.dts     | 116 +++++++++
>  arch/arm64/boot/dts/qcom/x1e80100.dtsi        | 205 +++++++++++++++-
>  drivers/clk/qcom/gcc-x1e80100.c               |  10 +-
>  drivers/pci/controller/dwc/pcie-qcom.c        |  52 +++-
>  drivers/phy/qualcomm/phy-qcom-qmp-pcie.c      | 222 +++++++++++++++++-
>  .../qualcomm/phy-qcom-qmp-pcs-pcie-v6_30.h    |  25 ++
>  drivers/phy/qualcomm/phy-qcom-qmp-pcs-v6_30.h |  19 ++
>  8 files changed, 657 insertions(+), 10 deletions(-)
>  create mode 100644 drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v6_30.h
>  create mode 100644 drivers/phy/qualcomm/phy-qcom-qmp-pcs-v6_30.h
> 
> --
> 2.34.1
> 
> 
> 


My bot found new DTB warnings on the .dts files added or changed in this
series.

Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.

If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:

  pip3 install dtschema --upgrade


New warnings running 'make CHECK_DTBS=y qcom/x1e80100-qcp.dtb' for 20240827063631.3932971-1-quic_qianyu at quicinc.com:

arch/arm64/boot/dts/qcom/x1e80100-qcp.dtb: pci at 1bd0000: reg: [[0, 29163520, 0, 12288], [0, 2013265920, 0, 3869], [0, 2013269824, 0, 168], [0, 2013270016, 0, 4096], [0, 2014314496, 0, 1048576]] is too short
	from schema $id: http://devicetree.org/schemas/pci/qcom,pcie-x1e80100.yaml#
arch/arm64/boot/dts/qcom/x1e80100-qcp.dtb: pci at 1bd0000: reg-names: ['parf', 'dbi', 'elbi', 'atu', 'config'] is too short
	from schema $id: http://devicetree.org/schemas/pci/qcom,pcie-x1e80100.yaml#
arch/arm64/boot/dts/qcom/x1e80100-qcp.dtb: pci at 1bd0000: clocks: [[53, 348], [53, 84], [53, 86], [53, 87], [53, 94], [53, 95], [53, 22], [53, 33]] is too long
	from schema $id: http://devicetree.org/schemas/pci/qcom,pcie-x1e80100.yaml#
arch/arm64/boot/dts/qcom/x1e80100-qcp.dtb: pci at 1bd0000: clock-names:0: 'aux' was expected
	from schema $id: http://devicetree.org/schemas/pci/qcom,pcie-x1e80100.yaml#
arch/arm64/boot/dts/qcom/x1e80100-qcp.dtb: pci at 1bd0000: clock-names:1: 'cfg' was expected
	from schema $id: http://devicetree.org/schemas/pci/qcom,pcie-x1e80100.yaml#
arch/arm64/boot/dts/qcom/x1e80100-qcp.dtb: pci at 1bd0000: clock-names:2: 'bus_master' was expected
	from schema $id: http://devicetree.org/schemas/pci/qcom,pcie-x1e80100.yaml#
arch/arm64/boot/dts/qcom/x1e80100-qcp.dtb: pci at 1bd0000: clock-names:3: 'bus_slave' was expected
	from schema $id: http://devicetree.org/schemas/pci/qcom,pcie-x1e80100.yaml#
arch/arm64/boot/dts/qcom/x1e80100-qcp.dtb: pci at 1bd0000: clock-names:4: 'slave_q2a' was expected
	from schema $id: http://devicetree.org/schemas/pci/qcom,pcie-x1e80100.yaml#
arch/arm64/boot/dts/qcom/x1e80100-qcp.dtb: pci at 1bd0000: clock-names:5: 'noc_aggr' was expected
	from schema $id: http://devicetree.org/schemas/pci/qcom,pcie-x1e80100.yaml#
arch/arm64/boot/dts/qcom/x1e80100-qcp.dtb: pci at 1bd0000: clock-names:6: 'cnoc_sf_axi' was expected
	from schema $id: http://devicetree.org/schemas/pci/qcom,pcie-x1e80100.yaml#
arch/arm64/boot/dts/qcom/x1e80100-qcp.dtb: pci at 1bd0000: clock-names: ['pipe_clk_src', 'aux', 'cfg', 'bus_master', 'bus_slave', 'slave_q2a', 'noc_aggr', 'cnoc_sf_axi'] is too long
	from schema $id: http://devicetree.org/schemas/pci/qcom,pcie-x1e80100.yaml#
arch/arm64/boot/dts/qcom/x1e80100-qcp.dtb: pci at 1bd0000: Unevaluated properties are not allowed ('operating-points-v2', 'opp-table' were unexpected)
	from schema $id: http://devicetree.org/schemas/pci/qcom,pcie-x1e80100.yaml#
arch/arm64/boot/dts/qcom/x1e80100-qcp.dtb: phy at 1be0000: clock-names:4: 'pipe' was expected
	from schema $id: http://devicetree.org/schemas/phy/qcom,sc8280xp-qmp-pcie-phy.yaml#
arch/arm64/boot/dts/qcom/x1e80100-qcp.dtb: phy at 1be0000: clock-names:5: 'pipediv2' was expected
	from schema $id: http://devicetree.org/schemas/phy/qcom,sc8280xp-qmp-pcie-phy.yaml#
arch/arm64/boot/dts/qcom/x1e80100-qcp.dtb: phy at 1be0000: clock-names:6: 'phy_aux' was expected
	from schema $id: http://devicetree.org/schemas/phy/qcom,sc8280xp-qmp-pcie-phy.yaml#
arch/arm64/boot/dts/qcom/x1e80100-qcp.dtb: pmic at 3: gpio at 8800: 'pm_sde7_aux_3p3', 'pm_sde7_main_3p3' do not match any of the regexes: '-hog(-[0-9]+)?$', '-state$', 'pinctrl-[0-9]+'
	from schema $id: http://devicetree.org/schemas/mfd/qcom,spmi-pmic.yaml#
arch/arm64/boot/dts/qcom/x1e80100-qcp.dtb: gpio at 8800: 'pm_sde7_aux_3p3', 'pm_sde7_main_3p3' do not match any of the regexes: '-hog(-[0-9]+)?$', '-state$', 'pinctrl-[0-9]+'
	from schema $id: http://devicetree.org/schemas/pinctrl/qcom,pmic-gpio.yaml#
arch/arm64/boot/dts/qcom/x1e80100-qcp.dtb: pmic at 8: gpio at 8800: 'pcie_x8_12v_on' does not match any of the regexes: '-hog(-[0-9]+)?$', '-state$', 'pinctrl-[0-9]+'
	from schema $id: http://devicetree.org/schemas/mfd/qcom,spmi-pmic.yaml#
arch/arm64/boot/dts/qcom/x1e80100-qcp.dtb: gpio at 8800: 'pcie_x8_12v_on' does not match any of the regexes: '-hog(-[0-9]+)?$', '-state$', 'pinctrl-[0-9]+'
	from schema $id: http://devicetree.org/schemas/pinctrl/qcom,pmic-gpio.yaml#







From krzk at kernel.org  Tue Aug 27 06:23:40 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Tue, 27 Aug 2024 15:23:40 +0200
Subject: [PATCH 1/5] dt-bindings: phy: Add STM32MP25 COMBOPHY bindings
In-Reply-To: <20240827122459.1102889-2-christian.bruel@foss.st.com>
References: <20240827122459.1102889-1-christian.bruel@foss.st.com>
 <20240827122459.1102889-2-christian.bruel@foss.st.com>
Message-ID: <5f29a065-269d-4e72-81b8-30d247994fbd@kernel.org>

On 27/08/2024 14:24, Christian Bruel wrote:
> Document the bindings for STM32 COMBOPHY interface, used to support
> the PCIe and USB3 stm32mp25 drivers.
> Following entries can be used to tune caracterisation parameters
>  - st,output-micro-ohms and st,output-vswing-microvolt bindings entries
> to tune the impedance and voltage swing using discrete simulation results
>  - st,rx-equalizer register to set the internal rx equalizer filter value.
> 
> Reviewed-by: Rob Herring (Arm) <robh at kernel.org>
> Signed-off-by: Christian Bruel <christian.bruel at foss.st.com>

v1? Or v3?

> ---
>  .../bindings/phy/st,stm32-combophy.yaml       | 144 ++++++++++++++++++
>  1 file changed, 144 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml
> 
> diff --git a/Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml b/Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml
> new file mode 100644
> index 000000000000..c33a843b83a3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml

Filename matching compatible.

> @@ -0,0 +1,144 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/st,stm32-combophy.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: STMicroelectronics STM32MP25 USB3/PCIe COMBOPHY
> +
> +maintainers:
> +  - Christian Bruel <christian.bruel at foss.st.com>
> +
> +description:
> +  Single lane PHY shared (exclusive) between the USB3 and PCIe controllers.
> +  Supports 5Gbit/s for USB3 and PCIe gen2 or 2.5Gbit/s for PCIe gen1.
> +
> +properties:
> +  compatible:
> +    const: st,stm32mp25-combophy
> +
> +  reg:
> +    maxItems: 1
> +
> +  "#phy-cells":
> +    const: 1
> +    description: |
> +      The cells contain the following arguments.
> +
> +      - description: The PHY type

That's some sort of mess. Is it schema within description or schema? Why
two descriptions?

> +          enum:
> +            - PHY_TYPE_USB3
> +            - PHY_TYPE_PCIE
> +

...

> +required:
> +  - compatible
> +  - reg
> +  - st,syscfg
> +  - '#phy-cells'
> +  - resets
> +  - reset-names
> +  - clocks
> +  - clock-names
> +
> +allOf:
> +  - if:
> +      required:
> +        - wakeup-source
> +    then:
> +      anyOf:
> +        - required: [interrupts]
> +        - required: [interrupts-extended]
> +

I do not see any improvements.

The tag you received was CONDITIONAL. If you do not apply the comments,
you cannot just apply the tag.

Best regards,
Krzysztof



From krzk at kernel.org  Tue Aug 27 06:23:56 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Tue, 27 Aug 2024 15:23:56 +0200
Subject: [PATCH v3 0/5] Add STM32MP25 USB3/PCIE COMBOPHY driver
In-Reply-To: <20240827122459.1102889-1-christian.bruel@foss.st.com>
References: <20240827122459.1102889-1-christian.bruel@foss.st.com>
Message-ID: <2e634ee8-7622-4eb8-ba5b-0d218bb092eb@kernel.org>

On 27/08/2024 14:24, Christian Bruel wrote:
> This patch series adds USB3/PCIE COMBOPHY driver for the STM32MP25 SoC from
> STMicrolectronics, respective yaml schema and enable for the stm32mp257f-ev1
> device into which it is used for PCIe.
> 
> Changes in v3:
> Address comments from Rob and Krzysztof:
>    - Reorder MAINTAINERS patch
>    - Drop wakeup-source from bindings (should be generic)

Where? Point me to the exact line being dropped.

Best regards,
Krzysztof



From manivannan.sadhasivam at linaro.org  Tue Aug 27 09:58:26 2024
From: manivannan.sadhasivam at linaro.org (Manivannan Sadhasivam)
Date: Tue, 27 Aug 2024 22:28:26 +0530
Subject: [PATCH 8/8] PCI: qcom: Add support to PCIe slot power supplies
In-Reply-To: <CAA8EJpq5KergZ8czg4F=EYMLANoOeBsiSVoO-zAgfG0ezQrKCQ@mail.gmail.com>
References: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
 <20240827063631.3932971-9-quic_qianyu@quicinc.com>
 <CAA8EJpq5KergZ8czg4F=EYMLANoOeBsiSVoO-zAgfG0ezQrKCQ@mail.gmail.com>
Message-ID: <20240827165826.moe6cnemeheos6jn@thinkpad>

On Tue, Aug 27, 2024 at 02:44:09PM +0300, Dmitry Baryshkov wrote:
> On Tue, 27 Aug 2024 at 09:36, Qiang Yu <quic_qianyu at quicinc.com> wrote:
> >
> > On platform x1e80100 QCP, PCIe3 is a standard x8 form factor. Hence, add
> > support to use 3.3v, 3.3v aux and 12v regulators.
> 
> First of all, I don't see corresponding bindings change.
> 
> Second, these supplies power up the slot, not the host controller
> itself. As such these supplies do not belong to the host controller
> entry. Please consider using the pwrseq framework instead.
> 

Indeed. For legacy reasons, slot power supplies were populated in the host
bridge node itself until recently Rob started objecting it [1]. And it makes
real sense to put these supplies in the root port node and handle them in the
relevant driver.

I'm still evaluating whether the handling should be done in the portdrv or
pwrctl driver, but haven't reached the conclusion. Pwrctl seems to be the ideal
choice, but I see a few issues related to handling the OF node for the root
port.

Hope I'll come to a conclusion in the next few days and will update this thread.

- Mani

[1] https://lore.kernel.org/lkml/20240604235806.GA1903493-robh at kernel.org/

> >
> > Signed-off-by: Qiang Yu <quic_qianyu at quicinc.com>
> > ---
> >  drivers/pci/controller/dwc/pcie-qcom.c | 52 +++++++++++++++++++++++++-
> >  1 file changed, 50 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
> > index 6f953e32d990..59fb415dfeeb 100644
> > --- a/drivers/pci/controller/dwc/pcie-qcom.c
> > +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> > @@ -248,6 +248,8 @@ struct qcom_pcie_cfg {
> >         bool no_l0s;
> >  };
> >
> > +#define QCOM_PCIE_SLOT_MAX_SUPPLIES                    3
> > +
> >  struct qcom_pcie {
> >         struct dw_pcie *pci;
> >         void __iomem *parf;                     /* DT parf */
> > @@ -260,6 +262,7 @@ struct qcom_pcie {
> >         struct icc_path *icc_cpu;
> >         const struct qcom_pcie_cfg *cfg;
> >         struct dentry *debugfs;
> > +       struct regulator_bulk_data slot_supplies[QCOM_PCIE_SLOT_MAX_SUPPLIES];
> >         bool suspended;
> >         bool use_pm_opp;
> >  };
> > @@ -1174,6 +1177,41 @@ static int qcom_pcie_link_up(struct dw_pcie *pci)
> >         return !!(val & PCI_EXP_LNKSTA_DLLLA);
> >  }
> >
> > +static int qcom_pcie_enable_slot_supplies(struct qcom_pcie *pcie)
> > +{
> > +       struct dw_pcie *pci = pcie->pci;
> > +       int ret;
> > +
> > +       ret = regulator_bulk_enable(ARRAY_SIZE(pcie->slot_supplies),
> > +                                   pcie->slot_supplies);
> > +       if (ret < 0)
> > +               dev_err(pci->dev, "Failed to enable slot regulators\n");
> > +
> > +       return ret;
> > +}
> > +
> > +static void qcom_pcie_disable_slot_supplies(struct qcom_pcie *pcie)
> > +{
> > +       regulator_bulk_disable(ARRAY_SIZE(pcie->slot_supplies),
> > +                              pcie->slot_supplies);
> > +}
> > +
> > +static int qcom_pcie_get_slot_supplies(struct qcom_pcie *pcie)
> > +{
> > +       struct dw_pcie *pci = pcie->pci;
> > +       int ret;
> > +
> > +       pcie->slot_supplies[0].supply = "vpcie12v";
> > +       pcie->slot_supplies[1].supply = "vpcie3v3";
> > +       pcie->slot_supplies[2].supply = "vpcie3v3aux";
> > +       ret = devm_regulator_bulk_get(pci->dev, ARRAY_SIZE(pcie->slot_supplies),
> > +                                     pcie->slot_supplies);
> > +       if (ret < 0)
> > +               dev_err(pci->dev, "Failed to get slot regulators\n");
> > +
> > +       return ret;
> > +}
> > +
> >  static int qcom_pcie_host_init(struct dw_pcie_rp *pp)
> >  {
> >         struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> > @@ -1182,10 +1220,14 @@ static int qcom_pcie_host_init(struct dw_pcie_rp *pp)
> >
> >         qcom_ep_reset_assert(pcie);
> >
> > -       ret = pcie->cfg->ops->init(pcie);
> > +       ret = qcom_pcie_enable_slot_supplies(pcie);
> >         if (ret)
> >                 return ret;
> >
> > +       ret = pcie->cfg->ops->init(pcie);
> > +       if (ret)
> > +               goto err_disable_slot;
> > +
> >         ret = phy_set_mode_ext(pcie->phy, PHY_MODE_PCIE, PHY_MODE_PCIE_RC);
> >         if (ret)
> >                 goto err_deinit;
> > @@ -1216,7 +1258,8 @@ static int qcom_pcie_host_init(struct dw_pcie_rp *pp)
> >         phy_power_off(pcie->phy);
> >  err_deinit:
> >         pcie->cfg->ops->deinit(pcie);
> > -
> > +err_disable_slot:
> > +       qcom_pcie_disable_slot_supplies(pcie);
> >         return ret;
> >  }
> >
> > @@ -1228,6 +1271,7 @@ static void qcom_pcie_host_deinit(struct dw_pcie_rp *pp)
> >         qcom_ep_reset_assert(pcie);
> >         phy_power_off(pcie->phy);
> >         pcie->cfg->ops->deinit(pcie);
> > +       qcom_pcie_disable_slot_supplies(pcie);
> >  }
> >
> >  static void qcom_pcie_host_post_init(struct dw_pcie_rp *pp)
> > @@ -1602,6 +1646,10 @@ static int qcom_pcie_probe(struct platform_device *pdev)
> >                         goto err_pm_runtime_put;
> >         }
> >
> > +       ret = qcom_pcie_get_slot_supplies(pcie);
> > +       if (ret)
> > +               goto err_pm_runtime_put;
> > +
> >         ret = pcie->cfg->ops->get_resources(pcie);
> >         if (ret)
> >                 goto err_pm_runtime_put;
> > --
> > 2.34.1
> >
> 
> 
> -- 
> With best wishes
> Dmitry

-- 
????????? ????????


From shawnguo2 at yeah.net  Tue Aug 27 18:44:00 2024
From: shawnguo2 at yeah.net (Shawn Guo)
Date: Wed, 28 Aug 2024 09:44:00 +0800
Subject: [PATCH v2 6/6] ARM: dts: imx7ulp: add "nxp,sim" property for
 usbphy1
In-Reply-To: <20240826065612.ol4fjib4g2jrvoy7@hippo>
References: <20240726113207.3393247-1-xu.yang_2@nxp.com>
 <20240726113207.3393247-6-xu.yang_2@nxp.com>
 <20240826065612.ol4fjib4g2jrvoy7@hippo>
Message-ID: <Zs6A4OEgaC8a3gcw@dragon>

On Mon, Aug 26, 2024 at 02:56:12PM +0800, Xu Yang wrote:
> Hi Shawn,
> 
> On Fri, Jul 26, 2024 at 07:32:07PM +0800, Xu Yang wrote:
> > i.MX7ULP need properly set System Integration Module(SIM) module to make
> > usb wakeup work well. This will add a "nxp,sim" property for usbphy1.
> > 
> > Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> > 
> > ---
> > Changes in v2:
> >  - no changes
> > ---
> >  arch/arm/boot/dts/nxp/imx/imx7ulp.dtsi | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/arch/arm/boot/dts/nxp/imx/imx7ulp.dtsi b/arch/arm/boot/dts/nxp/imx/imx7ulp.dtsi
> > index ac338320ac1d..b093f2a447ae 100644
> > --- a/arch/arm/boot/dts/nxp/imx/imx7ulp.dtsi
> > +++ b/arch/arm/boot/dts/nxp/imx/imx7ulp.dtsi
> > @@ -214,6 +214,7 @@ usbphy1: usb-phy at 40350000 {
> >  			interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
> >  			clocks = <&pcc2 IMX7ULP_CLK_USB_PHY>;
> >  			#phy-cells = <0>;
> > +			nxp,sim = <&sim>;
> >  		};
> >  
> >  		usdhc0: mmc at 40370000 {
> 
> Could you please pick up patch 3 and 6?

Patch #3 should go via usb tree, and ping me on #6 after #3 is applied.

Shawn



From aford173 at gmail.com  Tue Aug 27 19:48:01 2024
From: aford173 at gmail.com (Adam Ford)
Date: Tue, 27 Aug 2024 21:48:01 -0500
Subject: [RFC 1/2] phy: freescale: fsl-samsung-hdmi: Replace register defines with macro
Message-ID: <20240828024813.1353572-1-aford173@gmail.com>

There are 47 registers defined as PHY_REG_xx were xx goes from 00 to
47.  Simplify this by replacing them all with a macro which is passed
the register number to return the proper register offset.

Signed-off-by: Adam Ford <aford173 at gmail.com>

diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
index 9048cdc760c2..bc5d3625ece6 100644
--- a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
+++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
@@ -14,76 +14,20 @@
 #include <linux/platform_device.h>
 #include <linux/pm_runtime.h>
 
-#define PHY_REG_00		0x00
-#define PHY_REG_01		0x04
-#define PHY_REG_02		0x08
-#define PHY_REG_08		0x20
-#define PHY_REG_09		0x24
-#define PHY_REG_10		0x28
-#define PHY_REG_11		0x2c
-
-#define PHY_REG_12		0x30
-#define  REG12_CK_DIV_MASK	GENMASK(5, 4)
-
-#define PHY_REG_13		0x34
-#define  REG13_TG_CODE_LOW_MASK	GENMASK(7, 0)
-
-#define PHY_REG_14		0x38
-#define  REG14_TOL_MASK		GENMASK(7, 4)
-#define  REG14_RP_CODE_MASK	GENMASK(3, 1)
-#define  REG14_TG_CODE_HIGH_MASK	GENMASK(0, 0)
-
-#define PHY_REG_15		0x3c
-#define PHY_REG_16		0x40
-#define PHY_REG_17		0x44
-#define PHY_REG_18		0x48
-#define PHY_REG_19		0x4c
-#define PHY_REG_20		0x50
-
-#define PHY_REG_21		0x54
-#define  REG21_SEL_TX_CK_INV	BIT(7)
-#define  REG21_PMS_S_MASK	GENMASK(3, 0)
-
-#define PHY_REG_22		0x58
-#define PHY_REG_23		0x5c
-#define PHY_REG_24		0x60
-#define PHY_REG_25		0x64
-#define PHY_REG_26		0x68
-#define PHY_REG_27		0x6c
-#define PHY_REG_28		0x70
-#define PHY_REG_29		0x74
-#define PHY_REG_30		0x78
-#define PHY_REG_31		0x7c
-#define PHY_REG_32		0x80
-
-/*
- * REG33 does not match the ref manual. According to Sandor Yu from NXP,
- * "There is a doc issue on the i.MX8MP latest RM"
- * REG33 is being used per guidance from Sandor
- */
-
-#define PHY_REG_33		0x84
-#define  REG33_MODE_SET_DONE	BIT(7)
-#define  REG33_FIX_DA		BIT(1)
-
-#define PHY_REG_34		0x88
-#define  REG34_PHY_READY	BIT(7)
-#define  REG34_PLL_LOCK		BIT(6)
-#define  REG34_PHY_CLK_READY	BIT(5)
-
-#define PHY_REG_35		0x8c
-#define PHY_REG_36		0x90
-#define PHY_REG_37		0x94
-#define PHY_REG_38		0x98
-#define PHY_REG_39		0x9c
-#define PHY_REG_40		0xa0
-#define PHY_REG_41		0xa4
-#define PHY_REG_42		0xa8
-#define PHY_REG_43		0xac
-#define PHY_REG_44		0xb0
-#define PHY_REG_45		0xb4
-#define PHY_REG_46		0xb8
-#define PHY_REG_47		0xbc
+#define PHY_REG(reg)		(reg * 4)
+
+#define REG12_CK_DIV_MASK	GENMASK(5, 4)
+#define REG13_TG_CODE_LOW_MASK	GENMASK(7, 0)
+#define REG14_TOL_MASK		GENMASK(7, 4)
+#define REG14_RP_CODE_MASK	GENMASK(3, 1)
+#define REG14_TG_CODE_HIGH_MASK	GENMASK(0, 0)
+#define REG21_SEL_TX_CK_INV	BIT(7)
+#define REG21_PMS_S_MASK	GENMASK(3, 0)
+#define REG33_MODE_SET_DONE	BIT(7)
+#define REG33_FIX_DA		BIT(1)
+#define REG34_PHY_READY	BIT(7)
+#define REG34_PLL_LOCK		BIT(6)
+#define REG34_PHY_CLK_READY	BIT(5)
 
 #define PHY_PLL_DIV_REGS_NUM 6
 
@@ -369,29 +313,29 @@ struct reg_settings {
 };
 
 static const struct reg_settings common_phy_cfg[] = {
-	{ PHY_REG_00, 0x00 }, { PHY_REG_01, 0xd1 },
-	{ PHY_REG_08, 0x4f }, { PHY_REG_09, 0x30 },
-	{ PHY_REG_10, 0x33 }, { PHY_REG_11, 0x65 },
+	{ PHY_REG(0), 0x00 }, { PHY_REG(1), 0xd1 },
+	{ PHY_REG(8), 0x4f }, { PHY_REG(9), 0x30 },
+	{ PHY_REG(10), 0x33 }, { PHY_REG(11), 0x65 },
 	/* REG12 pixclk specific */
 	/* REG13 pixclk specific */
 	/* REG14 pixclk specific */
-	{ PHY_REG_15, 0x80 }, { PHY_REG_16, 0x6c },
-	{ PHY_REG_17, 0xf2 }, { PHY_REG_18, 0x67 },
-	{ PHY_REG_19, 0x00 }, { PHY_REG_20, 0x10 },
+	{ PHY_REG(15), 0x80 }, { PHY_REG(16), 0x6c },
+	{ PHY_REG(17), 0xf2 }, { PHY_REG(18), 0x67 },
+	{ PHY_REG(19), 0x00 }, { PHY_REG(20), 0x10 },
 	/* REG21 pixclk specific */
-	{ PHY_REG_22, 0x30 }, { PHY_REG_23, 0x32 },
-	{ PHY_REG_24, 0x60 }, { PHY_REG_25, 0x8f },
-	{ PHY_REG_26, 0x00 }, { PHY_REG_27, 0x00 },
-	{ PHY_REG_28, 0x08 }, { PHY_REG_29, 0x00 },
-	{ PHY_REG_30, 0x00 }, { PHY_REG_31, 0x00 },
-	{ PHY_REG_32, 0x00 }, { PHY_REG_33, 0x80 },
-	{ PHY_REG_34, 0x00 }, { PHY_REG_35, 0x00 },
-	{ PHY_REG_36, 0x00 }, { PHY_REG_37, 0x00 },
-	{ PHY_REG_38, 0x00 }, { PHY_REG_39, 0x00 },
-	{ PHY_REG_40, 0x00 }, { PHY_REG_41, 0xe0 },
-	{ PHY_REG_42, 0x83 }, { PHY_REG_43, 0x0f },
-	{ PHY_REG_44, 0x3E }, { PHY_REG_45, 0xf8 },
-	{ PHY_REG_46, 0x00 }, { PHY_REG_47, 0x00 }
+	{ PHY_REG(22), 0x30 }, { PHY_REG(23), 0x32 },
+	{ PHY_REG(24), 0x60 }, { PHY_REG(25), 0x8f },
+	{ PHY_REG(26), 0x00 }, { PHY_REG(27), 0x00 },
+	{ PHY_REG(28), 0x08 }, { PHY_REG(29), 0x00 },
+	{ PHY_REG(30), 0x00 }, { PHY_REG(31), 0x00 },
+	{ PHY_REG(32), 0x00 }, { PHY_REG(33), 0x80 },
+	{ PHY_REG(34), 0x00 }, { PHY_REG(35), 0x00 },
+	{ PHY_REG(36), 0x00 }, { PHY_REG(37), 0x00 },
+	{ PHY_REG(38), 0x00 }, { PHY_REG(39), 0x00 },
+	{ PHY_REG(40), 0x00 }, { PHY_REG(41), 0xe0 },
+	{ PHY_REG(42), 0x83 }, { PHY_REG(43), 0x0f },
+	{ PHY_REG(44), 0x3E }, { PHY_REG(45), 0xf8 },
+	{ PHY_REG(46), 0x00 }, { PHY_REG(47), 0x00 }
 };
 
 struct fsl_samsung_hdmi_phy {
@@ -442,7 +386,7 @@ fsl_samsung_hdmi_phy_configure_pixclk(struct fsl_samsung_hdmi_phy *phy,
 	}
 
 	writeb(REG21_SEL_TX_CK_INV | FIELD_PREP(REG21_PMS_S_MASK, div),
-	       phy->regs + PHY_REG_21);
+	       phy->regs + PHY_REG(21));
 }
 
 static void
@@ -469,7 +413,7 @@ fsl_samsung_hdmi_phy_configure_pll_lock_det(struct fsl_samsung_hdmi_phy *phy,
 		break;
 	}
 
-	writeb(FIELD_PREP(REG12_CK_DIV_MASK, ilog2(div)), phy->regs + PHY_REG_12);
+	writeb(FIELD_PREP(REG12_CK_DIV_MASK, ilog2(div)), phy->regs + PHY_REG(12));
 
 	/*
 	 * Calculation for the frequency lock detector target code (fld_tg_code)
@@ -489,11 +433,11 @@ fsl_samsung_hdmi_phy_configure_pll_lock_det(struct fsl_samsung_hdmi_phy *phy,
 
 	/* FLD_TOL and FLD_RP_CODE taken from downstream driver */
 	writeb(FIELD_PREP(REG13_TG_CODE_LOW_MASK, fld_tg_code),
-	       phy->regs + PHY_REG_13);
+	       phy->regs + PHY_REG(13));
 	writeb(FIELD_PREP(REG14_TOL_MASK, 2) |
 	       FIELD_PREP(REG14_RP_CODE_MASK, 2) |
 	       FIELD_PREP(REG14_TG_CODE_HIGH_MASK, fld_tg_code >> 8),
-	       phy->regs + PHY_REG_14);
+	       phy->regs + PHY_REG(14));
 }
 
 static int fsl_samsung_hdmi_phy_configure(struct fsl_samsung_hdmi_phy *phy,
@@ -503,7 +447,7 @@ static int fsl_samsung_hdmi_phy_configure(struct fsl_samsung_hdmi_phy *phy,
 	u8 val;
 
 	/* HDMI PHY init */
-	writeb(REG33_FIX_DA, phy->regs + PHY_REG_33);
+	writeb(REG33_FIX_DA, phy->regs + PHY_REG(33));
 
 	/* common PHY registers */
 	for (i = 0; i < ARRAY_SIZE(common_phy_cfg); i++)
@@ -511,14 +455,14 @@ static int fsl_samsung_hdmi_phy_configure(struct fsl_samsung_hdmi_phy *phy,
 
 	/* set individual PLL registers PHY_REG2 ... PHY_REG7 */
 	for (i = 0; i < PHY_PLL_DIV_REGS_NUM; i++)
-		writeb(cfg->pll_div_regs[i], phy->regs + PHY_REG_02 + i * 4);
+		writeb(cfg->pll_div_regs[i], phy->regs + PHY_REG(2) + i * 4);
 
 	fsl_samsung_hdmi_phy_configure_pixclk(phy, cfg);
 	fsl_samsung_hdmi_phy_configure_pll_lock_det(phy, cfg);
 
-	writeb(REG33_FIX_DA | REG33_MODE_SET_DONE, phy->regs + PHY_REG_33);
+	writeb(REG33_FIX_DA | REG33_MODE_SET_DONE, phy->regs + PHY_REG(33));
 
-	ret = readb_poll_timeout(phy->regs + PHY_REG_34, val,
+	ret = readb_poll_timeout(phy->regs + PHY_REG(34), val,
 				 val & REG34_PLL_LOCK, 50, 20000);
 	if (ret)
 		dev_err(phy->dev, "PLL failed to lock\n");
-- 
2.43.0



From aford173 at gmail.com  Tue Aug 27 19:48:02 2024
From: aford173 at gmail.com (Adam Ford)
Date: Tue, 27 Aug 2024 21:48:02 -0500
Subject: [RFC 2/2] phy: freescale: fsl-samsung-hdmi: Support dynamic integer divider
In-Reply-To: <20240828024813.1353572-1-aford173@gmail.com>
References: <20240828024813.1353572-1-aford173@gmail.com>
Message-ID: <20240828024813.1353572-2-aford173@gmail.com>

There is currently a look-up table for a variety of resolutions.
Since the phy has the ability to dynamically calculate the values
necessary to use the intger divider which should allow more
resolutions without having to update the look-up-table.  If the
integer calculator cannot get an exact frequency, it falls back
to the look-up-table.  Because the LUT algorithm does some
rounding, I did not remove integer entries from the LUT.

Signed-off-by: Adam Ford <aford173 at gmail.com>

diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
index bc5d3625ece6..03b598f734e7 100644
--- a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
+++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
@@ -16,6 +16,8 @@
 
 #define PHY_REG(reg)		(reg * 4)
 
+#define REG01_PMS_P_MASK	GENMASK(3, 0)
+#define REG03_PMS_S_MASK	GENMASK(7, 4)
 #define REG12_CK_DIV_MASK	GENMASK(5, 4)
 #define REG13_TG_CODE_LOW_MASK	GENMASK(7, 0)
 #define REG14_TOL_MASK		GENMASK(7, 4)
@@ -31,6 +33,10 @@
 
 #define PHY_PLL_DIV_REGS_NUM 6
 
+#ifndef MHZ
+#define MHZ	(1000UL * 1000UL)
+#endif
+
 struct phy_config {
 	u32	pixclk;
 	u8	pll_div_regs[PHY_PLL_DIV_REGS_NUM];
@@ -440,10 +446,83 @@ fsl_samsung_hdmi_phy_configure_pll_lock_det(struct fsl_samsung_hdmi_phy *phy,
 	       phy->regs + PHY_REG(14));
 }
 
+static unsigned long fsl_samsung_hdmi_phy_find_pms(unsigned long fout, u8 *p, u16 *m, u8 *s)
+{
+	unsigned long best_freq = 0;
+	u32 min_delta = 0xffffffff;
+	u8 _p, best_p;
+	u16 _m, best_m;
+	u8 _s, best_s;
+
+	for (_p = 1; _p <= 11; ++_p) {
+		for (_s = 1; _s <= 16; ++_s) {
+			u64 tmp;
+			u32 delta;
+
+			/* s must be even */
+			if (_s > 1 && (_s & 0x01) == 1)
+				_s++;
+
+			/* _s cannot be 14 per the TRM */
+			if (_s == 14)
+				continue;
+
+			/*
+			 * TODO: Ref Manual doesn't state the range of _m
+			 * so this should be further refined if possible.
+			 * This range was set based on the original values
+			 * in the look-up table
+			 */
+			tmp = (u64)fout * (_p * _s);
+			do_div(tmp, 24 * MHZ);
+			_m = tmp;
+			if (_m < 0x30 || _m > 0x7b)
+				continue;
+
+			/*
+			 * Rev 2 of the Ref Manual states the
+			 * VCO can range between 750MHz and
+			 * 3GHz.  The VCO is assumed to be _m x
+			 * the reference frequency of 24MHz divided
+			 * by the prescaler, _p
+			 */
+			tmp = (u64)_m * 24 * MHZ;
+			do_div(tmp, _p);
+			if (tmp < 750 * MHZ ||
+			    tmp > 3000 * MHZ)
+				continue;
+
+			tmp = (u64)_m * 24 * MHZ;
+			do_div(tmp, _p * _s);
+
+			delta = abs(fout - tmp);
+			if (delta < min_delta) {
+				best_p = _p;
+				best_s = _s;
+				best_m = _m;
+				min_delta = delta;
+				best_freq = tmp;
+			}
+		}
+	}
+
+	if (best_freq) {
+		*p = best_p;
+		*m = best_m;
+		*s = best_s;
+	}
+
+	return best_freq;
+}
+
 static int fsl_samsung_hdmi_phy_configure(struct fsl_samsung_hdmi_phy *phy,
 					  const struct phy_config *cfg)
 {
+	u32 desired_clock = cfg->pixclk * 5;
+	u32 close_freq;
 	int i, ret;
+	u16 m;
+	u8 p, s;
 	u8 val;
 
 	/* HDMI PHY init */
@@ -453,11 +532,38 @@ static int fsl_samsung_hdmi_phy_configure(struct fsl_samsung_hdmi_phy *phy,
 	for (i = 0; i < ARRAY_SIZE(common_phy_cfg); i++)
 		writeb(common_phy_cfg[i].val, phy->regs + common_phy_cfg[i].reg);
 
-	/* set individual PLL registers PHY_REG2 ... PHY_REG7 */
-	for (i = 0; i < PHY_PLL_DIV_REGS_NUM; i++)
-		writeb(cfg->pll_div_regs[i], phy->regs + PHY_REG(2) + i * 4);
+	/* Using the PMS calculator alone, determine if can use integer divider */
+	close_freq = fsl_samsung_hdmi_phy_find_pms(desired_clock, &p, &m, &s);
+
+	/* If the clock cannot be configured with integer divder, use the fractional divider */
+	if (close_freq != desired_clock) {
+		dev_dbg(phy->dev, "fsl_samsung_hdmi_phy: use fractional divider\n");
+		/* set individual PLL registers PHY_REG2 ... PHY_REG7 */
+		for (i = 0; i < PHY_PLL_DIV_REGS_NUM; i++)
+			writeb(cfg->pll_div_regs[i], phy->regs + PHY_REG(2) + i * 4);
+		fsl_samsung_hdmi_phy_configure_pixclk(phy, cfg);
+	} else {
+		dev_dbg(phy->dev, "fsl_samsung_hdmi_phy: use integer divider\n");
+		dev_dbg(phy->dev, "fsl_samsung_hdmi_phy: P = %d\n", p);
+		dev_dbg(phy->dev, "fsl_samsung_hdmi_phy: M = %d\n", m);
+		dev_dbg(phy->dev, "fsl_samsung_hdmi_phy: S = %d\n", s);
+		dev_dbg(phy->dev, "fsl_samsung_hdmi_phy: frequency = %u\n", close_freq);
+
+		/* Write integer divder values for PMS */
+		writeb(FIELD_PREP(REG01_PMS_P_MASK, p), phy->regs + PHY_REG(1));
+		writeb(m, phy->regs + PHY_REG(2));
+		writeb(FIELD_PREP(REG03_PMS_S_MASK, s-1), phy->regs + PHY_REG(3));
+
+		/* Configure PHY to disable fractional divider */
+		writeb(0x00, phy->regs + PHY_REG(4));
+		writeb(0x00, phy->regs + PHY_REG(5));
+		writeb(0x80, phy->regs + PHY_REG(6));
+		writeb(0x00, phy->regs + PHY_REG(7));
+
+		writeb(REG21_SEL_TX_CK_INV | FIELD_PREP(REG21_PMS_S_MASK, s-1),
+		       phy->regs + PHY_REG(21));
+	}
 
-	fsl_samsung_hdmi_phy_configure_pixclk(phy, cfg);
 	fsl_samsung_hdmi_phy_configure_pll_lock_det(phy, cfg);
 
 	writeb(REG33_FIX_DA | REG33_MODE_SET_DONE, phy->regs + PHY_REG(33));
-- 
2.43.0



From christian.bruel at foss.st.com  Wed Aug 28 01:16:14 2024
From: christian.bruel at foss.st.com (Christian Bruel)
Date: Wed, 28 Aug 2024 10:16:14 +0200
Subject: [PATCH 1/5] dt-bindings: phy: Add STM32MP25 COMBOPHY bindings
In-Reply-To: <5f29a065-269d-4e72-81b8-30d247994fbd@kernel.org>
References: <20240827122459.1102889-1-christian.bruel@foss.st.com>
 <20240827122459.1102889-2-christian.bruel@foss.st.com>
 <5f29a065-269d-4e72-81b8-30d247994fbd@kernel.org>
Message-ID: <90ae7f29-19f8-4046-9b27-31739244e045@foss.st.com>


On 8/27/24 15:23, Krzysztof Kozlowski wrote:
> On 27/08/2024 14:24, Christian Bruel wrote:
>> Document the bindings for STM32 COMBOPHY interface, used to support
>> the PCIe and USB3 stm32mp25 drivers.
>> Following entries can be used to tune caracterisation parameters
>>   - st,output-micro-ohms and st,output-vswing-microvolt bindings entries
>> to tune the impedance and voltage swing using discrete simulation results
>>   - st,rx-equalizer register to set the internal rx equalizer filter value.
>>
>> Reviewed-by: Rob Herring (Arm) <robh at kernel.org>
>> Signed-off-by: Christian Bruel <christian.bruel at foss.st.com>
> v1? Or v3?


sorry, forgot to update Subject: it is v3, will resend a v4 with your 
further comments

Regards

Christian

>
>> ---
>>   .../bindings/phy/st,stm32-combophy.yaml       | 144 ++++++++++++++++++
>>   1 file changed, 144 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml b/Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml
>> new file mode 100644
>> index 000000000000..c33a843b83a3
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/st,stm32-combophy.yaml
> Filename matching compatible.

ok

>
>> @@ -0,0 +1,144 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/phy/st,stm32-combophy.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: STMicroelectronics STM32MP25 USB3/PCIe COMBOPHY
>> +
>> +maintainers:
>> +  - Christian Bruel <christian.bruel at foss.st.com>
>> +
>> +description:
>> +  Single lane PHY shared (exclusive) between the USB3 and PCIe controllers.
>> +  Supports 5Gbit/s for USB3 and PCIe gen2 or 2.5Gbit/s for PCIe gen1.
>> +
>> +properties:
>> +  compatible:
>> +    const: st,stm32mp25-combophy
>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  "#phy-cells":
>> +    const: 1
>> +    description: |
>> +      The cells contain the following arguments.
>> +
>> +      - description: The PHY type
> That's some sort of mess. Is it schema within description or schema? Why
> two descriptions?

yes, indeed

>> +          enum:
>> +            - PHY_TYPE_USB3
>> +            - PHY_TYPE_PCIE
>> +
> ...
>
>> +required:
>> +  - compatible
>> +  - reg
>> +  - st,syscfg
>> +  - '#phy-cells'
>> +  - resets
>> +  - reset-names
>> +  - clocks
>> +  - clock-names
>> +
>> +allOf:
>> +  - if:
>> +      required:
>> +        - wakeup-source
>> +    then:
>> +      anyOf:
>> +        - required: [interrupts]
>> +        - required: [interrupts-extended]
>> +
> I do not see any improvements.
>
> The tag you received was CONDITIONAL. If you do not apply the comments,
> you cannot just apply the tag.

my mistake again.


> Best regards,
> Krzysztof
>


From dominique.martinet at atmark-techno.com  Wed Aug 28 01:47:35 2024
From: dominique.martinet at atmark-techno.com (Dominique Martinet)
Date: Wed, 28 Aug 2024 17:47:35 +0900
Subject: [RFC 2/2] phy: freescale: fsl-samsung-hdmi: Support dynamic
 integer divider
In-Reply-To: <20240828024813.1353572-2-aford173@gmail.com>
References: <20240828024813.1353572-1-aford173@gmail.com>
 <20240828024813.1353572-2-aford173@gmail.com>
Message-ID: <Zs7kJ6vCDbxVvxU1@atmark-techno.com>

Adam Ford wrote on Tue, Aug 27, 2024 at 09:48:02PM -0500:
> There is currently a look-up table for a variety of resolutions.
> Since the phy has the ability to dynamically calculate the values
> necessary to use the intger divider which should allow more
> resolutions without having to update the look-up-table.  If the
> integer calculator cannot get an exact frequency, it falls back
> to the look-up-table.  Because the LUT algorithm does some
> rounding, I did not remove integer entries from the LUT.

Thank you!

We're still running 5.10 so I backported the driver as of it's current
state first (that part works), unfortunately our 51.2MHz display does
not work with this.

After phy_clk_round_rate() not round the pixel clock to the table values
(otherwise we'd only get rounded values), and making phy_clk_set_rate()
pass the requested `rate` instead of using the next smaller cfg->pixclk,
the display no longer comes up.

It comes up with the values obtained for 50.4MHz (next closest value),
which also has an exact match so uses the integer divider this patch
computes instead of the table values, but not with the 51.2MHz it
requests...
I'm afraid at this point I don't know how to debug that further without
getting a scope out (I don't know if the soc isn't generating something
correct or if the display actually doesn't like the frequency it
requests?! the later could be checked by plugging it in to another PC
that might support that frequency...), and that is going to take quite a
while...

Hopefully Frieder will have more success with his displays?
It could also be very well due to some of the differences with our 5.10
tree, sorry about that.

>  static int fsl_samsung_hdmi_phy_configure(struct fsl_samsung_hdmi_phy *phy,
>  					  const struct phy_config *cfg)
>  {
> +	u32 desired_clock = cfg->pixclk * 5;

(I don't really understand where that `* 5` comes from, but I guess it's
expected? works for other display and neighbor frequency anyway...)

Thanks,
-- 
Dominique




From quic_qianyu at quicinc.com  Wed Aug 28 02:41:32 2024
From: quic_qianyu at quicinc.com (Qiang Yu)
Date: Wed, 28 Aug 2024 17:41:32 +0800
Subject: [PATCH 1/8] phy: qcom-qmp: pcs-pcie: Add v6.30 register offsets
In-Reply-To: <2ojutgxk4kplxwrxxcq5zorejuohbow7dr6lhl4cwndkwzvxf6@lxg4um6krdnh>
References: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
 <20240827063631.3932971-2-quic_qianyu@quicinc.com>
 <2ojutgxk4kplxwrxxcq5zorejuohbow7dr6lhl4cwndkwzvxf6@lxg4um6krdnh>
Message-ID: <79a294b3-90a7-4900-bac1-281d321c9a55@quicinc.com>


On 8/27/2024 7:37 PM, Krzysztof Kozlowski wrote:
> On Mon, Aug 26, 2024 at 11:36:24PM -0700, Qiang Yu wrote:
>> x1e80100 SoC uses QMP phy with version v6.30 for PCIe Gen4 x8. Add the new
>> PCS PCIE specific offsets in a dedicated header file.
>>
>> Signed-off-by: Qiang Yu <quic_qianyu at quicinc.com>
>> ---
>>   .../qualcomm/phy-qcom-qmp-pcs-pcie-v6_30.h    | 25 +++++++++++++++++++
>>   1 file changed, 25 insertions(+)
>>   create mode 100644 drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v6_30.h
>>
>> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v6_30.h b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v6_30.h
>> new file mode 100644
>> index 000000000000..5a58ff197e6e
>> --- /dev/null
>> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v6_30.h
>> @@ -0,0 +1,25 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/*
>> + * Copyright (c) 2024 Qualcomm Innovation Center. All rights reserved.
>> + */
>> +
>> +#ifndef QCOM_PHY_QMP_PCS_PCIE_V6_30_H_
>> +#define QCOM_PHY_QMP_PCS_PCIE_V6_30_H_
>> +
>> +/* Only for QMP V6_30 PHY - PCIE have different offsets than V6 */
>> +#define QPHY_PCIE_V6_30_PCS_POWER_STATE_CONFIG2		0x014
>> +#define QPHY_PCIE_V6_30_PCS_TX_RX_CONFIG		0x020
>> +#define QPHY_PCIE_V6_30_PCS_ENDPOINT_REFCLK_DRIVE	0x024
>> +#define QPHY_PCIE_V6_30_PCS_OSC_DTCT_ACTIONS		0x098
>> +#define QPHY_PCIE_V6_30_PCS_EQ_CONFIG1			0x0a8
>> +#define QPHY_PCIE_V6_30_PCS_G3_RXEQEVAL_TIME		0x0f8
>> +#define QPHY_PCIE_V6_30_PCS_G4_RXEQEVAL_TIME		0x0fc
>> +#define QPHY_PCIE_V6_30_PCS_G4_EQ_CONFIG5		0x110
>> +#define QPHY_PCIE_V6_30_PCS_G4_PRE_GAIN			0x164
>> +#define QPHY_PCIE_V6_30_PCS_RX_MARGINING_CONFIG1	0x184
>> +#define QPHY_PCIE_V6_30_PCS_RX_MARGINING_CONFIG3	0x18c
>> +#define QPHY_PCIE_V6_30_PCS_RX_MARGINING_CONFIG5	0x194
>> +#define QPHY_PCIE_V6_30_PCS_G3_FOM_EQ_CONFIG5		0x1b4
>> +#define QPHY_PCIE_V6_30_PCS_G4_FOM_EQ_CONFIG5		0x1c8
> There is no user of these. Squash it with the user, because there is
> little point in adding dead code.
>
> Best regards,
> Krzysztof
OK, will squash this three patches related to phy setting into one patch.

Thanks,
Qiang


From quic_qianyu at quicinc.com  Wed Aug 28 02:47:04 2024
From: quic_qianyu at quicinc.com (Qiang Yu)
Date: Wed, 28 Aug 2024 17:47:04 +0800
Subject: [PATCH 3/8] phy: qcom: qmp: Add phy register and clk setting for
 x1e80100 PCIe3
In-Reply-To: <2d3f3da1-713e-4378-b87d-11f10f0f9590@kernel.org>
References: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
 <20240827063631.3932971-4-quic_qianyu@quicinc.com>
 <2d3f3da1-713e-4378-b87d-11f10f0f9590@kernel.org>
Message-ID: <2c23f7e8-c407-4c5c-a8e2-65be98f9c92b@quicinc.com>


On 8/27/2024 6:33 PM, Konrad Dybcio wrote:
> On 27.08.2024 8:36 AM, Qiang Yu wrote:
>> Currently driver supports only x4 lane based functionality using tx/rx and
>> tx2/rx2 pair of register sets. To support 8 lane functionality with PCIe3,
>> PCIe3 related QMP PHY provides additional programming which are available
>> as txz and rxz based register set. Hence adds txz and rxz based registers
>> usage and programming sequences. Phy register setting for txz and rxz will
>> be applied to all 8 lanes. Some lanes may have different settings on
>> several registers than txz/rxz, these registers should be programmed after
>> txz/rxz programming sequences completing.
>>
>> Besides, PCIe3 related QMP PHY also requires addtional clk, which is named
>> as clkref_en. Hence, add this clk into qmp_pciephy_clk_l so that it can be
>> easily parsed from devicetree during init.
>>
>> Signed-off-by: Qiang Yu <quic_qianyu at quicinc.com>
>> ---
> [...]
>
>> +static const struct qmp_phy_init_tbl x1e80100_qmp_gen4x8_pcie_rx_tbl[] = {
>> +	QMP_PHY_INIT_CFG_LANE(QSERDES_V6_20_RX_DFE_CTLE_POST_CAL_OFFSET, 0x3a, 1),
> 1 -> BIT(0)
>
> [...]
>
>> +	/* Set to true for programming all 8 lanes using txz/rxz registers */
>> +	bool lane_broadcasting;
> This is unnecessary because you call qmp_configure_lane conditionally,
> but that function has a nullcheck built in
Yes, there is null pointer check in qmp_configure_lane, will remove
lane_broadcating check.
>> +
>>   	/* resets to be requested */
>>   	const char * const *reset_list;
>>   	int num_resets;
>> @@ -2655,6 +2815,8 @@ struct qmp_pcie {
>>   	void __iomem *rx;
>>   	void __iomem *tx2;
>>   	void __iomem *rx2;
>> +	void __iomem *txz;
>> +	void __iomem *rxz;
>>   	void __iomem *ln_shrd;
>>   
>>   	void __iomem *port_b;
>> @@ -2700,7 +2862,7 @@ static inline void qphy_clrbits(void __iomem *base, u32 offset, u32 val)
>>   
>>   /* list of clocks required by phy */
>>   static const char * const qmp_pciephy_clk_l[] = {
>> -	"aux", "cfg_ahb", "ref", "refgen", "rchng", "phy_aux",
>> +	"aux", "cfg_ahb", "ref", "refgen", "rchng", "phy_aux", "clkref_en",
> Why not just put in TCSR_PCIE_8L_CLKREF_EN as "ref"? It's downstream
> of the XO anyway.
Yes, TCSR_PCIE_8L_CLKREF_EN is source from XO, will update patch as
your comments.

Thanks,
Qiang
>
> [...]
>
>>   	const struct qmp_phy_cfg *cfg = qmp->cfg;
>> @@ -3700,6 +3907,11 @@ static void qmp_pcie_init_registers(struct qmp_pcie *qmp, const struct qmp_phy_c
>>   
>>   	qmp_configure(qmp->dev, serdes, tbls->serdes, tbls->serdes_num);
>>   
>> +	if (cfg->lane_broadcasting) {
> All these ifs can be unconditional
>
> Konrad


From quic_qianyu at quicinc.com  Wed Aug 28 02:52:09 2024
From: quic_qianyu at quicinc.com (Qiang Yu)
Date: Wed, 28 Aug 2024 17:52:09 +0800
Subject: [PATCH 3/8] phy: qcom: qmp: Add phy register and clk setting for
 x1e80100 PCIe3
In-Reply-To: <3rwkr4tqyki7umt75bgy6wcs2whchw2vb5ckrkqffaizxm3ssp@glkarq76vl4f>
References: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
 <20240827063631.3932971-4-quic_qianyu@quicinc.com>
 <3rwkr4tqyki7umt75bgy6wcs2whchw2vb5ckrkqffaizxm3ssp@glkarq76vl4f>
Message-ID: <d79f84f1-345b-4099-b1d2-567ebfd3789d@quicinc.com>


On 8/27/2024 7:38 PM, Krzysztof Kozlowski wrote:
> On Mon, Aug 26, 2024 at 11:36:26PM -0700, Qiang Yu wrote:
>>   	if (cfg->tbls.ln_shrd)
>>   		qmp->ln_shrd = base + offs->ln_shrd;
>>   
>> @@ -4424,6 +4641,9 @@ static const struct of_device_id qmp_pcie_of_match_table[] = {
>>   	}, {
>>   		.compatible = "qcom,x1e80100-qmp-gen4x2-pcie-phy",
>>   		.data = &x1e80100_qmp_gen4x2_pciephy_cfg,
>> +	}, {
>> +		.compatible = "qcom,x1e80100-qmp-gen4x8-pcie-phy",
> Undocumented compatible or your patch order is wrong.
OK, will put the yaml patch in front of this patch

Thanks,
Qiang
>
>> +		.data = &x1e80100_qmp_gen4x8_pciephy_cfg,
>>   	},
> Best regards,
> Krzysztof
>


From quic_qianyu at quicinc.com  Wed Aug 28 06:36:01 2024
From: quic_qianyu at quicinc.com (Qiang Yu)
Date: Wed, 28 Aug 2024 21:36:01 +0800
Subject: [PATCH 4/8] arm64: dts: qcom: x1e80100: Add support for PCIe3 on
 x1e80100
In-Reply-To: <41d4bc67-e47c-4b6e-a620-b83f48f43103@kernel.org>
References: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
 <20240827063631.3932971-5-quic_qianyu@quicinc.com>
 <41d4bc67-e47c-4b6e-a620-b83f48f43103@kernel.org>
Message-ID: <ffbeb834-c56a-40b2-b9d6-f03149a1a37b@quicinc.com>


On 8/27/2024 6:42 PM, Konrad Dybcio wrote:
> On 27.08.2024 8:36 AM, Qiang Yu wrote:
>> Describe PCIe3 controller and PHY. Also add required system resources like
>> regulators, clocks, interrupts and registers configuration for PCIe3.
>>
>> Signed-off-by: Qiang Yu <quic_qianyu at quicinc.com>
>> ---
>>   arch/arm64/boot/dts/qcom/x1e80100.dtsi | 205 ++++++++++++++++++++++++-
>>   1 file changed, 204 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
>> index 74b694e74705..55b81e7de1c7 100644
>> --- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
>> @@ -744,7 +744,7 @@ gcc: clock-controller at 100000 {
>>   
>>   			clocks = <&bi_tcxo_div2>,
>>   				 <&sleep_clk>,
>> -				 <0>,
>> +				 <&pcie3_phy>,
>>   				 <&pcie4_phy>,
>>   				 <&pcie5_phy>,
>>   				 <&pcie6a_phy>,
>> @@ -2879,6 +2879,209 @@ mmss_noc: interconnect at 1780000 {
>>   			#interconnect-cells = <2>;
>>   		};
>>   
>> +		pcie3: pci at 1bd0000 {
>> +			device_type = "pci";
>> +			compatible = "qcom,pcie-x1e80100";
>> +			reg = <0 0x01bd0000 0 0x3000>,
>> +			      <0 0x78000000 0 0xf1d>,
>> +			      <0 0x78000f40 0 0xa8>,
>> +			      <0 0x78001000 0 0x1000>,
>> +			      <0 0x78100000 0 0x100000>;
>> +			reg-names = "parf",
>> +				    "dbi",
>> +				    "elbi",
>> +				    "atu",
>> +				    "config";
> There's a "mhi" region at 0x01bd3000, 0x1000-wide too, please add it
>
>> +			#address-cells = <3>;
>> +			#size-cells = <2>;
>> +			ranges = <0x01000000 0 0x00000000 0 0x78200000 0 0x100000>,
>> +				 <0x02000000 0 0x78300000 0 0x78300000 0 0x3d00000>;
> There's 64bit BAR space as well:
>
> <0x03000000 0x7 0x40000000 0x7 0x40000000 0x0 0x40000000>;
>
>> +			bus-range = <0 0xff>;
> 0x00 please
>
>> +
>> +			dma-coherent;
>> +
>> +			linux,pci-domain = <3>;
>> +			num-lanes = <8>;
>> +
>> +			interrupts = <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 769 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 836 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 671 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH>;
>> +			interrupt-names = "msi0",
>> +					  "msi1",
>> +					  "msi2",
>> +					  "msi3",
>> +					  "msi4",
>> +					  "msi5",
>> +					  "msi6",
>> +					  "msi7";
>> +
>> +			#interrupt-cells = <1>;
>> +			interrupt-map-mask = <0 0 0 0x7>;
>> +			interrupt-map = <0 0 0 1 &intc 0 0 0 220 IRQ_TYPE_LEVEL_HIGH>,
>> +					<0 0 0 2 &intc 0 0 0 221 IRQ_TYPE_LEVEL_HIGH>,
>> +					<0 0 0 3 &intc 0 0 0 237 IRQ_TYPE_LEVEL_HIGH>,
>> +					<0 0 0 4 &intc 0 0 0 238 IRQ_TYPE_LEVEL_HIGH>;
>> +
>> +			clocks = <&gcc GCC_PCIE_3_PIPE_CLK_SRC>,
> We don't toggle source clocks from dt, this is upstream of the pipe
> div clocks and is taken care of by the common clock framework,
> please drop.
GCC_PCIE_3_PIPE_CLK_SRC is a clk mux. The enable and disable callback
provided in clk driver is used to switch between pipe_clk and XO,
respectively. If we drop GCC_PCIE_3_PIPE_CLK_SRC here, that means
the mux will be XO until pipediv2 clk is enabled. I need to do some
experiment to check this. Will update in thread.

Thanks,
Qiang
>> +				 <&gcc GCC_PCIE_3_AUX_CLK>,
>> +				 <&gcc GCC_PCIE_3_CFG_AHB_CLK>,
>> +				 <&gcc GCC_PCIE_3_MSTR_AXI_CLK>,
>> +				 <&gcc GCC_PCIE_3_SLV_AXI_CLK>,
>> +				 <&gcc GCC_PCIE_3_SLV_Q2A_AXI_CLK>,
>> +				 <&gcc GCC_CFG_NOC_PCIE_ANOC_SOUTH_AHB_CLK>,
> GCC_CFG_NOC_PCIE_ANOC_NORTH_AHB_CLK
>
>> +				 <&gcc GCC_CNOC_PCIE_NORTH_SF_AXI_CLK>;
>> +			clock-names = "pipe_clk_src",
>> +				      "aux",
>> +				      "cfg",
>> +				      "bus_master",
>> +				      "bus_slave",
>> +				      "slave_q2a",
>> +				      "noc_aggr",
>> +				      "cnoc_sf_axi";
>> +
>> +			assigned-clocks = <&gcc GCC_PCIE_3_AUX_CLK>;
>> +			assigned-clock-rates = <19200000>;
>> +
>> +			interconnects = <&pcie_south_anoc MASTER_PCIE_3 QCOM_ICC_TAG_ALWAYS
>> +					 &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
>> +					<&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ALWAYS
>> +					 &cnoc_main SLAVE_PCIE_3 QCOM_ICC_TAG_ALWAYS>;
>> +			interconnect-names = "pcie-mem",
>> +					     "cpu-pcie";
>> +
>> +			resets = <&gcc GCC_PCIE_3_BCR>,
>> +				 <&gcc GCC_PCIE_3_LINK_DOWN_BCR>;
>> +			reset-names = "pci",
>> +				      "link_down";
>> +
>> +			power-domains = <&gcc GCC_PCIE_3_GDSC>;
>> +
>> +			phys = <&pcie3_phy>;
>> +			phy-names = "pciephy";
>> +
>> +			operating-points-v2 = <&pcie3_opp_table>;
>> +
>> +			status = "disabled";
>> +
>> +			pcie3_opp_table: opp-table {
>> +				compatible = "operating-points-v2";
>> +
>> +				/* GEN 1 x1 */
>> +				opp-2500000 {
>> +					opp-hz = /bits/ 64 <2500000>;
>> +					required-opps = <&rpmhpd_opp_low_svs>;
>> +					opp-peak-kBps = <250000 1>;
>> +				};
>> +
>> +				/* GEN 1 x2 and GEN 2 x1 */
>> +				opp-5000000 {
>> +					opp-hz = /bits/ 64 <5000000>;
>> +					required-opps = <&rpmhpd_opp_low_svs>;
>> +					opp-peak-kBps = <500000 1>;
>> +				};
>> +
>> +				/* GEN 1 x4 and GEN 2 x2*/
> Missing ' '
>
>> +				opp-10000000 {
>> +					opp-hz = /bits/ 64 <10000000>;
>> +					required-opps = <&rpmhpd_opp_low_svs>;
>> +					opp-peak-kBps = <1000000 1>;
>> +				};
>> +
>> +				/* GEN 1 x8 and GEN 2 X4 */
> Inconsistent capitalization, please use lowercase 'x'
>
> [...]
>
>> +		pcie3_phy: phy at 1be0000 {
>> +			compatible = "qcom,x1e80100-qmp-gen4x8-pcie-phy";
>> +			reg = <0 0x01be0000 0 0x10000>;
>> +
>> +			clocks = <&gcc GCC_PCIE_3_AUX_CLK>,
> This clock doesn't belong here, the PHY is clocked by PHY_AUX
>
>> +				 <&gcc GCC_PCIE_3_CFG_AHB_CLK>,
>> +				 <&rpmhcc RPMH_CXO_CLK>,
> This is unnecessary as commented before
>
>> +				 <&gcc GCC_PCIE_3_PHY_RCHNG_CLK>,
>> +				 <&gcc GCC_PCIE_3_PHY_AUX_CLK>,
>> +				 <&gcc GCC_PCIE_3_PIPE_CLK>,
>> +				 <&gcc GCC_PCIE_3_PIPEDIV2_CLK>,
>> +				 <&tcsr TCSR_PCIE_8L_CLKREF_EN>;
> This should be the 'ref' here
>
> Konrad


From quic_qianyu at quicinc.com  Wed Aug 28 06:44:11 2024
From: quic_qianyu at quicinc.com (Qiang Yu)
Date: Wed, 28 Aug 2024 21:44:11 +0800
Subject: [PATCH 8/8] PCI: qcom: Add support to PCIe slot power supplies
In-Reply-To: <CAA8EJpq5KergZ8czg4F=EYMLANoOeBsiSVoO-zAgfG0ezQrKCQ@mail.gmail.com>
References: <20240827063631.3932971-1-quic_qianyu@quicinc.com>
 <20240827063631.3932971-9-quic_qianyu@quicinc.com>
 <CAA8EJpq5KergZ8czg4F=EYMLANoOeBsiSVoO-zAgfG0ezQrKCQ@mail.gmail.com>
Message-ID: <844538cc-9f58-4e05-8356-096a98bd543a@quicinc.com>


On 8/27/2024 7:44 PM, Dmitry Baryshkov wrote:
> On Tue, 27 Aug 2024 at 09:36, Qiang Yu <quic_qianyu at quicinc.com> wrote:
>> On platform x1e80100 QCP, PCIe3 is a standard x8 form factor. Hence, add
>> support to use 3.3v, 3.3v aux and 12v regulators.
> First of all, I don't see corresponding bindings change.
>
> Second, these supplies power up the slot, not the host controller
> itself. As such these supplies do not belong to the host controller
> entry. Please consider using the pwrseq framework instead.
As Mani commented, he is exploring to use pwrctl driver to control this
three power. Will update the patch after Mani share his conclusion. This
patch may even not required.

Thanks,
Qiang
>
>> Signed-off-by: Qiang Yu <quic_qianyu at quicinc.com>
>> ---
>>   drivers/pci/controller/dwc/pcie-qcom.c | 52 +++++++++++++++++++++++++-
>>   1 file changed, 50 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
>> index 6f953e32d990..59fb415dfeeb 100644
>> --- a/drivers/pci/controller/dwc/pcie-qcom.c
>> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
>> @@ -248,6 +248,8 @@ struct qcom_pcie_cfg {
>>          bool no_l0s;
>>   };
>>
>> +#define QCOM_PCIE_SLOT_MAX_SUPPLIES                    3
>> +
>>   struct qcom_pcie {
>>          struct dw_pcie *pci;
>>          void __iomem *parf;                     /* DT parf */
>> @@ -260,6 +262,7 @@ struct qcom_pcie {
>>          struct icc_path *icc_cpu;
>>          const struct qcom_pcie_cfg *cfg;
>>          struct dentry *debugfs;
>> +       struct regulator_bulk_data slot_supplies[QCOM_PCIE_SLOT_MAX_SUPPLIES];
>>          bool suspended;
>>          bool use_pm_opp;
>>   };
>> @@ -1174,6 +1177,41 @@ static int qcom_pcie_link_up(struct dw_pcie *pci)
>>          return !!(val & PCI_EXP_LNKSTA_DLLLA);
>>   }
>>
>> +static int qcom_pcie_enable_slot_supplies(struct qcom_pcie *pcie)
>> +{
>> +       struct dw_pcie *pci = pcie->pci;
>> +       int ret;
>> +
>> +       ret = regulator_bulk_enable(ARRAY_SIZE(pcie->slot_supplies),
>> +                                   pcie->slot_supplies);
>> +       if (ret < 0)
>> +               dev_err(pci->dev, "Failed to enable slot regulators\n");
>> +
>> +       return ret;
>> +}
>> +
>> +static void qcom_pcie_disable_slot_supplies(struct qcom_pcie *pcie)
>> +{
>> +       regulator_bulk_disable(ARRAY_SIZE(pcie->slot_supplies),
>> +                              pcie->slot_supplies);
>> +}
>> +
>> +static int qcom_pcie_get_slot_supplies(struct qcom_pcie *pcie)
>> +{
>> +       struct dw_pcie *pci = pcie->pci;
>> +       int ret;
>> +
>> +       pcie->slot_supplies[0].supply = "vpcie12v";
>> +       pcie->slot_supplies[1].supply = "vpcie3v3";
>> +       pcie->slot_supplies[2].supply = "vpcie3v3aux";
>> +       ret = devm_regulator_bulk_get(pci->dev, ARRAY_SIZE(pcie->slot_supplies),
>> +                                     pcie->slot_supplies);
>> +       if (ret < 0)
>> +               dev_err(pci->dev, "Failed to get slot regulators\n");
>> +
>> +       return ret;
>> +}
>> +
>>   static int qcom_pcie_host_init(struct dw_pcie_rp *pp)
>>   {
>>          struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
>> @@ -1182,10 +1220,14 @@ static int qcom_pcie_host_init(struct dw_pcie_rp *pp)
>>
>>          qcom_ep_reset_assert(pcie);
>>
>> -       ret = pcie->cfg->ops->init(pcie);
>> +       ret = qcom_pcie_enable_slot_supplies(pcie);
>>          if (ret)
>>                  return ret;
>>
>> +       ret = pcie->cfg->ops->init(pcie);
>> +       if (ret)
>> +               goto err_disable_slot;
>> +
>>          ret = phy_set_mode_ext(pcie->phy, PHY_MODE_PCIE, PHY_MODE_PCIE_RC);
>>          if (ret)
>>                  goto err_deinit;
>> @@ -1216,7 +1258,8 @@ static int qcom_pcie_host_init(struct dw_pcie_rp *pp)
>>          phy_power_off(pcie->phy);
>>   err_deinit:
>>          pcie->cfg->ops->deinit(pcie);
>> -
>> +err_disable_slot:
>> +       qcom_pcie_disable_slot_supplies(pcie);
>>          return ret;
>>   }
>>
>> @@ -1228,6 +1271,7 @@ static void qcom_pcie_host_deinit(struct dw_pcie_rp *pp)
>>          qcom_ep_reset_assert(pcie);
>>          phy_power_off(pcie->phy);
>>          pcie->cfg->ops->deinit(pcie);
>> +       qcom_pcie_disable_slot_supplies(pcie);
>>   }
>>
>>   static void qcom_pcie_host_post_init(struct dw_pcie_rp *pp)
>> @@ -1602,6 +1646,10 @@ static int qcom_pcie_probe(struct platform_device *pdev)
>>                          goto err_pm_runtime_put;
>>          }
>>
>> +       ret = qcom_pcie_get_slot_supplies(pcie);
>> +       if (ret)
>> +               goto err_pm_runtime_put;
>> +
>>          ret = pcie->cfg->ops->get_resources(pcie);
>>          if (ret)
>>                  goto err_pm_runtime_put;
>> --
>> 2.34.1
>>
>


From aford173 at gmail.com  Wed Aug 28 07:11:16 2024
From: aford173 at gmail.com (Adam Ford)
Date: Wed, 28 Aug 2024 09:11:16 -0500
Subject: [RFC 2/2] phy: freescale: fsl-samsung-hdmi: Support dynamic
 integer divider
In-Reply-To: <Zs7kJ6vCDbxVvxU1@atmark-techno.com>
References: <20240828024813.1353572-1-aford173@gmail.com> <20240828024813.1353572-2-aford173@gmail.com>
 <Zs7kJ6vCDbxVvxU1@atmark-techno.com>
Message-ID: <CAHCN7xLX1FPQFFBsgfd4Msa+y=KNay9M9q1fu=P1uuKZLacS4g@mail.gmail.com>

On Wed, Aug 28, 2024 at 3:47?AM Dominique Martinet
<dominique.martinet at atmark-techno.com> wrote:
>
> Adam Ford wrote on Tue, Aug 27, 2024 at 09:48:02PM -0500:
> > There is currently a look-up table for a variety of resolutions.
> > Since the phy has the ability to dynamically calculate the values
> > necessary to use the intger divider which should allow more
> > resolutions without having to update the look-up-table.  If the
> > integer calculator cannot get an exact frequency, it falls back
> > to the look-up-table.  Because the LUT algorithm does some
> > rounding, I did not remove integer entries from the LUT.
>
> Thank you!
>
> We're still running 5.10 so I backported the driver as of it's current
> state first (that part works), unfortunately our 51.2MHz display does
> not work with this.
>
> After phy_clk_round_rate() not round the pixel clock to the table values
> (otherwise we'd only get rounded values), and making phy_clk_set_rate()
> pass the requested `rate` instead of using the next smaller cfg->pixclk,
> the display no longer comes up.

Do you want me to create a table entry for 51.2MHz?  I am pretty sure
the integer engine can handle it.  I'll investigate what's calling
phy_clk_round_rate to see if we can use the PMS calcualtor to avoid
the look-up table.


>
> It comes up with the values obtained for 50.4MHz (next closest value),
> which also has an exact match so uses the integer divider this patch
> computes instead of the table values, but not with the 51.2MHz it
> requests...
> I'm afraid at this point I don't know how to debug that further without
> getting a scope out (I don't know if the soc isn't generating something
> correct or if the display actually doesn't like the frequency it
> requests?! the later could be checked by plugging it in to another PC
> that might support that frequency...), and that is going to take quite a
> while...
>
> Hopefully Frieder will have more success with his displays?
> It could also be very well due to some of the differences with our 5.10
> tree, sorry about that.
>
> >  static int fsl_samsung_hdmi_phy_configure(struct fsl_samsung_hdmi_phy *phy,
> >                                         const struct phy_config *cfg)
> >  {
> > +     u32 desired_clock = cfg->pixclk * 5;
>
> (I don't really understand where that `* 5` comes from, but I guess it's
> expected? works for other display and neighbor frequency anyway...)

When I looked at the LUT entries for the clock rates that don't need
the fractional divider, I noted the clock rate was 5x the pix clock.
This was consistent for each entry.  Even when the fractional divider
was used, it appeared that the clock rate was 5x the pix clk.  Because
the PMS calculator I wrote is expecting a clock rate, I just
multiplied by 5 here instead of inside the PMS calculator.

adam
>
> Thanks,
> --
> Dominique
>
>


From christian.bruel at foss.st.com  Wed Aug 28 07:34:47 2024
From: christian.bruel at foss.st.com (Christian Bruel)
Date: Wed, 28 Aug 2024 16:34:47 +0200
Subject: [PATCH v4 0/5] Add STM32MP25 USB3/PCIE COMBOPHY driver 
Message-ID: <20240828143452.1407532-1-christian.bruel@foss.st.com>

Address comments from Rob and Krzysztof

Changes in v4:
   - "#phy-cells": Drop type item description since it is specified
     by user node phandle.
   - Rename stm32-combophy.yaml to match compatible
   - Drop wakeup-source from bindings (should be generic)
   - Alphabetically reorder required: list.
   - Drop "Reviewed-by" since those previous changes

Changes in v3:
   - Reorder MAINTAINERS patch

Changes in v2:
   - Reorder entries
   - Rename clock_names and reset_names bindings
   - Rename and clarify rx-equalizer binding 

Christian Bruel (5):
  dt-bindings: phy: Add STM32MP25 COMBOPHY bindings
  phy: stm32: Add support for STM32MP25 COMBOPHY.
  MAINTAINERS: add entry for ST STM32MP25 COMBOPHY driver
  arm64: dts: st: Add combophy node on stm32mp251
  arm64: dts: st: Enable COMBOPHY on the stm32mp257f-ev1 board

 .../bindings/phy/st,stm32mp25-combophy.yaml   | 128 ++++
 MAINTAINERS                                   |   6 +
 arch/arm64/boot/dts/st/stm32mp251.dtsi        |  17 +
 arch/arm64/boot/dts/st/stm32mp257f-ev1.dts    |  14 +
 drivers/phy/st/Kconfig                        |  11 +
 drivers/phy/st/Makefile                       |   1 +
 drivers/phy/st/phy-stm32-combophy.c           | 607 ++++++++++++++++++
 7 files changed, 784 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/st,stm32mp25-combophy.yaml
 create mode 100644 drivers/phy/st/phy-stm32-combophy.c

-- 
2.34.1



From christian.bruel at foss.st.com  Wed Aug 28 07:34:51 2024
From: christian.bruel at foss.st.com (Christian Bruel)
Date: Wed, 28 Aug 2024 16:34:51 +0200
Subject: [PATCH v4 4/5] arm64: dts: st: Add combophy node on stm32mp251
In-Reply-To: <20240828143452.1407532-1-christian.bruel@foss.st.com>
References: <20240828143452.1407532-1-christian.bruel@foss.st.com>
Message-ID: <20240828143452.1407532-5-christian.bruel@foss.st.com>

Add support for COMBOPHY which is used either by the USB3 and PCIe
controller.
USB3 or PCIe mode is done with phy_set_mode().
PCIe internal reference clock can be generated from the internal clock
source or optionnaly from an external 100Mhz pad.

Signed-off-by: Christian Bruel <christian.bruel at foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp251.dtsi | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
index 1167cf63d7e8..0d38763d9317 100644
--- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
@@ -7,6 +7,7 @@
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/reset/st,stm32mp25-rcc.h>
 #include <dt-bindings/regulator/st,stm32mp25-regulator.h>
+#include <dt-bindings/phy/phy.h>
 
 / {
 	#address-cells = <2>;
@@ -518,6 +519,22 @@ i2c8: i2c at 46040000 {
 				status = "disabled";
 			};
 
+			combophy: phy at 480c0000 {
+				compatible = "st,stm32mp25-combophy";
+				reg = <0x480c0000 0x1000>;
+				#phy-cells = <1>;
+				clocks = <&rcc CK_BUS_USB3PCIEPHY>, <&rcc CK_KER_USB3PCIEPHY>;
+				clock-names = "apb", "ker";
+				resets = <&rcc USB3PCIEPHY_R>;
+				reset-names = "phy";
+				st,syscfg = <&syscfg>;
+				access-controllers = <&rifsc 67>;
+				power-domains = <&CLUSTER_PD>;
+				wakeup-source;
+				interrupts-extended = <&exti1 45 IRQ_TYPE_EDGE_FALLING>;
+				status = "disabled";
+			};
+
 			sdmmc1: mmc at 48220000 {
 				compatible = "st,stm32mp25-sdmmc2", "arm,pl18x", "arm,primecell";
 				arm,primecell-periphid = <0x00353180>;
-- 
2.34.1



From christian.bruel at foss.st.com  Wed Aug 28 07:34:50 2024
From: christian.bruel at foss.st.com (Christian Bruel)
Date: Wed, 28 Aug 2024 16:34:50 +0200
Subject: [PATCH v4 3/5] MAINTAINERS: add entry for ST STM32MP25 COMBOPHY driver
In-Reply-To: <20240828143452.1407532-1-christian.bruel@foss.st.com>
References: <20240828143452.1407532-1-christian.bruel@foss.st.com>
Message-ID: <20240828143452.1407532-4-christian.bruel@foss.st.com>

Add myself as STM32MP25 COMBOPHY maintainer

Signed-off-by: Christian Bruel <christian.bruel at foss.st.com>
---
 MAINTAINERS | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f328373463b0..4dc304ba6f90 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -21910,6 +21910,12 @@ F:	arch/m68k/kernel/*sun3*
 F:	arch/m68k/sun3*/
 F:	drivers/net/ethernet/i825xx/sun3*
 
+STMICROELECTRONICS STMP32MP25 USB3/PCIE COMBOPHY DRIVER
+M:	Christian Bruel <christian.bruel at foss.st.com>
+S:	Maintained
+F:	Documentation/devicetree/bindings/phy/st,stm32mp25-combophy.yaml
+F:	drivers/phy/st/phy-stm32-combophy.c
+
 SUN4I LOW RES ADC ATTACHED TABLET KEYS DRIVER
 M:	Hans de Goede <hdegoede at redhat.com>
 L:	linux-input at vger.kernel.org
-- 
2.34.1



From christian.bruel at foss.st.com  Wed Aug 28 07:34:48 2024
From: christian.bruel at foss.st.com (Christian Bruel)
Date: Wed, 28 Aug 2024 16:34:48 +0200
Subject: [PATCH v4 1/5] dt-bindings: phy: Add STM32MP25 COMBOPHY bindings
In-Reply-To: <20240828143452.1407532-1-christian.bruel@foss.st.com>
References: <20240828143452.1407532-1-christian.bruel@foss.st.com>
Message-ID: <20240828143452.1407532-2-christian.bruel@foss.st.com>

Document the bindings for STM32 COMBOPHY interface, used to support
the PCIe and USB3 stm32mp25 drivers.
Following entries can be used to tune caracterisation parameters
 - st,output-micro-ohms and st,output-vswing-microvolt bindings entries
to tune the impedance and voltage swing using discrete simulation results
 - st,rx-equalizer register to set the internal rx equalizer filter value.

Signed-off-by: Christian Bruel <christian.bruel at foss.st.com>
---
 .../bindings/phy/st,stm32mp25-combophy.yaml   | 128 ++++++++++++++++++
 1 file changed, 128 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/st,stm32mp25-combophy.yaml

diff --git a/Documentation/devicetree/bindings/phy/st,stm32mp25-combophy.yaml b/Documentation/devicetree/bindings/phy/st,stm32mp25-combophy.yaml
new file mode 100644
index 000000000000..8d4a40b94507
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/st,stm32mp25-combophy.yaml
@@ -0,0 +1,128 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/st,stm32mp25-combophy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STM32MP25 USB3/PCIe COMBOPHY
+
+maintainers:
+  - Christian Bruel <christian.bruel at foss.st.com>
+
+description:
+  Single lane PHY shared (exclusive) between the USB3 and PCIe controllers.
+  Supports 5Gbit/s for USB3 and PCIe gen2 or 2.5Gbit/s for PCIe gen1.
+
+properties:
+  compatible:
+    const: st,stm32mp25-combophy
+
+  reg:
+    maxItems: 1
+
+  "#phy-cells":
+    const: 1
+
+  clocks:
+    minItems: 2
+    items:
+      - description: apb Bus clock mandatory to access registers.
+      - description: ker Internal RCC reference clock for USB3 or PCIe
+      - description: pad Optional on board clock input for PCIe only. Typically an
+                     external 100Mhz oscillator wired on dedicated CLKIN pad. Used as reference
+                     clock input instead of the ker
+
+  clock-names:
+    minItems: 2
+    items:
+      - const: apb
+      - const: ker
+      - const: pad
+
+  resets:
+    maxItems: 1
+
+  reset-names:
+    const: phy
+
+  power-domains:
+    maxItems: 1
+
+  wakeup-source: true
+
+  interrupts:
+    maxItems: 1
+    description: interrupt used for wakeup
+
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
+  st,syscfg:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description: Phandle to the SYSCON entry required for configuring PCIe
+      or USB3.
+
+  st,ssc-on:
+    type: boolean
+    description:
+      A boolean property whose presence indicates that the SSC for common clock
+      needs to be set.
+
+  st,rx-equalizer:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    minimum: 0
+    maximum: 7
+    default: 2
+    description:
+      A 3 bit value to tune the RX fixed equalizer setting for optimal eye compliance
+
+  st,output-micro-ohms:
+    minimum: 3999000
+    maximum: 6090000
+    default: 4968000
+    description:
+      A value property to tune the Single Ended Output Impedance, simulations results
+      at 25C for a VDDP=0.8V. The hardware accepts discrete values in this range.
+
+  st,output-vswing-microvolt:
+    minimum: 442000
+    maximum: 803000
+    default: 803000
+    description:
+      A value property in microvolt to tune the Single Ended Output Voltage Swing to change the
+      Vlo, Vhi for a VDDP = 0.8V. The hardware accepts discrete values in this range.
+
+required:
+  - "#phy-cells"
+  - compatible
+  - clocks
+  - clock-names
+  - reg
+  - resets
+  - reset-names
+  - st,syscfg
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/st,stm32mp25-rcc.h>
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/reset/st,stm32mp25-rcc.h>
+
+    combophy: phy at 480c0000 {
+        compatible = "st,stm32mp25-combophy";
+        reg = <0x480c0000 0x1000>;
+        #phy-cells = <1>;
+        clocks = <&rcc CK_BUS_USB3PCIEPHY>, <&rcc CK_KER_USB3PCIEPHY>;
+        clock-names = "apb", "ker";
+        resets = <&rcc USB3PCIEPHY_R>;
+        reset-names = "phy";
+        st,syscfg = <&syscfg>;
+        access-controllers = <&rifsc 67>;
+        power-domains = <&CLUSTER_PD>;
+        wakeup-source;
+        interrupts-extended = <&exti1 45 IRQ_TYPE_EDGE_FALLING>;
+    };
+...
-- 
2.34.1



From christian.bruel at foss.st.com  Wed Aug 28 07:34:49 2024
From: christian.bruel at foss.st.com (Christian Bruel)
Date: Wed, 28 Aug 2024 16:34:49 +0200
Subject: [PATCH v4 2/5] phy: stm32: Add support for STM32MP25 COMBOPHY.
In-Reply-To: <20240828143452.1407532-1-christian.bruel@foss.st.com>
References: <20240828143452.1407532-1-christian.bruel@foss.st.com>
Message-ID: <20240828143452.1407532-3-christian.bruel@foss.st.com>

Addition of the COMBOPHY driver found on STM32MP25 platforms

This single lane PHY is shared (exclusive) between the USB3 and PCIE
controllers.
Supports 5Gbit/s for PCIE gen2 or 2.5Gbit/s for PCIE gen1.

Supports wakeup-source capability to wakeup system using remote-wakeup
capable USB device

Signed-off-by: Christian Bruel <christian.bruel at foss.st.com>
---
 drivers/phy/st/Kconfig              |  11 +
 drivers/phy/st/Makefile             |   1 +
 drivers/phy/st/phy-stm32-combophy.c | 607 ++++++++++++++++++++++++++++
 3 files changed, 619 insertions(+)
 create mode 100644 drivers/phy/st/phy-stm32-combophy.c

diff --git a/drivers/phy/st/Kconfig b/drivers/phy/st/Kconfig
index 3fc3d0781fb8..304614b6dabf 100644
--- a/drivers/phy/st/Kconfig
+++ b/drivers/phy/st/Kconfig
@@ -33,6 +33,17 @@ config PHY_STIH407_USB
 	  Enable this support to enable the picoPHY device used by USB2
 	  and USB3 controllers on STMicroelectronics STiH407 SoC families.
 
+config PHY_STM32_COMBOPHY
+	tristate "STMicroelectronics COMBOPHY driver for STM32MP25"
+	depends on ARCH_STM32 || COMPILE_TEST
+	select GENERIC_PHY
+	help
+	  Enable this to support the COMBOPHY device used by USB3 or PCIe
+	  controllers on STMicroelectronics STM32MP25 SoC.
+	  This driver controls the COMBOPHY block to generate the PCIe 100Mhz
+	  reference clock from either the external clock generator or HSE
+	  internal SoC clock source.
+
 config PHY_STM32_USBPHYC
 	tristate "STMicroelectronics STM32 USB HS PHY Controller driver"
 	depends on ARCH_STM32 || COMPILE_TEST
diff --git a/drivers/phy/st/Makefile b/drivers/phy/st/Makefile
index c862dd937b64..cb80e954ea9f 100644
--- a/drivers/phy/st/Makefile
+++ b/drivers/phy/st/Makefile
@@ -3,4 +3,5 @@ obj-$(CONFIG_PHY_MIPHY28LP) 		+= phy-miphy28lp.o
 obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)	+= phy-spear1310-miphy.o
 obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)	+= phy-spear1340-miphy.o
 obj-$(CONFIG_PHY_STIH407_USB)		+= phy-stih407-usb.o
+obj-$(CONFIG_PHY_STM32_COMBOPHY)	+= phy-stm32-combophy.o
 obj-$(CONFIG_PHY_STM32_USBPHYC) 	+= phy-stm32-usbphyc.o
diff --git a/drivers/phy/st/phy-stm32-combophy.c b/drivers/phy/st/phy-stm32-combophy.c
new file mode 100644
index 000000000000..7cd4193b0277
--- /dev/null
+++ b/drivers/phy/st/phy-stm32-combophy.c
@@ -0,0 +1,607 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * STMicroelectronics COMBOPHY STM32MP25 Controller driver.
+ *
+ * Copyright (C) 2024 STMicroelectronics
+ * Author: Christian Bruel <christian.bruel at foss.st.com>
+ */
+
+#include <linux/clk.h>
+#include <linux/mfd/syscon.h>
+#include <linux/platform_device.h>
+#include <linux/phy/phy.h>
+#include <linux/pm_runtime.h>
+#include <linux/regmap.h>
+#include <linux/reset.h>
+#include <dt-bindings/phy/phy.h>
+
+#define SYSCFG_COMBOPHY_CR1 0x4C00
+#define SYSCFG_COMBOPHY_CR2 0x4C04
+#define SYSCFG_COMBOPHY_CR4 0x4C0C
+#define SYSCFG_COMBOPHY_CR5 0x4C10
+#define SYSCFG_COMBOPHY_SR  0x4C14
+#define SYSCFG_PCIEPRGCR    0x6080
+
+/* SYSCFG PCIEPRGCR */
+#define STM32MP25_PCIEPRGCR_EN	  BIT(0)
+#define STM32MP25_PCIEPRG_IMPCTRL_OHM     GENMASK(3, 1)
+#define STM32MP25_PCIEPRG_IMPCTRL_VSWING  GENMASK(5, 4)
+
+/* SYSCFG SYSCFG_COMBOPHY_SR */
+#define STM32MP25_PIPE0_PHYSTATUS BIT(1)
+
+/* SYSCFG CR1 */
+#define SYSCFG_COMBOPHY_CR1_REFUSEPAD BIT(0)
+#define SYSCFG_COMBOPHY_CR1_MPLLMULT GENMASK(7, 1)
+#define SYSCFG_COMBOPHY_CR1_REFCLKSEL GENMASK(16, 8)
+#define SYSCFG_COMBOPHY_CR1_REFCLKDIV2 BIT(17)
+#define SYSCFG_COMBOPHY_CR1_REFSSPEN BIT(18)
+#define SYSCFG_COMBOPHY_CR1_SSCEN BIT(19)
+
+/* SYSCFG CR4 */
+#define SYSCFG_COMBOPHY_CR4_RX0_EQ GENMASK(2, 0)
+
+#define MPLLMULT_19_2 (0x02u << 1)
+#define MPLLMULT_20   (0x7Du << 1)
+#define MPLLMULT_24   (0x68u << 1)
+#define MPLLMULT_25   (0x64u << 1)
+#define MPLLMULT_26   (0x60u << 1)
+#define MPLLMULT_38_4 (0x41u << 1)
+#define MPLLMULT_48   (0x6Cu << 1)
+#define MPLLMULT_50   (0x32u << 1)
+#define MPLLMULT_52   (0x30u << 1)
+#define MPLLMULT_100  (0x19u << 1)
+
+#define REFCLKSEL_0   0
+#define REFCLKSEL_1   (0x108u << 8)
+
+#define REFCLDIV_0    0
+
+/* SYSCFG CR2 */
+#define SYSCFG_COMBOPHY_CR2_MODESEL GENMASK(1, 0)
+#define SYSCFG_COMBOPHY_CR2_ISO_DIS BIT(15)
+
+#define COMBOPHY_MODESEL_PCIE 0
+#define COMBOPHY_MODESEL_USB  3
+
+/* SYSCFG CR5 */
+#define SYSCFG_COMBOPHY_CR5_COMMON_CLOCKS BIT(12)
+
+#define COMBOPHY_SUP_ANA_MPLL_LOOP_CTL 0xC0
+#define COMBOPHY_PROP_CNTRL GENMASK(7, 4)
+
+struct stm32_combophy {
+	struct phy *phy;
+	struct regmap *regmap;
+	struct device *dev;
+	void __iomem *base;
+	struct reset_control *phy_reset;
+	struct clk *phy_clk;
+	struct clk *pad_clk;
+	struct clk *ker_clk;
+	unsigned int type;
+	bool is_init;
+	int irq_wakeup;
+};
+
+struct clk_impedance  {
+	u32 microohm;
+	u32 vswing[4];
+};
+
+/*
+ * lookup table to hold the settings needed for a ref clock frequency
+ * impedance, the offset is used to set the IMP_CTL and DE_EMP bit of the
+ * PRG_IMP_CTRL register
+ */
+static const struct clk_impedance imp_lookup[] = {
+	{ 6090000, { 442000, 564000, 684000, 802000 } },
+	{ 5662000, { 528000, 621000, 712000, 803000 } },
+	{ 5292000, { 491000, 596000, 700000, 802000 } },
+	{ 4968000, { 558000, 640000, 722000, 803000 } },
+	{ 4684000, { 468000, 581000, 692000, 802000 } },
+	{ 4429000, { 554000, 613000, 717000, 803000 } },
+	{ 4204000, { 511000, 609000, 706000, 802000 } },
+	{ 3999000, { 571000, 648000, 726000, 803000 } }
+};
+
+static int stm32_impedance_tune(struct stm32_combophy *combophy)
+{
+	u8 imp_size = ARRAY_SIZE(imp_lookup);
+	u8 vswing_size = ARRAY_SIZE(imp_lookup[0].vswing);
+	u8 imp_of, vswing_of;
+	u32 max_imp = imp_lookup[0].microohm;
+	u32 min_imp = imp_lookup[imp_size - 1].microohm;
+	u32 max_vswing = imp_lookup[imp_size - 1].vswing[vswing_size - 1];
+	u32 min_vswing = imp_lookup[0].vswing[0];
+	u32 val;
+
+	if (!of_property_read_u32(combophy->dev->of_node, "st,output-micro-ohms", &val)) {
+		if (val < min_imp || val > max_imp) {
+			dev_err(combophy->dev, "Invalid value %u for output ohm\n", val);
+			return -EINVAL;
+		}
+
+		for (imp_of = 0 ; imp_of < ARRAY_SIZE(imp_lookup); imp_of++)
+			if (imp_lookup[imp_of].microohm <= val)
+				break;
+
+		dev_dbg(combophy->dev, "Set %u micro-ohms output impedance\n",
+			imp_lookup[imp_of].microohm);
+
+		regmap_update_bits(combophy->regmap, SYSCFG_PCIEPRGCR,
+				   STM32MP25_PCIEPRG_IMPCTRL_OHM,
+				   FIELD_PREP(STM32MP25_PCIEPRG_IMPCTRL_OHM, imp_of));
+	} else {
+		regmap_read(combophy->regmap, SYSCFG_PCIEPRGCR, &val);
+		imp_of = FIELD_GET(STM32MP25_PCIEPRG_IMPCTRL_OHM, val);
+	}
+
+	if (!of_property_read_u32(combophy->dev->of_node, "st,output-vswing-microvolt", &val)) {
+		if (val < min_vswing || val > max_vswing) {
+			dev_err(combophy->dev, "Invalid value %u for output vswing\n", val);
+			return -EINVAL;
+		}
+
+		for (vswing_of = 0 ; vswing_of < ARRAY_SIZE(imp_lookup[imp_of].vswing); vswing_of++)
+			if (imp_lookup[imp_of].vswing[vswing_of] >= val)
+				break;
+
+		dev_dbg(combophy->dev, "Set %u microvolt swing\n",
+			 imp_lookup[imp_of].vswing[vswing_of]);
+
+		regmap_update_bits(combophy->regmap, SYSCFG_PCIEPRGCR,
+				   STM32MP25_PCIEPRG_IMPCTRL_VSWING,
+				   FIELD_PREP(STM32MP25_PCIEPRG_IMPCTRL_VSWING, vswing_of));
+	}
+
+	return 0;
+}
+
+static int stm32_combophy_pll_init(struct stm32_combophy *combophy)
+{
+	int ret;
+	u32 refclksel, pllmult, propcntrl, val;
+	u32 clk_rate;
+
+	if (combophy->pad_clk)
+		clk_rate = clk_get_rate(combophy->pad_clk);
+	else
+		clk_rate = clk_get_rate(combophy->ker_clk);
+
+	reset_control_assert(combophy->phy_reset);
+
+	dev_dbg(combophy->dev, "%s pll init rate %d\n",
+		combophy->pad_clk ? "External" : "Ker", clk_rate);
+
+	/*
+	 * vddcombophy is interconnected with vddcore. Isolation bit should be unset
+	 * before using the ComboPHY.
+	 */
+	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR2,
+			   SYSCFG_COMBOPHY_CR2_ISO_DIS, SYSCFG_COMBOPHY_CR2_ISO_DIS);
+
+	if (combophy->type != PHY_TYPE_PCIE)
+		regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
+				   SYSCFG_COMBOPHY_CR1_REFSSPEN, SYSCFG_COMBOPHY_CR1_REFSSPEN);
+
+	if (combophy->type == PHY_TYPE_PCIE && !combophy->pad_clk)
+		regmap_update_bits(combophy->regmap, SYSCFG_PCIEPRGCR,
+				   STM32MP25_PCIEPRGCR_EN, STM32MP25_PCIEPRGCR_EN);
+
+	if (of_property_read_bool(combophy->dev->of_node, "st,ssc-on")) {
+		dev_dbg(combophy->dev, "Enabling clock with SSC\n");
+		regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
+				   SYSCFG_COMBOPHY_CR1_SSCEN, SYSCFG_COMBOPHY_CR1_SSCEN);
+	}
+
+	if (!of_property_read_u32(combophy->dev->of_node, "st,rx-equalizer", &val)) {
+		dev_dbg(combophy->dev, "Set RX equalizer %u\n", val);
+		if (val > SYSCFG_COMBOPHY_CR4_RX0_EQ) {
+			dev_err(combophy->dev, "Invalid value %u for rx0 equalizer\n", val);
+			return -EINVAL;
+		}
+
+		regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR4,
+			   SYSCFG_COMBOPHY_CR4_RX0_EQ, val);
+	}
+
+	if (combophy->type == PHY_TYPE_PCIE) {
+		ret = stm32_impedance_tune(combophy);
+		if (ret) {
+			reset_control_deassert(combophy->phy_reset);
+			goto out;
+		}
+
+		regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
+				   SYSCFG_COMBOPHY_CR1_REFUSEPAD,
+				   combophy->pad_clk ? SYSCFG_COMBOPHY_CR1_REFUSEPAD : 0);
+	}
+
+	switch (clk_rate) {
+	case 100000000:
+		pllmult = MPLLMULT_100;
+		refclksel = REFCLKSEL_0;
+		propcntrl = 0x8u << 4;
+		break;
+	case 19200000:
+		pllmult = MPLLMULT_19_2;
+		refclksel = REFCLKSEL_1;
+		propcntrl = 0x8u << 4;
+		break;
+	case 25000000:
+		pllmult = MPLLMULT_25;
+		refclksel = REFCLKSEL_0;
+		propcntrl = 0xEu << 4;
+		break;
+	case 24000000:
+		pllmult = MPLLMULT_24;
+		refclksel = REFCLKSEL_1;
+		propcntrl = 0xEu << 4;
+		break;
+	case 20000000:
+		pllmult = MPLLMULT_20;
+		refclksel = REFCLKSEL_0;
+		propcntrl = 0xEu << 4;
+		break;
+	default:
+		dev_err(combophy->dev, "Invalid rate 0x%x\n", clk_rate);
+		reset_control_deassert(combophy->phy_reset);
+		ret = -EINVAL;
+		goto out;
+	};
+
+	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
+			   SYSCFG_COMBOPHY_CR1_REFCLKDIV2, REFCLDIV_0);
+	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
+			   SYSCFG_COMBOPHY_CR1_REFCLKSEL, refclksel);
+	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
+			   SYSCFG_COMBOPHY_CR1_MPLLMULT, pllmult);
+
+	/*
+	 * Force elasticity buffer to be tuned for the reference clock as
+	 * the separated clock model is not supported
+	 */
+	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR5,
+			   SYSCFG_COMBOPHY_CR5_COMMON_CLOCKS, SYSCFG_COMBOPHY_CR5_COMMON_CLOCKS);
+
+	reset_control_deassert(combophy->phy_reset);
+
+	ret = regmap_read_poll_timeout(combophy->regmap, SYSCFG_COMBOPHY_SR, val,
+				       !(val & STM32MP25_PIPE0_PHYSTATUS),
+				       10, 1000);
+	if (ret) {
+		dev_err(combophy->dev, "timeout, cannot lock PLL\n");
+		goto out;
+	}
+
+	if (combophy->type == PHY_TYPE_PCIE) {
+		val = readl_relaxed(combophy->base + COMBOPHY_SUP_ANA_MPLL_LOOP_CTL);
+		val &= ~COMBOPHY_PROP_CNTRL;
+		val |= propcntrl;
+		writel_relaxed(val, combophy->base + COMBOPHY_SUP_ANA_MPLL_LOOP_CTL);
+	}
+
+	return 0;
+
+out:
+	if (combophy->type == PHY_TYPE_PCIE && !combophy->pad_clk)
+		regmap_update_bits(combophy->regmap, SYSCFG_PCIEPRGCR,
+				   STM32MP25_PCIEPRGCR_EN, 0);
+
+	if (combophy->type != PHY_TYPE_PCIE)
+		regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
+				   SYSCFG_COMBOPHY_CR1_REFSSPEN, 0);
+
+	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR2,
+			   SYSCFG_COMBOPHY_CR2_ISO_DIS, 0);
+
+	return ret;
+}
+
+static struct phy *stm32_combophy_xlate(struct device *dev,
+					const struct of_phandle_args *args)
+{
+	struct stm32_combophy *combophy = dev_get_drvdata(dev);
+	unsigned int type;
+
+	if (args->args_count != 1) {
+		dev_err(dev, "invalid number of cells in 'phy' property\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	type = args->args[0];
+	if (type != PHY_TYPE_USB3 && type != PHY_TYPE_PCIE) {
+		dev_err(dev, "unsupported device type: %d\n", type);
+		return ERR_PTR(-EINVAL);
+	}
+
+	if (combophy->pad_clk && type != PHY_TYPE_PCIE) {
+		dev_err(dev, "Invalid use of clk_pad for USB3 mode\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	combophy->type = type;
+
+	return combophy->phy;
+}
+
+static int stm32_combophy_set_mode(struct stm32_combophy *combophy)
+{
+	int type = combophy->type;
+	u32 val;
+
+	switch (type) {
+	case PHY_TYPE_PCIE:
+		dev_dbg(combophy->dev, "setting PCIe ComboPHY\n");
+		val = COMBOPHY_MODESEL_PCIE;
+		break;
+	case PHY_TYPE_USB3:
+		dev_dbg(combophy->dev, "setting USB3 ComboPHY\n");
+		val = COMBOPHY_MODESEL_USB;
+		break;
+	default:
+		dev_err(combophy->dev, "Invalid PHY mode %d\n", type);
+		return -EINVAL;
+	}
+
+	return regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR2,
+				  SYSCFG_COMBOPHY_CR2_MODESEL, val);
+}
+
+static int stm32_combophy_enable_clocks(struct stm32_combophy *combophy)
+{
+	int ret;
+
+	ret = clk_prepare_enable(combophy->phy_clk);
+	if (ret) {
+		dev_err(combophy->dev, "Core clock enable failed %d\n", ret);
+		return ret;
+	}
+
+	ret = clk_prepare_enable(combophy->ker_clk);
+	if (ret) {
+		dev_err(combophy->dev, "ker_usb3pcie clock enable failed %d\n", ret);
+		clk_disable_unprepare(combophy->phy_clk);
+		return ret;
+	}
+
+	if (combophy->pad_clk) {
+		ret = clk_prepare_enable(combophy->pad_clk);
+		if (ret) {
+			dev_err(combophy->dev, "External clock enable failed %d\n", ret);
+			clk_disable_unprepare(combophy->ker_clk);
+			clk_disable_unprepare(combophy->phy_clk);
+			return ret;
+		}
+	}
+
+	return 0;
+}
+
+static void stm32_combophy_disable_clocks(struct stm32_combophy *combophy)
+{
+	if (combophy->pad_clk)
+		clk_disable_unprepare(combophy->pad_clk);
+	clk_disable_unprepare(combophy->ker_clk);
+	clk_disable_unprepare(combophy->phy_clk);
+}
+
+static int stm32_combophy_suspend_noirq(struct device *dev)
+{
+	struct stm32_combophy *combophy = dev_get_drvdata(dev);
+
+	/*
+	 * Clocks should be turned off since it is not needed for
+	 * wakeup capability. In case usb-remote wakeup is not enabled,
+	 * combo-phy is already turned off by HCD driver using exit callback
+	 */
+	if (combophy->is_init) {
+		stm32_combophy_disable_clocks(combophy);
+
+		/* since wakeup is enabled for ctrl */
+		enable_irq_wake(combophy->irq_wakeup);
+	}
+
+	return 0;
+}
+
+static int stm32_combophy_resume_noirq(struct device *dev)
+{
+	struct stm32_combophy *combophy = dev_get_drvdata(dev);
+	int ret;
+
+	/*
+	 * If clocks was turned off by suspend call for wakeup then needs
+	 * to be turned back ON in resume. In case usb-remote wakeup is not
+	 * enabled, clocks already turned ON by HCD driver using init callback
+	 */
+	if (combophy->is_init) {
+		/* since wakeup was enabled for ctrl */
+		disable_irq_wake(combophy->irq_wakeup);
+
+		ret = stm32_combophy_enable_clocks(combophy);
+		if (ret) {
+			dev_err(dev, "can't enable clocks (%d)\n", ret);
+			return ret;
+		}
+	}
+
+	return 0;
+}
+
+static int stm32_combophy_exit(struct phy *phy)
+{
+	struct stm32_combophy *combophy = phy_get_drvdata(phy);
+	struct device *dev = combophy->dev;
+
+	combophy->is_init = false;
+
+	if (combophy->type == PHY_TYPE_PCIE && !combophy->pad_clk)
+		regmap_update_bits(combophy->regmap, SYSCFG_PCIEPRGCR,
+				   STM32MP25_PCIEPRGCR_EN, 0);
+
+	if (combophy->type != PHY_TYPE_PCIE)
+		regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
+				   SYSCFG_COMBOPHY_CR1_REFSSPEN, 0);
+
+	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR2,
+			   SYSCFG_COMBOPHY_CR2_ISO_DIS, 0);
+
+	stm32_combophy_disable_clocks(combophy);
+
+	pm_runtime_put_noidle(dev);
+
+	return 0;
+}
+
+static int stm32_combophy_init(struct phy *phy)
+{
+	struct stm32_combophy *combophy = phy_get_drvdata(phy);
+	struct device *dev = combophy->dev;
+	int ret;
+
+	pm_runtime_get_noresume(dev);
+
+	ret = stm32_combophy_enable_clocks(combophy);
+	if (ret) {
+		dev_err(dev, "Clock enable failed %d\n", ret);
+		pm_runtime_put_noidle(dev);
+		return ret;
+	}
+
+	ret = stm32_combophy_set_mode(combophy);
+	if (ret) {
+		dev_err(dev, "combophy mode not set\n");
+		stm32_combophy_disable_clocks(combophy);
+		pm_runtime_put_noidle(dev);
+		return ret;
+	}
+
+	ret = stm32_combophy_pll_init(combophy);
+	if (ret) {
+		stm32_combophy_disable_clocks(combophy);
+		pm_runtime_put_noidle(dev);
+		return ret;
+	}
+
+	pm_runtime_disable(dev);
+	pm_runtime_set_active(dev);
+	pm_runtime_enable(dev);
+
+	combophy->is_init = true;
+
+	return ret;
+}
+
+static const struct phy_ops stm32_combophy_phy_data = {
+	.init = stm32_combophy_init,
+	.exit = stm32_combophy_exit,
+	.owner = THIS_MODULE
+};
+
+static irqreturn_t stm32_combophy_irq_wakeup_handler(int irq, void *dev_id)
+{
+	return IRQ_HANDLED;
+}
+
+static int stm32_combophy_probe(struct platform_device *pdev)
+{
+	struct stm32_combophy *combophy;
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct phy_provider *phy_provider;
+	int ret, irq;
+
+	combophy = devm_kzalloc(dev, sizeof(*combophy), GFP_KERNEL);
+	if (!combophy)
+		return -ENOMEM;
+
+	combophy->dev = dev;
+
+	dev_set_drvdata(dev, combophy);
+
+	combophy->base = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(combophy->base))
+		return PTR_ERR(combophy->base);
+
+	combophy->phy_clk = devm_clk_get(dev, "apb");
+	if (IS_ERR(combophy->phy_clk))
+		return dev_err_probe(dev, PTR_ERR(combophy->phy_clk),
+				     "Failed to get PHY clock source\n");
+
+	combophy->ker_clk = devm_clk_get(dev, "ker");
+	if (IS_ERR(combophy->ker_clk))
+		return dev_err_probe(dev, PTR_ERR(combophy->ker_clk),
+				     "Failed to get PHY internal clock source\n");
+
+	combophy->pad_clk = devm_clk_get_optional(dev, "pad");
+	if (IS_ERR(combophy->pad_clk))
+		return dev_err_probe(dev, PTR_ERR(combophy->pad_clk),
+				     "Failed to get PHY external clock source\n");
+
+	combophy->phy_reset = devm_reset_control_get(dev, "phy");
+	if (IS_ERR(combophy->phy_reset))
+		return dev_err_probe(dev, PTR_ERR(combophy->phy_reset),
+				     "Failed to get PHY reset\n");
+
+	combophy->regmap = syscon_regmap_lookup_by_phandle(np, "st,syscfg");
+	if (IS_ERR(combophy->regmap))
+		return dev_err_probe(dev, PTR_ERR(combophy->regmap),
+				     "No syscfg phandle specified\n");
+
+	combophy->phy = devm_phy_create(dev, NULL, &stm32_combophy_phy_data);
+	if (IS_ERR(combophy->phy))
+		return dev_err_probe(dev, PTR_ERR(combophy->phy),
+				     "failed to create PCIe/USB3 ComboPHY\n");
+
+	if (device_property_read_bool(dev, "wakeup-source")) {
+		irq = platform_get_irq(pdev, 0);
+		if (irq < 0)
+			return dev_err_probe(dev, irq, "failed to get IRQ\n");
+		combophy->irq_wakeup = irq;
+
+		ret = devm_request_threaded_irq(dev, combophy->irq_wakeup, NULL,
+						stm32_combophy_irq_wakeup_handler, IRQF_ONESHOT,
+						NULL, NULL);
+		if (ret)
+			return dev_err_probe(dev, ret, "unable to request wake IRQ %d\n",
+						 combophy->irq_wakeup);
+	}
+
+	ret = devm_pm_runtime_enable(dev);
+	if (ret)
+		return dev_err_probe(dev, ret, "Failed to enable pm runtime\n");
+
+	phy_set_drvdata(combophy->phy, combophy);
+
+	phy_provider = devm_of_phy_provider_register(dev, stm32_combophy_xlate);
+
+	return PTR_ERR_OR_ZERO(phy_provider);
+}
+
+static const struct dev_pm_ops stm32_combophy_pm_ops = {
+	NOIRQ_SYSTEM_SLEEP_PM_OPS(stm32_combophy_suspend_noirq,
+				  stm32_combophy_resume_noirq)
+};
+
+static const struct of_device_id stm32_combophy_of_match[] = {
+	{ .compatible = "st,stm32mp25-combophy", },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, stm32_combophy_of_match);
+
+static struct platform_driver stm32_combophy_driver = {
+	.probe = stm32_combophy_probe,
+	.driver = {
+		   .name = "stm32-combophy",
+		   .of_match_table = stm32_combophy_of_match,
+		   .pm = pm_sleep_ptr(&stm32_combophy_pm_ops)
+	}
+};
+
+module_platform_driver(stm32_combophy_driver);
+
+MODULE_AUTHOR("Christian Bruel <christian.bruel at foss.st.com>");
+MODULE_DESCRIPTION("STM32MP25 Combophy USB3/PCIe controller driver");
+MODULE_LICENSE("GPL");
-- 
2.34.1



From christian.bruel at foss.st.com  Wed Aug 28 07:34:52 2024
From: christian.bruel at foss.st.com (Christian Bruel)
Date: Wed, 28 Aug 2024 16:34:52 +0200
Subject: [PATCH v4 5/5] arm64: dts: st: Enable COMBOPHY on the stm32mp257f-ev1 board
In-Reply-To: <20240828143452.1407532-1-christian.bruel@foss.st.com>
References: <20240828143452.1407532-1-christian.bruel@foss.st.com>
Message-ID: <20240828143452.1407532-6-christian.bruel@foss.st.com>

Enable the COMBOPHY with external pad clock on stm32mp257f-ev1
board, to be used for the PCIe clock provider.

Signed-off-by: Christian Bruel <christian.bruel at foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp257f-ev1.dts | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts b/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
index 214191a8322b..bcf84d533cb2 100644
--- a/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
+++ b/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
@@ -27,6 +27,14 @@ chosen {
 		stdout-path = "serial0:115200n8";
 	};
 
+	clocks {
+		pad_clk: pad-clk {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <100000000>;
+		};
+	};
+
 	memory at 80000000 {
 		device_type = "memory";
 		reg = <0x0 0x80000000 0x1 0x0>;
@@ -50,6 +58,12 @@ &arm_wdt {
 	status = "okay";
 };
 
+&combophy {
+	clocks = <&rcc CK_BUS_USB3PCIEPHY>, <&rcc CK_KER_USB3PCIEPHY>, <&pad_clk>;
+	clock-names = "apb", "ker", "pad";
+	status = "okay";
+};
+
 &ethernet2 {
 	pinctrl-names = "default", "sleep";
 	pinctrl-0 = <&eth2_rgmii_pins_a>;
-- 
2.34.1



From conor at kernel.org  Wed Aug 28 09:11:12 2024
From: conor at kernel.org (Conor Dooley)
Date: Wed, 28 Aug 2024 17:11:12 +0100
Subject: [PATCH v4 1/5] dt-bindings: phy: Add STM32MP25 COMBOPHY bindings
In-Reply-To: <20240828143452.1407532-2-christian.bruel@foss.st.com>
References: <20240828143452.1407532-1-christian.bruel@foss.st.com>
 <20240828143452.1407532-2-christian.bruel@foss.st.com>
Message-ID: <20240828-handsfree-overarch-cd1af26cb0c5@spud>

On Wed, Aug 28, 2024 at 04:34:48PM +0200, Christian Bruel wrote:
> Document the bindings for STM32 COMBOPHY interface, used to support
> the PCIe and USB3 stm32mp25 drivers.
> Following entries can be used to tune caracterisation parameters
>  - st,output-micro-ohms and st,output-vswing-microvolt bindings entries
> to tune the impedance and voltage swing using discrete simulation results
>  - st,rx-equalizer register to set the internal rx equalizer filter value.
> 
> Signed-off-by: Christian Bruel <christian.bruel at foss.st.com>
> ---
>  .../bindings/phy/st,stm32mp25-combophy.yaml   | 128 ++++++++++++++++++
>  1 file changed, 128 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/st,stm32mp25-combophy.yaml
> 
> diff --git a/Documentation/devicetree/bindings/phy/st,stm32mp25-combophy.yaml b/Documentation/devicetree/bindings/phy/st,stm32mp25-combophy.yaml
> new file mode 100644
> index 000000000000..8d4a40b94507
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/st,stm32mp25-combophy.yaml
> @@ -0,0 +1,128 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/st,stm32mp25-combophy.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: STMicroelectronics STM32MP25 USB3/PCIe COMBOPHY
> +
> +maintainers:
> +  - Christian Bruel <christian.bruel at foss.st.com>
> +
> +description:
> +  Single lane PHY shared (exclusive) between the USB3 and PCIe controllers.
> +  Supports 5Gbit/s for USB3 and PCIe gen2 or 2.5Gbit/s for PCIe gen1.
> +
> +properties:
> +  compatible:
> +    const: st,stm32mp25-combophy
> +
> +  reg:
> +    maxItems: 1
> +
> +  "#phy-cells":
> +    const: 1
> +
> +  clocks:
> +    minItems: 2
> +    items:
> +      - description: apb Bus clock mandatory to access registers.
> +      - description: ker Internal RCC reference clock for USB3 or PCIe
> +      - description: pad Optional on board clock input for PCIe only. Typically an
> +                     external 100Mhz oscillator wired on dedicated CLKIN pad. Used as reference
> +                     clock input instead of the ker
> +
> +  clock-names:
> +    minItems: 2
> +    items:
> +      - const: apb
> +      - const: ker
> +      - const: pad
> +
> +  resets:
> +    maxItems: 1
> +
> +  reset-names:
> +    const: phy
> +
> +  power-domains:
> +    maxItems: 1
> +
> +  wakeup-source: true
> +
> +  interrupts:
> +    maxItems: 1
> +    description: interrupt used for wakeup
> +
> +  access-controllers:
> +    minItems: 1
> +    maxItems: 2

Can you please describe the items here?

> +  st,syscfg:
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +    description: Phandle to the SYSCON entry required for configuring PCIe
> +      or USB3.

Why is a phandle required for this lookup, rather than doing it by
compatible?

> +
> +  st,ssc-on:
> +    type: boolean

flag, not boolean, for presence based stuff. And in the driver,
s/of_property_read_bool/of_property_present/.

> +    description:
> +      A boolean property whose presence indicates that the SSC for common clock
> +      needs to be set.

And what, may I ask, does "SSC" mean? "Common clock" is also a bit of a
"linuxism", what does this actually do in the hardware block?

> +
> +  st,rx-equalizer:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    minimum: 0
> +    maximum: 7
> +    default: 2
> +    description:
> +      A 3 bit value to tune the RX fixed equalizer setting for optimal eye compliance
> +
> +  st,output-micro-ohms:
> +    minimum: 3999000
> +    maximum: 6090000
> +    default: 4968000
> +    description:
> +      A value property to tune the Single Ended Output Impedance, simulations results
> +      at 25C for a VDDP=0.8V. The hardware accepts discrete values in this range.
> +
> +  st,output-vswing-microvolt:
> +    minimum: 442000
> +    maximum: 803000
> +    default: 803000
> +    description:
> +      A value property in microvolt to tune the Single Ended Output Voltage Swing to change the
> +      Vlo, Vhi for a VDDP = 0.8V. The hardware accepts discrete values in this range.
> +
> +required:
> +  - "#phy-cells"
> +  - compatible
> +  - clocks
> +  - clock-names
> +  - reg
> +  - resets
> +  - reset-names
> +  - st,syscfg

The order here should reflect the ordering in a node, so compatible and
reg first, rather than sorted alphanumerically. 

> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/clock/st,stm32mp25-rcc.h>
> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> +    #include <dt-bindings/reset/st,stm32mp25-rcc.h>
> +
> +    combophy: phy at 480c0000 {

You can drop the label here, it ain't used by anything.

Cheers,
Conor.

> +        compatible = "st,stm32mp25-combophy";
> +        reg = <0x480c0000 0x1000>;
> +        #phy-cells = <1>;
> +        clocks = <&rcc CK_BUS_USB3PCIEPHY>, <&rcc CK_KER_USB3PCIEPHY>;
> +        clock-names = "apb", "ker";
> +        resets = <&rcc USB3PCIEPHY_R>;
> +        reset-names = "phy";
> +        st,syscfg = <&syscfg>;
> +        access-controllers = <&rifsc 67>;
> +        power-domains = <&CLUSTER_PD>;
> +        wakeup-source;
> +        interrupts-extended = <&exti1 45 IRQ_TYPE_EDGE_FALLING>;
> +    };
> +...
> -- 
> 2.34.1
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-phy/attachments/20240828/024a31ae/attachment.sig>

From aford173 at gmail.com  Wed Aug 28 12:28:00 2024
From: aford173 at gmail.com (Adam Ford)
Date: Wed, 28 Aug 2024 14:28:00 -0500
Subject: [RFC 2/2] phy: freescale: fsl-samsung-hdmi: Support dynamic
 integer divider
In-Reply-To: <CAHCN7xLX1FPQFFBsgfd4Msa+y=KNay9M9q1fu=P1uuKZLacS4g@mail.gmail.com>
References: <20240828024813.1353572-1-aford173@gmail.com> <20240828024813.1353572-2-aford173@gmail.com>
 <Zs7kJ6vCDbxVvxU1@atmark-techno.com> <CAHCN7xLX1FPQFFBsgfd4Msa+y=KNay9M9q1fu=P1uuKZLacS4g@mail.gmail.com>
Message-ID: <CAHCN7xJtw2JakEtvD31dCKvpanzu6Pxbc0S81rDurYbVp5g_aA@mail.gmail.com>

On Wed, Aug 28, 2024 at 9:11?AM Adam Ford <aford173 at gmail.com> wrote:
>
> On Wed, Aug 28, 2024 at 3:47?AM Dominique Martinet
> <dominique.martinet at atmark-techno.com> wrote:
> >
> > Adam Ford wrote on Tue, Aug 27, 2024 at 09:48:02PM -0500:
> > > There is currently a look-up table for a variety of resolutions.
> > > Since the phy has the ability to dynamically calculate the values
> > > necessary to use the intger divider which should allow more
> > > resolutions without having to update the look-up-table.  If the
> > > integer calculator cannot get an exact frequency, it falls back
> > > to the look-up-table.  Because the LUT algorithm does some
> > > rounding, I did not remove integer entries from the LUT.
> >
> > Thank you!
> >
> > We're still running 5.10 so I backported the driver as of it's current
> > state first (that part works), unfortunately our 51.2MHz display does
> > not work with this.
> >
> > After phy_clk_round_rate() not round the pixel clock to the table values
> > (otherwise we'd only get rounded values), and making phy_clk_set_rate()
> > pass the requested `rate` instead of using the next smaller cfg->pixclk,
> > the display no longer comes up.

It looks like I need to update phy_clk_round_rate to calculate the
integer clock value there as well and if it's not possible to reach
the desired value, fall back to the LUT.

I likely won't get that done today, but I'll try.

adam
>
> Do you want me to create a table entry for 51.2MHz?  I am pretty sure
> the integer engine can handle it.  I'll investigate what's calling
> phy_clk_round_rate to see if we can use the PMS calcualtor to avoid
> the look-up table.
>
>
> >
> > It comes up with the values obtained for 50.4MHz (next closest value),
> > which also has an exact match so uses the integer divider this patch
> > computes instead of the table values, but not with the 51.2MHz it
> > requests...
> > I'm afraid at this point I don't know how to debug that further without
> > getting a scope out (I don't know if the soc isn't generating something
> > correct or if the display actually doesn't like the frequency it
> > requests?! the later could be checked by plugging it in to another PC
> > that might support that frequency...), and that is going to take quite a
> > while...
> >
> > Hopefully Frieder will have more success with his displays?
> > It could also be very well due to some of the differences with our 5.10
> > tree, sorry about that.
> >
> > >  static int fsl_samsung_hdmi_phy_configure(struct fsl_samsung_hdmi_phy *phy,
> > >                                         const struct phy_config *cfg)
> > >  {
> > > +     u32 desired_clock = cfg->pixclk * 5;
> >
> > (I don't really understand where that `* 5` comes from, but I guess it's
> > expected? works for other display and neighbor frequency anyway...)
>
> When I looked at the LUT entries for the clock rates that don't need
> the fractional divider, I noted the clock rate was 5x the pix clock.
> This was consistent for each entry.  Even when the fractional divider
> was used, it appeared that the clock rate was 5x the pix clk.  Because
> the PMS calculator I wrote is expecting a clock rate, I just
> multiplied by 5 here instead of inside the PMS calculator.
>
> adam
> >
> > Thanks,
> > --
> > Dominique
> >
> >


From aford173 at gmail.com  Wed Aug 28 19:12:44 2024
From: aford173 at gmail.com (Adam Ford)
Date: Wed, 28 Aug 2024 21:12:44 -0500
Subject: [RFC V2 1/2] phy: freescale: fsl-samsung-hdmi: Replace register defines with macro
Message-ID: <20240829021256.787615-1-aford173@gmail.com>

There are 47 registers defined as PHY_REG_xx were xx goes from 00 to
47.  Simplify this by replacing them all with a macro which is passed
the register number to return the proper register offset.

Signed-off-by: Adam Ford <aford173 at gmail.com>

diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
index 9048cdc760c2..bc5d3625ece6 100644
--- a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
+++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
@@ -14,76 +14,20 @@
 #include <linux/platform_device.h>
 #include <linux/pm_runtime.h>
 
-#define PHY_REG_00		0x00
-#define PHY_REG_01		0x04
-#define PHY_REG_02		0x08
-#define PHY_REG_08		0x20
-#define PHY_REG_09		0x24
-#define PHY_REG_10		0x28
-#define PHY_REG_11		0x2c
-
-#define PHY_REG_12		0x30
-#define  REG12_CK_DIV_MASK	GENMASK(5, 4)
-
-#define PHY_REG_13		0x34
-#define  REG13_TG_CODE_LOW_MASK	GENMASK(7, 0)
-
-#define PHY_REG_14		0x38
-#define  REG14_TOL_MASK		GENMASK(7, 4)
-#define  REG14_RP_CODE_MASK	GENMASK(3, 1)
-#define  REG14_TG_CODE_HIGH_MASK	GENMASK(0, 0)
-
-#define PHY_REG_15		0x3c
-#define PHY_REG_16		0x40
-#define PHY_REG_17		0x44
-#define PHY_REG_18		0x48
-#define PHY_REG_19		0x4c
-#define PHY_REG_20		0x50
-
-#define PHY_REG_21		0x54
-#define  REG21_SEL_TX_CK_INV	BIT(7)
-#define  REG21_PMS_S_MASK	GENMASK(3, 0)
-
-#define PHY_REG_22		0x58
-#define PHY_REG_23		0x5c
-#define PHY_REG_24		0x60
-#define PHY_REG_25		0x64
-#define PHY_REG_26		0x68
-#define PHY_REG_27		0x6c
-#define PHY_REG_28		0x70
-#define PHY_REG_29		0x74
-#define PHY_REG_30		0x78
-#define PHY_REG_31		0x7c
-#define PHY_REG_32		0x80
-
-/*
- * REG33 does not match the ref manual. According to Sandor Yu from NXP,
- * "There is a doc issue on the i.MX8MP latest RM"
- * REG33 is being used per guidance from Sandor
- */
-
-#define PHY_REG_33		0x84
-#define  REG33_MODE_SET_DONE	BIT(7)
-#define  REG33_FIX_DA		BIT(1)
-
-#define PHY_REG_34		0x88
-#define  REG34_PHY_READY	BIT(7)
-#define  REG34_PLL_LOCK		BIT(6)
-#define  REG34_PHY_CLK_READY	BIT(5)
-
-#define PHY_REG_35		0x8c
-#define PHY_REG_36		0x90
-#define PHY_REG_37		0x94
-#define PHY_REG_38		0x98
-#define PHY_REG_39		0x9c
-#define PHY_REG_40		0xa0
-#define PHY_REG_41		0xa4
-#define PHY_REG_42		0xa8
-#define PHY_REG_43		0xac
-#define PHY_REG_44		0xb0
-#define PHY_REG_45		0xb4
-#define PHY_REG_46		0xb8
-#define PHY_REG_47		0xbc
+#define PHY_REG(reg)		(reg * 4)
+
+#define REG12_CK_DIV_MASK	GENMASK(5, 4)
+#define REG13_TG_CODE_LOW_MASK	GENMASK(7, 0)
+#define REG14_TOL_MASK		GENMASK(7, 4)
+#define REG14_RP_CODE_MASK	GENMASK(3, 1)
+#define REG14_TG_CODE_HIGH_MASK	GENMASK(0, 0)
+#define REG21_SEL_TX_CK_INV	BIT(7)
+#define REG21_PMS_S_MASK	GENMASK(3, 0)
+#define REG33_MODE_SET_DONE	BIT(7)
+#define REG33_FIX_DA		BIT(1)
+#define REG34_PHY_READY	BIT(7)
+#define REG34_PLL_LOCK		BIT(6)
+#define REG34_PHY_CLK_READY	BIT(5)
 
 #define PHY_PLL_DIV_REGS_NUM 6
 
@@ -369,29 +313,29 @@ struct reg_settings {
 };
 
 static const struct reg_settings common_phy_cfg[] = {
-	{ PHY_REG_00, 0x00 }, { PHY_REG_01, 0xd1 },
-	{ PHY_REG_08, 0x4f }, { PHY_REG_09, 0x30 },
-	{ PHY_REG_10, 0x33 }, { PHY_REG_11, 0x65 },
+	{ PHY_REG(0), 0x00 }, { PHY_REG(1), 0xd1 },
+	{ PHY_REG(8), 0x4f }, { PHY_REG(9), 0x30 },
+	{ PHY_REG(10), 0x33 }, { PHY_REG(11), 0x65 },
 	/* REG12 pixclk specific */
 	/* REG13 pixclk specific */
 	/* REG14 pixclk specific */
-	{ PHY_REG_15, 0x80 }, { PHY_REG_16, 0x6c },
-	{ PHY_REG_17, 0xf2 }, { PHY_REG_18, 0x67 },
-	{ PHY_REG_19, 0x00 }, { PHY_REG_20, 0x10 },
+	{ PHY_REG(15), 0x80 }, { PHY_REG(16), 0x6c },
+	{ PHY_REG(17), 0xf2 }, { PHY_REG(18), 0x67 },
+	{ PHY_REG(19), 0x00 }, { PHY_REG(20), 0x10 },
 	/* REG21 pixclk specific */
-	{ PHY_REG_22, 0x30 }, { PHY_REG_23, 0x32 },
-	{ PHY_REG_24, 0x60 }, { PHY_REG_25, 0x8f },
-	{ PHY_REG_26, 0x00 }, { PHY_REG_27, 0x00 },
-	{ PHY_REG_28, 0x08 }, { PHY_REG_29, 0x00 },
-	{ PHY_REG_30, 0x00 }, { PHY_REG_31, 0x00 },
-	{ PHY_REG_32, 0x00 }, { PHY_REG_33, 0x80 },
-	{ PHY_REG_34, 0x00 }, { PHY_REG_35, 0x00 },
-	{ PHY_REG_36, 0x00 }, { PHY_REG_37, 0x00 },
-	{ PHY_REG_38, 0x00 }, { PHY_REG_39, 0x00 },
-	{ PHY_REG_40, 0x00 }, { PHY_REG_41, 0xe0 },
-	{ PHY_REG_42, 0x83 }, { PHY_REG_43, 0x0f },
-	{ PHY_REG_44, 0x3E }, { PHY_REG_45, 0xf8 },
-	{ PHY_REG_46, 0x00 }, { PHY_REG_47, 0x00 }
+	{ PHY_REG(22), 0x30 }, { PHY_REG(23), 0x32 },
+	{ PHY_REG(24), 0x60 }, { PHY_REG(25), 0x8f },
+	{ PHY_REG(26), 0x00 }, { PHY_REG(27), 0x00 },
+	{ PHY_REG(28), 0x08 }, { PHY_REG(29), 0x00 },
+	{ PHY_REG(30), 0x00 }, { PHY_REG(31), 0x00 },
+	{ PHY_REG(32), 0x00 }, { PHY_REG(33), 0x80 },
+	{ PHY_REG(34), 0x00 }, { PHY_REG(35), 0x00 },
+	{ PHY_REG(36), 0x00 }, { PHY_REG(37), 0x00 },
+	{ PHY_REG(38), 0x00 }, { PHY_REG(39), 0x00 },
+	{ PHY_REG(40), 0x00 }, { PHY_REG(41), 0xe0 },
+	{ PHY_REG(42), 0x83 }, { PHY_REG(43), 0x0f },
+	{ PHY_REG(44), 0x3E }, { PHY_REG(45), 0xf8 },
+	{ PHY_REG(46), 0x00 }, { PHY_REG(47), 0x00 }
 };
 
 struct fsl_samsung_hdmi_phy {
@@ -442,7 +386,7 @@ fsl_samsung_hdmi_phy_configure_pixclk(struct fsl_samsung_hdmi_phy *phy,
 	}
 
 	writeb(REG21_SEL_TX_CK_INV | FIELD_PREP(REG21_PMS_S_MASK, div),
-	       phy->regs + PHY_REG_21);
+	       phy->regs + PHY_REG(21));
 }
 
 static void
@@ -469,7 +413,7 @@ fsl_samsung_hdmi_phy_configure_pll_lock_det(struct fsl_samsung_hdmi_phy *phy,
 		break;
 	}
 
-	writeb(FIELD_PREP(REG12_CK_DIV_MASK, ilog2(div)), phy->regs + PHY_REG_12);
+	writeb(FIELD_PREP(REG12_CK_DIV_MASK, ilog2(div)), phy->regs + PHY_REG(12));
 
 	/*
 	 * Calculation for the frequency lock detector target code (fld_tg_code)
@@ -489,11 +433,11 @@ fsl_samsung_hdmi_phy_configure_pll_lock_det(struct fsl_samsung_hdmi_phy *phy,
 
 	/* FLD_TOL and FLD_RP_CODE taken from downstream driver */
 	writeb(FIELD_PREP(REG13_TG_CODE_LOW_MASK, fld_tg_code),
-	       phy->regs + PHY_REG_13);
+	       phy->regs + PHY_REG(13));
 	writeb(FIELD_PREP(REG14_TOL_MASK, 2) |
 	       FIELD_PREP(REG14_RP_CODE_MASK, 2) |
 	       FIELD_PREP(REG14_TG_CODE_HIGH_MASK, fld_tg_code >> 8),
-	       phy->regs + PHY_REG_14);
+	       phy->regs + PHY_REG(14));
 }
 
 static int fsl_samsung_hdmi_phy_configure(struct fsl_samsung_hdmi_phy *phy,
@@ -503,7 +447,7 @@ static int fsl_samsung_hdmi_phy_configure(struct fsl_samsung_hdmi_phy *phy,
 	u8 val;
 
 	/* HDMI PHY init */
-	writeb(REG33_FIX_DA, phy->regs + PHY_REG_33);
+	writeb(REG33_FIX_DA, phy->regs + PHY_REG(33));
 
 	/* common PHY registers */
 	for (i = 0; i < ARRAY_SIZE(common_phy_cfg); i++)
@@ -511,14 +455,14 @@ static int fsl_samsung_hdmi_phy_configure(struct fsl_samsung_hdmi_phy *phy,
 
 	/* set individual PLL registers PHY_REG2 ... PHY_REG7 */
 	for (i = 0; i < PHY_PLL_DIV_REGS_NUM; i++)
-		writeb(cfg->pll_div_regs[i], phy->regs + PHY_REG_02 + i * 4);
+		writeb(cfg->pll_div_regs[i], phy->regs + PHY_REG(2) + i * 4);
 
 	fsl_samsung_hdmi_phy_configure_pixclk(phy, cfg);
 	fsl_samsung_hdmi_phy_configure_pll_lock_det(phy, cfg);
 
-	writeb(REG33_FIX_DA | REG33_MODE_SET_DONE, phy->regs + PHY_REG_33);
+	writeb(REG33_FIX_DA | REG33_MODE_SET_DONE, phy->regs + PHY_REG(33));
 
-	ret = readb_poll_timeout(phy->regs + PHY_REG_34, val,
+	ret = readb_poll_timeout(phy->regs + PHY_REG(34), val,
 				 val & REG34_PLL_LOCK, 50, 20000);
 	if (ret)
 		dev_err(phy->dev, "PLL failed to lock\n");
-- 
2.43.0



From aford173 at gmail.com  Wed Aug 28 19:12:45 2024
From: aford173 at gmail.com (Adam Ford)
Date: Wed, 28 Aug 2024 21:12:45 -0500
Subject: [RFC V2 2/2] phy: freescale: fsl-samsung-hdmi: Support dynamic integer divider
In-Reply-To: <20240829021256.787615-1-aford173@gmail.com>
References: <20240829021256.787615-1-aford173@gmail.com>
Message-ID: <20240829021256.787615-2-aford173@gmail.com>

There is currently a look-up table for a variety of resolutions.
Since the phy has the ability to dynamically calculate the values
necessary to use the intger divider which should allow more
resolutions without having to update the look-up-table.  If the
integer calculator cannot get an exact frequency, it falls back
to the look-up-table.  Because the LUT algorithm does some
rounding, I did not remove integer entries from the LUT.

Signed-off-by: Adam Ford <aford173 at gmail.com>

diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
index bc5d3625ece6..76e0899c6006 100644
--- a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
+++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
@@ -16,6 +16,8 @@
 
 #define PHY_REG(reg)		(reg * 4)
 
+#define REG01_PMS_P_MASK	GENMASK(3, 0)
+#define REG03_PMS_S_MASK	GENMASK(7, 4)
 #define REG12_CK_DIV_MASK	GENMASK(5, 4)
 #define REG13_TG_CODE_LOW_MASK	GENMASK(7, 0)
 #define REG14_TOL_MASK		GENMASK(7, 4)
@@ -31,11 +33,17 @@
 
 #define PHY_PLL_DIV_REGS_NUM 6
 
+#ifndef MHZ
+#define MHZ	(1000UL * 1000UL)
+#endif
+
 struct phy_config {
 	u32	pixclk;
 	u8	pll_div_regs[PHY_PLL_DIV_REGS_NUM];
 };
 
+static struct phy_config custom_phy_pll_cfg;
+
 static const struct phy_config phy_pll_cfg[] = {
 	{
 		.pixclk = 22250000,
@@ -440,10 +448,83 @@ fsl_samsung_hdmi_phy_configure_pll_lock_det(struct fsl_samsung_hdmi_phy *phy,
 	       phy->regs + PHY_REG(14));
 }
 
+static unsigned long fsl_samsung_hdmi_phy_find_pms(unsigned long fout, u8 *p, u16 *m, u8 *s)
+{
+	unsigned long best_freq = 0;
+	u32 min_delta = 0xffffffff;
+	u8 _p, best_p;
+	u16 _m, best_m;
+	u8 _s, best_s;
+
+	for (_p = 1; _p <= 11; ++_p) {
+		for (_s = 1; _s <= 16; ++_s) {
+			u64 tmp;
+			u32 delta;
+
+			/* s must be even */
+			if (_s > 1 && (_s & 0x01) == 1)
+				_s++;
+
+			/* _s cannot be 14 per the TRM */
+			if (_s == 14)
+				continue;
+
+			/*
+			 * TODO: Ref Manual doesn't state the range of _m
+			 * so this should be further refined if possible.
+			 * This range was set based on the original values
+			 * in the look-up table
+			 */
+			tmp = (u64)fout * (_p * _s);
+			do_div(tmp, 24 * MHZ);
+			_m = tmp;
+			if (_m < 0x30 || _m > 0x7b)
+				continue;
+
+			/*
+			 * Rev 2 of the Ref Manual states the
+			 * VCO can range between 750MHz and
+			 * 3GHz.  The VCO is assumed to be _m x
+			 * the reference frequency of 24MHz divided
+			 * by the prescaler, _p
+			 */
+			tmp = (u64)_m * 24 * MHZ;
+			do_div(tmp, _p);
+			if (tmp < 750 * MHZ ||
+			    tmp > 3000 * MHZ)
+				continue;
+
+			tmp = (u64)_m * 24 * MHZ;
+			do_div(tmp, _p * _s);
+
+			delta = abs(fout - tmp);
+			if (delta < min_delta) {
+				best_p = _p;
+				best_s = _s;
+				best_m = _m;
+				min_delta = delta;
+				best_freq = tmp;
+			}
+		}
+	}
+
+	if (best_freq) {
+		*p = best_p;
+		*m = best_m;
+		*s = best_s;
+	}
+
+	return best_freq;
+}
+
 static int fsl_samsung_hdmi_phy_configure(struct fsl_samsung_hdmi_phy *phy,
 					  const struct phy_config *cfg)
 {
+	u32 desired_clock = cfg->pixclk * 5;
+	u32 close_freq;
 	int i, ret;
+	u16 m;
+	u8 p, s;
 	u8 val;
 
 	/* HDMI PHY init */
@@ -453,11 +534,38 @@ static int fsl_samsung_hdmi_phy_configure(struct fsl_samsung_hdmi_phy *phy,
 	for (i = 0; i < ARRAY_SIZE(common_phy_cfg); i++)
 		writeb(common_phy_cfg[i].val, phy->regs + common_phy_cfg[i].reg);
 
-	/* set individual PLL registers PHY_REG2 ... PHY_REG7 */
-	for (i = 0; i < PHY_PLL_DIV_REGS_NUM; i++)
-		writeb(cfg->pll_div_regs[i], phy->regs + PHY_REG(2) + i * 4);
+	/* Using the PMS calculator alone, determine if can use integer divider */
+	close_freq = fsl_samsung_hdmi_phy_find_pms(desired_clock, &p, &m, &s);
+
+	/* If the clock cannot be configured with integer divder, use the fractional divider */
+	if (close_freq != desired_clock) {
+		dev_dbg(phy->dev, "fsl_samsung_hdmi_phy: use fractional divider\n");
+		/* set individual PLL registers PHY_REG2 ... PHY_REG7 */
+		for (i = 0; i < PHY_PLL_DIV_REGS_NUM; i++)
+			writeb(cfg->pll_div_regs[i], phy->regs + PHY_REG(2) + i * 4);
+		fsl_samsung_hdmi_phy_configure_pixclk(phy, cfg);
+	} else {
+		dev_dbg(phy->dev, "fsl_samsung_hdmi_phy: use integer divider\n");
+		dev_dbg(phy->dev, "fsl_samsung_hdmi_phy: P = %d\n", p);
+		dev_dbg(phy->dev, "fsl_samsung_hdmi_phy: M = %d\n", m);
+		dev_dbg(phy->dev, "fsl_samsung_hdmi_phy: S = %d\n", s);
+		dev_dbg(phy->dev, "fsl_samsung_hdmi_phy: frequency = %u\n", close_freq);
+
+		/* Write integer divder values for PMS */
+		writeb(FIELD_PREP(REG01_PMS_P_MASK, p), phy->regs + PHY_REG(1));
+		writeb(m, phy->regs + PHY_REG(2));
+		writeb(FIELD_PREP(REG03_PMS_S_MASK, s-1), phy->regs + PHY_REG(3));
+
+		/* Configure PHY to disable fractional divider */
+		writeb(0x00, phy->regs + PHY_REG(4));
+		writeb(0x00, phy->regs + PHY_REG(5));
+		writeb(0x80, phy->regs + PHY_REG(6));
+		writeb(0x00, phy->regs + PHY_REG(7));
+
+		writeb(REG21_SEL_TX_CK_INV | FIELD_PREP(REG21_PMS_S_MASK, s-1),
+		       phy->regs + PHY_REG(21));
+	}
 
-	fsl_samsung_hdmi_phy_configure_pixclk(phy, cfg);
 	fsl_samsung_hdmi_phy_configure_pll_lock_det(phy, cfg);
 
 	writeb(REG33_FIX_DA | REG33_MODE_SET_DONE, phy->regs + PHY_REG(33));
@@ -484,8 +592,17 @@ static unsigned long phy_clk_recalc_rate(struct clk_hw *hw,
 static long phy_clk_round_rate(struct clk_hw *hw,
 			       unsigned long rate, unsigned long *parent_rate)
 {
+	u32 int_div_clk;
 	int i;
+	u16 m;
+	u8 p, s;
+
+	/* If the integer divider works, just use it */
+	int_div_clk = fsl_samsung_hdmi_phy_find_pms(rate * 5, &p, &m, &s) / 5;
+	if (int_div_clk == rate)
+		return int_div_clk;
 
+	/* Otherwise, fall back to the LUT */
 	for (i = ARRAY_SIZE(phy_pll_cfg) - 1; i >= 0; i--)
 		if (phy_pll_cfg[i].pixclk <= rate)
 			return phy_pll_cfg[i].pixclk;
@@ -497,16 +614,28 @@ static int phy_clk_set_rate(struct clk_hw *hw,
 			    unsigned long rate, unsigned long parent_rate)
 {
 	struct fsl_samsung_hdmi_phy *phy = to_fsl_samsung_hdmi_phy(hw);
+	u32 int_div_clk;
 	int i;
-
-	for (i = ARRAY_SIZE(phy_pll_cfg) - 1; i >= 0; i--)
-		if (phy_pll_cfg[i].pixclk <= rate)
-			break;
-
-	if (i < 0)
-		return -EINVAL;
-
-	phy->cur_cfg = &phy_pll_cfg[i];
+	u16 m;
+	u8 p, s;
+
+	/* If the integer divider works, just use it */
+	int_div_clk = fsl_samsung_hdmi_phy_find_pms(rate * 5, &p, &m, &s) / 5;
+	if (int_div_clk == rate) {
+		/* Just set the pixclk rate, the rest will be calculated */
+		custom_phy_pll_cfg.pixclk = int_div_clk;
+		phy->cur_cfg  = &custom_phy_pll_cfg;
+	} else {
+		/* Otherwise, search the LUT */
+		for (i = ARRAY_SIZE(phy_pll_cfg) - 1; i >= 0; i--)
+			if (phy_pll_cfg[i].pixclk <= rate)
+				break;
+
+		if (i < 0)
+			return -EINVAL;
+
+		phy->cur_cfg = &phy_pll_cfg[i];
+	}
 
 	return fsl_samsung_hdmi_phy_configure(phy, phy->cur_cfg);
 }
-- 
2.43.0



From dmitry.baryshkov at linaro.org  Thu Aug 29 01:08:40 2024
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Thu, 29 Aug 2024 11:08:40 +0300
Subject: [PATCH 2/4] phy: qualcomm: phy-qcom-apq8064-sata: Convert to
 devm_clk_get_enabled()
In-Reply-To: <20240822084400.1595426-1-frank.li@vivo.com>
References: <20240822084400.1595426-1-frank.li@vivo.com>
Message-ID: <fngnwis5yyf56w3vs424clfuqf6qvaquq4udipqidco7jmr6fx@ijledjmr6apj>

On Thu, Aug 22, 2024 at 02:44:00AM GMT, Yangtao Li wrote:
> Convert devm_clk_get(), clk_prepare_enable() to a single
> call to devm_clk_get_enabled(), as this is exactly
> what this function does.
> 
> Signed-off-by: Yangtao Li <frank.li at vivo.com>
> ---
>  drivers/phy/qualcomm/phy-qcom-apq8064-sata.c | 22 ++++----------------
>  1 file changed, 4 insertions(+), 18 deletions(-)
> 

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>


-- 
With best wishes
Dmitry


From dmitry.baryshkov at linaro.org  Thu Aug 29 01:08:54 2024
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Thu, 29 Aug 2024 11:08:54 +0300
Subject: [PATCH 3/4] phy: qualcomm: phy-qcom-ipq806x-sata: Convert to
 devm_clk_get_enabled()
In-Reply-To: <20240822084417.1596110-1-frank.li@vivo.com>
References: <20240822084417.1596110-1-frank.li@vivo.com>
Message-ID: <bo3hx7ma3np3wjpjc3zmya7iagefnlkwyh4s5gv7jxhr3ompob@cpehveanuxmw>

On Thu, Aug 22, 2024 at 02:44:16AM GMT, Yangtao Li wrote:
> Convert devm_clk_get(), clk_prepare_enable() to a single
> call to devm_clk_get_enabled(), as this is exactly
> what this function does.
> 
> Signed-off-by: Yangtao Li <frank.li at vivo.com>
> ---
>  drivers/phy/qualcomm/phy-qcom-ipq806x-sata.c | 22 ++++----------------
>  1 file changed, 4 insertions(+), 18 deletions(-)
> 


Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>

-- 
With best wishes
Dmitry


From dmitry.baryshkov at linaro.org  Thu Aug 29 01:21:12 2024
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Thu, 29 Aug 2024 11:21:12 +0300
Subject: [PATCH 0/2] phy: add NXP PTN3222 eUSB2 to USB2 redriver
Message-ID: <20240829-nxp-ptn3222-v1-0-46906bc4747a@linaro.org>

The NXP PTN3222 is the single-port eUSB2 to USB2 redriver that performs
translation between eUSB2 and USB2 signalling schemes. It supports all
three data rates: Low Speed, Full Speed and High Speed.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
---
Dmitry Baryshkov (2):
      dt-bindings: phy: add NXP PTN3222 eUSB2 to USB2 redriver
      phy: add NXP PTN3222 eUSB2 to USB2 redriver

 .../devicetree/bindings/phy/nxp,ptn3222.yaml       |  55 ++++++++++
 drivers/phy/Kconfig                                |  11 ++
 drivers/phy/Makefile                               |   1 +
 drivers/phy/phy-nxp-ptn3222.c                      | 119 +++++++++++++++++++++
 4 files changed, 186 insertions(+)
---
base-commit: 195a402a75791e6e0d96d9da27ca77671bc656a8
change-id: 20240829-nxp-ptn3222-30bbb81e984e

Best regards,
-- 
Dmitry Baryshkov <dmitry.baryshkov at linaro.org>



From dmitry.baryshkov at linaro.org  Thu Aug 29 01:21:14 2024
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Thu, 29 Aug 2024 11:21:14 +0300
Subject: [PATCH 2/2] phy: add NXP PTN3222 eUSB2 to USB2 redriver
In-Reply-To: <20240829-nxp-ptn3222-v1-0-46906bc4747a@linaro.org>
References: <20240829-nxp-ptn3222-v1-0-46906bc4747a@linaro.org>
Message-ID: <20240829-nxp-ptn3222-v1-2-46906bc4747a@linaro.org>

The NXP PTN3222 is the single-port eUSB2 to USB2 redriver that performs
translation between eUSB2 and USB2 signalling schemes. It supports all
three data rates: Low Speed, Full Speed and High Speed.

The reset state enables autonegotiation of the PHY role and of the data
rate, so no additional programming is required.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
---
 drivers/phy/Kconfig           |  11 ++++
 drivers/phy/Makefile          |   1 +
 drivers/phy/phy-nxp-ptn3222.c | 119 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 131 insertions(+)

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index dfab1c66b3e5..cb06a7f79740 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -82,6 +82,17 @@ config PHY_AIROHA_PCIE
 	  This driver create the basic PHY instance and provides initialize
 	  callback for PCIe GEN3 port.
 
+config PHY_NXP_PTN3222
+	tristate "NXP PTN3222 1-port eUSB2 to USB2 redriver"
+	depends on I2C
+	depends on OF
+	select GENERIC_PHY
+	help
+	  Enable this to support NXP PTN3222 1-port eUSB2 to USB2 Redriver.
+	  This redriver performs translation between eUSB2 and USB2 signalling
+	  schemes. It supports all three USB 2.0 data rates: Low Speed, Full
+	  Speed and High Speed.
+
 source "drivers/phy/allwinner/Kconfig"
 source "drivers/phy/amlogic/Kconfig"
 source "drivers/phy/broadcom/Kconfig"
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 5fcbce5f9ab1..b64247046575 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_PHY_XGENE)			+= phy-xgene.o
 obj-$(CONFIG_PHY_PISTACHIO_USB)		+= phy-pistachio-usb.o
 obj-$(CONFIG_USB_LGM_PHY)		+= phy-lgm-usb.o
 obj-$(CONFIG_PHY_AIROHA_PCIE)		+= phy-airoha-pcie.o
+obj-$(CONFIG_PHY_NXP_PTN3222)		+= phy-nxp-ptn3222.o
 obj-y					+= allwinner/	\
 					   amlogic/	\
 					   broadcom/	\
diff --git a/drivers/phy/phy-nxp-ptn3222.c b/drivers/phy/phy-nxp-ptn3222.c
new file mode 100644
index 000000000000..429a91910f14
--- /dev/null
+++ b/drivers/phy/phy-nxp-ptn3222.c
@@ -0,0 +1,119 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2024, Linaro Limited
+ */
+
+#include <linux/gpio/consumer.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/phy/phy.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+
+#define NUM_SUPPLIES 2
+
+struct ptn3222 {
+	struct i2c_client *client;
+	struct phy *phy;
+	struct gpio_desc *reset_gpio;
+	struct regulator_bulk_data supplies[NUM_SUPPLIES];
+};
+
+static int ptn3222_init(struct phy *phy)
+{
+	struct ptn3222 *ptn3222 = phy_get_drvdata(phy);
+	int ret;
+
+	ret = regulator_bulk_enable(NUM_SUPPLIES, ptn3222->supplies);
+	if (ret)
+		return ret;
+
+	gpiod_set_value_cansleep(ptn3222->reset_gpio, 0);
+
+	return 0;
+}
+
+static int ptn3222_exit(struct phy *phy)
+{
+	struct ptn3222 *ptn3222 = phy_get_drvdata(phy);
+
+	gpiod_set_value_cansleep(ptn3222->reset_gpio, 1);
+
+	return regulator_bulk_disable(NUM_SUPPLIES, ptn3222->supplies);
+}
+
+static const struct phy_ops ptn3222_ops = {
+	.init		= ptn3222_init,
+	.exit		= ptn3222_exit,
+	.owner		= THIS_MODULE,
+};
+
+static int ptn3222_probe(struct i2c_client *client)
+{
+	struct device *dev = &client->dev;
+	struct phy_provider *phy_provider;
+	struct ptn3222 *ptn3222;
+	int ret;
+
+	ptn3222 = devm_kzalloc(dev, sizeof(*ptn3222), GFP_KERNEL);
+	if (!ptn3222)
+		return -ENOMEM;
+
+	ptn3222->client = client;
+
+	ptn3222->reset_gpio = devm_gpiod_get_optional(dev, "reset",
+						      GPIOD_OUT_HIGH);
+	if (IS_ERR(ptn3222->reset_gpio))
+		return dev_err_probe(dev, PTR_ERR(ptn3222->reset_gpio),
+				     "unable to acquire reset gpio\n");
+
+	ptn3222->supplies[0].supply = "vdd3v3";
+	ptn3222->supplies[0].init_load_uA = 11000;
+	ptn3222->supplies[1].supply = "vdd1v8";
+	ptn3222->supplies[1].init_load_uA = 55000;
+
+	ret = devm_regulator_bulk_get(dev,
+				      NUM_SUPPLIES,
+				      ptn3222->supplies);
+	if (ret)
+		return ret;
+
+	ptn3222->phy = devm_phy_create(dev, dev->of_node, &ptn3222_ops);
+	if (IS_ERR(ptn3222->phy)) {
+		dev_err(dev, "failed to create PHY: %d\n", ret);
+		return PTR_ERR(ptn3222->phy);
+	}
+
+	phy_set_drvdata(ptn3222->phy, ptn3222);
+
+	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
+
+	return PTR_ERR_OR_ZERO(phy_provider);
+}
+
+static const struct i2c_device_id ptn3222_table[] = {
+	{ "ptn3222" },
+	{ }
+};
+MODULE_DEVICE_TABLE(i2c, ptn3222_table);
+
+static const struct of_device_id ptn3222_of_table[] = {
+	{ .compatible = "nxp,ptn3222" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, ptn3222_of_table);
+
+static struct i2c_driver ptn3222_driver = {
+	.driver = {
+		.name = "ptn3222",
+		.of_match_table = ptn3222_of_table,
+	},
+	.probe = ptn3222_probe,
+	.id_table = ptn3222_table,
+};
+
+module_i2c_driver(ptn3222_driver);
+
+MODULE_DESCRIPTION("NXP PTN3222 eUSB2 Redriver driver");
+MODULE_LICENSE("GPL");

-- 
2.39.2



From dmitry.baryshkov at linaro.org  Thu Aug 29 01:21:13 2024
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Thu, 29 Aug 2024 11:21:13 +0300
Subject: [PATCH 1/2] dt-bindings: phy: add NXP PTN3222 eUSB2 to USB2
 redriver
In-Reply-To: <20240829-nxp-ptn3222-v1-0-46906bc4747a@linaro.org>
References: <20240829-nxp-ptn3222-v1-0-46906bc4747a@linaro.org>
Message-ID: <20240829-nxp-ptn3222-v1-1-46906bc4747a@linaro.org>

The NXP PTN3222 is the single-port eUSB2 to USB2 redriver that performs
translation between eUSB2 and USB2 signalling schemes. It supports all
three data rates: Low Speed, Full Speed and High Speed.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
---
 .../devicetree/bindings/phy/nxp,ptn3222.yaml       | 55 ++++++++++++++++++++++
 1 file changed, 55 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/nxp,ptn3222.yaml b/Documentation/devicetree/bindings/phy/nxp,ptn3222.yaml
new file mode 100644
index 000000000000..acec5bb2391d
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/nxp,ptn3222.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/nxp,ptn3222.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP PTN3222 1-port eUSB2 to USB2 redriver
+
+maintainers:
+  - Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
+
+properties:
+  compatible:
+    enum:
+      - nxp,ptn3222
+
+  reg:
+    maxItems: 1
+
+  "#phy-cells":
+    const: 0
+
+  vdd1v8-supply:
+    description: power supply (1.8V)
+
+  vdd3v3-supply:
+    description: power supply (3.3V)
+
+  reset-gpios: true
+
+required:
+  - compatible
+  - reg
+  - '#phy-cells'
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/gpio/gpio.h>
+
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        redriver at 4f {
+            compatible = "nxp,ptn3222";
+            reg = <0x4f>;
+            #phy-cells = <0>;
+            vdd3v3-supply = <&vreg_3p3>;
+            vdd1v8-supply = <&vreg_1p8>;
+            reset-gpios = <&gpio_reset GPIO_ACTIVE_LOW>;
+        };
+    };
+...

-- 
2.39.2



From neil.armstrong at linaro.org  Thu Aug 29 01:30:49 2024
From: neil.armstrong at linaro.org (neil.armstrong at linaro.org)
Date: Thu, 29 Aug 2024 10:30:49 +0200
Subject: [PATCH 2/2] phy: add NXP PTN3222 eUSB2 to USB2 redriver
In-Reply-To: <20240829-nxp-ptn3222-v1-2-46906bc4747a@linaro.org>
References: <20240829-nxp-ptn3222-v1-0-46906bc4747a@linaro.org>
 <20240829-nxp-ptn3222-v1-2-46906bc4747a@linaro.org>
Message-ID: <79a643de-9808-4866-9e41-8bd5ab55ffed@linaro.org>

On 29/08/2024 10:21, Dmitry Baryshkov wrote:
> The NXP PTN3222 is the single-port eUSB2 to USB2 redriver that performs
> translation between eUSB2 and USB2 signalling schemes. It supports all
> three data rates: Low Speed, Full Speed and High Speed.
> 
> The reset state enables autonegotiation of the PHY role and of the data
> rate, so no additional programming is required.
> 
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
> ---
>   drivers/phy/Kconfig           |  11 ++++
>   drivers/phy/Makefile          |   1 +
>   drivers/phy/phy-nxp-ptn3222.c | 119 ++++++++++++++++++++++++++++++++++++++++++
>   3 files changed, 131 insertions(+)
> 
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index dfab1c66b3e5..cb06a7f79740 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -82,6 +82,17 @@ config PHY_AIROHA_PCIE
>   	  This driver create the basic PHY instance and provides initialize
>   	  callback for PCIe GEN3 port.
>   
> +config PHY_NXP_PTN3222
> +	tristate "NXP PTN3222 1-port eUSB2 to USB2 redriver"
> +	depends on I2C
> +	depends on OF
> +	select GENERIC_PHY
> +	help
> +	  Enable this to support NXP PTN3222 1-port eUSB2 to USB2 Redriver.
> +	  This redriver performs translation between eUSB2 and USB2 signalling
> +	  schemes. It supports all three USB 2.0 data rates: Low Speed, Full
> +	  Speed and High Speed.
> +
>   source "drivers/phy/allwinner/Kconfig"
>   source "drivers/phy/amlogic/Kconfig"
>   source "drivers/phy/broadcom/Kconfig"
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 5fcbce5f9ab1..b64247046575 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -11,6 +11,7 @@ obj-$(CONFIG_PHY_XGENE)			+= phy-xgene.o
>   obj-$(CONFIG_PHY_PISTACHIO_USB)		+= phy-pistachio-usb.o
>   obj-$(CONFIG_USB_LGM_PHY)		+= phy-lgm-usb.o
>   obj-$(CONFIG_PHY_AIROHA_PCIE)		+= phy-airoha-pcie.o
> +obj-$(CONFIG_PHY_NXP_PTN3222)		+= phy-nxp-ptn3222.o
>   obj-y					+= allwinner/	\
>   					   amlogic/	\
>   					   broadcom/	\
> diff --git a/drivers/phy/phy-nxp-ptn3222.c b/drivers/phy/phy-nxp-ptn3222.c
> new file mode 100644
> index 000000000000..429a91910f14
> --- /dev/null
> +++ b/drivers/phy/phy-nxp-ptn3222.c
> @@ -0,0 +1,119 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2024, Linaro Limited
> + */
> +
> +#include <linux/gpio/consumer.h>
> +#include <linux/i2c.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/phy/phy.h>
> +#include <linux/regmap.h>
> +#include <linux/regulator/consumer.h>
> +
> +#define NUM_SUPPLIES 2
> +
> +struct ptn3222 {
> +	struct i2c_client *client;
> +	struct phy *phy;
> +	struct gpio_desc *reset_gpio;
> +	struct regulator_bulk_data supplies[NUM_SUPPLIES];
> +};
> +
> +static int ptn3222_init(struct phy *phy)
> +{
> +	struct ptn3222 *ptn3222 = phy_get_drvdata(phy);
> +	int ret;
> +
> +	ret = regulator_bulk_enable(NUM_SUPPLIES, ptn3222->supplies);
> +	if (ret)
> +		return ret;
> +
> +	gpiod_set_value_cansleep(ptn3222->reset_gpio, 0);
> +
> +	return 0;
> +}
> +
> +static int ptn3222_exit(struct phy *phy)
> +{
> +	struct ptn3222 *ptn3222 = phy_get_drvdata(phy);
> +
> +	gpiod_set_value_cansleep(ptn3222->reset_gpio, 1);
> +
> +	return regulator_bulk_disable(NUM_SUPPLIES, ptn3222->supplies);
> +}
> +
> +static const struct phy_ops ptn3222_ops = {
> +	.init		= ptn3222_init,
> +	.exit		= ptn3222_exit,
> +	.owner		= THIS_MODULE,
> +};
> +
> +static int ptn3222_probe(struct i2c_client *client)
> +{
> +	struct device *dev = &client->dev;
> +	struct phy_provider *phy_provider;
> +	struct ptn3222 *ptn3222;
> +	int ret;
> +
> +	ptn3222 = devm_kzalloc(dev, sizeof(*ptn3222), GFP_KERNEL);
> +	if (!ptn3222)
> +		return -ENOMEM;
> +
> +	ptn3222->client = client;
> +
> +	ptn3222->reset_gpio = devm_gpiod_get_optional(dev, "reset",
> +						      GPIOD_OUT_HIGH);
> +	if (IS_ERR(ptn3222->reset_gpio))
> +		return dev_err_probe(dev, PTR_ERR(ptn3222->reset_gpio),
> +				     "unable to acquire reset gpio\n");
> +
> +	ptn3222->supplies[0].supply = "vdd3v3";
> +	ptn3222->supplies[0].init_load_uA = 11000;
> +	ptn3222->supplies[1].supply = "vdd1v8";
> +	ptn3222->supplies[1].init_load_uA = 55000;
> +
> +	ret = devm_regulator_bulk_get(dev,
> +				      NUM_SUPPLIES,
> +				      ptn3222->supplies);

Suggestion only, you could switch to devm_regulator_bulk_get_const()

> +	if (ret)
> +		return ret;
> +
> +	ptn3222->phy = devm_phy_create(dev, dev->of_node, &ptn3222_ops);
> +	if (IS_ERR(ptn3222->phy)) {
> +		dev_err(dev, "failed to create PHY: %d\n", ret);
> +		return PTR_ERR(ptn3222->phy);
> +	}
> +
> +	phy_set_drvdata(ptn3222->phy, ptn3222);
> +
> +	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
> +
> +	return PTR_ERR_OR_ZERO(phy_provider);
> +}
> +
> +static const struct i2c_device_id ptn3222_table[] = {
> +	{ "ptn3222" },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(i2c, ptn3222_table);
> +
> +static const struct of_device_id ptn3222_of_table[] = {
> +	{ .compatible = "nxp,ptn3222" },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(of, ptn3222_of_table);
> +
> +static struct i2c_driver ptn3222_driver = {
> +	.driver = {
> +		.name = "ptn3222",
> +		.of_match_table = ptn3222_of_table,
> +	},
> +	.probe = ptn3222_probe,
> +	.id_table = ptn3222_table,
> +};
> +
> +module_i2c_driver(ptn3222_driver);
> +
> +MODULE_DESCRIPTION("NXP PTN3222 eUSB2 Redriver driver");
> +MODULE_LICENSE("GPL");
> 

Apart that, it looks fine, please add my:
Reviewed-by: Neil Armstrong <neil.armstrong at linaro.org>


From xu.yang_2 at nxp.com  Thu Aug 29 01:54:44 2024
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Thu, 29 Aug 2024 16:54:44 +0800
Subject: [PATCH v2 6/6] ARM: dts: imx7ulp: add "nxp,sim" property for
 usbphy1
In-Reply-To: <Zs6A4OEgaC8a3gcw@dragon>
References: <20240726113207.3393247-1-xu.yang_2@nxp.com>
 <20240726113207.3393247-6-xu.yang_2@nxp.com>
 <20240826065612.ol4fjib4g2jrvoy7@hippo>
 <Zs6A4OEgaC8a3gcw@dragon>
Message-ID: <20240829085444.ayfp2zkeeyxya2ju@hippo>

On Wed, Aug 28, 2024 at 09:44:00AM +0800, Shawn Guo wrote:
> On Mon, Aug 26, 2024 at 02:56:12PM +0800, Xu Yang wrote:
> > Hi Shawn,
> > 
> > On Fri, Jul 26, 2024 at 07:32:07PM +0800, Xu Yang wrote:
> > > i.MX7ULP need properly set System Integration Module(SIM) module to make
> > > usb wakeup work well. This will add a "nxp,sim" property for usbphy1.
> > > 
> > > Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> > > 
> > > ---
> > > Changes in v2:
> > >  - no changes
> > > ---
> > >  arch/arm/boot/dts/nxp/imx/imx7ulp.dtsi | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/arch/arm/boot/dts/nxp/imx/imx7ulp.dtsi b/arch/arm/boot/dts/nxp/imx/imx7ulp.dtsi
> > > index ac338320ac1d..b093f2a447ae 100644
> > > --- a/arch/arm/boot/dts/nxp/imx/imx7ulp.dtsi
> > > +++ b/arch/arm/boot/dts/nxp/imx/imx7ulp.dtsi
> > > @@ -214,6 +214,7 @@ usbphy1: usb-phy at 40350000 {
> > >  			interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
> > >  			clocks = <&pcc2 IMX7ULP_CLK_USB_PHY>;
> > >  			#phy-cells = <0>;
> > > +			nxp,sim = <&sim>;
> > >  		};
> > >  
> > >  		usdhc0: mmc at 40370000 {
> > 
> > Could you please pick up patch 3 and 6?
> 
> Patch #3 should go via usb tree, and ping me on #6 after #3 is applied.

Okay.

Thanks,
Xu Yang

> 
> Shawn
> 


From dmitry.baryshkov at linaro.org  Thu Aug 29 02:02:46 2024
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Thu, 29 Aug 2024 12:02:46 +0300
Subject: [PATCH 07/11] phy: qcom: qmp-pcie-msm8996: Simplify with scoped
 for each OF child loop
In-Reply-To: <20240826-phy-of-node-scope-v1-7-5b4d82582644@linaro.org>
References: <20240826-phy-of-node-scope-v1-0-5b4d82582644@linaro.org>
 <20240826-phy-of-node-scope-v1-7-5b4d82582644@linaro.org>
Message-ID: <3omsbwonwputnyns5h6rq52bsafqb6is42jk6ty5pv7z2wmyvs@jeb33bmeotyh>

On Mon, Aug 26, 2024 at 12:07:23PM GMT, Krzysztof Kozlowski wrote:
> Use scoped for_each_available_child_of_node_scoped() when iterating over
> device nodes to make code a bit simpler.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> ---
>  drivers/phy/qualcomm/phy-qcom-qmp-pcie-msm8996.c | 11 +++--------
>  1 file changed, 3 insertions(+), 8 deletions(-)
> 

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>


-- 
With best wishes
Dmitry


From dmitry.baryshkov at linaro.org  Thu Aug 29 02:10:01 2024
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Thu, 29 Aug 2024 12:10:01 +0300
Subject: [PATCH V2 6/6] arm64: dts: qcom: ipq5018: Enable PCIe
In-Reply-To: <20240827045757.1101194-7-quic_srichara@quicinc.com>
References: <20240827045757.1101194-1-quic_srichara@quicinc.com>
 <20240827045757.1101194-7-quic_srichara@quicinc.com>
Message-ID: <nut3ru5rdjf3k3np47gqbpuczvpsuoismx6hp55ivc5mqmdglz@zyzbra46i6iz>

On Tue, Aug 27, 2024 at 10:27:57AM GMT, Sricharan R wrote:
> From: Nitheesh Sekar <quic_nsekar at quicinc.com>
> 
> Enable the PCIe controller and PHY nodes for RDP 432-c2.
> 
> Signed-off-by: Nitheesh Sekar <quic_nsekar at quicinc.com>
> Signed-off-by: Sricharan Ramabadhran <quic_srichara at quicinc.com>
> ---
>  [v2] Moved status as last property
> 
>  arch/arm64/boot/dts/qcom/ipq5018-rdp432-c2.dts | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/ipq5018-rdp432-c2.dts b/arch/arm64/boot/dts/qcom/ipq5018-rdp432-c2.dts
> index 8460b538eb6a..2b253da7f776 100644
> --- a/arch/arm64/boot/dts/qcom/ipq5018-rdp432-c2.dts
> +++ b/arch/arm64/boot/dts/qcom/ipq5018-rdp432-c2.dts
> @@ -28,6 +28,15 @@ &blsp1_uart1 {
>  	status = "okay";
>  };
>  
> +&pcie1 {
> +	perst-gpios = <&tlmm 15 GPIO_ACTIVE_LOW>;

pinctrl? wake-gpios?

> +	status = "okay";
> +};
> +
> +&pcie_x2phy {
> +	status = "okay";
> +};
> +
>  &sdhc_1 {
>  	pinctrl-0 = <&sdc_default_state>;
>  	pinctrl-names = "default";
> -- 
> 2.34.1
> 

-- 
With best wishes
Dmitry


From xu.yang_2 at nxp.com  Thu Aug 29 02:09:35 2024
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Thu, 29 Aug 2024 17:09:35 +0800
Subject: [PATCH v2 3/6] dt-bindings: phy: mxs-usb-phy: add nxp,sim
 property
In-Reply-To: <20240726113207.3393247-3-xu.yang_2@nxp.com>
References: <20240726113207.3393247-1-xu.yang_2@nxp.com>
 <20240726113207.3393247-3-xu.yang_2@nxp.com>
Message-ID: <20240829090935.ktc7jgd2en4qay2h@hippo>

Hi Greg,

On Fri, Jul 26, 2024 at 07:32:04PM +0800, Xu Yang wrote:
> i.MX7ULP need properly set System Integration Module(SIM) module to make
> usb wakeup work well. This will add a "nxp,sim" property.
> 
> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> 
> ---
> Changes in v2:
>  - add else branch suggested by Rob
> ---
>  .../devicetree/bindings/phy/fsl,mxs-usbphy.yaml | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/phy/fsl,mxs-usbphy.yaml b/Documentation/devicetree/bindings/phy/fsl,mxs-usbphy.yaml
> index f4b1ca2fb562..ce665a2779b7 100644
> --- a/Documentation/devicetree/bindings/phy/fsl,mxs-usbphy.yaml
> +++ b/Documentation/devicetree/bindings/phy/fsl,mxs-usbphy.yaml
> @@ -87,6 +87,12 @@ properties:
>      maximum: 119
>      default: 100
>  
> +  nxp,sim:
> +    description:
> +      The system integration module (SIM) provides system control and chip
> +      configuration registers.
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +
>  required:
>    - compatible
>    - reg
> @@ -110,6 +116,17 @@ allOf:
>        required:
>          - fsl,anatop
>  
> +  - if:
> +      properties:
> +        compatible:
> +          const: fsl,imx7ulp-usbphy
> +    then:
> +      required:
> +        - nxp,sim
> +    else:
> +      properties:
> +        nxp,sim: false
> +
>  additionalProperties: false
>  
>  examples:


Could you please pick up patch #3? Rest of the patches are mainlined.

Thanks,
Xu Yang

> -- 
> 2.34.1
> 


From dmitry.baryshkov at linaro.org  Thu Aug 29 03:19:24 2024
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Thu, 29 Aug 2024 13:19:24 +0300
Subject: [PATCH 2/2] phy: add NXP PTN3222 eUSB2 to USB2 redriver
In-Reply-To: <79a643de-9808-4866-9e41-8bd5ab55ffed@linaro.org>
References: <20240829-nxp-ptn3222-v1-0-46906bc4747a@linaro.org>
 <20240829-nxp-ptn3222-v1-2-46906bc4747a@linaro.org>
 <79a643de-9808-4866-9e41-8bd5ab55ffed@linaro.org>
Message-ID: <izr7linltwo4kbpp4dtls7bahvk4a2hwtqaz3fyuktjuiudqly@ivulir54ktxk>

On Thu, Aug 29, 2024 at 10:30:49AM GMT, neil.armstrong at linaro.org wrote:
> On 29/08/2024 10:21, Dmitry Baryshkov wrote:
> > The NXP PTN3222 is the single-port eUSB2 to USB2 redriver that performs
> > translation between eUSB2 and USB2 signalling schemes. It supports all
> > three data rates: Low Speed, Full Speed and High Speed.
> > 
> > The reset state enables autonegotiation of the PHY role and of the data
> > rate, so no additional programming is required.
> > 
> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
> > ---
> >   drivers/phy/Kconfig           |  11 ++++
> >   drivers/phy/Makefile          |   1 +
> >   drivers/phy/phy-nxp-ptn3222.c | 119 ++++++++++++++++++++++++++++++++++++++++++
> >   3 files changed, 131 insertions(+)

> > +
> > +	ptn3222->supplies[0].supply = "vdd3v3";
> > +	ptn3222->supplies[0].init_load_uA = 11000;
> > +	ptn3222->supplies[1].supply = "vdd1v8";
> > +	ptn3222->supplies[1].init_load_uA = 55000;
> > +
> > +	ret = devm_regulator_bulk_get(dev,
> > +				      NUM_SUPPLIES,
> > +				      ptn3222->supplies);
> 
> Suggestion only, you could switch to devm_regulator_bulk_get_const()

Good idea, I'll take a look.

> 
> > +	if (ret)
> > +		return ret;
> > +

-- 
With best wishes
Dmitry


From konradybcio at kernel.org  Thu Aug 29 04:06:41 2024
From: konradybcio at kernel.org (Konrad Dybcio)
Date: Thu, 29 Aug 2024 13:06:41 +0200
Subject: [PATCH 2/2] phy: add NXP PTN3222 eUSB2 to USB2 redriver
In-Reply-To: <20240829-nxp-ptn3222-v1-2-46906bc4747a@linaro.org>
References: <20240829-nxp-ptn3222-v1-0-46906bc4747a@linaro.org>
 <20240829-nxp-ptn3222-v1-2-46906bc4747a@linaro.org>
Message-ID: <b2bc241c-ed17-48d2-b665-50f9aac9daaf@kernel.org>

On 29.08.2024 10:21 AM, Dmitry Baryshkov wrote:
> The NXP PTN3222 is the single-port eUSB2 to USB2 redriver that performs
> translation between eUSB2 and USB2 signalling schemes. It supports all
> three data rates: Low Speed, Full Speed and High Speed.
> 
> The reset state enables autonegotiation of the PHY role and of the data
> rate, so no additional programming is required.
> 
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
> ---

Tested-by: Konrad Dybcio <konradybcio at kernel.org>

Konrad



From christian.bruel at foss.st.com  Thu Aug 29 04:06:53 2024
From: christian.bruel at foss.st.com (Christian Bruel)
Date: Thu, 29 Aug 2024 13:06:53 +0200
Subject: [PATCH v4 1/5] dt-bindings: phy: Add STM32MP25 COMBOPHY bindings
In-Reply-To: <20240828-handsfree-overarch-cd1af26cb0c5@spud>
References: <20240828143452.1407532-1-christian.bruel@foss.st.com>
 <20240828143452.1407532-2-christian.bruel@foss.st.com>
 <20240828-handsfree-overarch-cd1af26cb0c5@spud>
Message-ID: <005a2f7d-ab46-46c8-a0cc-b343685caf7c@foss.st.com>

On 8/28/24 18:11, Conor Dooley wrote:
> On Wed, Aug 28, 2024 at 04:34:48PM +0200, Christian Bruel wrote:
>> Document the bindings for STM32 COMBOPHY interface, used to support
>> the PCIe and USB3 stm32mp25 drivers.
>> Following entries can be used to tune caracterisation parameters
>>   - st,output-micro-ohms and st,output-vswing-microvolt bindings entries
>> to tune the impedance and voltage swing using discrete simulation results
>>   - st,rx-equalizer register to set the internal rx equalizer filter value.
>>
>> Signed-off-by: Christian Bruel <christian.bruel at foss.st.com>
>> ---
>>   .../bindings/phy/st,stm32mp25-combophy.yaml   | 128 ++++++++++++++++++
>>   1 file changed, 128 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/phy/st,stm32mp25-combophy.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/phy/st,stm32mp25-combophy.yaml b/Documentation/devicetree/bindings/phy/st,stm32mp25-combophy.yaml
>> new file mode 100644
>> index 000000000000..8d4a40b94507
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/st,stm32mp25-combophy.yaml
>> @@ -0,0 +1,128 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/phy/st,stm32mp25-combophy.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: STMicroelectronics STM32MP25 USB3/PCIe COMBOPHY
>> +
>> +maintainers:
>> +  - Christian Bruel <christian.bruel at foss.st.com>
>> +
>> +description:
>> +  Single lane PHY shared (exclusive) between the USB3 and PCIe controllers.
>> +  Supports 5Gbit/s for USB3 and PCIe gen2 or 2.5Gbit/s for PCIe gen1.
>> +
>> +properties:
>> +  compatible:
>> +    const: st,stm32mp25-combophy
>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  "#phy-cells":
>> +    const: 1
>> +
>> +  clocks:
>> +    minItems: 2
>> +    items:
>> +      - description: apb Bus clock mandatory to access registers.
>> +      - description: ker Internal RCC reference clock for USB3 or PCIe
>> +      - description: pad Optional on board clock input for PCIe only. Typically an
>> +                     external 100Mhz oscillator wired on dedicated CLKIN pad. Used as reference
>> +                     clock input instead of the ker
>> +
>> +  clock-names:
>> +    minItems: 2
>> +    items:
>> +      - const: apb
>> +      - const: ker
>> +      - const: pad
>> +
>> +  resets:
>> +    maxItems: 1
>> +
>> +  reset-names:
>> +    const: phy
>> +
>> +  power-domains:
>> +    maxItems: 1
>> +
>> +  wakeup-source: true
>> +
>> +  interrupts:
>> +    maxItems: 1
>> +    description: interrupt used for wakeup
>> +
>> +  access-controllers:
>> +    minItems: 1
>> +    maxItems: 2
> Can you please describe the items here?

I can specialize the description: "Phandle to the rifsc firewall device to check access right."

otherwise described in access-controllers/access-controllers.yaml, see also bindings/bus/st,stm32mp25-rifsc.yaml

>
>> +  st,syscfg:
>> +    $ref: /schemas/types.yaml#/definitions/phandle
>> +    description: Phandle to the SYSCON entry required for configuring PCIe
>> +      or USB3.
> Why is a phandle required for this lookup, rather than doing it by
> compatible?

the phandle is used to select the sysconf SoC configuration register 
depending on the PCIe/USB3 mode (selected by?xlate function), so it's 
not like a lookup here. This sysconf register is also used for other 
settings such as the PLL, Reference clock selection, ...

>
>> +
>> +  st,ssc-on:
>> +    type: boolean
> flag, not boolean, for presence based stuff. And in the driver,
> s/of_property_read_bool/of_property_present/.

ok

>
>> +    description:
>> +      A boolean property whose presence indicates that the SSC for common clock
>> +      needs to be set.
> And what, may I ask, does "SSC" mean? "Common clock" is also a bit of a
> "linuxism", what does this actually do in the hardware block?

SSC for Spread Spectrum Clocking. It is an hardware setting for the 100Mhz PCIe reference common clock,
I will rephrase the description

>
>> +
>> +  st,rx-equalizer:
>> +    $ref: /schemas/types.yaml#/definitions/uint32
>> +    minimum: 0
>> +    maximum: 7
>> +    default: 2
>> +    description:
>> +      A 3 bit value to tune the RX fixed equalizer setting for optimal eye compliance
>> +
>> +  st,output-micro-ohms:
>> +    minimum: 3999000
>> +    maximum: 6090000
>> +    default: 4968000
>> +    description:
>> +      A value property to tune the Single Ended Output Impedance, simulations results
>> +      at 25C for a VDDP=0.8V. The hardware accepts discrete values in this range.
>> +
>> +  st,output-vswing-microvolt:
>> +    minimum: 442000
>> +    maximum: 803000
>> +    default: 803000
>> +    description:
>> +      A value property in microvolt to tune the Single Ended Output Voltage Swing to change the
>> +      Vlo, Vhi for a VDDP = 0.8V. The hardware accepts discrete values in this range.
>> +
>> +required:
>> +  - "#phy-cells"
>> +  - compatible
>> +  - clocks
>> +  - clock-names
>> +  - reg
>> +  - resets
>> +  - reset-names
>> +  - st,syscfg
> The order here should reflect the ordering in a node, so compatible and
> reg first, rather than sorted alphanumerically.

ok

>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +    #include <dt-bindings/clock/st,stm32mp25-rcc.h>
>> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
>> +    #include <dt-bindings/reset/st,stm32mp25-rcc.h>
>> +
>> +    combophy: phy at 480c0000 {
> You can drop the label here, it ain't used by anything.

ok

thanks,
Christian

>
> Cheers,
> Conor.
>
>> +        compatible = "st,stm32mp25-combophy";
>> +        reg = <0x480c0000 0x1000>;
>> +        #phy-cells = <1>;
>> +        clocks = <&rcc CK_BUS_USB3PCIEPHY>, <&rcc CK_KER_USB3PCIEPHY>;
>> +        clock-names = "apb", "ker";
>> +        resets = <&rcc USB3PCIEPHY_R>;
>> +        reset-names = "phy";
>> +        st,syscfg = <&syscfg>;
>> +        access-controllers = <&rifsc 67>;
>> +        power-domains = <&CLUSTER_PD>;
>> +        wakeup-source;
>> +        interrupts-extended = <&exti1 45 IRQ_TYPE_EDGE_FALLING>;
>> +    };
>> +...
>> -- 
>> 2.34.1
>>


From geert at linux-m68k.org  Thu Aug 29 05:35:01 2024
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Thu, 29 Aug 2024 14:35:01 +0200
Subject: [PATCH 01/16] clk: renesas: r9a08g045: Add clocks, resets and
 power domains for USB
In-Reply-To: <20240822152801.602318-2-claudiu.beznea.uj@bp.renesas.com>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com> <20240822152801.602318-2-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <CAMuHMdUV04PO2Rak9fLxWNFSEoqVp+gAKj36NcHhEKhqqRRL=Q@mail.gmail.com>

On Thu, Aug 22, 2024 at 5:28?PM Claudiu <claudiu.beznea at tuxon.dev> wrote:
> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>
> Add clocks, resets and power domains for USB modules available on the
> Renesas RZ/G3S SoC.
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>

Reviewed-by: Geert Uytterhoeven <geert+renesas at glider.be>
i.e. will queue in renesas-clk for v6.12.

Gr{oetje,eeting}s,

                        Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From ulf.hansson at linaro.org  Thu Aug 29 08:26:04 2024
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Thu, 29 Aug 2024 17:26:04 +0200
Subject: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
In-Reply-To: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <CAPDyKFrS4Dhd7DZa2zz=oPro1TiTJFix0awzzzp8Qatm-8Z2Ug@mail.gmail.com>

On Thu, 22 Aug 2024 at 17:28, Claudiu <claudiu.beznea at tuxon.dev> wrote:
>
> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>
> Hi,
>
> Series adds initial USB support for the Renesas RZ/G3S SoC.
>
> Series is split as follows:
>
> - patch 01/16           - add clock reset and power domain support for USB
> - patch 02-04/16        - add reset control support for a USB signal
>                           that need to be controlled before/after
>                           the power to USB area is turned on/off.
>
>                           Philipp, Ulf, Geert, all,
>
>                           I detailed my approach for this in patch
>                           04/16, please have a look and let me know
>                           your input.

I have looked briefly. Your suggested approach may work, but I have a
few thoughts, see below.

If I understand correctly, it is the consumer driver for the device
that is attached to the USB power domain that becomes responsible for
asserting/de-asserting this new signal. Right?

In this regard, please note that the consumer driver doesn't really
know when the power domain really gets powered-on/off. Calling
pm_runtime_get|put*() is dealing with the reference counting. For
example, a call to pm_runtime_get*() just makes sure that the PM
domain gets-or-remains powered-on. Could this be a problem from the
reset-signal point of view?

[...]

Kind regards
Uffe


From florian.fainelli at broadcom.com  Thu Aug 29 09:04:10 2024
From: florian.fainelli at broadcom.com (Florian Fainelli)
Date: Thu, 29 Aug 2024 09:04:10 -0700
Subject: [PATCH 01/11] phy: broadcom: bcm-cygnus-pcie: Simplify with
 scoped for each OF child loop
In-Reply-To: <20240826-phy-of-node-scope-v1-1-5b4d82582644@linaro.org>
References: <20240826-phy-of-node-scope-v1-0-5b4d82582644@linaro.org>
 <20240826-phy-of-node-scope-v1-1-5b4d82582644@linaro.org>
Message-ID: <c0b22f29-be2f-4681-b963-ff80fbeeb4ff@broadcom.com>

On 8/26/24 03:07, Krzysztof Kozlowski wrote:
> Use scoped for_each_available_child_of_node_scoped() when iterating over
> device nodes to make code a bit simpler.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Reviewed-by: Florian Fainelli <florian.fainelli at broadcom.com>
-- 
Florian



From florian.fainelli at broadcom.com  Thu Aug 29 09:04:27 2024
From: florian.fainelli at broadcom.com (Florian Fainelli)
Date: Thu, 29 Aug 2024 09:04:27 -0700
Subject: [PATCH 02/11] phy: broadcom: brcm-sata: Simplify with scoped for
 each OF child loop
In-Reply-To: <20240826-phy-of-node-scope-v1-2-5b4d82582644@linaro.org>
References: <20240826-phy-of-node-scope-v1-0-5b4d82582644@linaro.org>
 <20240826-phy-of-node-scope-v1-2-5b4d82582644@linaro.org>
Message-ID: <b64f0713-31ab-4ea7-a1a7-3e904f253c86@broadcom.com>

On 8/26/24 03:07, Krzysztof Kozlowski wrote:
> Use scoped for_each_available_child_of_node_scoped() when iterating over
> device nodes to make code a bit simpler.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Reviewed-by: Florian Fainelli <florian.fainelli at broadcom.com>
-- 
Florian



From conor at kernel.org  Thu Aug 29 09:18:17 2024
From: conor at kernel.org (Conor Dooley)
Date: Thu, 29 Aug 2024 17:18:17 +0100
Subject: [PATCH 1/2] dt-bindings: phy: add NXP PTN3222 eUSB2 to USB2
 redriver
In-Reply-To: <20240829-nxp-ptn3222-v1-1-46906bc4747a@linaro.org>
References: <20240829-nxp-ptn3222-v1-0-46906bc4747a@linaro.org>
 <20240829-nxp-ptn3222-v1-1-46906bc4747a@linaro.org>
Message-ID: <20240829-dandy-jingle-1002fb99b900@spud>

On Thu, Aug 29, 2024 at 11:21:13AM +0300, Dmitry Baryshkov wrote:
> The NXP PTN3222 is the single-port eUSB2 to USB2 redriver that performs
> translation between eUSB2 and USB2 signalling schemes. It supports all
> three data rates: Low Speed, Full Speed and High Speed.
> 
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
> ---
>  .../devicetree/bindings/phy/nxp,ptn3222.yaml       | 55 ++++++++++++++++++++++
>  1 file changed, 55 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/phy/nxp,ptn3222.yaml b/Documentation/devicetree/bindings/phy/nxp,ptn3222.yaml
> new file mode 100644
> index 000000000000..acec5bb2391d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/nxp,ptn3222.yaml
> @@ -0,0 +1,55 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/nxp,ptn3222.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NXP PTN3222 1-port eUSB2 to USB2 redriver
> +
> +maintainers:
> +  - Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
> +
> +properties:
> +  compatible:
> +    enum:
> +      - nxp,ptn3222
> +
> +  reg:
> +    maxItems: 1
> +
> +  "#phy-cells":
> +    const: 0
> +
> +  vdd1v8-supply:
> +    description: power supply (1.8V)

As a nit, these descriptions could just be ": true" like the
reset-gpios, they're equally obvious.

Reviewed-by: Conor Dooley <conor.dooley at microchip.com>

Cheers,
Conor.

> +
> +  vdd3v3-supply:
> +    description: power supply (3.3V)
> +
> +  reset-gpios: true
> +
> +required:
> +  - compatible
> +  - reg
> +  - '#phy-cells'
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/gpio/gpio.h>
> +
> +    i2c {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        redriver at 4f {
> +            compatible = "nxp,ptn3222";
> +            reg = <0x4f>;
> +            #phy-cells = <0>;
> +            vdd3v3-supply = <&vreg_3p3>;
> +            vdd1v8-supply = <&vreg_1p8>;
> +            reset-gpios = <&gpio_reset GPIO_ACTIVE_LOW>;
> +        };
> +    };
> +...
> 
> -- 
> 2.39.2
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-phy/attachments/20240829/a51265c1/attachment.sig>

From conor at kernel.org  Thu Aug 29 09:44:50 2024
From: conor at kernel.org (Conor Dooley)
Date: Thu, 29 Aug 2024 17:44:50 +0100
Subject: [PATCH v4 1/5] dt-bindings: phy: Add STM32MP25 COMBOPHY bindings
In-Reply-To: <005a2f7d-ab46-46c8-a0cc-b343685caf7c@foss.st.com>
References: <20240828143452.1407532-1-christian.bruel@foss.st.com>
 <20240828143452.1407532-2-christian.bruel@foss.st.com>
 <20240828-handsfree-overarch-cd1af26cb0c5@spud>
 <005a2f7d-ab46-46c8-a0cc-b343685caf7c@foss.st.com>
Message-ID: <20240829-manifesto-tray-65443d6e7e6e@spud>

On Thu, Aug 29, 2024 at 01:06:53PM +0200, Christian Bruel wrote:
> On 8/28/24 18:11, Conor Dooley wrote:
> > On Wed, Aug 28, 2024 at 04:34:48PM +0200, Christian Bruel wrote:
> > > Document the bindings for STM32 COMBOPHY interface, used to support
> > > the PCIe and USB3 stm32mp25 drivers.
> > > Following entries can be used to tune caracterisation parameters
> > >   - st,output-micro-ohms and st,output-vswing-microvolt bindings entries
> > > to tune the impedance and voltage swing using discrete simulation results
> > >   - st,rx-equalizer register to set the internal rx equalizer filter value.
> > > 
> > > Signed-off-by: Christian Bruel <christian.bruel at foss.st.com>
> > > ---
> > >   .../bindings/phy/st,stm32mp25-combophy.yaml   | 128 ++++++++++++++++++
> > >   1 file changed, 128 insertions(+)
> > >   create mode 100644 Documentation/devicetree/bindings/phy/st,stm32mp25-combophy.yaml
> > > 
> > > diff --git a/Documentation/devicetree/bindings/phy/st,stm32mp25-combophy.yaml b/Documentation/devicetree/bindings/phy/st,stm32mp25-combophy.yaml
> > > new file mode 100644
> > > index 000000000000..8d4a40b94507
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/phy/st,stm32mp25-combophy.yaml
> > > @@ -0,0 +1,128 @@
> > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/phy/st,stm32mp25-combophy.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: STMicroelectronics STM32MP25 USB3/PCIe COMBOPHY
> > > +
> > > +maintainers:
> > > +  - Christian Bruel <christian.bruel at foss.st.com>
> > > +
> > > +description:
> > > +  Single lane PHY shared (exclusive) between the USB3 and PCIe controllers.
> > > +  Supports 5Gbit/s for USB3 and PCIe gen2 or 2.5Gbit/s for PCIe gen1.
> > > +
> > > +properties:
> > > +  compatible:
> > > +    const: st,stm32mp25-combophy
> > > +
> > > +  reg:
> > > +    maxItems: 1
> > > +
> > > +  "#phy-cells":
> > > +    const: 1
> > > +
> > > +  clocks:
> > > +    minItems: 2
> > > +    items:
> > > +      - description: apb Bus clock mandatory to access registers.
> > > +      - description: ker Internal RCC reference clock for USB3 or PCIe
> > > +      - description: pad Optional on board clock input for PCIe only. Typically an
> > > +                     external 100Mhz oscillator wired on dedicated CLKIN pad. Used as reference
> > > +                     clock input instead of the ker
> > > +
> > > +  clock-names:
> > > +    minItems: 2
> > > +    items:
> > > +      - const: apb
> > > +      - const: ker
> > > +      - const: pad
> > > +
> > > +  resets:
> > > +    maxItems: 1
> > > +
> > > +  reset-names:
> > > +    const: phy
> > > +
> > > +  power-domains:
> > > +    maxItems: 1
> > > +
> > > +  wakeup-source: true
> > > +
> > > +  interrupts:
> > > +    maxItems: 1
> > > +    description: interrupt used for wakeup
> > > +
> > > +  access-controllers:
> > > +    minItems: 1
> > > +    maxItems: 2
> > Can you please describe the items here?
> 
> I can specialize the description: "Phandle to the rifsc firewall device to check access right."

Right, but there are potentially two access controllers here. You need
to describe which is which, so that people can hook them up in the
correct order. In what case are there two? Your dts patch only has one.

> otherwise described in access-controllers/access-controllers.yaml, see also bindings/bus/st,stm32mp25-rifsc.yaml
> 
> > 
> > > +  st,syscfg:
> > > +    $ref: /schemas/types.yaml#/definitions/phandle
> > > +    description: Phandle to the SYSCON entry required for configuring PCIe
> > > +      or USB3.
> > Why is a phandle required for this lookup, rather than doing it by
> > compatible?
> 
> the phandle is used to select the sysconf SoC configuration register
> depending on the PCIe/USB3 mode (selected by?xlate function), so it's not
> like a lookup here.

If "syscon_regmap_lookup_by_phandle()" is not a lookup, then I do not
know what is. An example justification for it would be that there are
multiple combophys on the same soc, each using a different sysconf
region. Your dts suggests that is not the case though, since you have
st,syscfg = <&syscfg>; in it, rather than st,syscfg = <&syscfg0>;.

> This sysconf register is also used for other settings
> such as the PLL, Reference clock selection, ...
> 
> > 
> > > +
> > > +  st,ssc-on:
> > > +    type: boolean
> > flag, not boolean, for presence based stuff. And in the driver,
> > s/of_property_read_bool/of_property_present/.
> 
> ok
> 
> > 
> > > +    description:
> > > +      A boolean property whose presence indicates that the SSC for common clock
> > > +      needs to be set.
> > And what, may I ask, does "SSC" mean? "Common clock" is also a bit of a
> > "linuxism", what does this actually do in the hardware block?
> 
> SSC for Spread Spectrum Clocking. It is an hardware setting for the 100Mhz PCIe reference common clock,

Ah, so not really a "common clock" linuxism at all.

> I will rephrase the description

How is someone supposed to decide between on and off? Is it always on
for PCIe, or only on in some configurations? Or maybe only (or always?) on
if the pad clock is provided?

Cheers,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-phy/attachments/20240829/4c9eafb9/attachment-0001.sig>

From vkoul at kernel.org  Thu Aug 29 10:39:59 2024
From: vkoul at kernel.org (Vinod Koul)
Date: Thu, 29 Aug 2024 23:09:59 +0530
Subject: [PATCH v4 2/5] phy: stm32: Add support for STM32MP25 COMBOPHY.
In-Reply-To: <20240828143452.1407532-3-christian.bruel@foss.st.com>
References: <20240828143452.1407532-1-christian.bruel@foss.st.com>
 <20240828143452.1407532-3-christian.bruel@foss.st.com>
Message-ID: <ZtCyb7AzLmuUoBGT@vaman>

On 28-08-24, 16:34, Christian Bruel wrote:
> Addition of the COMBOPHY driver found on STM32MP25 platforms
> 
> This single lane PHY is shared (exclusive) between the USB3 and PCIE
> controllers.
> Supports 5Gbit/s for PCIE gen2 or 2.5Gbit/s for PCIE gen1.
> 
> Supports wakeup-source capability to wakeup system using remote-wakeup
> capable USB device
> 
> Signed-off-by: Christian Bruel <christian.bruel at foss.st.com>
> ---
>  drivers/phy/st/Kconfig              |  11 +
>  drivers/phy/st/Makefile             |   1 +
>  drivers/phy/st/phy-stm32-combophy.c | 607 ++++++++++++++++++++++++++++
>  3 files changed, 619 insertions(+)
>  create mode 100644 drivers/phy/st/phy-stm32-combophy.c
> 
> diff --git a/drivers/phy/st/Kconfig b/drivers/phy/st/Kconfig
> index 3fc3d0781fb8..304614b6dabf 100644
> --- a/drivers/phy/st/Kconfig
> +++ b/drivers/phy/st/Kconfig
> @@ -33,6 +33,17 @@ config PHY_STIH407_USB
>  	  Enable this support to enable the picoPHY device used by USB2
>  	  and USB3 controllers on STMicroelectronics STiH407 SoC families.
>  
> +config PHY_STM32_COMBOPHY
> +	tristate "STMicroelectronics COMBOPHY driver for STM32MP25"
> +	depends on ARCH_STM32 || COMPILE_TEST
> +	select GENERIC_PHY
> +	help
> +	  Enable this to support the COMBOPHY device used by USB3 or PCIe
> +	  controllers on STMicroelectronics STM32MP25 SoC.
> +	  This driver controls the COMBOPHY block to generate the PCIe 100Mhz
> +	  reference clock from either the external clock generator or HSE
> +	  internal SoC clock source.
> +
>  config PHY_STM32_USBPHYC
>  	tristate "STMicroelectronics STM32 USB HS PHY Controller driver"
>  	depends on ARCH_STM32 || COMPILE_TEST
> diff --git a/drivers/phy/st/Makefile b/drivers/phy/st/Makefile
> index c862dd937b64..cb80e954ea9f 100644
> --- a/drivers/phy/st/Makefile
> +++ b/drivers/phy/st/Makefile
> @@ -3,4 +3,5 @@ obj-$(CONFIG_PHY_MIPHY28LP) 		+= phy-miphy28lp.o
>  obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)	+= phy-spear1310-miphy.o
>  obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)	+= phy-spear1340-miphy.o
>  obj-$(CONFIG_PHY_STIH407_USB)		+= phy-stih407-usb.o
> +obj-$(CONFIG_PHY_STM32_COMBOPHY)	+= phy-stm32-combophy.o
>  obj-$(CONFIG_PHY_STM32_USBPHYC) 	+= phy-stm32-usbphyc.o
> diff --git a/drivers/phy/st/phy-stm32-combophy.c b/drivers/phy/st/phy-stm32-combophy.c
> new file mode 100644
> index 000000000000..7cd4193b0277
> --- /dev/null
> +++ b/drivers/phy/st/phy-stm32-combophy.c
> @@ -0,0 +1,607 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * STMicroelectronics COMBOPHY STM32MP25 Controller driver.
> + *
> + * Copyright (C) 2024 STMicroelectronics
> + * Author: Christian Bruel <christian.bruel at foss.st.com>
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/platform_device.h>
> +#include <linux/phy/phy.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/regmap.h>
> +#include <linux/reset.h>
> +#include <dt-bindings/phy/phy.h>
> +
> +#define SYSCFG_COMBOPHY_CR1 0x4C00
> +#define SYSCFG_COMBOPHY_CR2 0x4C04
> +#define SYSCFG_COMBOPHY_CR4 0x4C0C
> +#define SYSCFG_COMBOPHY_CR5 0x4C10
> +#define SYSCFG_COMBOPHY_SR  0x4C14

Lowercase hex values please

> +#define SYSCFG_PCIEPRGCR    0x6080
> +
> +/* SYSCFG PCIEPRGCR */
> +#define STM32MP25_PCIEPRGCR_EN	  BIT(0)
> +#define STM32MP25_PCIEPRG_IMPCTRL_OHM     GENMASK(3, 1)
> +#define STM32MP25_PCIEPRG_IMPCTRL_VSWING  GENMASK(5, 4)
> +
> +/* SYSCFG SYSCFG_COMBOPHY_SR */
> +#define STM32MP25_PIPE0_PHYSTATUS BIT(1)
> +
> +/* SYSCFG CR1 */
> +#define SYSCFG_COMBOPHY_CR1_REFUSEPAD BIT(0)
> +#define SYSCFG_COMBOPHY_CR1_MPLLMULT GENMASK(7, 1)
> +#define SYSCFG_COMBOPHY_CR1_REFCLKSEL GENMASK(16, 8)
> +#define SYSCFG_COMBOPHY_CR1_REFCLKDIV2 BIT(17)
> +#define SYSCFG_COMBOPHY_CR1_REFSSPEN BIT(18)
> +#define SYSCFG_COMBOPHY_CR1_SSCEN BIT(19)
> +
> +/* SYSCFG CR4 */
> +#define SYSCFG_COMBOPHY_CR4_RX0_EQ GENMASK(2, 0)
> +
> +#define MPLLMULT_19_2 (0x02u << 1)
> +#define MPLLMULT_20   (0x7Du << 1)
> +#define MPLLMULT_24   (0x68u << 1)
> +#define MPLLMULT_25   (0x64u << 1)
> +#define MPLLMULT_26   (0x60u << 1)
> +#define MPLLMULT_38_4 (0x41u << 1)
> +#define MPLLMULT_48   (0x6Cu << 1)
> +#define MPLLMULT_50   (0x32u << 1)
> +#define MPLLMULT_52   (0x30u << 1)
> +#define MPLLMULT_100  (0x19u << 1)
> +
> +#define REFCLKSEL_0   0
> +#define REFCLKSEL_1   (0x108u << 8)
> +
> +#define REFCLDIV_0    0
> +
> +/* SYSCFG CR2 */
> +#define SYSCFG_COMBOPHY_CR2_MODESEL GENMASK(1, 0)
> +#define SYSCFG_COMBOPHY_CR2_ISO_DIS BIT(15)
> +
> +#define COMBOPHY_MODESEL_PCIE 0
> +#define COMBOPHY_MODESEL_USB  3
> +
> +/* SYSCFG CR5 */
> +#define SYSCFG_COMBOPHY_CR5_COMMON_CLOCKS BIT(12)
> +
> +#define COMBOPHY_SUP_ANA_MPLL_LOOP_CTL 0xC0
> +#define COMBOPHY_PROP_CNTRL GENMASK(7, 4)
> +
> +struct stm32_combophy {
> +	struct phy *phy;
> +	struct regmap *regmap;
> +	struct device *dev;
> +	void __iomem *base;
> +	struct reset_control *phy_reset;
> +	struct clk *phy_clk;
> +	struct clk *pad_clk;
> +	struct clk *ker_clk;
> +	unsigned int type;
> +	bool is_init;
> +	int irq_wakeup;
> +};
> +
> +struct clk_impedance  {
> +	u32 microohm;
> +	u32 vswing[4];
> +};
> +
> +/*
> + * lookup table to hold the settings needed for a ref clock frequency
> + * impedance, the offset is used to set the IMP_CTL and DE_EMP bit of the
> + * PRG_IMP_CTRL register
> + */
> +static const struct clk_impedance imp_lookup[] = {
> +	{ 6090000, { 442000, 564000, 684000, 802000 } },
> +	{ 5662000, { 528000, 621000, 712000, 803000 } },
> +	{ 5292000, { 491000, 596000, 700000, 802000 } },
> +	{ 4968000, { 558000, 640000, 722000, 803000 } },
> +	{ 4684000, { 468000, 581000, 692000, 802000 } },
> +	{ 4429000, { 554000, 613000, 717000, 803000 } },
> +	{ 4204000, { 511000, 609000, 706000, 802000 } },
> +	{ 3999000, { 571000, 648000, 726000, 803000 } }
> +};
> +
> +static int stm32_impedance_tune(struct stm32_combophy *combophy)
> +{
> +	u8 imp_size = ARRAY_SIZE(imp_lookup);
> +	u8 vswing_size = ARRAY_SIZE(imp_lookup[0].vswing);
> +	u8 imp_of, vswing_of;
> +	u32 max_imp = imp_lookup[0].microohm;
> +	u32 min_imp = imp_lookup[imp_size - 1].microohm;

table is ordered, pls mention that in comments somewhere

> +	u32 max_vswing = imp_lookup[imp_size - 1].vswing[vswing_size - 1];
> +	u32 min_vswing = imp_lookup[0].vswing[0];
> +	u32 val;
> +
> +	if (!of_property_read_u32(combophy->dev->of_node, "st,output-micro-ohms", &val)) {
> +		if (val < min_imp || val > max_imp) {
> +			dev_err(combophy->dev, "Invalid value %u for output ohm\n", val);
> +			return -EINVAL;
> +		}
> +
> +		for (imp_of = 0 ; imp_of < ARRAY_SIZE(imp_lookup); imp_of++)
> +			if (imp_lookup[imp_of].microohm <= val)
> +				break;
> +
> +		dev_dbg(combophy->dev, "Set %u micro-ohms output impedance\n",
> +			imp_lookup[imp_of].microohm);
> +
> +		regmap_update_bits(combophy->regmap, SYSCFG_PCIEPRGCR,
> +				   STM32MP25_PCIEPRG_IMPCTRL_OHM,
> +				   FIELD_PREP(STM32MP25_PCIEPRG_IMPCTRL_OHM, imp_of));
> +	} else {
> +		regmap_read(combophy->regmap, SYSCFG_PCIEPRGCR, &val);
> +		imp_of = FIELD_GET(STM32MP25_PCIEPRG_IMPCTRL_OHM, val);
> +	}
> +
> +	if (!of_property_read_u32(combophy->dev->of_node, "st,output-vswing-microvolt", &val)) {
> +		if (val < min_vswing || val > max_vswing) {
> +			dev_err(combophy->dev, "Invalid value %u for output vswing\n", val);
> +			return -EINVAL;
> +		}
> +
> +		for (vswing_of = 0 ; vswing_of < ARRAY_SIZE(imp_lookup[imp_of].vswing); vswing_of++)
> +			if (imp_lookup[imp_of].vswing[vswing_of] >= val)
> +				break;
> +
> +		dev_dbg(combophy->dev, "Set %u microvolt swing\n",
> +			 imp_lookup[imp_of].vswing[vswing_of]);
> +
> +		regmap_update_bits(combophy->regmap, SYSCFG_PCIEPRGCR,
> +				   STM32MP25_PCIEPRG_IMPCTRL_VSWING,
> +				   FIELD_PREP(STM32MP25_PCIEPRG_IMPCTRL_VSWING, vswing_of));
> +	}
> +
> +	return 0;
> +}
> +
> +static int stm32_combophy_pll_init(struct stm32_combophy *combophy)
> +{
> +	int ret;
> +	u32 refclksel, pllmult, propcntrl, val;
> +	u32 clk_rate;
> +
> +	if (combophy->pad_clk)
> +		clk_rate = clk_get_rate(combophy->pad_clk);
> +	else
> +		clk_rate = clk_get_rate(combophy->ker_clk);
> +
> +	reset_control_assert(combophy->phy_reset);
> +
> +	dev_dbg(combophy->dev, "%s pll init rate %d\n",
> +		combophy->pad_clk ? "External" : "Ker", clk_rate);
> +
> +	/*
> +	 * vddcombophy is interconnected with vddcore. Isolation bit should be unset
> +	 * before using the ComboPHY.
> +	 */
> +	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR2,
> +			   SYSCFG_COMBOPHY_CR2_ISO_DIS, SYSCFG_COMBOPHY_CR2_ISO_DIS);
> +
> +	if (combophy->type != PHY_TYPE_PCIE)
> +		regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
> +				   SYSCFG_COMBOPHY_CR1_REFSSPEN, SYSCFG_COMBOPHY_CR1_REFSSPEN);
> +
> +	if (combophy->type == PHY_TYPE_PCIE && !combophy->pad_clk)
> +		regmap_update_bits(combophy->regmap, SYSCFG_PCIEPRGCR,
> +				   STM32MP25_PCIEPRGCR_EN, STM32MP25_PCIEPRGCR_EN);
> +
> +	if (of_property_read_bool(combophy->dev->of_node, "st,ssc-on")) {
> +		dev_dbg(combophy->dev, "Enabling clock with SSC\n");
> +		regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
> +				   SYSCFG_COMBOPHY_CR1_SSCEN, SYSCFG_COMBOPHY_CR1_SSCEN);
> +	}
> +
> +	if (!of_property_read_u32(combophy->dev->of_node, "st,rx-equalizer", &val)) {
> +		dev_dbg(combophy->dev, "Set RX equalizer %u\n", val);
> +		if (val > SYSCFG_COMBOPHY_CR4_RX0_EQ) {
> +			dev_err(combophy->dev, "Invalid value %u for rx0 equalizer\n", val);
> +			return -EINVAL;
> +		}
> +
> +		regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR4,
> +			   SYSCFG_COMBOPHY_CR4_RX0_EQ, val);
> +	}
> +
> +	if (combophy->type == PHY_TYPE_PCIE) {
> +		ret = stm32_impedance_tune(combophy);
> +		if (ret) {
> +			reset_control_deassert(combophy->phy_reset);
> +			goto out;
> +		}
> +
> +		regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
> +				   SYSCFG_COMBOPHY_CR1_REFUSEPAD,
> +				   combophy->pad_clk ? SYSCFG_COMBOPHY_CR1_REFUSEPAD : 0);
> +	}
> +
> +	switch (clk_rate) {
> +	case 100000000:
> +		pllmult = MPLLMULT_100;
> +		refclksel = REFCLKSEL_0;
> +		propcntrl = 0x8u << 4;
> +		break;
> +	case 19200000:
> +		pllmult = MPLLMULT_19_2;
> +		refclksel = REFCLKSEL_1;
> +		propcntrl = 0x8u << 4;
> +		break;
> +	case 25000000:
> +		pllmult = MPLLMULT_25;
> +		refclksel = REFCLKSEL_0;
> +		propcntrl = 0xEu << 4;
> +		break;
> +	case 24000000:
> +		pllmult = MPLLMULT_24;
> +		refclksel = REFCLKSEL_1;
> +		propcntrl = 0xEu << 4;
> +		break;
> +	case 20000000:
> +		pllmult = MPLLMULT_20;
> +		refclksel = REFCLKSEL_0;
> +		propcntrl = 0xEu << 4;
> +		break;
> +	default:
> +		dev_err(combophy->dev, "Invalid rate 0x%x\n", clk_rate);
> +		reset_control_deassert(combophy->phy_reset);
> +		ret = -EINVAL;
> +		goto out;
> +	};
> +
> +	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
> +			   SYSCFG_COMBOPHY_CR1_REFCLKDIV2, REFCLDIV_0);
> +	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
> +			   SYSCFG_COMBOPHY_CR1_REFCLKSEL, refclksel);
> +	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
> +			   SYSCFG_COMBOPHY_CR1_MPLLMULT, pllmult);
> +
> +	/*
> +	 * Force elasticity buffer to be tuned for the reference clock as
> +	 * the separated clock model is not supported
> +	 */
> +	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR5,
> +			   SYSCFG_COMBOPHY_CR5_COMMON_CLOCKS, SYSCFG_COMBOPHY_CR5_COMMON_CLOCKS);
> +
> +	reset_control_deassert(combophy->phy_reset);
> +
> +	ret = regmap_read_poll_timeout(combophy->regmap, SYSCFG_COMBOPHY_SR, val,
> +				       !(val & STM32MP25_PIPE0_PHYSTATUS),
> +				       10, 1000);
> +	if (ret) {
> +		dev_err(combophy->dev, "timeout, cannot lock PLL\n");
> +		goto out;
> +	}
> +
> +	if (combophy->type == PHY_TYPE_PCIE) {
> +		val = readl_relaxed(combophy->base + COMBOPHY_SUP_ANA_MPLL_LOOP_CTL);
> +		val &= ~COMBOPHY_PROP_CNTRL;
> +		val |= propcntrl;
> +		writel_relaxed(val, combophy->base + COMBOPHY_SUP_ANA_MPLL_LOOP_CTL);
> +	}
> +
> +	return 0;
> +
> +out:
> +	if (combophy->type == PHY_TYPE_PCIE && !combophy->pad_clk)
> +		regmap_update_bits(combophy->regmap, SYSCFG_PCIEPRGCR,
> +				   STM32MP25_PCIEPRGCR_EN, 0);
> +
> +	if (combophy->type != PHY_TYPE_PCIE)
> +		regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR1,
> +				   SYSCFG_COMBOPHY_CR1_REFSSPEN, 0);
> +
> +	regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR2,
> +			   SYSCFG_COMBOPHY_CR2_ISO_DIS, 0);
> +
> +	return ret;
> +}
> +
> +static struct phy *stm32_combophy_xlate(struct device *dev,
> +					const struct of_phandle_args *args)
> +{
> +	struct stm32_combophy *combophy = dev_get_drvdata(dev);
> +	unsigned int type;
> +
> +	if (args->args_count != 1) {
> +		dev_err(dev, "invalid number of cells in 'phy' property\n");
> +		return ERR_PTR(-EINVAL);
> +	}
> +
> +	type = args->args[0];
> +	if (type != PHY_TYPE_USB3 && type != PHY_TYPE_PCIE) {
> +		dev_err(dev, "unsupported device type: %d\n", type);
> +		return ERR_PTR(-EINVAL);
> +	}
> +
> +	if (combophy->pad_clk && type != PHY_TYPE_PCIE) {
> +		dev_err(dev, "Invalid use of clk_pad for USB3 mode\n");
> +		return ERR_PTR(-EINVAL);
> +	}
> +
> +	combophy->type = type;
> +
> +	return combophy->phy;
> +}
> +
> +static int stm32_combophy_set_mode(struct stm32_combophy *combophy)
> +{
> +	int type = combophy->type;
> +	u32 val;
> +
> +	switch (type) {
> +	case PHY_TYPE_PCIE:
> +		dev_dbg(combophy->dev, "setting PCIe ComboPHY\n");
> +		val = COMBOPHY_MODESEL_PCIE;
> +		break;
> +	case PHY_TYPE_USB3:
> +		dev_dbg(combophy->dev, "setting USB3 ComboPHY\n");
> +		val = COMBOPHY_MODESEL_USB;
> +		break;
> +	default:
> +		dev_err(combophy->dev, "Invalid PHY mode %d\n", type);
> +		return -EINVAL;
> +	}
> +
> +	return regmap_update_bits(combophy->regmap, SYSCFG_COMBOPHY_CR2,
> +				  SYSCFG_COMBOPHY_CR2_MODESEL, val);
> +}
> +
> +static int stm32_combophy_enable_clocks(struct stm32_combophy *combophy)
> +{
> +	int ret;
> +
> +	ret = clk_prepare_enable(combophy->phy_clk);
> +	if (ret) {
> +		dev_err(combophy->dev, "Core clock enable failed %d\n", ret);
> +		return ret;
> +	}
> +
> +	ret = clk_prepare_enable(combophy->ker_clk);
> +	if (ret) {
> +		dev_err(combophy->dev, "ker_usb3pcie clock enable failed %d\n", ret);
> +		clk_disable_unprepare(combophy->phy_clk);
> +		return ret;
> +	}
> +
> +	if (combophy->pad_clk) {
> +		ret = clk_prepare_enable(combophy->pad_clk);
> +		if (ret) {
> +			dev_err(combophy->dev, "External clock enable failed %d\n", ret);
> +			clk_disable_unprepare(combophy->ker_clk);
> +			clk_disable_unprepare(combophy->phy_clk);
> +			return ret;
> +		}
> +	}

Can you use bulk_prepare for this?

-- 
~Vinod


From vkoul at kernel.org  Thu Aug 29 10:49:03 2024
From: vkoul at kernel.org (Vinod Koul)
Date: Thu, 29 Aug 2024 23:19:03 +0530
Subject: [PATCH 2/4] phy: qualcomm: phy-qcom-apq8064-sata: Convert to
 devm_clk_get_enabled()
In-Reply-To: <20240822084400.1595426-1-frank.li@vivo.com>
References: <20240822084400.1595426-1-frank.li@vivo.com>
Message-ID: <ZtC0j1kaHKHA3v/P@vaman>

On 22-08-24, 02:44, Yangtao Li wrote:
> Convert devm_clk_get(), clk_prepare_enable() to a single
> call to devm_clk_get_enabled(), as this is exactly
> what this function does.

Can you please resend this as a single thread. Threading is broken in
this series, I see 2, 3 patches, no idea where 1, 4 are...

> 
> Signed-off-by: Yangtao Li <frank.li at vivo.com>
> ---
>  drivers/phy/qualcomm/phy-qcom-apq8064-sata.c | 22 ++++----------------
>  1 file changed, 4 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/phy/qualcomm/phy-qcom-apq8064-sata.c b/drivers/phy/qualcomm/phy-qcom-apq8064-sata.c
> index 3642a5d4f2f3..18c0dbd8e707 100644
> --- a/drivers/phy/qualcomm/phy-qcom-apq8064-sata.c
> +++ b/drivers/phy/qualcomm/phy-qcom-apq8064-sata.c
> @@ -68,7 +68,6 @@
>  
>  struct qcom_apq8064_sata_phy {
>  	void __iomem *mmio;
> -	struct clk *cfg_clk;
>  	struct device *dev;
>  };
>  
> @@ -203,7 +202,7 @@ static int qcom_apq8064_sata_phy_probe(struct platform_device *pdev)
>  	struct device *dev = &pdev->dev;
>  	struct phy_provider *phy_provider;
>  	struct phy *generic_phy;
> -	int ret;
> +	struct clk *cfg_clk;
>  
>  	phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
>  	if (!phy)
> @@ -223,19 +222,14 @@ static int qcom_apq8064_sata_phy_probe(struct platform_device *pdev)
>  	phy_set_drvdata(generic_phy, phy);
>  	platform_set_drvdata(pdev, phy);
>  
> -	phy->cfg_clk = devm_clk_get(dev, "cfg");
> -	if (IS_ERR(phy->cfg_clk)) {
> +	cfg_clk = devm_clk_get_enabled(dev, "cfg");
> +	if (IS_ERR(cfg_clk)) {
>  		dev_err(dev, "Failed to get sata cfg clock\n");
> -		return PTR_ERR(phy->cfg_clk);
> +		return PTR_ERR(cfg_clk);
>  	}
>  
> -	ret = clk_prepare_enable(phy->cfg_clk);
> -	if (ret)
> -		return ret;
> -
>  	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
>  	if (IS_ERR(phy_provider)) {
> -		clk_disable_unprepare(phy->cfg_clk);
>  		dev_err(dev, "%s: failed to register phy\n", __func__);
>  		return PTR_ERR(phy_provider);
>  	}
> @@ -243,13 +237,6 @@ static int qcom_apq8064_sata_phy_probe(struct platform_device *pdev)
>  	return 0;
>  }
>  
> -static void qcom_apq8064_sata_phy_remove(struct platform_device *pdev)
> -{
> -	struct qcom_apq8064_sata_phy *phy = platform_get_drvdata(pdev);
> -
> -	clk_disable_unprepare(phy->cfg_clk);
> -}
> -
>  static const struct of_device_id qcom_apq8064_sata_phy_of_match[] = {
>  	{ .compatible = "qcom,apq8064-sata-phy" },
>  	{ },
> @@ -258,7 +245,6 @@ MODULE_DEVICE_TABLE(of, qcom_apq8064_sata_phy_of_match);
>  
>  static struct platform_driver qcom_apq8064_sata_phy_driver = {
>  	.probe	= qcom_apq8064_sata_phy_probe,
> -	.remove_new = qcom_apq8064_sata_phy_remove,
>  	.driver = {
>  		.name	= "qcom-apq8064-sata-phy",
>  		.of_match_table	= qcom_apq8064_sata_phy_of_match,
> -- 
> 2.39.0

-- 
~Vinod


From vkoul at kernel.org  Thu Aug 29 10:55:58 2024
From: vkoul at kernel.org (Vinod Koul)
Date: Thu, 29 Aug 2024 23:25:58 +0530
Subject: [RFC V2 2/2] phy: freescale: fsl-samsung-hdmi: Support dynamic
 integer divider
In-Reply-To: <20240829021256.787615-2-aford173@gmail.com>
References: <20240829021256.787615-1-aford173@gmail.com>
 <20240829021256.787615-2-aford173@gmail.com>
Message-ID: <ZtC2LhYAAdPdSRpz@vaman>

On 28-08-24, 21:12, Adam Ford wrote:
> There is currently a look-up table for a variety of resolutions.
> Since the phy has the ability to dynamically calculate the values
> necessary to use the intger divider which should allow more
> resolutions without having to update the look-up-table.  If the
> integer calculator cannot get an exact frequency, it falls back
> to the look-up-table.  Because the LUT algorithm does some
> rounding, I did not remove integer entries from the LUT.

Any reason why this is RFC?

> 
> Signed-off-by: Adam Ford <aford173 at gmail.com>
> 
> diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> index bc5d3625ece6..76e0899c6006 100644
> --- a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> +++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> @@ -16,6 +16,8 @@
>  
>  #define PHY_REG(reg)		(reg * 4)
>  
> +#define REG01_PMS_P_MASK	GENMASK(3, 0)
> +#define REG03_PMS_S_MASK	GENMASK(7, 4)
>  #define REG12_CK_DIV_MASK	GENMASK(5, 4)
>  #define REG13_TG_CODE_LOW_MASK	GENMASK(7, 0)
>  #define REG14_TOL_MASK		GENMASK(7, 4)
> @@ -31,11 +33,17 @@
>  
>  #define PHY_PLL_DIV_REGS_NUM 6
>  
> +#ifndef MHZ
> +#define MHZ	(1000UL * 1000UL)
> +#endif
> +
>  struct phy_config {
>  	u32	pixclk;
>  	u8	pll_div_regs[PHY_PLL_DIV_REGS_NUM];
>  };
>  
> +static struct phy_config custom_phy_pll_cfg;
> +
>  static const struct phy_config phy_pll_cfg[] = {
>  	{
>  		.pixclk = 22250000,
> @@ -440,10 +448,83 @@ fsl_samsung_hdmi_phy_configure_pll_lock_det(struct fsl_samsung_hdmi_phy *phy,
>  	       phy->regs + PHY_REG(14));
>  }
>  
> +static unsigned long fsl_samsung_hdmi_phy_find_pms(unsigned long fout, u8 *p, u16 *m, u8 *s)
> +{
> +	unsigned long best_freq = 0;
> +	u32 min_delta = 0xffffffff;

> +	u8 _p, best_p;
> +	u16 _m, best_m;
> +	u8 _s, best_s;
> +
> +	for (_p = 1; _p <= 11; ++_p) {

starts with 1 to 11.. why?

> +		for (_s = 1; _s <= 16; ++_s) {
> +			u64 tmp;
> +			u32 delta;
> +
> +			/* s must be even */
> +			if (_s > 1 && (_s & 0x01) == 1)
> +				_s++;
> +
> +			/* _s cannot be 14 per the TRM */
> +			if (_s == 14)
> +				continue;
> +
> +			/*
> +			 * TODO: Ref Manual doesn't state the range of _m
> +			 * so this should be further refined if possible.
> +			 * This range was set based on the original values
> +			 * in the look-up table
> +			 */
> +			tmp = (u64)fout * (_p * _s);
> +			do_div(tmp, 24 * MHZ);
> +			_m = tmp;
> +			if (_m < 0x30 || _m > 0x7b)
> +				continue;
> +
> +			/*
> +			 * Rev 2 of the Ref Manual states the
> +			 * VCO can range between 750MHz and
> +			 * 3GHz.  The VCO is assumed to be _m x
> +			 * the reference frequency of 24MHz divided
> +			 * by the prescaler, _p
> +			 */
> +			tmp = (u64)_m * 24 * MHZ;
> +			do_div(tmp, _p);
> +			if (tmp < 750 * MHZ ||
> +			    tmp > 3000 * MHZ)
> +				continue;
> +
> +			tmp = (u64)_m * 24 * MHZ;
> +			do_div(tmp, _p * _s);
> +
> +			delta = abs(fout - tmp);
> +			if (delta < min_delta) {
> +				best_p = _p;
> +				best_s = _s;
> +				best_m = _m;
> +				min_delta = delta;
> +				best_freq = tmp;
> +			}
> +		}
> +	}
> +
> +	if (best_freq) {
> +		*p = best_p;
> +		*m = best_m;
> +		*s = best_s;
> +	}
> +
> +	return best_freq;
> +}
> +
>  static int fsl_samsung_hdmi_phy_configure(struct fsl_samsung_hdmi_phy *phy,
>  					  const struct phy_config *cfg)
>  {
> +	u32 desired_clock = cfg->pixclk * 5;
> +	u32 close_freq;
>  	int i, ret;
> +	u16 m;
> +	u8 p, s;
>  	u8 val;
>  
>  	/* HDMI PHY init */
> @@ -453,11 +534,38 @@ static int fsl_samsung_hdmi_phy_configure(struct fsl_samsung_hdmi_phy *phy,
>  	for (i = 0; i < ARRAY_SIZE(common_phy_cfg); i++)
>  		writeb(common_phy_cfg[i].val, phy->regs + common_phy_cfg[i].reg);
>  
> -	/* set individual PLL registers PHY_REG2 ... PHY_REG7 */
> -	for (i = 0; i < PHY_PLL_DIV_REGS_NUM; i++)
> -		writeb(cfg->pll_div_regs[i], phy->regs + PHY_REG(2) + i * 4);
> +	/* Using the PMS calculator alone, determine if can use integer divider */
> +	close_freq = fsl_samsung_hdmi_phy_find_pms(desired_clock, &p, &m, &s);
> +
> +	/* If the clock cannot be configured with integer divder, use the fractional divider */
> +	if (close_freq != desired_clock) {
> +		dev_dbg(phy->dev, "fsl_samsung_hdmi_phy: use fractional divider\n");
> +		/* set individual PLL registers PHY_REG2 ... PHY_REG7 */
> +		for (i = 0; i < PHY_PLL_DIV_REGS_NUM; i++)
> +			writeb(cfg->pll_div_regs[i], phy->regs + PHY_REG(2) + i * 4);
> +		fsl_samsung_hdmi_phy_configure_pixclk(phy, cfg);
> +	} else {
> +		dev_dbg(phy->dev, "fsl_samsung_hdmi_phy: use integer divider\n");
> +		dev_dbg(phy->dev, "fsl_samsung_hdmi_phy: P = %d\n", p);
> +		dev_dbg(phy->dev, "fsl_samsung_hdmi_phy: M = %d\n", m);
> +		dev_dbg(phy->dev, "fsl_samsung_hdmi_phy: S = %d\n", s);
> +		dev_dbg(phy->dev, "fsl_samsung_hdmi_phy: frequency = %u\n", close_freq);
> +
> +		/* Write integer divder values for PMS */
> +		writeb(FIELD_PREP(REG01_PMS_P_MASK, p), phy->regs + PHY_REG(1));
> +		writeb(m, phy->regs + PHY_REG(2));
> +		writeb(FIELD_PREP(REG03_PMS_S_MASK, s-1), phy->regs + PHY_REG(3));
> +
> +		/* Configure PHY to disable fractional divider */
> +		writeb(0x00, phy->regs + PHY_REG(4));
> +		writeb(0x00, phy->regs + PHY_REG(5));
> +		writeb(0x80, phy->regs + PHY_REG(6));
> +		writeb(0x00, phy->regs + PHY_REG(7));
> +
> +		writeb(REG21_SEL_TX_CK_INV | FIELD_PREP(REG21_PMS_S_MASK, s-1),
> +		       phy->regs + PHY_REG(21));
> +	}
>  
> -	fsl_samsung_hdmi_phy_configure_pixclk(phy, cfg);
>  	fsl_samsung_hdmi_phy_configure_pll_lock_det(phy, cfg);
>  
>  	writeb(REG33_FIX_DA | REG33_MODE_SET_DONE, phy->regs + PHY_REG(33));
> @@ -484,8 +592,17 @@ static unsigned long phy_clk_recalc_rate(struct clk_hw *hw,
>  static long phy_clk_round_rate(struct clk_hw *hw,
>  			       unsigned long rate, unsigned long *parent_rate)
>  {
> +	u32 int_div_clk;
>  	int i;
> +	u16 m;
> +	u8 p, s;
> +
> +	/* If the integer divider works, just use it */
> +	int_div_clk = fsl_samsung_hdmi_phy_find_pms(rate * 5, &p, &m, &s) / 5;
> +	if (int_div_clk == rate)
> +		return int_div_clk;
>  
> +	/* Otherwise, fall back to the LUT */
>  	for (i = ARRAY_SIZE(phy_pll_cfg) - 1; i >= 0; i--)
>  		if (phy_pll_cfg[i].pixclk <= rate)
>  			return phy_pll_cfg[i].pixclk;
> @@ -497,16 +614,28 @@ static int phy_clk_set_rate(struct clk_hw *hw,
>  			    unsigned long rate, unsigned long parent_rate)
>  {
>  	struct fsl_samsung_hdmi_phy *phy = to_fsl_samsung_hdmi_phy(hw);
> +	u32 int_div_clk;
>  	int i;
> -
> -	for (i = ARRAY_SIZE(phy_pll_cfg) - 1; i >= 0; i--)
> -		if (phy_pll_cfg[i].pixclk <= rate)
> -			break;
> -
> -	if (i < 0)
> -		return -EINVAL;
> -
> -	phy->cur_cfg = &phy_pll_cfg[i];
> +	u16 m;
> +	u8 p, s;
> +
> +	/* If the integer divider works, just use it */
> +	int_div_clk = fsl_samsung_hdmi_phy_find_pms(rate * 5, &p, &m, &s) / 5;
> +	if (int_div_clk == rate) {
> +		/* Just set the pixclk rate, the rest will be calculated */
> +		custom_phy_pll_cfg.pixclk = int_div_clk;
> +		phy->cur_cfg  = &custom_phy_pll_cfg;
> +	} else {
> +		/* Otherwise, search the LUT */
> +		for (i = ARRAY_SIZE(phy_pll_cfg) - 1; i >= 0; i--)
> +			if (phy_pll_cfg[i].pixclk <= rate)
> +				break;
> +
> +		if (i < 0)
> +			return -EINVAL;
> +
> +		phy->cur_cfg = &phy_pll_cfg[i];
> +	}
>  
>  	return fsl_samsung_hdmi_phy_configure(phy, phy->cur_cfg);
>  }
> -- 
> 2.43.0

-- 
~Vinod


From vkoul at kernel.org  Thu Aug 29 11:08:30 2024
From: vkoul at kernel.org (Vinod Koul)
Date: Thu, 29 Aug 2024 23:38:30 +0530
Subject: [PATCH v3 3/5] phy: fsl-imx8mq-usb: add tca function driver for
 imx95
In-Reply-To: <20240826070854.1948347-3-xu.yang_2@nxp.com>
References: <20240826070854.1948347-1-xu.yang_2@nxp.com>
 <20240826070854.1948347-3-xu.yang_2@nxp.com>
Message-ID: <ZtC5HqOzgDBYc8uW@vaman>

On 26-08-24, 15:08, Xu Yang wrote:
> The i.MX95 USB3 phy has a Type-C Assist block (TCA). This block consists
> two functional blocks (XBar assist and VBus assist) and one system
> access interface using APB.
> 
> The primary functionality of XBar assist is:
>  - switching lane for flip
>  - moving unused lanes into lower power states.
> 
> This info can be get from:
> i.MX95 RM Chapter 163.3.8 Type-C assist (TCA) block.
> 
> This will add support for TCA block to achieve lane switching and tca
> lower power functionality.
> 
> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> Reviewed-by: Jun Li <jun.li at nxp.com>
> 
> ---
> Changes in v2:
>  - return the value of imx95_usb_phy_get_tca()
> Changes in v3:
>  - no changes
> ---
>  drivers/phy/freescale/Kconfig              |   1 +
>  drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 240 +++++++++++++++++++++
>  2 files changed, 241 insertions(+)
> 
> diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
> index dcd9acff6d01..81f53564ee15 100644
> --- a/drivers/phy/freescale/Kconfig
> +++ b/drivers/phy/freescale/Kconfig
> @@ -5,6 +5,7 @@ if (ARCH_MXC && ARM64) || COMPILE_TEST
>  config PHY_FSL_IMX8MQ_USB
>  	tristate "Freescale i.MX8M USB3 PHY"
>  	depends on OF && HAS_IOMEM
> +	depends on TYPEC || TYPEC=n
>  	select GENERIC_PHY
>  	default ARCH_MXC && ARM64
>  
> diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> index adc6394626ce..8bd6d91951a2 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> @@ -10,6 +10,7 @@
>  #include <linux/phy/phy.h>
>  #include <linux/platform_device.h>
>  #include <linux/regulator/consumer.h>
> +#include <linux/usb/typec_mux.h>
>  
>  #define PHY_CTRL0			0x0
>  #define PHY_CTRL0_REF_SSP_EN		BIT(2)
> @@ -50,11 +51,66 @@
>  
>  #define PHY_TUNE_DEFAULT		0xffffffff
>  
> +#define TCA_CLK_RST			0x00
> +#define TCA_CLK_RST_SW			BIT(9)
> +#define TCA_CLK_RST_REF_CLK_EN		BIT(1)
> +#define TCA_CLK_RST_SUSPEND_CLK_EN	BIT(0)
> +
> +#define TCA_INTR_EN			0x04
> +#define TCA_INTR_STS			0x08
> +
> +#define TCA_GCFG			0x10
> +#define TCA_GCFG_ROLE_HSTDEV		BIT(4)
> +#define TCA_GCFG_OP_MODE		GENMASK(1, 0)
> +#define TCA_GCFG_OP_MODE_SYSMODE	0
> +#define TCA_GCFG_OP_MODE_SYNCMODE	1
> +
> +#define TCA_TCPC			0x14
> +#define TCA_TCPC_VALID			BIT(4)
> +#define TCA_TCPC_LOW_POWER_EN		BIT(3)
> +#define TCA_TCPC_ORIENTATION_NORMAL	BIT(2)
> +#define TCA_TCPC_MUX_CONTRL		GENMASK(1, 0)
> +#define TCA_TCPC_MUX_CONTRL_NO_CONN	0
> +#define TCA_TCPC_MUX_CONTRL_USB_CONN	1
> +
> +#define TCA_SYSMODE_CFG			0x18
> +#define TCA_SYSMODE_TCPC_DISABLE	BIT(3)
> +#define TCA_SYSMODE_TCPC_FLIP		BIT(2)
> +
> +#define TCA_CTRLSYNCMODE_CFG0		0x20
> +#define TCA_CTRLSYNCMODE_CFG1           0x20
> +
> +#define TCA_PSTATE			0x30
> +#define TCA_PSTATE_CM_STS		BIT(4)
> +#define TCA_PSTATE_TX_STS		BIT(3)
> +#define TCA_PSTATE_RX_PLL_STS		BIT(2)
> +#define TCA_PSTATE_PIPE0_POWER_DOWN	GENMASK(1, 0)
> +
> +#define TCA_GEN_STATUS			0x34
> +#define TCA_GEN_DEV_POR			BIT(12)
> +#define TCA_GEN_REF_CLK_SEL		BIT(8)
> +#define TCA_GEN_TYPEC_FLIP_INVERT	BIT(4)
> +#define TCA_GEN_PHY_TYPEC_DISABLE	BIT(3)
> +#define TCA_GEN_PHY_TYPEC_FLIP		BIT(2)
> +
> +#define TCA_VBUS_CTRL			0x40
> +#define TCA_VBUS_STATUS			0x44
> +
> +#define TCA_INFO			0xFC
> +
> +struct tca_blk {
> +	struct typec_switch_dev *sw;
> +	void __iomem *base;
> +	struct mutex mutex;
> +	enum typec_orientation orientation;
> +};
> +
>  struct imx8mq_usb_phy {
>  	struct phy *phy;
>  	struct clk *clk;
>  	void __iomem *base;
>  	struct regulator *vbus;
> +	struct tca_blk *tca;
>  	u32 pcs_tx_swing_full;
>  	u32 pcs_tx_deemph_3p5db;
>  	u32 tx_vref_tune;
> @@ -64,6 +120,170 @@ struct imx8mq_usb_phy {
>  	u32 comp_dis_tune;
>  };
>  
> +
> +static void tca_blk_orientation_set(struct tca_blk *tca,
> +				enum typec_orientation orientation);
> +
> +#ifdef CONFIG_TYPEC
> +
> +static int tca_blk_typec_switch_set(struct typec_switch_dev *sw,
> +				enum typec_orientation orientation)
> +{
> +	struct imx8mq_usb_phy *imx_phy = typec_switch_get_drvdata(sw);
> +	struct tca_blk *tca = imx_phy->tca;
> +	int ret;
> +
> +	if (tca->orientation == orientation)
> +		return 0;
> +
> +	ret = clk_prepare_enable(imx_phy->clk);
> +	if (ret)
> +		return ret;
> +
> +	tca_blk_orientation_set(tca, orientation);
> +	clk_disable_unprepare(imx_phy->clk);
> +
> +	return 0;
> +}
> +
> +static struct typec_switch_dev *tca_blk_get_typec_switch(struct platform_device *pdev,
> +					struct imx8mq_usb_phy *imx_phy)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct typec_switch_dev *sw;
> +	struct typec_switch_desc sw_desc = { };
> +
> +	sw_desc.drvdata = imx_phy;
> +	sw_desc.fwnode = dev->fwnode;
> +	sw_desc.set = tca_blk_typec_switch_set;
> +	sw_desc.name = NULL;
> +
> +	sw = typec_switch_register(dev, &sw_desc);
> +	if (IS_ERR(sw)) {
> +		dev_err(dev, "Error register tca orientation switch: %ld",
> +				PTR_ERR(sw));
> +		return NULL;
> +	}
> +
> +	return sw;
> +}
> +
> +static void tca_blk_put_typec_switch(struct typec_switch_dev *sw)
> +{
> +	typec_switch_unregister(sw);
> +}
> +
> +#else
> +
> +static struct typec_switch_dev *tca_blk_get_typec_switch(struct platform_device *pdev,
> +			struct imx8mq_usb_phy *imx_phy)
> +{
> +	return NULL;
> +}
> +
> +static void tca_blk_put_typec_switch(struct typec_switch_dev *sw) {}
> +
> +#endif /* CONFIG_TYPEC */
> +
> +static void tca_blk_orientation_set(struct tca_blk *tca,
> +				enum typec_orientation orientation)
> +{
> +	u32 val;
> +
> +	mutex_lock(&tca->mutex);
> +
> +	if (orientation == TYPEC_ORIENTATION_NONE) {
> +		/*
> +		 * use Controller Synced Mode for TCA low power enable and
> +		 * put PHY to USB safe state.
> +		 */
> +		val = readl(tca->base + TCA_GCFG);
> +		val = FIELD_PREP(TCA_GCFG_OP_MODE, TCA_GCFG_OP_MODE_SYNCMODE);
> +		writel(val, tca->base + TCA_GCFG);
> +
> +		val = readl(tca->base + TCA_TCPC);
> +		val = TCA_TCPC_VALID | TCA_TCPC_LOW_POWER_EN;
> +		writel(val, tca->base + TCA_TCPC);
> +
> +		goto out;
> +	}
> +
> +	/* use System Configuration Mode for TCA mux control. */
> +	val = readl(tca->base + TCA_GCFG);
> +	val = FIELD_PREP(TCA_GCFG_OP_MODE, TCA_GCFG_OP_MODE_SYSMODE);
> +	writel(val, tca->base + TCA_GCFG);
> +
> +	/* Disable TCA module */
> +	val = readl(tca->base + TCA_SYSMODE_CFG);
> +	val |= TCA_SYSMODE_TCPC_DISABLE;
> +	writel(val, tca->base + TCA_SYSMODE_CFG);
> +
> +	if (orientation == TYPEC_ORIENTATION_REVERSE)
> +		val |= TCA_SYSMODE_TCPC_FLIP;
> +	else if (orientation == TYPEC_ORIENTATION_NORMAL)
> +		val &= ~TCA_SYSMODE_TCPC_FLIP;
> +
> +	writel(val, tca->base + TCA_SYSMODE_CFG);
> +
> +	/* Enable TCA module */
> +	val &= ~TCA_SYSMODE_TCPC_DISABLE;
> +	writel(val, tca->base + TCA_SYSMODE_CFG);
> +
> +out:
> +	tca->orientation = orientation;
> +	mutex_unlock(&tca->mutex);
> +}
> +
> +static void tca_blk_init(struct tca_blk *tca)
> +{
> +	u32 val;
> +
> +	/* reset XBar block */
> +	val = readl(tca->base + TCA_CLK_RST);
> +	val &= ~TCA_CLK_RST_SW;
> +	writel(val, tca->base + TCA_CLK_RST);
> +
> +	udelay(100);
> +
> +	/* clear reset */
> +	val |= TCA_CLK_RST_SW;
> +	writel(val, tca->base + TCA_CLK_RST);
> +
> +	tca_blk_orientation_set(tca, tca->orientation);
> +}
> +
> +static struct tca_blk *imx95_usb_phy_get_tca(struct platform_device *pdev,
> +				struct imx8mq_usb_phy *imx_phy)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct tca_blk *tca;
> +
> +	tca = devm_kzalloc(dev, sizeof(*tca), GFP_KERNEL);
> +	if (!tca)
> +		return ERR_PTR(-ENOMEM);
> +
> +	tca->base = devm_platform_ioremap_resource(pdev, 1);
> +	if (IS_ERR(tca->base))
> +		return tca->base;
> +
> +	mutex_init(&tca->mutex);
> +
> +	tca->orientation = TYPEC_ORIENTATION_NORMAL;
> +	tca->sw = tca_blk_get_typec_switch(pdev, imx_phy);
> +
> +	return tca;
> +}
> +
> +static void imx95_usb_phy_put_tca(struct imx8mq_usb_phy *imx_phy)
> +{
> +	struct tca_blk *tca = imx_phy->tca;
> +
> +	if (!tca)
> +		return;
> +
> +	tca_blk_put_typec_switch(tca->sw);
> +}
> +
>  static u32 phy_tx_vref_tune_from_property(u32 percent)
>  {
>  	percent = clamp(percent, 94U, 124U);
> @@ -315,6 +535,9 @@ static int imx8mp_usb_phy_init(struct phy *phy)
>  
>  	imx8m_phy_tune(imx_phy);
>  
> +	if (imx_phy->tca)
> +		tca_blk_init(imx_phy->tca);
> +
>  	return 0;
>  }
>  
> @@ -359,6 +582,8 @@ static const struct of_device_id imx8mq_usb_phy_of_match[] = {
>  	 .data = &imx8mq_usb_phy_ops,},
>  	{.compatible = "fsl,imx8mp-usb-phy",
>  	 .data = &imx8mp_usb_phy_ops,},
> +	{.compatible = "fsl,imx95-usb-phy",
> +	 .data = &imx8mp_usb_phy_ops,},

Okay

>  	{ }
>  };
>  MODULE_DEVICE_TABLE(of, imx8mq_usb_phy_of_match);
> @@ -398,6 +623,13 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
>  
>  	phy_set_drvdata(imx_phy->phy, imx_phy);
>  
> +	if (device_is_compatible(dev, "fsl,imx95-usb-phy")) {

so future version will also have this check, so are we going to increase
this..? maybe better idea is to expand imx8mp_usb_phy_ops and add a flag
for tca support and set that for required compatible, or make this a
property?


> +		imx_phy->tca = imx95_usb_phy_get_tca(pdev, imx_phy);
> +		if (IS_ERR(imx_phy->tca))
> +			return dev_err_probe(dev, PTR_ERR(imx_phy->tca),
> +						"failed to get tca\n");
> +	}
> +
>  	imx8m_get_phy_tuning_data(imx_phy);
>  
>  	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
> @@ -405,8 +637,16 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
>  	return PTR_ERR_OR_ZERO(phy_provider);
>  }
>  
> +static void imx8mq_usb_phy_remove(struct platform_device *pdev)
> +{
> +	struct imx8mq_usb_phy *imx_phy = platform_get_drvdata(pdev);
> +
> +	imx95_usb_phy_put_tca(imx_phy);
> +}
> +
>  static struct platform_driver imx8mq_usb_phy_driver = {
>  	.probe	= imx8mq_usb_phy_probe,
> +	.remove = imx8mq_usb_phy_remove,
>  	.driver = {
>  		.name	= "imx8mq-usb-phy",
>  		.of_match_table	= imx8mq_usb_phy_of_match,
> -- 
> 2.34.1

-- 
~Vinod


From vkoul at kernel.org  Thu Aug 29 11:13:31 2024
From: vkoul at kernel.org (Vinod Koul)
Date: Thu, 29 Aug 2024 23:43:31 +0530
Subject: [PATCH v4 1/1] dt-bindings: phy: ti,tcan104x-can: Document
 Microchip ATA6561
In-Reply-To: <20240822105238.213019-2-ilordash02@gmail.com>
References: <20240822105238.213019-1-ilordash02@gmail.com>
 <20240822105238.213019-2-ilordash02@gmail.com>
Message-ID: <ZtC6S6I/QKihcsyu@vaman>

On 22-08-24, 13:52, Ilya Orazov wrote:
> Microchip ATA6561 is High-Speed CAN Transceiver with Standby Mode.
> It is pin-compatible with TI TCAN1042 and has a compatible programming
> model, therefore use ti,tcan1042 as fallback compatible.
> 
> Acked-by: Conor Dooley <conor.dooley at microchip.com>
> Signed-off-by: Ilya Orazov <ilordash02 at gmail.com>
> ---
>  .../devicetree/bindings/phy/ti,tcan104x-can.yaml    | 13 +++++++++----
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> index 79dad3e89aa6..4a8c3829d85d 100644
> --- a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> +++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> @@ -14,10 +14,15 @@ properties:
>      pattern: "^can-phy"
>  
>    compatible:
> -    enum:
> -      - nxp,tjr1443
> -      - ti,tcan1042
> -      - ti,tcan1043
> +    oneOf:
> +      - items:
> +          - enum:
> +              - microchip,ata6561
> +          - const: ti,tcan1042
> +      - enum:
> +          - ti,tcan1042
> +          - ti,tcan1043
> +          - nxp,tjr1443

No driver/dt for new compatibles?

>  
>    '#phy-cells':
>      const: 0
> -- 
> 2.34.1

-- 
~Vinod


From aford173 at gmail.com  Thu Aug 29 11:30:29 2024
From: aford173 at gmail.com (Adam Ford)
Date: Thu, 29 Aug 2024 13:30:29 -0500
Subject: [RFC V2 2/2] phy: freescale: fsl-samsung-hdmi: Support dynamic
 integer divider
In-Reply-To: <ZtC2LhYAAdPdSRpz@vaman>
References: <20240829021256.787615-1-aford173@gmail.com> <20240829021256.787615-2-aford173@gmail.com>
 <ZtC2LhYAAdPdSRpz@vaman>
Message-ID: <CAHCN7xKW=zxips+J73913eEfS+p_e3dN9BWU08=poj599JbUxA@mail.gmail.com>

On Thu, Aug 29, 2024 at 12:56?PM Vinod Koul <vkoul at kernel.org> wrote:
>
> On 28-08-24, 21:12, Adam Ford wrote:
> > There is currently a look-up table for a variety of resolutions.
> > Since the phy has the ability to dynamically calculate the values
> > necessary to use the intger divider which should allow more
> > resolutions without having to update the look-up-table.  If the
> > integer calculator cannot get an exact frequency, it falls back
> > to the look-up-table.  Because the LUT algorithm does some
> > rounding, I did not remove integer entries from the LUT.
>
> Any reason why this is RFC?

Someone was asking for functionality, but I'm not 100% sure this is
the right approach or it would even work.  I am waiting for feedback
from Dominique to determine if this helps solve the display for that
particular display.

>
> >
> > Signed-off-by: Adam Ford <aford173 at gmail.com>
> >
> > diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > index bc5d3625ece6..76e0899c6006 100644
> > --- a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > +++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > @@ -16,6 +16,8 @@
> >
> >  #define PHY_REG(reg)         (reg * 4)
> >
> > +#define REG01_PMS_P_MASK     GENMASK(3, 0)
> > +#define REG03_PMS_S_MASK     GENMASK(7, 4)
> >  #define REG12_CK_DIV_MASK    GENMASK(5, 4)
> >  #define REG13_TG_CODE_LOW_MASK       GENMASK(7, 0)
> >  #define REG14_TOL_MASK               GENMASK(7, 4)
> > @@ -31,11 +33,17 @@
> >
> >  #define PHY_PLL_DIV_REGS_NUM 6
> >
> > +#ifndef MHZ
> > +#define MHZ  (1000UL * 1000UL)
> > +#endif
> > +
> >  struct phy_config {
> >       u32     pixclk;
> >       u8      pll_div_regs[PHY_PLL_DIV_REGS_NUM];
> >  };
> >
> > +static struct phy_config custom_phy_pll_cfg;
> > +
> >  static const struct phy_config phy_pll_cfg[] = {
> >       {
> >               .pixclk = 22250000,
> > @@ -440,10 +448,83 @@ fsl_samsung_hdmi_phy_configure_pll_lock_det(struct fsl_samsung_hdmi_phy *phy,
> >              phy->regs + PHY_REG(14));
> >  }
> >
> > +static unsigned long fsl_samsung_hdmi_phy_find_pms(unsigned long fout, u8 *p, u16 *m, u8 *s)
> > +{
> > +     unsigned long best_freq = 0;
> > +     u32 min_delta = 0xffffffff;
>
> > +     u8 _p, best_p;
> > +     u16 _m, best_m;
> > +     u8 _s, best_s;
> > +
> > +     for (_p = 1; _p <= 11; ++_p) {
>
> starts with 1 to 11.. why?

According to Rev 2 of the 8MP Reference Manual, the Previder range is
between 1 and 11.

>
> > +             for (_s = 1; _s <= 16; ++_s) {
> > +                     u64 tmp;
> > +                     u32 delta;
> > +
> > +                     /* s must be even */
> > +                     if (_s > 1 && (_s & 0x01) == 1)
> > +                             _s++;
> > +
> > +                     /* _s cannot be 14 per the TRM */
> > +                     if (_s == 14)
> > +                             continue;
> > +
> > +                     /*
> > +                      * TODO: Ref Manual doesn't state the range of _m
> > +                      * so this should be further refined if possible.
> > +                      * This range was set based on the original values
> > +                      * in the look-up table
> > +                      */
> > +                     tmp = (u64)fout * (_p * _s);
> > +                     do_div(tmp, 24 * MHZ);
> > +                     _m = tmp;
> > +                     if (_m < 0x30 || _m > 0x7b)
> > +                             continue;
> > +
> > +                     /*
> > +                      * Rev 2 of the Ref Manual states the
> > +                      * VCO can range between 750MHz and
> > +                      * 3GHz.  The VCO is assumed to be _m x
> > +                      * the reference frequency of 24MHz divided
> > +                      * by the prescaler, _p
> > +                      */
> > +                     tmp = (u64)_m * 24 * MHZ;
> > +                     do_div(tmp, _p);
> > +                     if (tmp < 750 * MHZ ||
> > +                         tmp > 3000 * MHZ)
> > +                             continue;
> > +
> > +                     tmp = (u64)_m * 24 * MHZ;
> > +                     do_div(tmp, _p * _s);
> > +
> > +                     delta = abs(fout - tmp);
> > +                     if (delta < min_delta) {
> > +                             best_p = _p;
> > +                             best_s = _s;
> > +                             best_m = _m;
> > +                             min_delta = delta;
> > +                             best_freq = tmp;
> > +                     }
> > +             }
> > +     }
> > +
> > +     if (best_freq) {
> > +             *p = best_p;
> > +             *m = best_m;
> > +             *s = best_s;
> > +     }
> > +
> > +     return best_freq;
> > +}
> > +
> >  static int fsl_samsung_hdmi_phy_configure(struct fsl_samsung_hdmi_phy *phy,
> >                                         const struct phy_config *cfg)
> >  {
> > +     u32 desired_clock = cfg->pixclk * 5;
> > +     u32 close_freq;
> >       int i, ret;
> > +     u16 m;
> > +     u8 p, s;
> >       u8 val;
> >
> >       /* HDMI PHY init */
> > @@ -453,11 +534,38 @@ static int fsl_samsung_hdmi_phy_configure(struct fsl_samsung_hdmi_phy *phy,
> >       for (i = 0; i < ARRAY_SIZE(common_phy_cfg); i++)
> >               writeb(common_phy_cfg[i].val, phy->regs + common_phy_cfg[i].reg);
> >
> > -     /* set individual PLL registers PHY_REG2 ... PHY_REG7 */
> > -     for (i = 0; i < PHY_PLL_DIV_REGS_NUM; i++)
> > -             writeb(cfg->pll_div_regs[i], phy->regs + PHY_REG(2) + i * 4);
> > +     /* Using the PMS calculator alone, determine if can use integer divider */
> > +     close_freq = fsl_samsung_hdmi_phy_find_pms(desired_clock, &p, &m, &s);
> > +
> > +     /* If the clock cannot be configured with integer divder, use the fractional divider */
> > +     if (close_freq != desired_clock) {
> > +             dev_dbg(phy->dev, "fsl_samsung_hdmi_phy: use fractional divider\n");
> > +             /* set individual PLL registers PHY_REG2 ... PHY_REG7 */
> > +             for (i = 0; i < PHY_PLL_DIV_REGS_NUM; i++)
> > +                     writeb(cfg->pll_div_regs[i], phy->regs + PHY_REG(2) + i * 4);
> > +             fsl_samsung_hdmi_phy_configure_pixclk(phy, cfg);
> > +     } else {
> > +             dev_dbg(phy->dev, "fsl_samsung_hdmi_phy: use integer divider\n");
> > +             dev_dbg(phy->dev, "fsl_samsung_hdmi_phy: P = %d\n", p);
> > +             dev_dbg(phy->dev, "fsl_samsung_hdmi_phy: M = %d\n", m);
> > +             dev_dbg(phy->dev, "fsl_samsung_hdmi_phy: S = %d\n", s);
> > +             dev_dbg(phy->dev, "fsl_samsung_hdmi_phy: frequency = %u\n", close_freq);
> > +
> > +             /* Write integer divder values for PMS */
> > +             writeb(FIELD_PREP(REG01_PMS_P_MASK, p), phy->regs + PHY_REG(1));
> > +             writeb(m, phy->regs + PHY_REG(2));
> > +             writeb(FIELD_PREP(REG03_PMS_S_MASK, s-1), phy->regs + PHY_REG(3));
> > +
> > +             /* Configure PHY to disable fractional divider */
> > +             writeb(0x00, phy->regs + PHY_REG(4));
> > +             writeb(0x00, phy->regs + PHY_REG(5));
> > +             writeb(0x80, phy->regs + PHY_REG(6));
> > +             writeb(0x00, phy->regs + PHY_REG(7));
> > +
> > +             writeb(REG21_SEL_TX_CK_INV | FIELD_PREP(REG21_PMS_S_MASK, s-1),
> > +                    phy->regs + PHY_REG(21));
> > +     }
> >
> > -     fsl_samsung_hdmi_phy_configure_pixclk(phy, cfg);
> >       fsl_samsung_hdmi_phy_configure_pll_lock_det(phy, cfg);
> >
> >       writeb(REG33_FIX_DA | REG33_MODE_SET_DONE, phy->regs + PHY_REG(33));
> > @@ -484,8 +592,17 @@ static unsigned long phy_clk_recalc_rate(struct clk_hw *hw,
> >  static long phy_clk_round_rate(struct clk_hw *hw,
> >                              unsigned long rate, unsigned long *parent_rate)
> >  {
> > +     u32 int_div_clk;
> >       int i;
> > +     u16 m;
> > +     u8 p, s;
> > +
> > +     /* If the integer divider works, just use it */
> > +     int_div_clk = fsl_samsung_hdmi_phy_find_pms(rate * 5, &p, &m, &s) / 5;
> > +     if (int_div_clk == rate)
> > +             return int_div_clk;
> >
> > +     /* Otherwise, fall back to the LUT */
> >       for (i = ARRAY_SIZE(phy_pll_cfg) - 1; i >= 0; i--)
> >               if (phy_pll_cfg[i].pixclk <= rate)
> >                       return phy_pll_cfg[i].pixclk;
> > @@ -497,16 +614,28 @@ static int phy_clk_set_rate(struct clk_hw *hw,
> >                           unsigned long rate, unsigned long parent_rate)
> >  {
> >       struct fsl_samsung_hdmi_phy *phy = to_fsl_samsung_hdmi_phy(hw);
> > +     u32 int_div_clk;
> >       int i;
> > -
> > -     for (i = ARRAY_SIZE(phy_pll_cfg) - 1; i >= 0; i--)
> > -             if (phy_pll_cfg[i].pixclk <= rate)
> > -                     break;
> > -
> > -     if (i < 0)
> > -             return -EINVAL;
> > -
> > -     phy->cur_cfg = &phy_pll_cfg[i];
> > +     u16 m;
> > +     u8 p, s;
> > +
> > +     /* If the integer divider works, just use it */
> > +     int_div_clk = fsl_samsung_hdmi_phy_find_pms(rate * 5, &p, &m, &s) / 5;
> > +     if (int_div_clk == rate) {
> > +             /* Just set the pixclk rate, the rest will be calculated */
> > +             custom_phy_pll_cfg.pixclk = int_div_clk;
> > +             phy->cur_cfg  = &custom_phy_pll_cfg;
> > +     } else {
> > +             /* Otherwise, search the LUT */
> > +             for (i = ARRAY_SIZE(phy_pll_cfg) - 1; i >= 0; i--)
> > +                     if (phy_pll_cfg[i].pixclk <= rate)
> > +                             break;
> > +
> > +             if (i < 0)
> > +                     return -EINVAL;
> > +
> > +             phy->cur_cfg = &phy_pll_cfg[i];
> > +     }
> >
> >       return fsl_samsung_hdmi_phy_configure(phy, phy->cur_cfg);
> >  }
> > --
> > 2.43.0
>
> --
> ~Vinod


From vkoul at kernel.org  Thu Aug 29 12:05:31 2024
From: vkoul at kernel.org (Vinod Koul)
Date: Fri, 30 Aug 2024 00:35:31 +0530
Subject: [PATCH v2] phy: qcom: qmp-pcie: Configure all tables on port B
 PHY
In-Reply-To: <20240801-phy-qcom-qmp-pcie-write-all-tbls-second-port-v2-1-6e53c701e87e@linaro.org>
References: <20240801-phy-qcom-qmp-pcie-write-all-tbls-second-port-v2-1-6e53c701e87e@linaro.org>
Message-ID: <172495833122.405683.1905233025604889518.b4-ty@kernel.org>


On Thu, 01 Aug 2024 18:54:53 +0300, Abel Vesa wrote:
> Currently, only the RX and TX tables are written to the second PHY
> (port B) when the 4-lanes mode is configured, but according to Qualcomm
> internal documentation, the pcs, pcs_misc, serdes and ln_shrd tables need
> to be written as well.
> 
> 

Applied, thanks!

[1/1] phy: qcom: qmp-pcie: Configure all tables on port B PHY
      commit: 00c5f32283f377ec60870bccbd518d9feb7fbc52

Best regards,
-- 
~Vinod




From vkoul at kernel.org  Thu Aug 29 12:05:34 2024
From: vkoul at kernel.org (Vinod Koul)
Date: Fri, 30 Aug 2024 00:35:34 +0530
Subject: [PATCH v3 0/2] phy: qcom: qmp-pcie: Add support for Gen4
 4-lane mode for X1E80100
In-Reply-To: <20240823-x1e80100-phy-add-gen4x4-v3-0-b7765631ca01@linaro.org>
References: <20240823-x1e80100-phy-add-gen4x4-v3-0-b7765631ca01@linaro.org>
Message-ID: <172495833400.405683.4328817324548517864.b4-ty@kernel.org>


On Fri, 23 Aug 2024 10:04:14 +0300, Abel Vesa wrote:
> On all X Elite boards currently supported upstream, the NVMe sits
> on the PCIe 6. Until now that has been configured in dual lane mode
> only. The schematics reveal that the NVMe is actually using 4 lanes.
> So add support for the 4-lane mode and document the compatible for it.
> 
> This patchset depends on:
> https://lore.kernel.org/all/20240805-phy-qcom-qmp-pcie-write-all-tbls-second-port-v3-1-6967c6bf61d1 at linaro.org/
> 
> [...]

Applied, thanks!

[1/2] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Document the X1E80100 QMP PCIe PHY Gen4 x4
      commit: 0c5f4d23f77631f657b60ef660676303f7620688
[2/2] phy: qcom: qmp-pcie: Add Gen4 4-lanes mode for X1E80100
      commit: 9dab00ee95447b286ebb0ada3a5edc00beab3750

Best regards,
-- 
~Vinod




From vkoul at kernel.org  Thu Aug 29 12:05:37 2024
From: vkoul at kernel.org (Vinod Koul)
Date: Fri, 30 Aug 2024 00:35:37 +0530
Subject: [PATCH] dt-bindings: phy: socionext,uniphier: add top-level
 constraints
In-Reply-To: <20240818172835.121757-1-krzysztof.kozlowski@linaro.org>
References: <20240818172835.121757-1-krzysztof.kozlowski@linaro.org>
Message-ID: <172495833772.405683.9269300572581371262.b4-ty@kernel.org>


On Sun, 18 Aug 2024 19:28:35 +0200, Krzysztof Kozlowski wrote:
> Properties with variable number of items per each device are expected to
> have widest constraints in top-level "properties:" block and further
> customized (narrowed) in "if:then:".  Add missing top-level constraints
> for clock-names and reset-names.
> 
> 

Applied, thanks!

[1/1] dt-bindings: phy: socionext,uniphier: add top-level constraints
      commit: 45a4237b9be24d6c93db9da2b2180810c5bb2929

Best regards,
-- 
~Vinod




From vkoul at kernel.org  Thu Aug 29 12:05:41 2024
From: vkoul at kernel.org (Vinod Koul)
Date: Fri, 30 Aug 2024 00:35:41 +0530
Subject: [PATCH v3] phy: airoha: adjust initialization delay in
 airoha_pcie_phy_init()
In-Reply-To: <8af6f27857619f1e0dd227f08b8584ae8fb22fb2.1722959625.git.lorenzo@kernel.org>
References: <8af6f27857619f1e0dd227f08b8584ae8fb22fb2.1722959625.git.lorenzo@kernel.org>
Message-ID: <172495834118.405683.17095010628277184659.b4-ty@kernel.org>


On Tue, 06 Aug 2024 17:55:48 +0200, Lorenzo Bianconi wrote:
> Align phy-pcie initialization delay to the vendor sdk in
> airoha_pcie_phy_init routine and allow the hw to complete required
> configuration before proceeding
> 
> 

Applied, thanks!

[1/1] phy: airoha: adjust initialization delay in airoha_pcie_phy_init()
      commit: 7f7315db3d262298ab33d198d3f0b09cabfa7b6b

Best regards,
-- 
~Vinod




From vkoul at kernel.org  Thu Aug 29 12:05:44 2024
From: vkoul at kernel.org (Vinod Koul)
Date: Fri, 30 Aug 2024 00:35:44 +0530
Subject: [PATCH v3] phy: qcom: qmp-pcie: Configure all tables on port B
 PHY
In-Reply-To: <20240805-phy-qcom-qmp-pcie-write-all-tbls-second-port-v3-1-6967c6bf61d1@linaro.org>
References: <20240805-phy-qcom-qmp-pcie-write-all-tbls-second-port-v3-1-6967c6bf61d1@linaro.org>
Message-ID: <172495834439.405683.7952114059467744681.b4-ty@kernel.org>


On Mon, 05 Aug 2024 19:45:18 +0300, Abel Vesa wrote:
> Currently, only the RX and TX tables are written to the second PHY
> (port B) when the 4-lanes mode is configured, but according to Qualcomm
> internal documentation, the pcs, pcs_misc, serdes and ln_shrd tables need
> to be written as well.
> 
> 

Applied, thanks!

[1/1] phy: qcom: qmp-pcie: Configure all tables on port B PHY
      commit: 00c5f32283f377ec60870bccbd518d9feb7fbc52

Best regards,
-- 
~Vinod




From vkoul at kernel.org  Thu Aug 29 12:05:47 2024
From: vkoul at kernel.org (Vinod Koul)
Date: Fri, 30 Aug 2024 00:35:47 +0530
Subject: [PATCH v4 0/2] Add support for nuvoton ma35 usb2 phy
In-Reply-To: <20240805030356.14565-1-hpchen0nvt@gmail.com>
References: <20240805030356.14565-1-hpchen0nvt@gmail.com>
Message-ID: <172495834711.405683.69011643308831007.b4-ty@kernel.org>


On Mon, 05 Aug 2024 03:03:54 +0000, Hui-Ping Chen wrote:
> This patch series adds the usb2 phy driver for the nuvoton ma35 ARMv8 SoC.
> It includes DT binding documentation and the ma35 usb2 phy driver.
> 
> v4:
>   - Update ma35d1 usb2 phy driver
>     - Update the 'readl_poll_timeout' to 'regmap_read_poll_timeout'.
>     - Update MODULE_AUTHOR name.
> 
> [...]

Applied, thanks!

[1/2] dt-bindings: phy: nuvoton,ma35-usb2-phy: add new bindings
      commit: c174f1c6c100b18c4a908b117265d7cd99fff6c7
[2/2] phy: nuvoton: add new driver for the Nuvoton MA35 SoC USB 2.0 PHY
      commit: b48baf69db9725aa5ddde52d98cd7b5517ddd9eb

Best regards,
-- 
~Vinod




From aford173 at gmail.com  Thu Aug 29 20:24:25 2024
From: aford173 at gmail.com (Adam Ford)
Date: Thu, 29 Aug 2024 22:24:25 -0500
Subject: [RFC V3 1/3] phy: freescale: fsl-samsung-hdmi: Replace register defines with macro
Message-ID: <20240830032442.226031-1-aford173@gmail.com>

There are 47 registers defined as PHY_REG_xx were xx goes from 00 to
47.  Simplify this by replacing them all with a macro which is passed
the register number to return the proper register offset.

Signed-off-by: Adam Ford <aford173 at gmail.com>

diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
index 9048cdc760c2..bc5d3625ece6 100644
--- a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
+++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
@@ -14,76 +14,20 @@
 #include <linux/platform_device.h>
 #include <linux/pm_runtime.h>
 
-#define PHY_REG_00		0x00
-#define PHY_REG_01		0x04
-#define PHY_REG_02		0x08
-#define PHY_REG_08		0x20
-#define PHY_REG_09		0x24
-#define PHY_REG_10		0x28
-#define PHY_REG_11		0x2c
-
-#define PHY_REG_12		0x30
-#define  REG12_CK_DIV_MASK	GENMASK(5, 4)
-
-#define PHY_REG_13		0x34
-#define  REG13_TG_CODE_LOW_MASK	GENMASK(7, 0)
-
-#define PHY_REG_14		0x38
-#define  REG14_TOL_MASK		GENMASK(7, 4)
-#define  REG14_RP_CODE_MASK	GENMASK(3, 1)
-#define  REG14_TG_CODE_HIGH_MASK	GENMASK(0, 0)
-
-#define PHY_REG_15		0x3c
-#define PHY_REG_16		0x40
-#define PHY_REG_17		0x44
-#define PHY_REG_18		0x48
-#define PHY_REG_19		0x4c
-#define PHY_REG_20		0x50
-
-#define PHY_REG_21		0x54
-#define  REG21_SEL_TX_CK_INV	BIT(7)
-#define  REG21_PMS_S_MASK	GENMASK(3, 0)
-
-#define PHY_REG_22		0x58
-#define PHY_REG_23		0x5c
-#define PHY_REG_24		0x60
-#define PHY_REG_25		0x64
-#define PHY_REG_26		0x68
-#define PHY_REG_27		0x6c
-#define PHY_REG_28		0x70
-#define PHY_REG_29		0x74
-#define PHY_REG_30		0x78
-#define PHY_REG_31		0x7c
-#define PHY_REG_32		0x80
-
-/*
- * REG33 does not match the ref manual. According to Sandor Yu from NXP,
- * "There is a doc issue on the i.MX8MP latest RM"
- * REG33 is being used per guidance from Sandor
- */
-
-#define PHY_REG_33		0x84
-#define  REG33_MODE_SET_DONE	BIT(7)
-#define  REG33_FIX_DA		BIT(1)
-
-#define PHY_REG_34		0x88
-#define  REG34_PHY_READY	BIT(7)
-#define  REG34_PLL_LOCK		BIT(6)
-#define  REG34_PHY_CLK_READY	BIT(5)
-
-#define PHY_REG_35		0x8c
-#define PHY_REG_36		0x90
-#define PHY_REG_37		0x94
-#define PHY_REG_38		0x98
-#define PHY_REG_39		0x9c
-#define PHY_REG_40		0xa0
-#define PHY_REG_41		0xa4
-#define PHY_REG_42		0xa8
-#define PHY_REG_43		0xac
-#define PHY_REG_44		0xb0
-#define PHY_REG_45		0xb4
-#define PHY_REG_46		0xb8
-#define PHY_REG_47		0xbc
+#define PHY_REG(reg)		(reg * 4)
+
+#define REG12_CK_DIV_MASK	GENMASK(5, 4)
+#define REG13_TG_CODE_LOW_MASK	GENMASK(7, 0)
+#define REG14_TOL_MASK		GENMASK(7, 4)
+#define REG14_RP_CODE_MASK	GENMASK(3, 1)
+#define REG14_TG_CODE_HIGH_MASK	GENMASK(0, 0)
+#define REG21_SEL_TX_CK_INV	BIT(7)
+#define REG21_PMS_S_MASK	GENMASK(3, 0)
+#define REG33_MODE_SET_DONE	BIT(7)
+#define REG33_FIX_DA		BIT(1)
+#define REG34_PHY_READY	BIT(7)
+#define REG34_PLL_LOCK		BIT(6)
+#define REG34_PHY_CLK_READY	BIT(5)
 
 #define PHY_PLL_DIV_REGS_NUM 6
 
@@ -369,29 +313,29 @@ struct reg_settings {
 };
 
 static const struct reg_settings common_phy_cfg[] = {
-	{ PHY_REG_00, 0x00 }, { PHY_REG_01, 0xd1 },
-	{ PHY_REG_08, 0x4f }, { PHY_REG_09, 0x30 },
-	{ PHY_REG_10, 0x33 }, { PHY_REG_11, 0x65 },
+	{ PHY_REG(0), 0x00 }, { PHY_REG(1), 0xd1 },
+	{ PHY_REG(8), 0x4f }, { PHY_REG(9), 0x30 },
+	{ PHY_REG(10), 0x33 }, { PHY_REG(11), 0x65 },
 	/* REG12 pixclk specific */
 	/* REG13 pixclk specific */
 	/* REG14 pixclk specific */
-	{ PHY_REG_15, 0x80 }, { PHY_REG_16, 0x6c },
-	{ PHY_REG_17, 0xf2 }, { PHY_REG_18, 0x67 },
-	{ PHY_REG_19, 0x00 }, { PHY_REG_20, 0x10 },
+	{ PHY_REG(15), 0x80 }, { PHY_REG(16), 0x6c },
+	{ PHY_REG(17), 0xf2 }, { PHY_REG(18), 0x67 },
+	{ PHY_REG(19), 0x00 }, { PHY_REG(20), 0x10 },
 	/* REG21 pixclk specific */
-	{ PHY_REG_22, 0x30 }, { PHY_REG_23, 0x32 },
-	{ PHY_REG_24, 0x60 }, { PHY_REG_25, 0x8f },
-	{ PHY_REG_26, 0x00 }, { PHY_REG_27, 0x00 },
-	{ PHY_REG_28, 0x08 }, { PHY_REG_29, 0x00 },
-	{ PHY_REG_30, 0x00 }, { PHY_REG_31, 0x00 },
-	{ PHY_REG_32, 0x00 }, { PHY_REG_33, 0x80 },
-	{ PHY_REG_34, 0x00 }, { PHY_REG_35, 0x00 },
-	{ PHY_REG_36, 0x00 }, { PHY_REG_37, 0x00 },
-	{ PHY_REG_38, 0x00 }, { PHY_REG_39, 0x00 },
-	{ PHY_REG_40, 0x00 }, { PHY_REG_41, 0xe0 },
-	{ PHY_REG_42, 0x83 }, { PHY_REG_43, 0x0f },
-	{ PHY_REG_44, 0x3E }, { PHY_REG_45, 0xf8 },
-	{ PHY_REG_46, 0x00 }, { PHY_REG_47, 0x00 }
+	{ PHY_REG(22), 0x30 }, { PHY_REG(23), 0x32 },
+	{ PHY_REG(24), 0x60 }, { PHY_REG(25), 0x8f },
+	{ PHY_REG(26), 0x00 }, { PHY_REG(27), 0x00 },
+	{ PHY_REG(28), 0x08 }, { PHY_REG(29), 0x00 },
+	{ PHY_REG(30), 0x00 }, { PHY_REG(31), 0x00 },
+	{ PHY_REG(32), 0x00 }, { PHY_REG(33), 0x80 },
+	{ PHY_REG(34), 0x00 }, { PHY_REG(35), 0x00 },
+	{ PHY_REG(36), 0x00 }, { PHY_REG(37), 0x00 },
+	{ PHY_REG(38), 0x00 }, { PHY_REG(39), 0x00 },
+	{ PHY_REG(40), 0x00 }, { PHY_REG(41), 0xe0 },
+	{ PHY_REG(42), 0x83 }, { PHY_REG(43), 0x0f },
+	{ PHY_REG(44), 0x3E }, { PHY_REG(45), 0xf8 },
+	{ PHY_REG(46), 0x00 }, { PHY_REG(47), 0x00 }
 };
 
 struct fsl_samsung_hdmi_phy {
@@ -442,7 +386,7 @@ fsl_samsung_hdmi_phy_configure_pixclk(struct fsl_samsung_hdmi_phy *phy,
 	}
 
 	writeb(REG21_SEL_TX_CK_INV | FIELD_PREP(REG21_PMS_S_MASK, div),
-	       phy->regs + PHY_REG_21);
+	       phy->regs + PHY_REG(21));
 }
 
 static void
@@ -469,7 +413,7 @@ fsl_samsung_hdmi_phy_configure_pll_lock_det(struct fsl_samsung_hdmi_phy *phy,
 		break;
 	}
 
-	writeb(FIELD_PREP(REG12_CK_DIV_MASK, ilog2(div)), phy->regs + PHY_REG_12);
+	writeb(FIELD_PREP(REG12_CK_DIV_MASK, ilog2(div)), phy->regs + PHY_REG(12));
 
 	/*
 	 * Calculation for the frequency lock detector target code (fld_tg_code)
@@ -489,11 +433,11 @@ fsl_samsung_hdmi_phy_configure_pll_lock_det(struct fsl_samsung_hdmi_phy *phy,
 
 	/* FLD_TOL and FLD_RP_CODE taken from downstream driver */
 	writeb(FIELD_PREP(REG13_TG_CODE_LOW_MASK, fld_tg_code),
-	       phy->regs + PHY_REG_13);
+	       phy->regs + PHY_REG(13));
 	writeb(FIELD_PREP(REG14_TOL_MASK, 2) |
 	       FIELD_PREP(REG14_RP_CODE_MASK, 2) |
 	       FIELD_PREP(REG14_TG_CODE_HIGH_MASK, fld_tg_code >> 8),
-	       phy->regs + PHY_REG_14);
+	       phy->regs + PHY_REG(14));
 }
 
 static int fsl_samsung_hdmi_phy_configure(struct fsl_samsung_hdmi_phy *phy,
@@ -503,7 +447,7 @@ static int fsl_samsung_hdmi_phy_configure(struct fsl_samsung_hdmi_phy *phy,
 	u8 val;
 
 	/* HDMI PHY init */
-	writeb(REG33_FIX_DA, phy->regs + PHY_REG_33);
+	writeb(REG33_FIX_DA, phy->regs + PHY_REG(33));
 
 	/* common PHY registers */
 	for (i = 0; i < ARRAY_SIZE(common_phy_cfg); i++)
@@ -511,14 +455,14 @@ static int fsl_samsung_hdmi_phy_configure(struct fsl_samsung_hdmi_phy *phy,
 
 	/* set individual PLL registers PHY_REG2 ... PHY_REG7 */
 	for (i = 0; i < PHY_PLL_DIV_REGS_NUM; i++)
-		writeb(cfg->pll_div_regs[i], phy->regs + PHY_REG_02 + i * 4);
+		writeb(cfg->pll_div_regs[i], phy->regs + PHY_REG(2) + i * 4);
 
 	fsl_samsung_hdmi_phy_configure_pixclk(phy, cfg);
 	fsl_samsung_hdmi_phy_configure_pll_lock_det(phy, cfg);
 
-	writeb(REG33_FIX_DA | REG33_MODE_SET_DONE, phy->regs + PHY_REG_33);
+	writeb(REG33_FIX_DA | REG33_MODE_SET_DONE, phy->regs + PHY_REG(33));
 
-	ret = readb_poll_timeout(phy->regs + PHY_REG_34, val,
+	ret = readb_poll_timeout(phy->regs + PHY_REG(34), val,
 				 val & REG34_PLL_LOCK, 50, 20000);
 	if (ret)
 		dev_err(phy->dev, "PLL failed to lock\n");
-- 
2.43.0



From aford173 at gmail.com  Thu Aug 29 20:24:26 2024
From: aford173 at gmail.com (Adam Ford)
Date: Thu, 29 Aug 2024 22:24:26 -0500
Subject: [RFC V3 2/3] phy: freescale: fsl-samsung-hdmi: Simplify REG21_PMS_S_MASK lookup
In-Reply-To: <20240830032442.226031-1-aford173@gmail.com>
References: <20240830032442.226031-1-aford173@gmail.com>
Message-ID: <20240830032442.226031-2-aford173@gmail.com>

The value of 'S' is writen to two places, PHY_REG3[7:4] and
PHY_REG21[3:0].  There is a lookup table which contains
the value of PHY_REG3.  Rather than using a switch statement
based on the pixel clock to search for the value of 'S' again,
just shift the contents of PHY_REG3[7:4] >> 4 and place the value
in PHY_REG21[3:0].  Doing this can eliminate an entire function.

Signed-off-by: Adam Ford <aford173 at gmail.com>
---
V3: New to series

diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
index bc5d3625ece6..a700a300dc6f 100644
--- a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
+++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
@@ -355,40 +355,6 @@ to_fsl_samsung_hdmi_phy(struct clk_hw *hw)
 	return container_of(hw, struct fsl_samsung_hdmi_phy, hw);
 }
 
-static void
-fsl_samsung_hdmi_phy_configure_pixclk(struct fsl_samsung_hdmi_phy *phy,
-				      const struct phy_config *cfg)
-{
-	u8 div = 0x1;
-
-	switch (cfg->pixclk) {
-	case  22250000 ...  33750000:
-		div = 0xf;
-		break;
-	case  35000000 ...  40000000:
-		div = 0xb;
-		break;
-	case  43200000 ...  47500000:
-		div = 0x9;
-		break;
-	case  50349650 ...  63500000:
-		div = 0x7;
-		break;
-	case  67500000 ...  90000000:
-		div = 0x5;
-		break;
-	case  94000000 ... 148500000:
-		div = 0x3;
-		break;
-	case 154000000 ... 297000000:
-		div = 0x1;
-		break;
-	}
-
-	writeb(REG21_SEL_TX_CK_INV | FIELD_PREP(REG21_PMS_S_MASK, div),
-	       phy->regs + PHY_REG(21));
-}
-
 static void
 fsl_samsung_hdmi_phy_configure_pll_lock_det(struct fsl_samsung_hdmi_phy *phy,
 					    const struct phy_config *cfg)
@@ -457,7 +423,10 @@ static int fsl_samsung_hdmi_phy_configure(struct fsl_samsung_hdmi_phy *phy,
 	for (i = 0; i < PHY_PLL_DIV_REGS_NUM; i++)
 		writeb(cfg->pll_div_regs[i], phy->regs + PHY_REG(2) + i * 4);
 
-	fsl_samsung_hdmi_phy_configure_pixclk(phy, cfg);
+	/* High nibble of pll_div_regs[1] contains S which also gets written to REG21 */
+	writeb(REG21_SEL_TX_CK_INV | FIELD_PREP(REG21_PMS_S_MASK,
+	       cfg->pll_div_regs[1] >> 4), phy->regs + PHY_REG(21));
+
 	fsl_samsung_hdmi_phy_configure_pll_lock_det(phy, cfg);
 
 	writeb(REG33_FIX_DA | REG33_MODE_SET_DONE, phy->regs + PHY_REG(33));
-- 
2.43.0



From aford173 at gmail.com  Thu Aug 29 20:24:27 2024
From: aford173 at gmail.com (Adam Ford)
Date: Thu, 29 Aug 2024 22:24:27 -0500
Subject: [RFC V3 3/3] phy: freescale: fsl-samsung-hdmi: Support dynamic integer
In-Reply-To: <20240830032442.226031-1-aford173@gmail.com>
References: <20240830032442.226031-1-aford173@gmail.com>
Message-ID: <20240830032442.226031-3-aford173@gmail.com>

There is currently a look-up table for a variety of resolutions.
Since the phy has the ability to dynamically calculate the values
necessary to use the intger divider which should allow more
resolutions without having to update the look-up-table.

If the lookup table cannot find an exact match, fall back to the
dynamic calculator of the integer divider.

Previously, the value of P was hard-coded to 1, this required an
update to the phy_pll_cfg table to add in the extra value into the
table, so if the value of P is calculated to be something else
by the PMS calculator, the calculated_phy_pll_cfg structure
can be used instead without having to keep track of which method
was used.

Signed-off-by: Adam Ford <aford173 at gmail.com>
---
V3:  Change size of pll_div_regs to include PHY_REG01 (P)
     Create calculated_phy_pll_cfg to containe the values
     Eliminate the PMS calculation from fsl_samsung_hdmi_phy_configure
     Make the LUT primary and fall back to integer calculator in
     phy_clk_round_rate.
     Check the range right away to ensure it's reaonsable rather than
     trying to find a clock only to learn it's outside the range.
     Overall added notes and comments where stuff may not be intuitive.

V2:  Update phy_clk_round_rate and phy_clk_set_rate to both support
     the integer clock PMS calculator.

diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
index a700a300dc6f..3fab40cde40d 100644
--- a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
+++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
@@ -16,6 +16,8 @@
 
 #define PHY_REG(reg)		(reg * 4)
 
+#define REG01_PMS_P_MASK	GENMASK(3, 0)
+#define REG03_PMS_S_MASK	GENMASK(7, 4)
 #define REG12_CK_DIV_MASK	GENMASK(5, 4)
 #define REG13_TG_CODE_LOW_MASK	GENMASK(7, 0)
 #define REG14_TOL_MASK		GENMASK(7, 4)
@@ -29,281 +31,296 @@
 #define REG34_PLL_LOCK		BIT(6)
 #define REG34_PHY_CLK_READY	BIT(5)
 
-#define PHY_PLL_DIV_REGS_NUM 6
+#ifndef MHZ
+#define MHZ	(1000UL * 1000UL)
+#endif
+
+#define PHY_PLL_DIV_REGS_NUM 7
 
 struct phy_config {
 	u32	pixclk;
 	u8	pll_div_regs[PHY_PLL_DIV_REGS_NUM];
 };
 
+/*
+ * The calculated_phy_pll_cfg only handles integer divider for PMS only,
+ * meaning the last four entries will be fixed, but the first three will
+ * be calculated by the PMS calculator
+ */
+static struct phy_config calculated_phy_pll_cfg = {
+	.pixclk = 0,
+	.pll_div_regs = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0x00 },
+};
+
+/* The lookup table contains values for which the fractional divder is used */
 static const struct phy_config phy_pll_cfg[] = {
 	{
 		.pixclk = 22250000,
-		.pll_div_regs = { 0x4b, 0xf1, 0x89, 0x88, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x4b, 0xf1, 0x89, 0x88, 0x80, 0x40 },
 	}, {
 		.pixclk = 23750000,
-		.pll_div_regs = { 0x50, 0xf1, 0x86, 0x85, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x50, 0xf1, 0x86, 0x85, 0x80, 0x40 },
 	}, {
 		.pixclk = 24000000,
-		.pll_div_regs = { 0x50, 0xf0, 0x00, 0x00, 0x80, 0x00 },
+		.pll_div_regs = { 0xd1, 0x50, 0xf0, 0x00, 0x00, 0x80, 0x00 },
 	}, {
 		.pixclk = 24024000,
-		.pll_div_regs = { 0x50, 0xf1, 0x99, 0x02, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x50, 0xf1, 0x99, 0x02, 0x80, 0x40 },
 	}, {
 		.pixclk = 25175000,
-		.pll_div_regs = { 0x54, 0xfc, 0xcc, 0x91, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x54, 0xfc, 0xcc, 0x91, 0x80, 0x40 },
 	}, {
 		.pixclk = 25200000,
-		.pll_div_regs = { 0x54, 0xf0, 0x00, 0x00, 0x80, 0x00 },
+		.pll_div_regs = { 0xd1, 0x54, 0xf0, 0x00, 0x00, 0x80, 0x00 },
 	}, {
 		.pixclk = 26750000,
-		.pll_div_regs = { 0x5a, 0xf2, 0x89, 0x88, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x5a, 0xf2, 0x89, 0x88, 0x80, 0x40 },
 	}, {
 		.pixclk = 27000000,
-		.pll_div_regs = { 0x5a, 0xf0, 0x00, 0x00, 0x80, 0x00 },
+		.pll_div_regs = { 0xd1, 0x5a, 0xf0, 0x00, 0x00, 0x80, 0x00 },
 	}, {
 		.pixclk = 27027000,
-		.pll_div_regs = { 0x5a, 0xf2, 0xfd, 0x0c, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x5a, 0xf2, 0xfd, 0x0c, 0x80, 0x40 },
 	}, {
 		.pixclk = 29500000,
-		.pll_div_regs = { 0x62, 0xf4, 0x95, 0x08, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x62, 0xf4, 0x95, 0x08, 0x80, 0x40 },
 	}, {
 		.pixclk = 30750000,
-		.pll_div_regs = { 0x66, 0xf4, 0x82, 0x01, 0x88, 0x45 },
+		.pll_div_regs = { 0xd1, 0x66, 0xf4, 0x82, 0x01, 0x88, 0x45 },
 	}, {
 		.pixclk = 30888000,
-		.pll_div_regs = { 0x66, 0xf4, 0x99, 0x18, 0x88, 0x45 },
+		.pll_div_regs = { 0xd1, 0x66, 0xf4, 0x99, 0x18, 0x88, 0x45 },
 	}, {
 		.pixclk = 33750000,
-		.pll_div_regs = { 0x70, 0xf4, 0x82, 0x01, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x70, 0xf4, 0x82, 0x01, 0x80, 0x40 },
 	}, {
 		.pixclk = 35000000,
-		.pll_div_regs = { 0x58, 0xb8, 0x8b, 0x88, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x58, 0xb8, 0x8b, 0x88, 0x80, 0x40 },
 	}, {
 		.pixclk = 36000000,
-		.pll_div_regs = { 0x5a, 0xb0, 0x00, 0x00, 0x80, 0x00 },
+		.pll_div_regs = { 0xd1, 0x5a, 0xb0, 0x00, 0x00, 0x80, 0x00 },
 	}, {
 		.pixclk = 36036000,
-		.pll_div_regs = { 0x5a, 0xb2, 0xfd, 0x0c, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x5a, 0xb2, 0xfd, 0x0c, 0x80, 0x40 },
 	}, {
 		.pixclk = 40000000,
-		.pll_div_regs = { 0x64, 0xb0, 0x00, 0x00, 0x80, 0x00 },
+		.pll_div_regs = { 0xd1, 0x64, 0xb0, 0x00, 0x00, 0x80, 0x00 },
 	}, {
 		.pixclk = 43200000,
-		.pll_div_regs = { 0x5a, 0x90, 0x00, 0x00, 0x80, 0x00 },
+		.pll_div_regs = { 0xd1, 0x5a, 0x90, 0x00, 0x00, 0x80, 0x00 },
 	}, {
 		.pixclk = 43243200,
-		.pll_div_regs = { 0x5a, 0x92, 0xfd, 0x0c, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x5a, 0x92, 0xfd, 0x0c, 0x80, 0x40 },
 	}, {
 		.pixclk = 44500000,
-		.pll_div_regs = { 0x5c, 0x92, 0x98, 0x11, 0x84, 0x41 },
+		.pll_div_regs = { 0xd1, 0x5c, 0x92, 0x98, 0x11, 0x84, 0x41 },
 	}, {
 		.pixclk = 47000000,
-		.pll_div_regs = { 0x62, 0x94, 0x95, 0x82, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x62, 0x94, 0x95, 0x82, 0x80, 0x40 },
 	}, {
 		.pixclk = 47500000,
-		.pll_div_regs = { 0x63, 0x96, 0xa1, 0x82, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x63, 0x96, 0xa1, 0x82, 0x80, 0x40 },
 	}, {
 		.pixclk = 50349650,
-		.pll_div_regs = { 0x54, 0x7c, 0xc3, 0x8f, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x54, 0x7c, 0xc3, 0x8f, 0x80, 0x40 },
 	}, {
 		.pixclk = 50400000,
-		.pll_div_regs = { 0x54, 0x70, 0x00, 0x00, 0x80, 0x00 },
+		.pll_div_regs = { 0xd1, 0x54, 0x70, 0x00, 0x00, 0x80, 0x00 },
 	}, {
 		.pixclk = 53250000,
-		.pll_div_regs = { 0x58, 0x72, 0x84, 0x03, 0x82, 0x41 },
+		.pll_div_regs = { 0xd1, 0x58, 0x72, 0x84, 0x03, 0x82, 0x41 },
 	}, {
 		.pixclk = 53500000,
-		.pll_div_regs = { 0x5a, 0x72, 0x89, 0x88, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x5a, 0x72, 0x89, 0x88, 0x80, 0x40 },
 	}, {
 		.pixclk = 54000000,
-		.pll_div_regs = { 0x5a, 0x70, 0x00, 0x00, 0x80, 0x00 },
+		.pll_div_regs = { 0xd1, 0x5a, 0x70, 0x00, 0x00, 0x80, 0x00 },
 	}, {
 		.pixclk = 54054000,
-		.pll_div_regs = { 0x5a, 0x72, 0xfd, 0x0c, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x5a, 0x72, 0xfd, 0x0c, 0x80, 0x40 },
 	}, {
 		.pixclk = 59000000,
-		.pll_div_regs = { 0x62, 0x74, 0x95, 0x08, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x62, 0x74, 0x95, 0x08, 0x80, 0x40 },
 	}, {
 		.pixclk = 59340659,
-		.pll_div_regs = { 0x62, 0x74, 0xdb, 0x52, 0x88, 0x47 },
+		.pll_div_regs = { 0xd1, 0x62, 0x74, 0xdb, 0x52, 0x88, 0x47 },
 	}, {
 		.pixclk = 59400000,
-		.pll_div_regs = { 0x63, 0x70, 0x00, 0x00, 0x80, 0x00 },
+		.pll_div_regs = { 0xd1, 0x63, 0x70, 0x00, 0x00, 0x80, 0x00 },
 	}, {
 		.pixclk = 61500000,
-		.pll_div_regs = { 0x66, 0x74, 0x82, 0x01, 0x88, 0x45 },
+		.pll_div_regs = { 0xd1, 0x66, 0x74, 0x82, 0x01, 0x88, 0x45 },
 	}, {
 		.pixclk = 63500000,
-		.pll_div_regs = { 0x69, 0x74, 0x89, 0x08, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x69, 0x74, 0x89, 0x08, 0x80, 0x40 },
 	}, {
 		.pixclk = 67500000,
-		.pll_div_regs = { 0x54, 0x52, 0x87, 0x03, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x54, 0x52, 0x87, 0x03, 0x80, 0x40 },
 	}, {
 		.pixclk = 70000000,
-		.pll_div_regs = { 0x58, 0x58, 0x8b, 0x88, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x58, 0x58, 0x8b, 0x88, 0x80, 0x40 },
 	}, {
 		.pixclk = 72000000,
-		.pll_div_regs = { 0x5a, 0x50, 0x00, 0x00, 0x80, 0x00 },
+		.pll_div_regs = { 0xd1, 0x5a, 0x50, 0x00, 0x00, 0x80, 0x00 },
 	}, {
 		.pixclk = 72072000,
-		.pll_div_regs = { 0x5a, 0x52, 0xfd, 0x0c, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x5a, 0x52, 0xfd, 0x0c, 0x80, 0x40 },
 	}, {
 		.pixclk = 74176000,
-		.pll_div_regs = { 0x5d, 0x58, 0xdb, 0xA2, 0x88, 0x41 },
+		.pll_div_regs = { 0xd1, 0x5d, 0x58, 0xdb, 0xA2, 0x88, 0x41 },
 	}, {
 		.pixclk = 74250000,
-		.pll_div_regs = { 0x5c, 0x52, 0x90, 0x0d, 0x84, 0x41 },
+		.pll_div_regs = { 0xd1, 0x5c, 0x52, 0x90, 0x0d, 0x84, 0x41 },
 	}, {
 		.pixclk = 78500000,
-		.pll_div_regs = { 0x62, 0x54, 0x87, 0x01, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x62, 0x54, 0x87, 0x01, 0x80, 0x40 },
 	}, {
 		.pixclk = 80000000,
-		.pll_div_regs = { 0x64, 0x50, 0x00, 0x00, 0x80, 0x00 },
+		.pll_div_regs = { 0xd1, 0x64, 0x50, 0x00, 0x00, 0x80, 0x00 },
 	}, {
 		.pixclk = 82000000,
-		.pll_div_regs = { 0x66, 0x54, 0x82, 0x01, 0x88, 0x45 },
+		.pll_div_regs = { 0xd1, 0x66, 0x54, 0x82, 0x01, 0x88, 0x45 },
 	}, {
 		.pixclk = 82500000,
-		.pll_div_regs = { 0x67, 0x54, 0x88, 0x01, 0x90, 0x49 },
+		.pll_div_regs = { 0xd1, 0x67, 0x54, 0x88, 0x01, 0x90, 0x49 },
 	}, {
 		.pixclk = 89000000,
-		.pll_div_regs = { 0x70, 0x54, 0x84, 0x83, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x70, 0x54, 0x84, 0x83, 0x80, 0x40 },
 	}, {
 		.pixclk = 90000000,
-		.pll_div_regs = { 0x70, 0x54, 0x82, 0x01, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x70, 0x54, 0x82, 0x01, 0x80, 0x40 },
 	}, {
 		.pixclk = 94000000,
-		.pll_div_regs = { 0x4e, 0x32, 0xa7, 0x10, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x4e, 0x32, 0xa7, 0x10, 0x80, 0x40 },
 	}, {
 		.pixclk = 95000000,
-		.pll_div_regs = { 0x50, 0x31, 0x86, 0x85, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x50, 0x31, 0x86, 0x85, 0x80, 0x40 },
 	}, {
 		.pixclk = 98901099,
-		.pll_div_regs = { 0x52, 0x3a, 0xdb, 0x4c, 0x88, 0x47 },
+		.pll_div_regs = { 0xd1, 0x52, 0x3a, 0xdb, 0x4c, 0x88, 0x47 },
 	}, {
 		.pixclk = 99000000,
-		.pll_div_regs = { 0x52, 0x32, 0x82, 0x01, 0x88, 0x47 },
+		.pll_div_regs = { 0xd1, 0x52, 0x32, 0x82, 0x01, 0x88, 0x47 },
 	}, {
 		.pixclk = 100699300,
-		.pll_div_regs = { 0x54, 0x3c, 0xc3, 0x8f, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x54, 0x3c, 0xc3, 0x8f, 0x80, 0x40 },
 	}, {
 		.pixclk = 100800000,
-		.pll_div_regs = { 0x54, 0x30, 0x00, 0x00, 0x80, 0x00 },
+		.pll_div_regs = { 0xd1, 0x54, 0x30, 0x00, 0x00, 0x80, 0x00 },
 	}, {
 		.pixclk = 102500000,
-		.pll_div_regs = { 0x55, 0x32, 0x8c, 0x05, 0x90, 0x4b },
+		.pll_div_regs = { 0xd1, 0x55, 0x32, 0x8c, 0x05, 0x90, 0x4b },
 	}, {
 		.pixclk = 104750000,
-		.pll_div_regs = { 0x57, 0x32, 0x98, 0x07, 0x90, 0x49 },
+		.pll_div_regs = { 0xd1, 0x57, 0x32, 0x98, 0x07, 0x90, 0x49 },
 	}, {
 		.pixclk = 106500000,
-		.pll_div_regs = { 0x58, 0x32, 0x84, 0x03, 0x82, 0x41 },
+		.pll_div_regs = { 0xd1, 0x58, 0x32, 0x84, 0x03, 0x82, 0x41 },
 	}, {
 		.pixclk = 107000000,
-		.pll_div_regs = { 0x5a, 0x32, 0x89, 0x88, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x5a, 0x32, 0x89, 0x88, 0x80, 0x40 },
 	}, {
 		.pixclk = 108000000,
-		.pll_div_regs = { 0x5a, 0x30, 0x00, 0x00, 0x80, 0x00 },
+		.pll_div_regs = { 0xd1, 0x5a, 0x30, 0x00, 0x00, 0x80, 0x00 },
 	}, {
 		.pixclk = 108108000,
-		.pll_div_regs = { 0x5a, 0x32, 0xfd, 0x0c, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x5a, 0x32, 0xfd, 0x0c, 0x80, 0x40 },
 	}, {
 		.pixclk = 118000000,
-		.pll_div_regs = { 0x62, 0x34, 0x95, 0x08, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x62, 0x34, 0x95, 0x08, 0x80, 0x40 },
 	}, {
 		.pixclk = 118800000,
-		.pll_div_regs = { 0x63, 0x30, 0x00, 0x00, 0x80, 0x00 },
+		.pll_div_regs = { 0xd1, 0x63, 0x30, 0x00, 0x00, 0x80, 0x00 },
 	}, {
 		.pixclk = 123000000,
-		.pll_div_regs = { 0x66, 0x34, 0x82, 0x01, 0x88, 0x45 },
+		.pll_div_regs = { 0xd1, 0x66, 0x34, 0x82, 0x01, 0x88, 0x45 },
 	}, {
 		.pixclk = 127000000,
-		.pll_div_regs = { 0x69, 0x34, 0x89, 0x08, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x69, 0x34, 0x89, 0x08, 0x80, 0x40 },
 	}, {
 		.pixclk = 135000000,
-		.pll_div_regs = { 0x70, 0x34, 0x82, 0x01, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x70, 0x34, 0x82, 0x01, 0x80, 0x40 },
 	}, {
 		.pixclk = 135580000,
-		.pll_div_regs = { 0x71, 0x39, 0xe9, 0x82, 0x9c, 0x5b },
+		.pll_div_regs = { 0xd1, 0x71, 0x39, 0xe9, 0x82, 0x9c, 0x5b },
 	}, {
 		.pixclk = 137520000,
-		.pll_div_regs = { 0x72, 0x38, 0x99, 0x10, 0x85, 0x41 },
+		.pll_div_regs = { 0xd1, 0x72, 0x38, 0x99, 0x10, 0x85, 0x41 },
 	}, {
 		.pixclk = 138750000,
-		.pll_div_regs = { 0x73, 0x35, 0x88, 0x05, 0x90, 0x4d },
+		.pll_div_regs = { 0xd1, 0x73, 0x35, 0x88, 0x05, 0x90, 0x4d },
 	}, {
 		.pixclk = 140000000,
-		.pll_div_regs = { 0x75, 0x36, 0xa7, 0x90, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x75, 0x36, 0xa7, 0x90, 0x80, 0x40 },
 	}, {
 		.pixclk = 144000000,
-		.pll_div_regs = { 0x78, 0x30, 0x00, 0x00, 0x80, 0x00 },
+		.pll_div_regs = { 0xd1, 0x78, 0x30, 0x00, 0x00, 0x80, 0x00 },
 	}, {
 		.pixclk = 148352000,
-		.pll_div_regs = { 0x7b, 0x35, 0xdb, 0x39, 0x90, 0x45 },
+		.pll_div_regs = { 0xd1, 0x7b, 0x35, 0xdb, 0x39, 0x90, 0x45 },
 	}, {
 		.pixclk = 148500000,
-		.pll_div_regs = { 0x7b, 0x35, 0x84, 0x03, 0x90, 0x45 },
+		.pll_div_regs = { 0xd1, 0x7b, 0x35, 0x84, 0x03, 0x90, 0x45 },
 	}, {
 		.pixclk = 154000000,
-		.pll_div_regs = { 0x40, 0x18, 0x83, 0x01, 0x00, 0x40 },
+		.pll_div_regs = { 0xd1, 0x40, 0x18, 0x83, 0x01, 0x00, 0x40 },
 	}, {
 		.pixclk = 157000000,
-		.pll_div_regs = { 0x41, 0x11, 0xa7, 0x14, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x41, 0x11, 0xa7, 0x14, 0x80, 0x40 },
 	}, {
 		.pixclk = 160000000,
-		.pll_div_regs = { 0x42, 0x12, 0xa1, 0x20, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x42, 0x12, 0xa1, 0x20, 0x80, 0x40 },
 	}, {
 		.pixclk = 162000000,
-		.pll_div_regs = { 0x43, 0x18, 0x8b, 0x08, 0x96, 0x55 },
+		.pll_div_regs = { 0xd1, 0x43, 0x18, 0x8b, 0x08, 0x96, 0x55 },
 	}, {
 		.pixclk = 164000000,
-		.pll_div_regs = { 0x45, 0x11, 0x83, 0x82, 0x90, 0x4b },
+		.pll_div_regs = { 0xd1, 0x45, 0x11, 0x83, 0x82, 0x90, 0x4b },
 	}, {
 		.pixclk = 165000000,
-		.pll_div_regs = { 0x45, 0x11, 0x84, 0x81, 0x90, 0x4b },
+		.pll_div_regs = { 0xd1, 0x45, 0x11, 0x84, 0x81, 0x90, 0x4b },
 	}, {
 		.pixclk = 180000000,
-		.pll_div_regs = { 0x4b, 0x10, 0x00, 0x00, 0x80, 0x00 },
+		.pll_div_regs = { 0xd1, 0x4b, 0x10, 0x00, 0x00, 0x80, 0x00 },
 	}, {
 		.pixclk = 185625000,
-		.pll_div_regs = { 0x4e, 0x12, 0x9a, 0x95, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x4e, 0x12, 0x9a, 0x95, 0x80, 0x40 },
 	}, {
 		.pixclk = 188000000,
-		.pll_div_regs = { 0x4e, 0x12, 0xa7, 0x10, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x4e, 0x12, 0xa7, 0x10, 0x80, 0x40 },
 	}, {
 		.pixclk = 198000000,
-		.pll_div_regs = { 0x52, 0x12, 0x82, 0x01, 0x88, 0x47 },
+		.pll_div_regs = { 0xd1, 0x52, 0x12, 0x82, 0x01, 0x88, 0x47 },
 	}, {
 		.pixclk = 205000000,
-		.pll_div_regs = { 0x55, 0x12, 0x8c, 0x05, 0x90, 0x4b },
+		.pll_div_regs = { 0xd1, 0x55, 0x12, 0x8c, 0x05, 0x90, 0x4b },
 	}, {
 		.pixclk = 209500000,
-		.pll_div_regs = { 0x57, 0x12, 0x98, 0x07, 0x90, 0x49 },
+		.pll_div_regs = { 0xd1, 0x57, 0x12, 0x98, 0x07, 0x90, 0x49 },
 	}, {
 		.pixclk = 213000000,
-		.pll_div_regs = { 0x58, 0x12, 0x84, 0x03, 0x82, 0x41 },
+		.pll_div_regs = { 0xd1, 0x58, 0x12, 0x84, 0x03, 0x82, 0x41 },
 	}, {
 		.pixclk = 216000000,
-		.pll_div_regs = { 0x5a, 0x10, 0x00, 0x00, 0x80, 0x00 },
+		.pll_div_regs = { 0xd1, 0x5a, 0x10, 0x00, 0x00, 0x80, 0x00 },
 	}, {
 		.pixclk = 216216000,
-		.pll_div_regs = { 0x5a, 0x12, 0xfd, 0x0c, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x5a, 0x12, 0xfd, 0x0c, 0x80, 0x40 },
 	}, {
 		.pixclk = 237600000,
-		.pll_div_regs = { 0x63, 0x10, 0x00, 0x00, 0x80, 0x00 },
+		.pll_div_regs = { 0xd1, 0x63, 0x10, 0x00, 0x00, 0x80, 0x00 },
 	}, {
 		.pixclk = 254000000,
-		.pll_div_regs = { 0x69, 0x14, 0x89, 0x08, 0x80, 0x40 },
+		.pll_div_regs = { 0xd1, 0x69, 0x14, 0x89, 0x08, 0x80, 0x40 },
 	}, {
 		.pixclk = 277500000,
-		.pll_div_regs = { 0x73, 0x15, 0x88, 0x05, 0x90, 0x4d },
+		.pll_div_regs = { 0xd1, 0x73, 0x15, 0x88, 0x05, 0x90, 0x4d },
 	}, {
 		.pixclk = 288000000,
-		.pll_div_regs = { 0x78, 0x10, 0x00, 0x00, 0x80, 0x00 },
+		.pll_div_regs = { 0xd1, 0x78, 0x10, 0x00, 0x00, 0x80, 0x00 },
 	}, {
 		.pixclk = 297000000,
-		.pll_div_regs = { 0x7b, 0x15, 0x84, 0x03, 0x90, 0x45 },
+		.pll_div_regs = { 0xd1, 0x7b, 0x15, 0x84, 0x03, 0x90, 0x45 },
 	},
 };
 
@@ -313,7 +330,8 @@ struct reg_settings {
 };
 
 static const struct reg_settings common_phy_cfg[] = {
-	{ PHY_REG(0), 0x00 }, { PHY_REG(1), 0xd1 },
+	{ PHY_REG(0), 0x00 },
+	/* PHY_REG(1-7) pix clk specific */
 	{ PHY_REG(8), 0x4f }, { PHY_REG(9), 0x30 },
 	{ PHY_REG(10), 0x33 }, { PHY_REG(11), 0x65 },
 	/* REG12 pixclk specific */
@@ -406,6 +424,76 @@ fsl_samsung_hdmi_phy_configure_pll_lock_det(struct fsl_samsung_hdmi_phy *phy,
 	       phy->regs + PHY_REG(14));
 }
 
+static unsigned long fsl_samsung_hdmi_phy_find_pms(unsigned long fout, u8 *p, u16 *m, u8 *s)
+{
+	unsigned long best_freq = 0;
+	u32 min_delta = 0xffffffff;
+	u8 _p, best_p;
+	u16 _m, best_m;
+	u8 _s, best_s;
+
+	/* The ref manual states the values of 'P' rannge from 1 to 11 */
+	for (_p = 1; _p <= 11; ++_p) {
+		for (_s = 1; _s <= 16; ++_s) {
+			u64 tmp;
+			u32 delta;
+
+			/* s must be one or even */
+			if (_s > 1 && (_s & 0x01) == 1)
+				_s++;
+
+			/* _s cannot be 14 per the TRM */
+			if (_s == 14)
+				continue;
+
+			/*
+			 * TODO: Ref Manual doesn't state the range of _m
+			 * so this should be further refined if possible.
+			 * This range was set based on the original values
+			 * in the look-up table
+			 */
+			tmp = (u64)fout * (_p * _s);
+			do_div(tmp, 24 * MHZ);
+			_m = tmp;
+			if (_m < 0x30 || _m > 0x7b)
+				continue;
+
+			/*
+			 * Rev 2 of the Ref Manual states the
+			 * VCO can range between 750MHz and
+			 * 3GHz.  The VCO is assumed to be _m x
+			 * the reference frequency of 24MHz divided
+			 * by the prescaler, _p
+			 */
+			tmp = (u64)_m * 24 * MHZ;
+			do_div(tmp, _p);
+			if (tmp < 750 * MHZ ||
+			    tmp > 3000 * MHZ)
+				continue;
+
+			tmp = (u64)_m * 24 * MHZ;
+			do_div(tmp, _p * _s);
+
+			delta = abs(fout - tmp);
+			if (delta < min_delta) {
+				best_p = _p;
+				best_s = _s;
+				best_m = _m;
+				min_delta = delta;
+				best_freq = tmp;
+			}
+		}
+	}
+
+	if (best_freq) {
+		*p = best_p;
+		*m = best_m;
+		*s = best_s;
+	}
+
+	return best_freq;
+}
+
 static int fsl_samsung_hdmi_phy_configure(struct fsl_samsung_hdmi_phy *phy,
 					  const struct phy_config *cfg)
 {
@@ -419,13 +507,13 @@ static int fsl_samsung_hdmi_phy_configure(struct fsl_samsung_hdmi_phy *phy,
 	for (i = 0; i < ARRAY_SIZE(common_phy_cfg); i++)
 		writeb(common_phy_cfg[i].val, phy->regs + common_phy_cfg[i].reg);
 
-	/* set individual PLL registers PHY_REG2 ... PHY_REG7 */
+	/* set individual PLL registers PHY_REG1 ... PHY_REG7 */
 	for (i = 0; i < PHY_PLL_DIV_REGS_NUM; i++)
-		writeb(cfg->pll_div_regs[i], phy->regs + PHY_REG(2) + i * 4);
+		writeb(cfg->pll_div_regs[i], phy->regs + PHY_REG(1) + i * 4);
 
-	/* High nibble of pll_div_regs[1] contains S which also gets written to REG21 */
+	/* High nibble of PHY_REG3 and low nibble of PHY_REG21 both contain 'S' */
 	writeb(REG21_SEL_TX_CK_INV | FIELD_PREP(REG21_PMS_S_MASK,
-	       cfg->pll_div_regs[1] >> 4), phy->regs + PHY_REG(21));
+	       cfg->pll_div_regs[2] >> 4), phy->regs + PHY_REG(21));
 
 	fsl_samsung_hdmi_phy_configure_pll_lock_det(phy, cfg);
 
@@ -453,29 +541,70 @@ static unsigned long phy_clk_recalc_rate(struct clk_hw *hw,
 static long phy_clk_round_rate(struct clk_hw *hw,
 			       unsigned long rate, unsigned long *parent_rate)
 {
+	u32 int_div_clk;
 	int i;
+	u16 m;
+	u8 p, s;
+
+	/* If the clock is out of range return error instead of searching */
+	if (rate > 297000000 || rate < 22250000)
+		return -EINVAL;
 
+	/* Check the look-up table */
 	for (i = ARRAY_SIZE(phy_pll_cfg) - 1; i >= 0; i--)
 		if (phy_pll_cfg[i].pixclk <= rate)
-			return phy_pll_cfg[i].pixclk;
+			break;
+	/* If the rate is an exact match, return it now */
+	if (rate == phy_pll_cfg[i].pixclk)
+		return phy_pll_cfg[i].pixclk;
+
+	/*
+	 * The math on the lookup table shows the PMS math yields a
+	 * frequency 5 x pixclk.
+	 * When we check the integer divider against the desired rate,
+	 * multiply the rate x 5 and then divide the outcome by 5.
+	 */
+	int_div_clk = fsl_samsung_hdmi_phy_find_pms(rate * 5, &p, &m, &s) / 5;
 
-	return -EINVAL;
+	/* If the rate is an exact match, return it now */
+	if (int_div_clk == rate)
+		return int_div_clk;
+
+	/* Fall back to the closest value in the LUT */
+	return phy_pll_cfg[i].pixclk;
 }
 
 static int phy_clk_set_rate(struct clk_hw *hw,
 			    unsigned long rate, unsigned long parent_rate)
 {
 	struct fsl_samsung_hdmi_phy *phy = to_fsl_samsung_hdmi_phy(hw);
+	u32 int_div_clk;
 	int i;
-
-	for (i = ARRAY_SIZE(phy_pll_cfg) - 1; i >= 0; i--)
-		if (phy_pll_cfg[i].pixclk <= rate)
-			break;
-
-	if (i < 0)
-		return -EINVAL;
-
-	phy->cur_cfg = &phy_pll_cfg[i];
+	u16 m;
+	u8 p, s;
+
+	/* If the integer divider works, just use it */
+	int_div_clk = fsl_samsung_hdmi_phy_find_pms(rate * 5, &p, &m, &s) / 5;
+	if (int_div_clk == rate) {
+		dev_dbg(phy->dev, "fsl_samsung_hdmi_phy: using integer divider\n");
+		calculated_phy_pll_cfg.pixclk = int_div_clk;
+		calculated_phy_pll_cfg.pll_div_regs[0] = FIELD_PREP(REG01_PMS_P_MASK, p);
+		calculated_phy_pll_cfg.pll_div_regs[1] = m;
+		calculated_phy_pll_cfg.pll_div_regs[2] = FIELD_PREP(REG03_PMS_S_MASK, s-1);
+		/* pll_div_regs 3-6 are fixed and pre-defined already */
+		phy->cur_cfg  = &calculated_phy_pll_cfg;
+	} else {
+		/* Otherwise, search the LUT */
+		dev_dbg(phy->dev, "fsl_samsung_hdmi_phy: using fractional divider\n");
+		for (i = ARRAY_SIZE(phy_pll_cfg) - 1; i >= 0; i--)
+			if (phy_pll_cfg[i].pixclk <= rate)
+				break;
+
+		if (i < 0)
+			return -EINVAL;
+
+		phy->cur_cfg = &phy_pll_cfg[i];
+	}
 
 	return fsl_samsung_hdmi_phy_configure(phy, phy->cur_cfg);
 }
-- 
2.43.0



From dominique.martinet at atmark-techno.com  Thu Aug 29 22:56:22 2024
From: dominique.martinet at atmark-techno.com (Dominique Martinet)
Date: Fri, 30 Aug 2024 14:56:22 +0900
Subject: [RFC V3 3/3] phy: freescale: fsl-samsung-hdmi: Support dynamic
 integer
In-Reply-To: <20240830032442.226031-3-aford173@gmail.com>
References: <20240830032442.226031-1-aford173@gmail.com>
 <20240830032442.226031-3-aford173@gmail.com>
Message-ID: <ZtFfBs4HEShmJKsi@atmark-techno.com>

Adam Ford wrote on Thu, Aug 29, 2024 at 10:24:27PM -0500:
> There is currently a look-up table for a variety of resolutions.
> Since the phy has the ability to dynamically calculate the values
> necessary to use the intger divider which should allow more
> resolutions without having to update the look-up-table.
> 
> If the lookup table cannot find an exact match, fall back to the
> dynamic calculator of the integer divider.
> 
> Previously, the value of P was hard-coded to 1, this required an
> update to the phy_pll_cfg table to add in the extra value into the
> table, so if the value of P is calculated to be something else
> by the PMS calculator, the calculated_phy_pll_cfg structure
> can be used instead without having to keep track of which method
> was used.

Thank you!

I've updated to v3 and we must have missed something fiddling with v1
but our 31.5MHz-only screen turns on with this!

Unfortunately among the other odd devices we support, there's one
whose native resolution only supports 83.5MHz, and that doesn't come out
right with the integer divider (that function returns 83.2MHz, which is
0.4%off)
If we force the round/set rate functions to prefer the calculated value
and allow that in imx8mp_hdmi_check_clk_rate (dw_hdmi-imx.c) then it
also works, so I don't think we actually need to affine the model...
Coming back to what Lucas replied to my initial mail HDMI would also a
rate mismatch of ?0.5%, so the integer calculator works for all the
frequencies we've currently added manually if we fix the check to allow
that as well:
32000000: found 32000000 (100.0% match): p 1 / m 80 / s 12
51200000: found 51200000 (100.0% match): p 1 / m 64 / s 6
65000000: found 64800000 (99.6% match): p 1 / m 54 / s 4
71000000: found 70800000 (99.7% match): p 1 / m 59 / s 4
83500000: found 83200000 (99.6% match): p 1 / m 104 / s 6

(only actually tested 51.2 and 83.5 here, we don't have all the hardware
available; I'll try to play with normal monitors that support more modes
once the patch gets further finalized)


So, as far as I'm concerned I'd be happy to move forward with that and
will backport this to our tree/remove our kludged values, would "just"
need to properly pick the closest value if no exact match instead of
always falling back to the table (or just remove the table altogether if
we can test a few monitors?)

A couple of style nitpicks below

> diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> index a700a300dc6f..3fab40cde40d 100644
> --- a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> +++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> @@ -16,6 +16,8 @@
>  
>  #define PHY_REG(reg)		(reg * 4)
>  
> +#define REG01_PMS_P_MASK	GENMASK(3, 0)
> +#define REG03_PMS_S_MASK	GENMASK(7, 4)
>  #define REG12_CK_DIV_MASK	GENMASK(5, 4)
>  #define REG13_TG_CODE_LOW_MASK	GENMASK(7, 0)
>  #define REG14_TOL_MASK		GENMASK(7, 4)
> @@ -29,281 +31,296 @@
>  #define REG34_PLL_LOCK		BIT(6)
>  #define REG34_PHY_CLK_READY	BIT(5)
>  
> -#define PHY_PLL_DIV_REGS_NUM 6
> +#ifndef MHZ
> +#define MHZ	(1000UL * 1000UL)
> +#endif
> +
> +#define PHY_PLL_DIV_REGS_NUM 7
>  
>  struct phy_config {
>  	u32	pixclk;
>  	u8	pll_div_regs[PHY_PLL_DIV_REGS_NUM];
>  };
>  
> +/*
> + * The calculated_phy_pll_cfg only handles integer divider for PMS only,
> + * meaning the last four entries will be fixed, but the first three will
> + * be calculated by the PMS calculator
> + */
> +static struct phy_config calculated_phy_pll_cfg = {

I'd change cur_cfg from pointer to the struct itself like this (partial
patch that probably won't even apply on your branch:)
----
diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
index 9048cdc760c2..d7124604819c 100644
--- a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
+++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
@@ -402,7 +402,7 @@ struct fsl_samsung_hdmi_phy {
 
 	/* clk provider */
 	struct clk_hw hw;
-	const struct phy_config *cur_cfg;
+	struct phy_config cur_cfg;
 };
 
 static inline struct fsl_samsung_hdmi_phy *
@@ -562,9 +562,9 @@ static int phy_clk_set_rate(struct clk_hw *hw,
 	if (i < 0)
 		return -EINVAL;
 
-	phy->cur_cfg = &phy_pll_cfg[i];
+	phy->cur_cfg = phy_pll_cfg[i];
 
-	return fsl_samsung_hdmi_phy_configure(phy, phy->cur_cfg);
+	return fsl_samsung_hdmi_phy_configure(phy, &phy->cur_cfg);
 }
 
 static const struct clk_ops phy_clk_ops = {
----

Then you can just set it directly for calculated values.
But conceptually it's the same, just one less indirection.

> @@ -406,6 +424,76 @@ fsl_samsung_hdmi_phy_configure_pll_lock_det(struct fsl_samsung_hdmi_phy *phy,
>  	       phy->regs + PHY_REG(14));
>  }
>  
> +static unsigned long fsl_samsung_hdmi_phy_find_pms(unsigned long fout, u8 *p, u16 *m, u8 *s)
> +{
> +	unsigned long best_freq = 0;
> +	u32 min_delta = 0xffffffff;
> +	u8 _p, best_p;
> +	u16 _m, best_m;
> +	u8 _s, best_s;
> +
> +	/* The ref manual states the values of 'P' rannge from 1 to 11 */

typo: range

> +	for (_p = 1; _p <= 11; ++_p) {
> +		for (_s = 1; _s <= 16; ++_s) {
> +			u64 tmp;
> +			u32 delta;
> +
> +			/* s must be one or even */
> +			if (_s > 1 && (_s & 0x01) == 1)
> +				_s++;
> +
> +			/* _s cannot be 14 per the TRM */
> +			if (_s == 14)
> +				continue;
> +
> +			/*
> +			 * TODO: Ref Manual doesn't state the range of _m
> +			 * so this should be further refined if possible.
> +			 * This range was set based on the original values
> +			 * in the look-up table
> +			 */
> +			tmp = (u64)fout * (_p * _s);
> +			do_div(tmp, 24 * MHZ);
> +			_m = tmp;
> +			if (_m < 0x30 || _m > 0x7b)
> +				continue;
> +
> +			/*
> +			 * Rev 2 of the Ref Manual states the
> +			 * VCO can range between 750MHz and
> +			 * 3GHz.  The VCO is assumed to be _m x
> +			 * the reference frequency of 24MHz divided
> +			 * by the prescaler, _p
> +			 */
> +			tmp = (u64)_m * 24 * MHZ;
> +			do_div(tmp, _p);
> +			if (tmp < 750 * MHZ ||
> +			    tmp > 3000 * MHZ)
> +				continue;
> +
> +			tmp = (u64)_m * 24 * MHZ;
> +			do_div(tmp, _p * _s);
> +
> +			delta = abs(fout - tmp);
> +			if (delta < min_delta) {
> +				best_p = _p;
> +				best_s = _s;
> +				best_m = _m;
> +				min_delta = delta;
> +				best_freq = tmp;
> +			}
> +		}
> +	}
> +
> +	if (best_freq) {
> +		*p = best_p;
> +		*m = best_m;
> +		*s = best_s;
> +	}
> +
> +	return best_freq;
> +}
> +
>  static int fsl_samsung_hdmi_phy_configure(struct fsl_samsung_hdmi_phy *phy,
>  					  const struct phy_config *cfg)
>  {
> @@ -419,13 +507,13 @@ static int fsl_samsung_hdmi_phy_configure(struct fsl_samsung_hdmi_phy *phy,
>  	for (i = 0; i < ARRAY_SIZE(common_phy_cfg); i++)
>  		writeb(common_phy_cfg[i].val, phy->regs + common_phy_cfg[i].reg);
>  
> -	/* set individual PLL registers PHY_REG2 ... PHY_REG7 */
> +	/* set individual PLL registers PHY_REG1 ... PHY_REG7 */
>  	for (i = 0; i < PHY_PLL_DIV_REGS_NUM; i++)
> -		writeb(cfg->pll_div_regs[i], phy->regs + PHY_REG(2) + i * 4);
> +		writeb(cfg->pll_div_regs[i], phy->regs + PHY_REG(1) + i * 4);
>  
> -	/* High nibble of pll_div_regs[1] contains S which also gets written to REG21 */
> +	/* High nibble of PHY_REG3 and low nibble of PHY_REG21 both contain 'S' */
>  	writeb(REG21_SEL_TX_CK_INV | FIELD_PREP(REG21_PMS_S_MASK,
> -	       cfg->pll_div_regs[1] >> 4), phy->regs + PHY_REG(21));
> +	       cfg->pll_div_regs[2] >> 4), phy->regs + PHY_REG(21));
>  
>  	fsl_samsung_hdmi_phy_configure_pll_lock_det(phy, cfg);
>  
> @@ -453,29 +541,70 @@ static unsigned long phy_clk_recalc_rate(struct clk_hw *hw,
>  static long phy_clk_round_rate(struct clk_hw *hw,
>  			       unsigned long rate, unsigned long *parent_rate)
>  {
> +	u32 int_div_clk;
>  	int i;
> +	u16 m;
> +	u8 p, s;
> +
> +	/* If the clock is out of range return error instead of searching */
> +	if (rate > 297000000 || rate < 22250000)
> +		return -EINVAL;
>  
> +	/* Check the look-up table */
>  	for (i = ARRAY_SIZE(phy_pll_cfg) - 1; i >= 0; i--)
>  		if (phy_pll_cfg[i].pixclk <= rate)
> -			return phy_pll_cfg[i].pixclk;
> +			break;
> +	/* If the rate is an exact match, return it now */
> +	if (rate == phy_pll_cfg[i].pixclk)
> +		return phy_pll_cfg[i].pixclk;
> +
> +	/*
> +	 * The math on the lookup table shows the PMS math yields a
> +	 * frequency 5 x pixclk.
> +	 * When we check the integer divider against the desired rate,
> +	 * multiply the rate x 5 and then divide the outcome by 5.
> +	 */
> +	int_div_clk = fsl_samsung_hdmi_phy_find_pms(rate * 5, &p, &m, &s) / 5;

I'd move that comment and both multiplication and division inside
fsl_samsung_hdmi_phy_find_pms, since it's a property of the computation
(not having the comment made me ask last time, with the comment it's
fine -- thanks for adding these comments, very helpful.)

-- 
Dominique




From quic_srichara at quicinc.com  Fri Aug 30 00:54:46 2024
From: quic_srichara at quicinc.com (Sricharan Ramabadhran)
Date: Fri, 30 Aug 2024 13:24:46 +0530
Subject: [PATCH V2 6/6] arm64: dts: qcom: ipq5018: Enable PCIe
In-Reply-To: <nut3ru5rdjf3k3np47gqbpuczvpsuoismx6hp55ivc5mqmdglz@zyzbra46i6iz>
References: <20240827045757.1101194-1-quic_srichara@quicinc.com>
 <20240827045757.1101194-7-quic_srichara@quicinc.com>
 <nut3ru5rdjf3k3np47gqbpuczvpsuoismx6hp55ivc5mqmdglz@zyzbra46i6iz>
Message-ID: <c17d6216-654d-427a-b267-a3886929ab48@quicinc.com>



On 8/29/2024 2:40 PM, Dmitry Baryshkov wrote:
> On Tue, Aug 27, 2024 at 10:27:57AM GMT, Sricharan R wrote:
>> From: Nitheesh Sekar <quic_nsekar at quicinc.com>
>>
>> Enable the PCIe controller and PHY nodes for RDP 432-c2.
>>
>> Signed-off-by: Nitheesh Sekar <quic_nsekar at quicinc.com>
>> Signed-off-by: Sricharan Ramabadhran <quic_srichara at quicinc.com>
>> ---
>>   [v2] Moved status as last property
>>
>>   arch/arm64/boot/dts/qcom/ipq5018-rdp432-c2.dts | 9 +++++++++
>>   1 file changed, 9 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/ipq5018-rdp432-c2.dts b/arch/arm64/boot/dts/qcom/ipq5018-rdp432-c2.dts
>> index 8460b538eb6a..2b253da7f776 100644
>> --- a/arch/arm64/boot/dts/qcom/ipq5018-rdp432-c2.dts
>> +++ b/arch/arm64/boot/dts/qcom/ipq5018-rdp432-c2.dts
>> @@ -28,6 +28,15 @@ &blsp1_uart1 {
>>   	status = "okay";
>>   };
>>   
>> +&pcie1 {
>> +	perst-gpios = <&tlmm 15 GPIO_ACTIVE_LOW>;
> 
> pinctrl? wake-gpios?
> 

  ok, will add to make it explicit.
  Otherwise pinctrl was default muxed.

Regards,
  Sricharan


From vkoul at kernel.org  Fri Aug 30 00:55:32 2024
From: vkoul at kernel.org (Vinod Koul)
Date: Fri, 30 Aug 2024 13:25:32 +0530
Subject: [RFC V2 2/2] phy: freescale: fsl-samsung-hdmi: Support dynamic
 integer divider
In-Reply-To: <CAHCN7xKW=zxips+J73913eEfS+p_e3dN9BWU08=poj599JbUxA@mail.gmail.com>
References: <20240829021256.787615-1-aford173@gmail.com>
 <20240829021256.787615-2-aford173@gmail.com>
 <ZtC2LhYAAdPdSRpz@vaman>
 <CAHCN7xKW=zxips+J73913eEfS+p_e3dN9BWU08=poj599JbUxA@mail.gmail.com>
Message-ID: <ZtF69NSHFtAwDupq@vaman>

On 29-08-24, 13:30, Adam Ford wrote:
> On Thu, Aug 29, 2024 at 12:56?PM Vinod Koul <vkoul at kernel.org> wrote:
> >
> > On 28-08-24, 21:12, Adam Ford wrote:
> > > There is currently a look-up table for a variety of resolutions.
> > > Since the phy has the ability to dynamically calculate the values
> > > necessary to use the intger divider which should allow more
> > > resolutions without having to update the look-up-table.  If the
> > > integer calculator cannot get an exact frequency, it falls back
> > > to the look-up-table.  Because the LUT algorithm does some
> > > rounding, I did not remove integer entries from the LUT.
> >
> > Any reason why this is RFC?
> 
> Someone was asking for functionality, but I'm not 100% sure this is
> the right approach or it would even work.  I am waiting for feedback
> from Dominique to determine if this helps solve the display for that
> particular display.
> 
> >
> > >
> > > Signed-off-by: Adam Ford <aford173 at gmail.com>
> > >
> > > diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > > index bc5d3625ece6..76e0899c6006 100644
> > > --- a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > > +++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > > @@ -16,6 +16,8 @@
> > >
> > >  #define PHY_REG(reg)         (reg * 4)
> > >
> > > +#define REG01_PMS_P_MASK     GENMASK(3, 0)
> > > +#define REG03_PMS_S_MASK     GENMASK(7, 4)
> > >  #define REG12_CK_DIV_MASK    GENMASK(5, 4)
> > >  #define REG13_TG_CODE_LOW_MASK       GENMASK(7, 0)
> > >  #define REG14_TOL_MASK               GENMASK(7, 4)
> > > @@ -31,11 +33,17 @@
> > >
> > >  #define PHY_PLL_DIV_REGS_NUM 6
> > >
> > > +#ifndef MHZ
> > > +#define MHZ  (1000UL * 1000UL)
> > > +#endif
> > > +
> > >  struct phy_config {
> > >       u32     pixclk;
> > >       u8      pll_div_regs[PHY_PLL_DIV_REGS_NUM];
> > >  };
> > >
> > > +static struct phy_config custom_phy_pll_cfg;
> > > +
> > >  static const struct phy_config phy_pll_cfg[] = {
> > >       {
> > >               .pixclk = 22250000,
> > > @@ -440,10 +448,83 @@ fsl_samsung_hdmi_phy_configure_pll_lock_det(struct fsl_samsung_hdmi_phy *phy,
> > >              phy->regs + PHY_REG(14));
> > >  }
> > >
> > > +static unsigned long fsl_samsung_hdmi_phy_find_pms(unsigned long fout, u8 *p, u16 *m, u8 *s)
> > > +{
> > > +     unsigned long best_freq = 0;
> > > +     u32 min_delta = 0xffffffff;
> >
> > > +     u8 _p, best_p;
> > > +     u16 _m, best_m;
> > > +     u8 _s, best_s;
> > > +
> > > +     for (_p = 1; _p <= 11; ++_p) {
> >
> > starts with 1 to 11.. why?
> 
> According to Rev 2 of the 8MP Reference Manual, the Previder range is
> between 1 and 11.

Would be better to document these assumptions, am sure if someone asks
you this next year, it would be hard to recall :-)

-- 
~Vinod


From vkoul at kernel.org  Fri Aug 30 01:02:54 2024
From: vkoul at kernel.org (Vinod Koul)
Date: Fri, 30 Aug 2024 13:32:54 +0530
Subject: [PATCH 10/16] phy: renesas: rcar-gen3-usb2: Add support to
 initialize the bus
In-Reply-To: <TY3PR01MB11346FBA77256F2156D374ECF86882@TY3PR01MB11346.jpnprd01.prod.outlook.com>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
 <20240822152801.602318-11-claudiu.beznea.uj@bp.renesas.com>
 <TY3PR01MB113468A6CA4ADBCA577670AD486882@TY3PR01MB11346.jpnprd01.prod.outlook.com>
 <8faa6b6d-a013-4a71-a8b7-af02ac92d94b@tuxon.dev>
 <TY3PR01MB11346FBA77256F2156D374ECF86882@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Message-ID: <ZtF8rtI7e/7cK4BR@vaman>

On 23-08-24, 09:01, Biju Das wrote:
> > >> The Renesas RZ/G3S need to initialize the USB BUS before transferring data due to hardware
> > limitation.
> > >> As the register that need to be touched for this is in the address
> > >> space of the USB PHY, and the UBS PHY need to be initialized before
> > >> any other USB drivers handling data transfer, add support to initialize the USB BUS.
> > >>
> > >> As the USB PHY is probed before any other USB drivers that enables
> > >> clocks and de-assert the reset signals and the BUS initialization is
> > >> done in the probe phase, we need to add code to de-assert reset signal and runtime resume the
> > device (which enables its clocks) before accessing the registers.
> > >>
> > >> As the reset signals are not required by the USB PHY driver for the
> > >> other USB PHY hardware variants, the reset signals and runtime PM was handled only in the function
> > that initialize the USB BUS.
> > >>
> > >> The PHY initialization was done right after runtime PM enable to have
> > >> all in place when the PHYs are registered.
> > >
> > > There is no user for this patch. The first user is RZ/G3S and you
> > > should merge this patch with next one.
> > 
> > I think this is a matter of taste... This is how I usually format the patches (for scenarios like
> > this) and got no request for squashing.
> 
> That is strange for trivial patches like this.

Splitting is better, this patch does one thing whereas the next one uses
it adds in new device, i would say quite a clean approach

NOTE: Don't quote the not required context while replying, it is good
mail list hygiene

-- 
~Vinod


From biju.das.jz at bp.renesas.com  Fri Aug 30 01:06:25 2024
From: biju.das.jz at bp.renesas.com (Biju Das)
Date: Fri, 30 Aug 2024 08:06:25 +0000
Subject: [PATCH 10/16] phy: renesas: rcar-gen3-usb2: Add support to
 initialize the bus
In-Reply-To: <ZtF8rtI7e/7cK4BR@vaman>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
 <20240822152801.602318-11-claudiu.beznea.uj@bp.renesas.com>
 <TY3PR01MB113468A6CA4ADBCA577670AD486882@TY3PR01MB11346.jpnprd01.prod.outlook.com>
 <8faa6b6d-a013-4a71-a8b7-af02ac92d94b@tuxon.dev>
 <TY3PR01MB11346FBA77256F2156D374ECF86882@TY3PR01MB11346.jpnprd01.prod.outlook.com>
 <ZtF8rtI7e/7cK4BR@vaman>
Message-ID: <TY3PR01MB11346AE72983D6E3749AC8EC386972@TY3PR01MB11346.jpnprd01.prod.outlook.com>

Hi Vinod,

> -----Original Message-----
> From: Vinod Koul <vkoul at kernel.org>
> Sent: Friday, August 30, 2024 9:03 AM
> Subject: Re: [PATCH 10/16] phy: renesas: rcar-gen3-usb2: Add support to initialize the bus
> 
> On 23-08-24, 09:01, Biju Das wrote:
> > > >> The Renesas RZ/G3S need to initialize the USB BUS before
> > > >> transferring data due to hardware
> > > limitation.
> > > >> As the register that need to be touched for this is in the
> > > >> address space of the USB PHY, and the UBS PHY need to be
> > > >> initialized before any other USB drivers handling data transfer, add support to initialize the
> USB BUS.
> > > >>
> > > >> As the USB PHY is probed before any other USB drivers that
> > > >> enables clocks and de-assert the reset signals and the BUS
> > > >> initialization is done in the probe phase, we need to add code to
> > > >> de-assert reset signal and runtime resume the
> > > device (which enables its clocks) before accessing the registers.
> > > >>
> > > >> As the reset signals are not required by the USB PHY driver for
> > > >> the other USB PHY hardware variants, the reset signals and
> > > >> runtime PM was handled only in the function
> > > that initialize the USB BUS.
> > > >>
> > > >> The PHY initialization was done right after runtime PM enable to
> > > >> have all in place when the PHYs are registered.
> > > >
> > > > There is no user for this patch. The first user is RZ/G3S and you
> > > > should merge this patch with next one.
> > >
> > > I think this is a matter of taste... This is how I usually format
> > > the patches (for scenarios like
> > > this) and got no request for squashing.
> >
> > That is strange for trivial patches like this.
> 
> Splitting is better, this patch does one thing whereas the next one uses it adds in new device, i
> would say quite a clean approach
> 
> NOTE: Don't quote the not required context while replying, it is good mail list hygiene

Agreed. I was wrong then. To support a new device, bus initialization is required.
So I thought it should go together.

Cheers,
Biju


From vkoul at kernel.org  Fri Aug 30 01:10:46 2024
From: vkoul at kernel.org (Vinod Koul)
Date: Fri, 30 Aug 2024 13:40:46 +0530
Subject: [PATCH 00/11] phy: simplify with cleanup.h and few other ideas
In-Reply-To: <20240826-phy-of-node-scope-v1-0-5b4d82582644@linaro.org>
References: <20240826-phy-of-node-scope-v1-0-5b4d82582644@linaro.org>
Message-ID: <172500544630.434293.13040748970370817856.b4-ty@kernel.org>


On Mon, 26 Aug 2024 12:07:16 +0200, Krzysztof Kozlowski wrote:
> Make code simpler with scoped/cleanup.h/dev_err_probe.
> 
> Best regards,
> Krzysztof
> 

Applied, thanks!

[01/11] phy: broadcom: bcm-cygnus-pcie: Simplify with scoped for each OF child loop
        commit: e33525de6c3c7780564e0859ea6daef27309995b
[02/11] phy: broadcom: brcm-sata: Simplify with scoped for each OF child loop
        commit: a7f1dbf479d2a3cbf2a25bd186bbe15efd17d849
[03/11] phy: cadence: sierra: Simplify with scoped for each OF child loop
        commit: 612f9fcb435fdc9abd46b6339c9000cef6d323a2
[04/11] phy: hisilicon: usb2: Simplify with scoped for each OF child loop
        commit: 93cab07a02f08e4a2837dd22280b741ba0a7a541
[05/11] phy: mediatek: tphy: Simplify with scoped for each OF child loop
        commit: d2714416770ed0cecaf69eaff34d20817f2c3bea
[06/11] phy: mediatek: xsphy: Simplify with scoped for each OF child loop
        commit: 77df35acd182a23c117a937ffd6b0830a5428649
[07/11] phy: qcom: qmp-pcie-msm8996: Simplify with scoped for each OF child loop
        commit: 608863e1e600a4d91b00dddd6ff11eda1cbebaa5
[08/11] phy: ti: am654-serdes: Use scoped device node handling to simplify error paths
        commit: 29b44a38503856952862c710d47d933c0173fd04
[09/11] phy: ti: gmii-sel: Simplify with dev_err_probe()
        commit: 27a4046255377eb0faab5c41fd271b1acab1ac41
[10/11] phy: ti: j721e-wiz: Drop OF node reference earlier for simpler code
        commit: afd7aaf3ecaf1b247db1294ef0687fb3cb530213
[11/11] phy: ti: j721e-wiz: Simplify with scoped for each OF child loop
        commit: 0d5a213c2eae880e0f7f8bc252314bae194d68d8

Best regards,
-- 
~Vinod




From vkoul at kernel.org  Fri Aug 30 01:10:50 2024
From: vkoul at kernel.org (Vinod Koul)
Date: Fri, 30 Aug 2024 13:40:50 +0530
Subject: (subset) [PATCH 00/16] Add initial USB support for the Renesas
 RZ/G3S SoC
In-Reply-To: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <172500545045.434293.2799164142138573835.b4-ty@kernel.org>


On Thu, 22 Aug 2024 18:27:45 +0300, Claudiu wrote:
> Series adds initial USB support for the Renesas RZ/G3S SoC.
> 
> Series is split as follows:
> 
> - patch 01/16		- add clock reset and power domain support for USB
> - patch 02-04/16	- add reset control support for a USB signal
> 			  that need to be controlled before/after
> 			  the power to USB area is turned on/off.
> 
> [...]

Applied, thanks!

[10/16] phy: renesas: rcar-gen3-usb2: Add support to initialize the bus
        commit: 4eae16375357a2a7e8501be5469532f7636064b3
[11/16] dt-bindings: phy: renesas,usb2-phy: Document RZ/G3S phy bindings
        commit: f3c8498551146dfb014be0d85d3a7df98be16aa2
[12/16] phy: renesas: rcar-gen3-usb2: Add support for the RZ/G3S SoC
        commit: 3c2ea12a625dbf5a864f4920235fa1c739d06e7d

Best regards,
-- 
~Vinod




From quic_srichara at quicinc.com  Fri Aug 30 01:11:28 2024
From: quic_srichara at quicinc.com (Sricharan R)
Date: Fri, 30 Aug 2024 13:41:28 +0530
Subject: [PATCH V3 2/6] dt-bindings: PCI: qcom: Add IPQ5108 SoC
In-Reply-To: <20240830081132.4016860-1-quic_srichara@quicinc.com>
References: <20240830081132.4016860-1-quic_srichara@quicinc.com>
Message-ID: <20240830081132.4016860-3-quic_srichara@quicinc.com>

From: Nitheesh Sekar <quic_nsekar at quicinc.com>

Add support for the PCIe controller on the Qualcomm
IPQ5108 SoC to the bindings.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Nitheesh Sekar <quic_nsekar at quicinc.com>
Signed-off-by: Sricharan Ramabadhran <quic_srichara at quicinc.com>
---
 [v3] No change

 .../devicetree/bindings/pci/qcom,pcie.yaml    | 35 +++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
index f867746b1ae5..c12efa27b8d8 100644
--- a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
@@ -21,6 +21,7 @@ properties:
           - qcom,pcie-apq8064
           - qcom,pcie-apq8084
           - qcom,pcie-ipq4019
+          - qcom,pcie-ipq5018
           - qcom,pcie-ipq6018
           - qcom,pcie-ipq8064
           - qcom,pcie-ipq8064-v2
@@ -312,6 +313,39 @@ allOf:
             - const: ahb # AHB reset
             - const: phy_ahb # PHY AHB reset
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - qcom,pcie-ipq5018
+    then:
+      properties:
+        clocks:
+          minItems: 6
+          maxItems: 6
+        clock-names:
+          items:
+            - const: iface # PCIe to SysNOC BIU clock
+            - const: axi_m # AXI Master clock
+            - const: axi_s # AXI Slave clock
+            - const: ahb # AHB clock
+            - const: aux # Auxiliary clock
+            - const: axi_bridge # AXI bridge clock
+        resets:
+          minItems: 8
+          maxItems: 8
+        reset-names:
+          items:
+            - const: pipe # PIPE reset
+            - const: sleep # Sleep reset
+            - const: sticky # Core sticky reset
+            - const: axi_m # AXI master reset
+            - const: axi_s # AXI slave reset
+            - const: ahb # AHB reset
+            - const: axi_m_sticky # AXI master sticky reset
+            - const: axi_s_sticky # AXI slave sticky reset
+
   - if:
       properties:
         compatible:
@@ -503,6 +537,7 @@ allOf:
               enum:
                 - qcom,pcie-apq8064
                 - qcom,pcie-ipq4019
+                - qcom,pcie-ipq5018
                 - qcom,pcie-ipq8064
                 - qcom,pcie-ipq8064v2
                 - qcom,pcie-ipq8074
-- 
2.34.1



From quic_srichara at quicinc.com  Fri Aug 30 01:11:29 2024
From: quic_srichara at quicinc.com (Sricharan R)
Date: Fri, 30 Aug 2024 13:41:29 +0530
Subject: [PATCH V3 3/6] phy: qcom: Introduce PCIe UNIPHY 28LP driver
In-Reply-To: <20240830081132.4016860-1-quic_srichara@quicinc.com>
References: <20240830081132.4016860-1-quic_srichara@quicinc.com>
Message-ID: <20240830081132.4016860-4-quic_srichara@quicinc.com>

From: Nitheesh Sekar <quic_nsekar at quicinc.com>

Add Qualcomm PCIe UNIPHY 28LP driver support present
in Qualcomm IPQ5018 SoC and the phy init sequence.

Signed-off-by: Nitheesh Sekar <quic_nsekar at quicinc.com>
Signed-off-by: Sricharan Ramabadhran <quic_srichara at quicinc.com>
---
 [V3] Fixed dev_err_probe usage

 drivers/phy/qualcomm/Kconfig                  |  12 +
 drivers/phy/qualcomm/Makefile                 |   1 +
 .../phy/qualcomm/phy-qcom-uniphy-pcie-28lp.c  | 346 ++++++++++++++++++
 3 files changed, 359 insertions(+)
 create mode 100644 drivers/phy/qualcomm/phy-qcom-uniphy-pcie-28lp.c

diff --git a/drivers/phy/qualcomm/Kconfig b/drivers/phy/qualcomm/Kconfig
index 846f8c99547f..8f043e8cb71c 100644
--- a/drivers/phy/qualcomm/Kconfig
+++ b/drivers/phy/qualcomm/Kconfig
@@ -154,6 +154,18 @@ config PHY_QCOM_M31_USB
 	  management. This driver is required even for peripheral only or
 	  host only mode configurations.
 
+config PHY_QCOM_UNIPHY_PCIE_28LP
+	bool "PCIE UNIPHY 28LP PHY driver"
+	depends on ARCH_QCOM
+	depends on HAS_IOMEM
+	depends on OF
+	select GENERIC_PHY
+	help
+	  Enable this to support the PCIe UNIPHY 28LP phy transceiver that
+	  is used with PCIe controllers on Qualcomm IPQ5018 chips. It
+	  handles PHY initialization, clock management required after
+	  resetting the hardware and power management.
+
 config PHY_QCOM_USB_HS
 	tristate "Qualcomm USB HS PHY module"
 	depends on USB_ULPI_BUS
diff --git a/drivers/phy/qualcomm/Makefile b/drivers/phy/qualcomm/Makefile
index eb60e950ad53..42038bc30974 100644
--- a/drivers/phy/qualcomm/Makefile
+++ b/drivers/phy/qualcomm/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_PHY_QCOM_QMP_USB_LEGACY)	+= phy-qcom-qmp-usb-legacy.o
 obj-$(CONFIG_PHY_QCOM_QUSB2)		+= phy-qcom-qusb2.o
 obj-$(CONFIG_PHY_QCOM_SNPS_EUSB2)	+= phy-qcom-snps-eusb2.o
 obj-$(CONFIG_PHY_QCOM_EUSB2_REPEATER)	+= phy-qcom-eusb2-repeater.o
+obj-$(CONFIG_PHY_QCOM_UNIPHY_PCIE_28LP)	+= phy-qcom-uniphy-pcie-28lp.o
 obj-$(CONFIG_PHY_QCOM_USB_HS) 		+= phy-qcom-usb-hs.o
 obj-$(CONFIG_PHY_QCOM_USB_HSIC) 	+= phy-qcom-usb-hsic.o
 obj-$(CONFIG_PHY_QCOM_USB_HS_28NM)	+= phy-qcom-usb-hs-28nm.o
diff --git a/drivers/phy/qualcomm/phy-qcom-uniphy-pcie-28lp.c b/drivers/phy/qualcomm/phy-qcom-uniphy-pcie-28lp.c
new file mode 100644
index 000000000000..95740850bdc0
--- /dev/null
+++ b/drivers/phy/qualcomm/phy-qcom-uniphy-pcie-28lp.c
@@ -0,0 +1,346 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2024, The Linux Foundation. All rights reserved.
+ */
+
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/phy/phy.h>
+#include <linux/reset.h>
+#include <linux/of_device.h>
+#include <linux/delay.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+
+#define CDR_CTRL_REG_1		0x80
+#define CDR_CTRL_REG_2		0x84
+#define CDR_CTRL_REG_3		0x88
+#define CDR_CTRL_REG_4		0x8C
+#define CDR_CTRL_REG_5		0x90
+#define CDR_CTRL_REG_6		0x94
+#define CDR_CTRL_REG_7		0x98
+#define SSCG_CTRL_REG_1		0x9c
+#define SSCG_CTRL_REG_2		0xa0
+#define SSCG_CTRL_REG_3		0xa4
+#define SSCG_CTRL_REG_4		0xa8
+#define SSCG_CTRL_REG_5		0xac
+#define SSCG_CTRL_REG_6		0xb0
+#define PCS_INTERNAL_CONTROL_2	0x2d8
+
+#define PHY_MODE_FIXED		0x1
+
+enum qcom_uniphy_pcie_type {
+	PHY_TYPE_PCIE = 1,
+	PHY_TYPE_PCIE_GEN2,
+	PHY_TYPE_PCIE_GEN3,
+};
+
+struct qcom_uniphy_regs {
+	unsigned int offset;
+	unsigned int val;
+};
+
+struct qcom_uniphy_pcie_data {
+	int lanes;
+	/* 2nd lane offset */
+	int lane_offset;
+	unsigned int phy_type;
+	const struct qcom_uniphy_regs *init_seq;
+	unsigned int init_seq_num;
+};
+
+struct qcom_uniphy_pcie {
+	struct phy phy;
+	struct device *dev;
+	const struct qcom_uniphy_pcie_data *data;
+	struct clk_bulk_data *clks;
+	int num_clks;
+	struct reset_control *resets;
+	void __iomem *base;
+};
+
+#define	phy_to_dw_phy(x)	container_of((x), struct qca_uni_pcie_phy, phy)
+
+static const struct qcom_uniphy_regs ipq5018_regs[] = {
+	{
+		.offset = SSCG_CTRL_REG_4,
+		.val = 0x1cb9,
+	},
+	{
+		.offset = SSCG_CTRL_REG_5,
+		.val = 0x023a,
+	},
+	{
+		.offset = SSCG_CTRL_REG_3,
+		.val = 0xd360,
+	},
+	{
+		.offset = SSCG_CTRL_REG_1,
+		.val = 0x1,
+	},
+	{
+		.offset = SSCG_CTRL_REG_2,
+		.val = 0xeb,
+	},
+	{
+		.offset = CDR_CTRL_REG_4,
+		.val = 0x3f9,
+	},
+	{
+		.offset = CDR_CTRL_REG_5,
+		.val = 0x1c9,
+	},
+	{
+		.offset = CDR_CTRL_REG_2,
+		.val = 0x419,
+	},
+	{
+		.offset = CDR_CTRL_REG_1,
+		.val = 0x200,
+	},
+	{
+		.offset = PCS_INTERNAL_CONTROL_2,
+		.val = 0xf101,
+	},
+};
+
+static const struct qcom_uniphy_pcie_data ipq5018_2x1_data = {
+	.lanes		= 1,
+	.lane_offset	= 0x800,
+	.phy_type	= PHY_TYPE_PCIE_GEN2,
+	.init_seq	= ipq5018_regs,
+	.init_seq_num	= ARRAY_SIZE(ipq5018_regs),
+};
+
+static const struct qcom_uniphy_pcie_data ipq5018_2x2_data = {
+	.lanes		= 2,
+	.lane_offset	= 0x800,
+	.phy_type	= PHY_TYPE_PCIE_GEN2,
+	.init_seq	= ipq5018_regs,
+	.init_seq_num	= ARRAY_SIZE(ipq5018_regs),
+};
+
+static void qcom_uniphy_pcie_init(struct qcom_uniphy_pcie *phy)
+{
+	const struct qcom_uniphy_pcie_data *data = phy->data;
+	const struct qcom_uniphy_regs *init_seq;
+	void __iomem *base = phy->base;
+	int lane = 0;
+	int i;
+
+	for (lane = 0; lane < data->lanes; lane++) {
+		init_seq = data->init_seq;
+
+		for (i = 0; i < data->init_seq_num; i++, init_seq++)
+			writel(init_seq->val, base + init_seq->offset);
+
+		base += data->lane_offset;
+	}
+}
+
+static int qcom_uniphy_pcie_power_off(struct phy *x)
+{
+	struct qcom_uniphy_pcie *phy = phy_get_drvdata(x);
+
+	reset_control_assert(phy->resets);
+
+	clk_bulk_disable_unprepare(phy->num_clks, phy->clks);
+
+	return 0;
+}
+
+static int qcom_uniphy_pcie_power_on(struct phy *x)
+{
+	int ret;
+	struct qcom_uniphy_pcie *phy = phy_get_drvdata(x);
+
+	ret = clk_bulk_prepare_enable(phy->num_clks, phy->clks);
+	if (ret) {
+		dev_err(phy->dev, "clk prepare and enable failed %d\n", ret);
+		return ret;
+	}
+
+	usleep_range(30, 50);
+
+	ret = reset_control_assert(phy->resets);
+	if (ret) {
+		dev_err(phy->dev, "reset assert failed (%d)\n", ret);
+		return ret;
+	}
+
+	/*
+	 * Delay periods before and after reset deassert are working values
+	 * from downstream Codeaurora kernel
+	 */
+	usleep_range(100, 150);
+
+	ret = reset_control_deassert(phy->resets);
+	if (ret) {
+		dev_err(phy->dev, "reset deassert failed (%d)\n", ret);
+		return ret;
+	}
+
+	usleep_range(5000, 5100);
+
+	qcom_uniphy_pcie_init(phy);
+
+	return 0;
+}
+
+static inline int qcom_uniphy_pcie_get_resources(struct platform_device *pdev,
+						 struct qcom_uniphy_pcie *phy)
+{
+	struct resource *res;
+
+	phy->base = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
+	if (IS_ERR(phy->base)) {
+		dev_err(phy->dev, "cannot get phy registers\n");
+		return PTR_ERR(phy->base);
+	}
+
+	phy->num_clks = devm_clk_bulk_get_all(phy->dev, &phy->clks);
+	if (phy->num_clks < 0)
+		return phy->num_clks;
+
+	phy->resets = devm_reset_control_array_get_exclusive(phy->dev);
+	if (IS_ERR(phy->resets))
+		return PTR_ERR(phy->resets);
+
+	return 0;
+}
+
+/*
+ * Register a fixed rate pipe clock.
+ *
+ * The <s>_pipe_clksrc generated by PHY goes to the GCC that gate
+ * controls it. The <s>_pipe_clk coming out of the GCC is requested
+ * by the PHY driver for its operations.
+ * We register the <s>_pipe_clksrc here. The gcc driver takes care
+ * of assigning this <s>_pipe_clksrc as parent to <s>_pipe_clk.
+ * Below picture shows this relationship.
+ *
+ *         +---------------+
+ *         |   PHY block   |<<---------------------------------------+
+ *         |               |                                         |
+ *         |   +-------+   |                   +-----+               |
+ *   I/P---^-->|  PLL  |---^--->pipe_clksrc--->| GCC |--->pipe_clk---+
+ *    clk  |   +-------+   |                   +-----+
+ *         +---------------+
+ */
+static inline int phy_pipe_clk_register(struct qcom_uniphy_pcie  *phy,
+					struct device_node *np)
+{
+	struct clk_init_data init = { };
+	struct clk_fixed_rate *fixed;
+	struct clk_hw *hw;
+	char name[64];
+	int ret;
+
+	snprintf(name, sizeof(name), "%s::pipe_clk", dev_name(phy->dev));
+
+	fixed = devm_kzalloc(phy->dev, sizeof(*fixed), GFP_KERNEL);
+	if (!fixed)
+		return -ENOMEM;
+
+	init.ops = &clk_fixed_rate_ops;
+	fixed->fixed_rate = 125000000;
+	fixed->hw.init = &init;
+	hw = &fixed->hw;
+
+	hw = devm_clk_hw_register_fixed_rate(phy->dev, name, NULL,
+					     0, 125000000);
+	if (IS_ERR(hw))
+		return PTR_ERR(hw);
+
+	ret = devm_of_clk_add_hw_provider(phy->dev, of_clk_hw_simple_get, hw);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static const struct of_device_id qcom_uniphy_pcie_id_table[] = {
+	{
+		.compatible = "qcom,ipq5018-uniphy-pcie-gen2x2",
+		.data = &ipq5018_2x2_data,
+	},
+	{
+		.compatible = "qcom,ipq5018-uniphy-pcie-gen2x1",
+		.data = &ipq5018_2x1_data,
+	},
+
+	{ /* Sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, qcom_uniphy_pcie_id_table);
+
+static const struct phy_ops pcie_ops = {
+	.power_on	= qcom_uniphy_pcie_power_on,
+	.power_off	= qcom_uniphy_pcie_power_off,
+	.owner          = THIS_MODULE,
+};
+
+static int qcom_uniphy_pcie_probe(struct platform_device *pdev)
+{
+	struct phy_provider *phy_provider;
+	struct device *dev = &pdev->dev;
+	struct qcom_uniphy_pcie *phy;
+	struct phy *generic_phy;
+	struct device_node *np;
+	int ret;
+
+	np = of_node_get(dev->of_node);
+
+	phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
+	if (!phy)
+		return -ENOMEM;
+
+	platform_set_drvdata(pdev, phy);
+	phy->dev = &pdev->dev;
+
+	phy->data = of_device_get_match_data(dev);
+	if (!phy->data)
+		return dev_err_probe(&pdev->dev, PTR_ERR(phy->data),
+				     "Failed to get data\n");
+
+	ret = qcom_uniphy_pcie_get_resources(pdev, phy);
+	if (ret < 0)
+		return dev_err_probe(&pdev->dev, ret,
+				     "Failed to get resources:\n");
+
+	ret = phy_pipe_clk_register(phy, np);
+	if (ret)
+		return dev_err_probe(&pdev->dev, ret,
+				     "pipe clk register failed\n");
+
+	generic_phy = devm_phy_create(phy->dev, NULL, &pcie_ops);
+	if (IS_ERR(generic_phy))
+		return dev_err_probe(&pdev->dev, PTR_ERR(generic_phy),
+				     "phy create failed\n");
+
+	phy_set_drvdata(generic_phy, phy);
+	phy_provider = devm_of_phy_provider_register(phy->dev,
+						     of_phy_simple_xlate);
+	if (IS_ERR(phy_provider))
+		return dev_err_probe(&pdev->dev, PTR_ERR(phy_provider),
+				     "phy register failed\n");
+
+	return 0;
+}
+
+static struct platform_driver qcom_uniphy_pcie_driver = {
+	.probe		= qcom_uniphy_pcie_probe,
+	.driver		= {
+		.name	= "qcom-uniphy-pcie",
+		.of_match_table = qcom_uniphy_pcie_id_table,
+	},
+};
+
+module_platform_driver(qcom_uniphy_pcie_driver);
+
+MODULE_LICENSE("Dual BSD/GPL");
+MODULE_DESCRIPTION("PCIE QCOM UNIPHY driver");
-- 
2.34.1



From quic_srichara at quicinc.com  Fri Aug 30 01:11:30 2024
From: quic_srichara at quicinc.com (Sricharan R)
Date: Fri, 30 Aug 2024 13:41:30 +0530
Subject: [PATCH V3 4/6] PCI: qcom: Add support for IPQ5018
In-Reply-To: <20240830081132.4016860-1-quic_srichara@quicinc.com>
References: <20240830081132.4016860-1-quic_srichara@quicinc.com>
Message-ID: <20240830081132.4016860-5-quic_srichara@quicinc.com>

Introduce a new compatible and re-use 2_9_0 ops.

Signed-off-by: Nitheesh Sekar <quic_nsekar at quicinc.com>
Signed-off-by: Sricharan R <quic_srichara at quicinc.com>
---
 [V3] No change

 drivers/pci/controller/dwc/pcie-qcom.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
index 6f953e32d990..e814d6cc062d 100644
--- a/drivers/pci/controller/dwc/pcie-qcom.c
+++ b/drivers/pci/controller/dwc/pcie-qcom.c
@@ -1722,6 +1722,7 @@ static const struct of_device_id qcom_pcie_match[] = {
 	{ .compatible = "qcom,pcie-apq8064", .data = &cfg_2_1_0 },
 	{ .compatible = "qcom,pcie-apq8084", .data = &cfg_1_0_0 },
 	{ .compatible = "qcom,pcie-ipq4019", .data = &cfg_2_4_0 },
+	{ .compatible = "qcom,pcie-ipq5018", .data = &cfg_2_9_0 },
 	{ .compatible = "qcom,pcie-ipq6018", .data = &cfg_2_9_0 },
 	{ .compatible = "qcom,pcie-ipq8064", .data = &cfg_2_1_0 },
 	{ .compatible = "qcom,pcie-ipq8064-v2", .data = &cfg_2_1_0 },
-- 
2.34.1



From quic_srichara at quicinc.com  Fri Aug 30 01:11:27 2024
From: quic_srichara at quicinc.com (Sricharan R)
Date: Fri, 30 Aug 2024 13:41:27 +0530
Subject: [PATCH V3 1/6] dt-bindings: phy: qcom,uniphy-pcie: Document PCIe uniphy
In-Reply-To: <20240830081132.4016860-1-quic_srichara@quicinc.com>
References: <20240830081132.4016860-1-quic_srichara@quicinc.com>
Message-ID: <20240830081132.4016860-2-quic_srichara@quicinc.com>

From: Nitheesh Sekar <quic_nsekar at quicinc.com>

Document the Qualcomm UNIPHY PCIe 28LP present in IPQ5018.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Nitheesh Sekar <quic_nsekar at quicinc.com>
Signed-off-by: Sricharan Ramabadhran <quic_srichara at quicinc.com>
---
 [v3] Added reviewed-by tags

 .../phy/qcom,ipq5018-uniphy-pcie.yaml         | 70 +++++++++++++++++++
 1 file changed, 70 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom,ipq5018-uniphy-pcie.yaml

diff --git a/Documentation/devicetree/bindings/phy/qcom,ipq5018-uniphy-pcie.yaml b/Documentation/devicetree/bindings/phy/qcom,ipq5018-uniphy-pcie.yaml
new file mode 100644
index 000000000000..c04dd179eb8b
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,ipq5018-uniphy-pcie.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/qcom,ipq5018-uniphy-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm UNIPHY PCIe 28LP PHY controller for genx1, genx2
+
+maintainers:
+  - Nitheesh Sekar <quic_nsekar at quicinc.com>
+  - Sricharan Ramabadhran <quic_srichara at quicinc.com>
+
+properties:
+  compatible:
+    enum:
+      - qcom,ipq5018-uniphy-pcie-gen2x1
+      - qcom,ipq5018-uniphy-pcie-gen2x2
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+  clock-names:
+    items:
+      - const: pipe
+
+  resets:
+    maxItems: 2
+
+  reset-names:
+    items:
+      - const: phy
+      - const: common
+
+  "#phy-cells":
+    const: 0
+
+  "#clock-cells":
+    const: 0
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - resets
+  - reset-names
+  - "#phy-cells"
+  - "#clock-cells"
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/qcom,gcc-ipq5018.h>
+    #include <dt-bindings/reset/qcom,gcc-ipq5018.h>
+
+    phy at 86000 {
+        compatible = "qcom,ipq5018-uniphy-pcie-gen2x2";
+        reg = <0x86000 0x1000>;
+        clocks = <&gcc GCC_PCIE0_PIPE_CLK>;
+        clock-names = "pipe";
+        resets = <&gcc GCC_PCIE0_PHY_BCR>,
+                 <&gcc GCC_PCIE0PHY_PHY_BCR>;
+        reset-names = "phy", "common";
+        #phy-cells = <0>;
+        #clock-cells = <0>;
+    };
-- 
2.34.1



From quic_srichara at quicinc.com  Fri Aug 30 01:11:26 2024
From: quic_srichara at quicinc.com (Sricharan R)
Date: Fri, 30 Aug 2024 13:41:26 +0530
Subject: [PATCH V3 0/6] Enable IPQ5018 PCI support
Message-ID: <20240830081132.4016860-1-quic_srichara@quicinc.com>

From: Sricharan Ramabadhran <quic_srichara at quicinc.com>

This patch series adds the relevant phy and controller
DT configurations for enabling PCI gen2 support
on IPQ5018.

v3:
  Added Reviewed-by tag for patch#1.
  Fixed dev_err_probe usage in patch#3.
  Added pinctrl/wak pins for pcie1 in patch#6.

v2:
  Fixed all review comments from Krzysztof, Robert Marko,
  Dmitry Baryshkov, Manivannan Sadhasivam, Konrad Dybcio.
  Updated the respective patches for their changes.

v1:
 https://lore.kernel.org/lkml/32389b66-48f3-8ee8-e2f1-1613feed3cc7 at gmail.com/T/

Nitheesh Sekar (5):
  dt-bindings: phy: qcom,uniphy-pcie: Document PCIe uniphy
  dt-bindings: PCI: qcom: Add IPQ5108 SoC
  phy: qcom: Introduce PCIe UNIPHY 28LP driver
  arm64: dts: qcom: ipq5018: Add PCIe related nodes
  arm64: dts: qcom: ipq5018: Enable PCIe

Sricharan R (1):
  PCI: qcom: Add support for IPQ5018

 .../devicetree/bindings/pci/qcom,pcie.yaml    |  35 ++
 .../phy/qcom,ipq5018-uniphy-pcie.yaml         |  70 ++++
 .../arm64/boot/dts/qcom/ipq5018-rdp432-c2.dts |  37 ++
 arch/arm64/boot/dts/qcom/ipq5018.dtsi         | 168 ++++++++-
 drivers/pci/controller/dwc/pcie-qcom.c        |   1 +
 drivers/phy/qualcomm/Kconfig                  |  12 +
 drivers/phy/qualcomm/Makefile                 |   1 +
 .../phy/qualcomm/phy-qcom-uniphy-pcie-28lp.c  | 346 ++++++++++++++++++
 8 files changed, 668 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom,ipq5018-uniphy-pcie.yaml
 create mode 100644 drivers/phy/qualcomm/phy-qcom-uniphy-pcie-28lp.c

-- 
2.34.1



From quic_srichara at quicinc.com  Fri Aug 30 01:11:31 2024
From: quic_srichara at quicinc.com (Sricharan R)
Date: Fri, 30 Aug 2024 13:41:31 +0530
Subject: [PATCH V3 5/6] arm64: dts: qcom: ipq5018: Add PCIe related nodes
In-Reply-To: <20240830081132.4016860-1-quic_srichara@quicinc.com>
References: <20240830081132.4016860-1-quic_srichara@quicinc.com>
Message-ID: <20240830081132.4016860-6-quic_srichara@quicinc.com>

From: Nitheesh Sekar <quic_nsekar at quicinc.com>

Add phy and controller nodes for a 2-lane Gen2 and
1-lane Gen2 PCIe buses.

Signed-off-by: Nitheesh Sekar <quic_nsekar at quicinc.com>
Signed-off-by: Sricharan R <quic_srichara at quicinc.com>
---
 [V3] No change

 arch/arm64/boot/dts/qcom/ipq5018.dtsi | 168 +++++++++++++++++++++++++-
 1 file changed, 166 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/ipq5018.dtsi b/arch/arm64/boot/dts/qcom/ipq5018.dtsi
index 7e6e2c121979..dd5d6b7ff094 100644
--- a/arch/arm64/boot/dts/qcom/ipq5018.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq5018.dtsi
@@ -9,6 +9,7 @@
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/clock/qcom,gcc-ipq5018.h>
 #include <dt-bindings/reset/qcom,gcc-ipq5018.h>
+#include <dt-bindings/gpio/gpio.h>
 
 / {
 	interrupt-parent = <&intc>;
@@ -143,7 +144,33 @@ usbphy0: phy at 5b000 {
 			resets = <&gcc GCC_QUSB2_0_PHY_BCR>;
 
 			#phy-cells = <0>;
+		};
+
+		pcie_x1phy: phy at 7e000{
+			compatible = "qcom,ipq5018-uniphy-pcie-gen2x1";
+			reg = <0x0007e000 0x800>;
+			#phy-cells = <0>;
+			#clock-cells = <0>;
+			clocks = <&gcc GCC_PCIE1_PIPE_CLK>;
+			clock-names = "pipe";
+			assigned-clocks = <&gcc GCC_PCIE1_PIPE_CLK>;
+			resets = <&gcc GCC_PCIE1_PHY_BCR>,
+				 <&gcc GCC_PCIE1PHY_PHY_BCR>;
+			reset-names = "phy", "common";
+			status = "disabled";
+		};
 
+		pcie_x2phy: phy at 86000{
+			compatible = "qcom,ipq5018-uniphy-pcie-gen2x2";
+			reg = <0x00086000 0x1000>;
+			#phy-cells = <0>;
+			#clock-cells = <0>;
+			clocks = <&gcc GCC_PCIE0_PIPE_CLK>;
+			clock-names = "pipe";
+			assigned-clocks = <&gcc GCC_PCIE0_PIPE_CLK>;
+			resets = <&gcc GCC_PCIE0_PHY_BCR>,
+				 <&gcc GCC_PCIE0PHY_PHY_BCR>;
+			reset-names = "phy", "common";
 			status = "disabled";
 		};
 
@@ -170,8 +197,8 @@ gcc: clock-controller at 1800000 {
 			reg = <0x01800000 0x80000>;
 			clocks = <&xo_board_clk>,
 				 <&sleep_clk>,
-				 <0>,
-				 <0>,
+				 <&pcie_x2phy>,
+				 <&pcie_x1phy>,
 				 <0>,
 				 <0>,
 				 <0>,
@@ -387,6 +414,143 @@ frame at b128000 {
 				status = "disabled";
 			};
 		};
+
+		pcie0: pci at 80000000 {
+			compatible = "qcom,pcie-ipq5018";
+			reg =  <0x80000000 0xf1d>,
+			       <0x80000f20 0xa8>,
+			       <0x80001000 0x1000>,
+			       <0x00078000 0x3000>,
+			       <0x80100000 0x1000>;
+			reg-names = "dbi", "elbi", "atu", "parf", "config";
+			device_type = "pci";
+			linux,pci-domain = <0>;
+			bus-range = <0x00 0xff>;
+			num-lanes = <1>;
+			max-link-speed = <2>;
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			phys = <&pcie_x1phy>;
+			phy-names ="pciephy";
+
+			ranges = <0x01000000 0 0x80200000 0x80200000 0 0x00100000
+				  0x02000000 0 0x80300000 0x80300000 0 0x10000000>;
+
+			#interrupt-cells = <1>;
+			interrupt-map-mask = <0 0 0 0x7>;
+			interrupt-map = <0 0 0 1 &intc 0 0 142 IRQ_TYPE_LEVEL_HIGH>,
+					<0 0 0 2 &intc 0 0 143 IRQ_TYPE_LEVEL_HIGH>,
+					<0 0 0 3 &intc 0 0 144 IRQ_TYPE_LEVEL_HIGH>,
+					<0 0 0 4 &intc 0 0 145 IRQ_TYPE_LEVEL_HIGH>;
+
+			interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "global_irq";
+
+			clocks = <&gcc GCC_SYS_NOC_PCIE1_AXI_CLK>,
+				 <&gcc GCC_PCIE1_AXI_M_CLK>,
+				 <&gcc GCC_PCIE1_AXI_S_CLK>,
+				 <&gcc GCC_PCIE1_AHB_CLK>,
+				 <&gcc GCC_PCIE1_AUX_CLK>,
+				 <&gcc GCC_PCIE1_AXI_S_BRIDGE_CLK>;
+
+			clock-names = "iface",
+				      "axi_m",
+				      "axi_s",
+				      "ahb",
+				      "aux",
+				      "axi_bridge";
+
+			resets = <&gcc GCC_PCIE1_PIPE_ARES>,
+				 <&gcc GCC_PCIE1_SLEEP_ARES>,
+				 <&gcc GCC_PCIE1_CORE_STICKY_ARES>,
+				 <&gcc GCC_PCIE1_AXI_MASTER_ARES>,
+				 <&gcc GCC_PCIE1_AXI_SLAVE_ARES>,
+				 <&gcc GCC_PCIE1_AHB_ARES>,
+				 <&gcc GCC_PCIE1_AXI_MASTER_STICKY_ARES>,
+				 <&gcc GCC_PCIE1_AXI_SLAVE_STICKY_ARES>;
+
+			reset-names = "pipe",
+				      "sleep",
+				      "sticky",
+				      "axi_m",
+				      "axi_s",
+				      "ahb",
+				      "axi_m_sticky",
+				      "axi_s_sticky";
+
+			msi-map = <0x0 &v2m0 0x0 0xff8>;
+			status = "disabled";
+		};
+
+		pcie1: pci at a0000000 {
+			compatible = "qcom,pcie-ipq5018";
+			reg =  <0xa0000000 0xf1d>,
+			       <0xa0000f20 0xa8>,
+			       <0xa0001000 0x1000>,
+			       <0x00080000 0x3000>,
+			       <0xa0100000 0x1000>;
+			reg-names = "dbi", "elbi", "atu", "parf", "config";
+			device_type = "pci";
+			linux,pci-domain = <1>;
+			bus-range = <0x00 0xff>;
+			num-lanes = <2>;
+			max-link-speed = <2>;
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			phys = <&pcie_x2phy>;
+			phy-names ="pciephy";
+
+			ranges = <0x01000000 0 0xa0200000 0xa0200000 0 0x00100000
+				  0x02000000 0 0xa0300000 0xa0300000 0 0x10000000>;
+
+			#interrupt-cells = <1>;
+			interrupt-map-mask = <0 0 0 0x7>;
+			interrupt-map = <0 0 0 1 &intc 0 0 75 IRQ_TYPE_LEVEL_HIGH>,
+					<0 0 0 2 &intc 0 0 78 IRQ_TYPE_LEVEL_HIGH>,
+					<0 0 0 3 &intc 0 0 79 IRQ_TYPE_LEVEL_HIGH>,
+					<0 0 0 4 &intc 0 0 83 IRQ_TYPE_LEVEL_HIGH>;
+
+			interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "global_irq";
+
+			clocks = <&gcc GCC_SYS_NOC_PCIE0_AXI_CLK>,
+				 <&gcc GCC_PCIE0_AXI_M_CLK>,
+				 <&gcc GCC_PCIE0_AXI_S_CLK>,
+				 <&gcc GCC_PCIE0_AHB_CLK>,
+				 <&gcc GCC_PCIE0_AUX_CLK>,
+				 <&gcc GCC_PCIE0_AXI_S_BRIDGE_CLK>;
+
+			clock-names = "iface",
+				      "axi_m",
+				      "axi_s",
+				      "ahb",
+				      "aux",
+				      "axi_bridge";
+
+			resets = <&gcc GCC_PCIE0_PIPE_ARES>,
+				 <&gcc GCC_PCIE0_SLEEP_ARES>,
+				 <&gcc GCC_PCIE0_CORE_STICKY_ARES>,
+				 <&gcc GCC_PCIE0_AXI_MASTER_ARES>,
+				 <&gcc GCC_PCIE0_AXI_SLAVE_ARES>,
+				 <&gcc GCC_PCIE0_AHB_ARES>,
+				 <&gcc GCC_PCIE0_AXI_MASTER_STICKY_ARES>,
+				 <&gcc GCC_PCIE0_AXI_SLAVE_STICKY_ARES>;
+
+			reset-names = "pipe",
+				      "sleep",
+				      "sticky",
+				      "axi_m",
+				      "axi_s",
+				      "ahb",
+				      "axi_m_sticky",
+				      "axi_s_sticky";
+
+			msi-map = <0x0 &v2m0 0x0 0xff8>;
+			status = "disabled";
+		};
+
 	};
 
 	timer {
-- 
2.34.1



From quic_srichara at quicinc.com  Fri Aug 30 01:11:32 2024
From: quic_srichara at quicinc.com (Sricharan R)
Date: Fri, 30 Aug 2024 13:41:32 +0530
Subject: [PATCH V3 6/6] arm64: dts: qcom: ipq5018: Enable PCIe
In-Reply-To: <20240830081132.4016860-1-quic_srichara@quicinc.com>
References: <20240830081132.4016860-1-quic_srichara@quicinc.com>
Message-ID: <20240830081132.4016860-7-quic_srichara@quicinc.com>

From: Nitheesh Sekar <quic_nsekar at quicinc.com>

Enable the PCIe controller and PHY nodes for RDP 432-c2.

Signed-off-by: Nitheesh Sekar <quic_nsekar at quicinc.com>
Signed-off-by: Sricharan Ramabadhran <quic_srichara at quicinc.com>
---
 [V3] Added perst/wake pins

 .../arm64/boot/dts/qcom/ipq5018-rdp432-c2.dts | 37 +++++++++++++++++++
 1 file changed, 37 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/ipq5018-rdp432-c2.dts b/arch/arm64/boot/dts/qcom/ipq5018-rdp432-c2.dts
index 8460b538eb6a..602c3c2d6ca3 100644
--- a/arch/arm64/boot/dts/qcom/ipq5018-rdp432-c2.dts
+++ b/arch/arm64/boot/dts/qcom/ipq5018-rdp432-c2.dts
@@ -28,6 +28,19 @@ &blsp1_uart1 {
 	status = "okay";
 };
 
+&pcie1 {
+	pinctrl-0 = <&pcie1_default>;
+	pinctrl-names = "default";
+
+	perst-gpios = <&tlmm 15 GPIO_ACTIVE_LOW>;
+	wake-gpios = <&tlmm 19 GPIO_ACTIVE_LOW>;
+	status = "okay";
+};
+
+&pcie_x2phy {
+	status = "okay";
+};
+
 &sdhc_1 {
 	pinctrl-0 = <&sdc_default_state>;
 	pinctrl-names = "default";
@@ -43,6 +56,30 @@ &sleep_clk {
 };
 
 &tlmm {
+	pcie1_default: pcie1-default-state {
+		clkreq-n-pins {
+			pins = "gpio17";
+			function = "pcie1_clk";
+			drive-strength = <6>;
+			bias-pull-up;
+		};
+
+		perst-n-pins {
+			pins = "gpio15";
+			function = "gpio";
+			drive-strength = <8>;
+			bias-pull-down;
+			output-low;
+		};
+
+		wake-n-pins {
+			pins = "gpio19";
+			function = "pcie1_wake";
+			drive-strength = <6>;
+			bias-pull-up;
+		};
+	};
+
 	sdc_default_state: sdc-default-state {
 		clk-pins {
 			pins = "gpio9";
-- 
2.34.1



From dmitry.baryshkov at linaro.org  Fri Aug 30 01:20:44 2024
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Fri, 30 Aug 2024 11:20:44 +0300
Subject: [PATCH v2 0/2] phy: add NXP PTN3222 eUSB2 to USB2 redriver
Message-ID: <20240830-nxp-ptn3222-v2-0-4c6d8535cf6c@linaro.org>

The NXP PTN3222 is the single-port eUSB2 to USB2 redriver that performs
translation between eUSB2 and USB2 signalling schemes. It supports all
three data rates: Low Speed, Full Speed and High Speed.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
---
Changes in v2:
- Switched to devm_regulator_bulk_get_const() (Neil)
- Link to v1: https://lore.kernel.org/r/20240829-nxp-ptn3222-v1-0-46906bc4747a at linaro.org

---
Dmitry Baryshkov (2):
      dt-bindings: phy: add NXP PTN3222 eUSB2 to USB2 redriver
      phy: add NXP PTN3222 eUSB2 to USB2 redriver

 .../devicetree/bindings/phy/nxp,ptn3222.yaml       |  55 +++++++++
 drivers/phy/Kconfig                                |  11 ++
 drivers/phy/Makefile                               |   1 +
 drivers/phy/phy-nxp-ptn3222.c                      | 123 +++++++++++++++++++++
 4 files changed, 190 insertions(+)
---
base-commit: 195a402a75791e6e0d96d9da27ca77671bc656a8
change-id: 20240829-nxp-ptn3222-30bbb81e984e

Best regards,
-- 
Dmitry Baryshkov <dmitry.baryshkov at linaro.org>



From dmitry.baryshkov at linaro.org  Fri Aug 30 01:20:45 2024
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Fri, 30 Aug 2024 11:20:45 +0300
Subject: [PATCH v2 1/2] dt-bindings: phy: add NXP PTN3222 eUSB2 to USB2
 redriver
In-Reply-To: <20240830-nxp-ptn3222-v2-0-4c6d8535cf6c@linaro.org>
References: <20240830-nxp-ptn3222-v2-0-4c6d8535cf6c@linaro.org>
Message-ID: <20240830-nxp-ptn3222-v2-1-4c6d8535cf6c@linaro.org>

The NXP PTN3222 is the single-port eUSB2 to USB2 redriver that performs
translation between eUSB2 and USB2 signalling schemes. It supports all
three data rates: Low Speed, Full Speed and High Speed.

Reviewed-by: Conor Dooley <conor.dooley at microchip.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
---
 .../devicetree/bindings/phy/nxp,ptn3222.yaml       | 55 ++++++++++++++++++++++
 1 file changed, 55 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/nxp,ptn3222.yaml b/Documentation/devicetree/bindings/phy/nxp,ptn3222.yaml
new file mode 100644
index 000000000000..acec5bb2391d
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/nxp,ptn3222.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/nxp,ptn3222.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP PTN3222 1-port eUSB2 to USB2 redriver
+
+maintainers:
+  - Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
+
+properties:
+  compatible:
+    enum:
+      - nxp,ptn3222
+
+  reg:
+    maxItems: 1
+
+  "#phy-cells":
+    const: 0
+
+  vdd1v8-supply:
+    description: power supply (1.8V)
+
+  vdd3v3-supply:
+    description: power supply (3.3V)
+
+  reset-gpios: true
+
+required:
+  - compatible
+  - reg
+  - '#phy-cells'
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/gpio/gpio.h>
+
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        redriver at 4f {
+            compatible = "nxp,ptn3222";
+            reg = <0x4f>;
+            #phy-cells = <0>;
+            vdd3v3-supply = <&vreg_3p3>;
+            vdd1v8-supply = <&vreg_1p8>;
+            reset-gpios = <&gpio_reset GPIO_ACTIVE_LOW>;
+        };
+    };
+...

-- 
2.39.2



From dmitry.baryshkov at linaro.org  Fri Aug 30 01:20:46 2024
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Fri, 30 Aug 2024 11:20:46 +0300
Subject: [PATCH v2 2/2] phy: add NXP PTN3222 eUSB2 to USB2 redriver
In-Reply-To: <20240830-nxp-ptn3222-v2-0-4c6d8535cf6c@linaro.org>
References: <20240830-nxp-ptn3222-v2-0-4c6d8535cf6c@linaro.org>
Message-ID: <20240830-nxp-ptn3222-v2-2-4c6d8535cf6c@linaro.org>

The NXP PTN3222 is the single-port eUSB2 to USB2 redriver that performs
translation between eUSB2 and USB2 signalling schemes. It supports all
three data rates: Low Speed, Full Speed and High Speed.

The reset state enables autonegotiation of the PHY role and of the data
rate, so no additional programming is required.

Reviewed-by: Neil Armstrong <neil.armstrong at linaro.org>
Tested-by: Konrad Dybcio <konradybcio at kernel.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
---
 drivers/phy/Kconfig           |  11 ++++
 drivers/phy/Makefile          |   1 +
 drivers/phy/phy-nxp-ptn3222.c | 123 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 135 insertions(+)

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index dfab1c66b3e5..cb06a7f79740 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -82,6 +82,17 @@ config PHY_AIROHA_PCIE
 	  This driver create the basic PHY instance and provides initialize
 	  callback for PCIe GEN3 port.
 
+config PHY_NXP_PTN3222
+	tristate "NXP PTN3222 1-port eUSB2 to USB2 redriver"
+	depends on I2C
+	depends on OF
+	select GENERIC_PHY
+	help
+	  Enable this to support NXP PTN3222 1-port eUSB2 to USB2 Redriver.
+	  This redriver performs translation between eUSB2 and USB2 signalling
+	  schemes. It supports all three USB 2.0 data rates: Low Speed, Full
+	  Speed and High Speed.
+
 source "drivers/phy/allwinner/Kconfig"
 source "drivers/phy/amlogic/Kconfig"
 source "drivers/phy/broadcom/Kconfig"
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 5fcbce5f9ab1..b64247046575 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_PHY_XGENE)			+= phy-xgene.o
 obj-$(CONFIG_PHY_PISTACHIO_USB)		+= phy-pistachio-usb.o
 obj-$(CONFIG_USB_LGM_PHY)		+= phy-lgm-usb.o
 obj-$(CONFIG_PHY_AIROHA_PCIE)		+= phy-airoha-pcie.o
+obj-$(CONFIG_PHY_NXP_PTN3222)		+= phy-nxp-ptn3222.o
 obj-y					+= allwinner/	\
 					   amlogic/	\
 					   broadcom/	\
diff --git a/drivers/phy/phy-nxp-ptn3222.c b/drivers/phy/phy-nxp-ptn3222.c
new file mode 100644
index 000000000000..c6179d8701e6
--- /dev/null
+++ b/drivers/phy/phy-nxp-ptn3222.c
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2024, Linaro Limited
+ */
+
+#include <linux/gpio/consumer.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/phy/phy.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+
+#define NUM_SUPPLIES 2
+
+struct ptn3222 {
+	struct i2c_client *client;
+	struct phy *phy;
+	struct gpio_desc *reset_gpio;
+	struct regulator_bulk_data *supplies;
+};
+
+static int ptn3222_init(struct phy *phy)
+{
+	struct ptn3222 *ptn3222 = phy_get_drvdata(phy);
+	int ret;
+
+	ret = regulator_bulk_enable(NUM_SUPPLIES, ptn3222->supplies);
+	if (ret)
+		return ret;
+
+	gpiod_set_value_cansleep(ptn3222->reset_gpio, 0);
+
+	return 0;
+}
+
+static int ptn3222_exit(struct phy *phy)
+{
+	struct ptn3222 *ptn3222 = phy_get_drvdata(phy);
+
+	gpiod_set_value_cansleep(ptn3222->reset_gpio, 1);
+
+	return regulator_bulk_disable(NUM_SUPPLIES, ptn3222->supplies);
+}
+
+static const struct phy_ops ptn3222_ops = {
+	.init		= ptn3222_init,
+	.exit		= ptn3222_exit,
+	.owner		= THIS_MODULE,
+};
+
+static const struct regulator_bulk_data ptn3222_supplies[NUM_SUPPLIES] = {
+	{
+		.supply = "vdd3v3",
+		.init_load_uA = 11000,
+	}, {
+		.supply = "vdd1v8",
+		.init_load_uA = 55000,
+	}
+};
+
+static int ptn3222_probe(struct i2c_client *client)
+{
+	struct device *dev = &client->dev;
+	struct phy_provider *phy_provider;
+	struct ptn3222 *ptn3222;
+	int ret;
+
+	ptn3222 = devm_kzalloc(dev, sizeof(*ptn3222), GFP_KERNEL);
+	if (!ptn3222)
+		return -ENOMEM;
+
+	ptn3222->client = client;
+
+	ptn3222->reset_gpio = devm_gpiod_get_optional(dev, "reset",
+						      GPIOD_OUT_HIGH);
+	if (IS_ERR(ptn3222->reset_gpio))
+		return dev_err_probe(dev, PTR_ERR(ptn3222->reset_gpio),
+				     "unable to acquire reset gpio\n");
+
+	ret = devm_regulator_bulk_get_const(dev, NUM_SUPPLIES, ptn3222_supplies,
+					    &ptn3222->supplies);
+	if (ret)
+		return ret;
+
+	ptn3222->phy = devm_phy_create(dev, dev->of_node, &ptn3222_ops);
+	if (IS_ERR(ptn3222->phy)) {
+		dev_err(dev, "failed to create PHY: %d\n", ret);
+		return PTR_ERR(ptn3222->phy);
+	}
+
+	phy_set_drvdata(ptn3222->phy, ptn3222);
+
+	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
+
+	return PTR_ERR_OR_ZERO(phy_provider);
+}
+
+static const struct i2c_device_id ptn3222_table[] = {
+	{ "ptn3222" },
+	{ }
+};
+MODULE_DEVICE_TABLE(i2c, ptn3222_table);
+
+static const struct of_device_id ptn3222_of_table[] = {
+	{ .compatible = "nxp,ptn3222" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, ptn3222_of_table);
+
+static struct i2c_driver ptn3222_driver = {
+	.driver = {
+		.name = "ptn3222",
+		.of_match_table = ptn3222_of_table,
+	},
+	.probe = ptn3222_probe,
+	.id_table = ptn3222_table,
+};
+
+module_i2c_driver(ptn3222_driver);
+
+MODULE_DESCRIPTION("NXP PTN3222 eUSB2 Redriver driver");
+MODULE_LICENSE("GPL");

-- 
2.39.2



From claudiu.beznea at tuxon.dev  Fri Aug 30 01:22:41 2024
From: claudiu.beznea at tuxon.dev (claudiu beznea)
Date: Fri, 30 Aug 2024 11:22:41 +0300
Subject: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
In-Reply-To: <CAPDyKFrS4Dhd7DZa2zz=oPro1TiTJFix0awzzzp8Qatm-8Z2Ug@mail.gmail.com>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
 <CAPDyKFrS4Dhd7DZa2zz=oPro1TiTJFix0awzzzp8Qatm-8Z2Ug@mail.gmail.com>
Message-ID: <99bef301-9f6c-4797-b47e-c83e56dfbda9@tuxon.dev>

Hi, Ulf,

On 29.08.2024 18:26, Ulf Hansson wrote:
> On Thu, 22 Aug 2024 at 17:28, Claudiu <claudiu.beznea at tuxon.dev> wrote:
>>
>> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>>
>> Hi,
>>
>> Series adds initial USB support for the Renesas RZ/G3S SoC.
>>
>> Series is split as follows:
>>
>> - patch 01/16           - add clock reset and power domain support for USB
>> - patch 02-04/16        - add reset control support for a USB signal
>>                           that need to be controlled before/after
>>                           the power to USB area is turned on/off.
>>
>>                           Philipp, Ulf, Geert, all,
>>
>>                           I detailed my approach for this in patch
>>                           04/16, please have a look and let me know
>>                           your input.
> 
> I have looked briefly. Your suggested approach may work, but I have a
> few thoughts, see below.
> 
> If I understand correctly, it is the consumer driver for the device
> that is attached to the USB power domain that becomes responsible for
> asserting/de-asserting this new signal. Right?

Right!

> 
> In this regard, please note that the consumer driver doesn't really
> know when the power domain really gets powered-on/off. Calling
> pm_runtime_get|put*() is dealing with the reference counting. For
> example, a call to pm_runtime_get*() just makes sure that the PM
> domain gets-or-remains powered-on. Could this be a problem from the
> reset-signal point of view?

It should be safe. From the HW manual I understand the hardware block is
something like the following:


                  USB area
         +-------------------------+
         |                         |
         | PHY --->USB controller  |
SYSC --> |  ^                      |
         |  |                      |
         | PHY reset               |
         +-------------------------+

Where:
- SYSC is the system controller that controls the new signal for which
  I'm requesting opinions in this series
- PHY reset: is the block controlling the PHYs
- PHY: is the block controlling the USB PHYs
- USB controller: is the USB controller

Currently, I passed the SYSC signal handling to the PHY reset driver; w/o
PHY reset the rest of the USB logic cannot work (neither PHY block nor USB
controller).

Currently, the PHY reset driver call pm_runtime_resume_and_get() in probe
and pm_runtime_put() in remove. The struct reset_control_ops::{assert,
deassert} only set specific bits in registers (no pm_runtime* calls).

The PHY driver is taking its PHY reset in probe and release it in remove().
With this approach the newly introduced SYSC signal will be
de-asserted/asserted only in the PHY reset probe/remove (either if it is
handled though PM domain or reset control signal).

If the SYSC signal would be passed to all the blocks in the USB area (and
it would be handled though PM domains) it should be no problem either,
AFAICT, because of reference counting the pm_runtime_get|put*() is taking
care of. As the PHY reset is the root node the in the devices node tree for
USB the reference counting should work, too (I may miss something though,
please correct me if I'm wrong).

If the SYSC signal would be handled though a reset control driver (as
proposed in this series) and we want to pass this reference to all the
blocks in the USB area then we can request the reset signal as shared and,
AFAIK, this is also reference counted. The devices node tree should help
with the order, too, if I'm not wrong.

Thank you for looking at this,
Claudiu Beznea

> 
> [...]
> 
> Kind regards
> Uffe


From krzk at kernel.org  Fri Aug 30 01:23:44 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Fri, 30 Aug 2024 10:23:44 +0200
Subject: [PATCH V3 1/6] dt-bindings: phy: qcom,uniphy-pcie: Document PCIe
 uniphy
In-Reply-To: <20240830081132.4016860-2-quic_srichara@quicinc.com>
References: <20240830081132.4016860-1-quic_srichara@quicinc.com>
 <20240830081132.4016860-2-quic_srichara@quicinc.com>
Message-ID: <e2qgpvfccpo2sd4mbrynxruvt5attqmtd5oik26of7tv7u4lq6@kvb63sglwa5b>

On Fri, Aug 30, 2024 at 01:41:27PM +0530, Sricharan R wrote:
> From: Nitheesh Sekar <quic_nsekar at quicinc.com>
> 
> Document the Qualcomm UNIPHY PCIe 28LP present in IPQ5018.
> 
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> Signed-off-by: Nitheesh Sekar <quic_nsekar at quicinc.com>
> Signed-off-by: Sricharan Ramabadhran <quic_srichara at quicinc.com>
> ---
>  [v3] Added reviewed-by tags
> 
>  .../phy/qcom,ipq5018-uniphy-pcie.yaml         | 70 +++++++++++++++++++
>  1 file changed, 70 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/qcom,ipq5018-uniphy-pcie.yaml
> 
> diff --git a/Documentation/devicetree/bindings/phy/qcom,ipq5018-uniphy-pcie.yaml b/Documentation/devicetree/bindings/phy/qcom,ipq5018-uniphy-pcie.yaml
> new file mode 100644
> index 000000000000..c04dd179eb8b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/qcom,ipq5018-uniphy-pcie.yaml
> @@ -0,0 +1,70 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/qcom,ipq5018-uniphy-pcie.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm UNIPHY PCIe 28LP PHY controller for genx1, genx2
> +
> +maintainers:
> +  - Nitheesh Sekar <quic_nsekar at quicinc.com>
> +  - Sricharan Ramabadhran <quic_srichara at quicinc.com>
> +
> +properties:
> +  compatible:
> +    enum:
> +      - qcom,ipq5018-uniphy-pcie-gen2x1
> +      - qcom,ipq5018-uniphy-pcie-gen2x2

... and now I wonder why there are two compatibles. Isn't the phy the
same? We talk about the same hardware?

Best regards,
Krzysztof



From manivannan.sadhasivam at linaro.org  Fri Aug 30 01:35:51 2024
From: manivannan.sadhasivam at linaro.org (Manivannan Sadhasivam)
Date: Fri, 30 Aug 2024 14:05:51 +0530
Subject: [PATCH V2 2/6] dt-bindings: PCI: qcom: Add IPQ5108 SoC
In-Reply-To: <20240827045757.1101194-3-quic_srichara@quicinc.com>
References: <20240827045757.1101194-1-quic_srichara@quicinc.com>
 <20240827045757.1101194-3-quic_srichara@quicinc.com>
Message-ID: <20240830083551.yazww3kj2shf4ocq@thinkpad>

On Tue, Aug 27, 2024 at 10:27:53AM +0530, Sricharan R wrote:
> From: Nitheesh Sekar <quic_nsekar at quicinc.com>
> 
> Add support for the PCIe controller on the Qualcomm
> IPQ5108 SoC to the bindings.
> 
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> Signed-off-by: Nitheesh Sekar <quic_nsekar at quicinc.com>
> Signed-off-by: Sricharan Ramabadhran <quic_srichara at quicinc.com>

Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam at linaro.org>

- Mani

> ---
>  [v2] Added reviewed by tag
> 
>  .../devicetree/bindings/pci/qcom,pcie.yaml    | 35 +++++++++++++++++++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
> index f867746b1ae5..c12efa27b8d8 100644
> --- a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
> +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
> @@ -21,6 +21,7 @@ properties:
>            - qcom,pcie-apq8064
>            - qcom,pcie-apq8084
>            - qcom,pcie-ipq4019
> +          - qcom,pcie-ipq5018
>            - qcom,pcie-ipq6018
>            - qcom,pcie-ipq8064
>            - qcom,pcie-ipq8064-v2
> @@ -312,6 +313,39 @@ allOf:
>              - const: ahb # AHB reset
>              - const: phy_ahb # PHY AHB reset
>  
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - qcom,pcie-ipq5018
> +    then:
> +      properties:
> +        clocks:
> +          minItems: 6
> +          maxItems: 6
> +        clock-names:
> +          items:
> +            - const: iface # PCIe to SysNOC BIU clock
> +            - const: axi_m # AXI Master clock
> +            - const: axi_s # AXI Slave clock
> +            - const: ahb # AHB clock
> +            - const: aux # Auxiliary clock
> +            - const: axi_bridge # AXI bridge clock
> +        resets:
> +          minItems: 8
> +          maxItems: 8
> +        reset-names:
> +          items:
> +            - const: pipe # PIPE reset
> +            - const: sleep # Sleep reset
> +            - const: sticky # Core sticky reset
> +            - const: axi_m # AXI master reset
> +            - const: axi_s # AXI slave reset
> +            - const: ahb # AHB reset
> +            - const: axi_m_sticky # AXI master sticky reset
> +            - const: axi_s_sticky # AXI slave sticky reset
> +
>    - if:
>        properties:
>          compatible:
> @@ -503,6 +537,7 @@ allOf:
>                enum:
>                  - qcom,pcie-apq8064
>                  - qcom,pcie-ipq4019
> +                - qcom,pcie-ipq5018
>                  - qcom,pcie-ipq8064
>                  - qcom,pcie-ipq8064v2
>                  - qcom,pcie-ipq8074
> -- 
> 2.34.1
> 

-- 
????????? ????????


From ilordash02 at gmail.com  Fri Aug 30 01:36:56 2024
From: ilordash02 at gmail.com (Ilya Orazov)
Date: Fri, 30 Aug 2024 11:36:56 +0300
Subject: [PATCH v4 1/1] dt-bindings: phy: ti,tcan104x-can: Document
 Microchip ATA6561
In-Reply-To: <ZtC6S6I/QKihcsyu@vaman>
References: <20240822105238.213019-1-ilordash02@gmail.com> <20240822105238.213019-2-ilordash02@gmail.com>
 <ZtC6S6I/QKihcsyu@vaman>
Message-ID: <CAGCz5HmTNtGJHoXmuFhC_43jTObDN+Bxn0rLK3OfH-DBhacomA@mail.gmail.com>

On Thu, 29 Aug 2024 at 21:13, Vinod Koul <vkoul at kernel.org> wrote:
>
> On 22-08-24, 13:52, Ilya Orazov wrote:
> > Microchip ATA6561 is High-Speed CAN Transceiver with Standby Mode.
> > It is pin-compatible with TI TCAN1042 and has a compatible programming
> > model, therefore use ti,tcan1042 as fallback compatible.
> >
> > Acked-by: Conor Dooley <conor.dooley at microchip.com>
> > Signed-off-by: Ilya Orazov <ilordash02 at gmail.com>
> > ---
> >  .../devicetree/bindings/phy/ti,tcan104x-can.yaml    | 13 +++++++++----
> >  1 file changed, 9 insertions(+), 4 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> > index 79dad3e89aa6..4a8c3829d85d 100644
> > --- a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> > +++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> > @@ -14,10 +14,15 @@ properties:
> >      pattern: "^can-phy"
> >
> >    compatible:
> > -    enum:
> > -      - nxp,tjr1443
> > -      - ti,tcan1042
> > -      - ti,tcan1043
> > +    oneOf:
> > +      - items:
> > +          - enum:
> > +              - microchip,ata6561
> > +          - const: ti,tcan1042
> > +      - enum:
> > +          - ti,tcan1042
> > +          - ti,tcan1043
> > +          - nxp,tjr1443
>
> No driver/dt for new compatibles?

There is phy-can-transceiver.c driver that can be used also for
ata6561. I used this PHY in my own DTS. It is a popular chip, so I
decided to add ATA6561 to the kernel, as I believe it would be
beneficial.


>
> >
> >    '#phy-cells':
> >      const: 0
> > --
> > 2.34.1
>
> --
> ~Vinod



--
Best regards,
Ilya Orazov


From manivannan.sadhasivam at linaro.org  Fri Aug 30 01:38:52 2024
From: manivannan.sadhasivam at linaro.org (Manivannan Sadhasivam)
Date: Fri, 30 Aug 2024 14:08:52 +0530
Subject: [PATCH V2 4/6] PCI: qcom: Add support for IPQ5018
In-Reply-To: <20240827045757.1101194-5-quic_srichara@quicinc.com>
References: <20240827045757.1101194-1-quic_srichara@quicinc.com>
 <20240827045757.1101194-5-quic_srichara@quicinc.com>
Message-ID: <20240830083852.cwjc6skgypva6u6u@thinkpad>

On Tue, Aug 27, 2024 at 10:27:55AM +0530, Sricharan R wrote:
> Introduce a new compatible and re-use 2_9_0 ops.
> 

While adding a new SoC, please add more info about the controller. Like the
hardware revision (internal/synopsys), max number of lanes supported, max link
speed, is it a derivative etc...

- Mani

> Signed-off-by: Nitheesh Sekar <quic_nsekar at quicinc.com>
> Signed-off-by: Sricharan R <quic_srichara at quicinc.com>
> ---
>  [v2] Rebased on top of latest tip and only compatiable addition is required
> 
>  drivers/pci/controller/dwc/pcie-qcom.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
> index 6f953e32d990..e814d6cc062d 100644
> --- a/drivers/pci/controller/dwc/pcie-qcom.c
> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> @@ -1722,6 +1722,7 @@ static const struct of_device_id qcom_pcie_match[] = {
>  	{ .compatible = "qcom,pcie-apq8064", .data = &cfg_2_1_0 },
>  	{ .compatible = "qcom,pcie-apq8084", .data = &cfg_1_0_0 },
>  	{ .compatible = "qcom,pcie-ipq4019", .data = &cfg_2_4_0 },
> +	{ .compatible = "qcom,pcie-ipq5018", .data = &cfg_2_9_0 },
>  	{ .compatible = "qcom,pcie-ipq6018", .data = &cfg_2_9_0 },
>  	{ .compatible = "qcom,pcie-ipq8064", .data = &cfg_2_1_0 },
>  	{ .compatible = "qcom,pcie-ipq8064-v2", .data = &cfg_2_1_0 },
> -- 
> 2.34.1
> 

-- 
????????? ????????


From manivannan.sadhasivam at linaro.org  Fri Aug 30 01:59:01 2024
From: manivannan.sadhasivam at linaro.org (Manivannan Sadhasivam)
Date: Fri, 30 Aug 2024 14:29:01 +0530
Subject: [PATCH V2 5/6] arm64: dts: qcom: ipq5018: Add PCIe related nodes
In-Reply-To: <20240827045757.1101194-6-quic_srichara@quicinc.com>
References: <20240827045757.1101194-1-quic_srichara@quicinc.com>
 <20240827045757.1101194-6-quic_srichara@quicinc.com>
Message-ID: <20240830085901.oeiuuijlvq2ydho2@thinkpad>

On Tue, Aug 27, 2024 at 10:27:56AM +0530, Sricharan R wrote:
> From: Nitheesh Sekar <quic_nsekar at quicinc.com>
> 
> Add phy and controller nodes for a 2-lane Gen2 and
> 1-lane Gen2 PCIe buses.
> 
> Signed-off-by: Nitheesh Sekar <quic_nsekar at quicinc.com>
> Signed-off-by: Sricharan R <quic_srichara at quicinc.com>
> ---
>  [v2] Removed relocatable flags,  removed assigned-clock-rates,
>       fixed rest of the cosmetic comments.
> 
>  arch/arm64/boot/dts/qcom/ipq5018.dtsi | 168 +++++++++++++++++++++++++-
>  1 file changed, 166 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/ipq5018.dtsi b/arch/arm64/boot/dts/qcom/ipq5018.dtsi
> index 7e6e2c121979..dd5d6b7ff094 100644
> --- a/arch/arm64/boot/dts/qcom/ipq5018.dtsi
> +++ b/arch/arm64/boot/dts/qcom/ipq5018.dtsi
> @@ -9,6 +9,7 @@
>  #include <dt-bindings/interrupt-controller/arm-gic.h>
>  #include <dt-bindings/clock/qcom,gcc-ipq5018.h>
>  #include <dt-bindings/reset/qcom,gcc-ipq5018.h>
> +#include <dt-bindings/gpio/gpio.h>
>  
>  / {
>  	interrupt-parent = <&intc>;
> @@ -143,7 +144,33 @@ usbphy0: phy at 5b000 {
>  			resets = <&gcc GCC_QUSB2_0_PHY_BCR>;
>  
>  			#phy-cells = <0>;
> +		};
> +
> +		pcie_x1phy: phy at 7e000{
> +			compatible = "qcom,ipq5018-uniphy-pcie-gen2x1";
> +			reg = <0x0007e000 0x800>;
> +			#phy-cells = <0>;
> +			#clock-cells = <0>;
> +			clocks = <&gcc GCC_PCIE1_PIPE_CLK>;
> +			clock-names = "pipe";
> +			assigned-clocks = <&gcc GCC_PCIE1_PIPE_CLK>;
> +			resets = <&gcc GCC_PCIE1_PHY_BCR>,
> +				 <&gcc GCC_PCIE1PHY_PHY_BCR>;
> +			reset-names = "phy", "common";
> +			status = "disabled";
> +		};
>  
> +		pcie_x2phy: phy at 86000{
> +			compatible = "qcom,ipq5018-uniphy-pcie-gen2x2";
> +			reg = <0x00086000 0x1000>;
> +			#phy-cells = <0>;
> +			#clock-cells = <0>;
> +			clocks = <&gcc GCC_PCIE0_PIPE_CLK>;
> +			clock-names = "pipe";
> +			assigned-clocks = <&gcc GCC_PCIE0_PIPE_CLK>;
> +			resets = <&gcc GCC_PCIE0_PHY_BCR>,
> +				 <&gcc GCC_PCIE0PHY_PHY_BCR>;
> +			reset-names = "phy", "common";
>  			status = "disabled";
>  		};
>  
> @@ -170,8 +197,8 @@ gcc: clock-controller at 1800000 {
>  			reg = <0x01800000 0x80000>;
>  			clocks = <&xo_board_clk>,
>  				 <&sleep_clk>,
> -				 <0>,
> -				 <0>,
> +				 <&pcie_x2phy>,
> +				 <&pcie_x1phy>,
>  				 <0>,
>  				 <0>,
>  				 <0>,
> @@ -387,6 +414,143 @@ frame at b128000 {
>  				status = "disabled";
>  			};
>  		};
> +
> +		pcie0: pci at 80000000 {

pcie@

> +			compatible = "qcom,pcie-ipq5018";
> +			reg =  <0x80000000 0xf1d>,
> +			       <0x80000f20 0xa8>,
> +			       <0x80001000 0x1000>,
> +			       <0x00078000 0x3000>,
> +			       <0x80100000 0x1000>;

Are you sure that the config space is only 4K?

> +			reg-names = "dbi", "elbi", "atu", "parf", "config";
> +			device_type = "pci";
> +			linux,pci-domain = <0>;
> +			bus-range = <0x00 0xff>;
> +			num-lanes = <1>;
> +			max-link-speed = <2>;
> +			#address-cells = <3>;
> +			#size-cells = <2>;
> +
> +			phys = <&pcie_x1phy>;
> +			phy-names ="pciephy";
> +
> +			ranges = <0x01000000 0 0x80200000 0x80200000 0 0x00100000

Please check the value of this field in other SoCs.

> +				  0x02000000 0 0x80300000 0x80300000 0 0x10000000>;
> +
> +			#interrupt-cells = <1>;
> +			interrupt-map-mask = <0 0 0 0x7>;
> +			interrupt-map = <0 0 0 1 &intc 0 0 142 IRQ_TYPE_LEVEL_HIGH>,
> +					<0 0 0 2 &intc 0 0 143 IRQ_TYPE_LEVEL_HIGH>,
> +					<0 0 0 3 &intc 0 0 144 IRQ_TYPE_LEVEL_HIGH>,
> +					<0 0 0 4 &intc 0 0 145 IRQ_TYPE_LEVEL_HIGH>;
> +
> +			interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
> +			interrupt-names = "global_irq";

I'm pretty sure that this SoC has SPI based MSI interrupts. So they should be
described even though ITS is supported.

> +
> +			clocks = <&gcc GCC_SYS_NOC_PCIE1_AXI_CLK>,
> +				 <&gcc GCC_PCIE1_AXI_M_CLK>,
> +				 <&gcc GCC_PCIE1_AXI_S_CLK>,
> +				 <&gcc GCC_PCIE1_AHB_CLK>,
> +				 <&gcc GCC_PCIE1_AUX_CLK>,
> +				 <&gcc GCC_PCIE1_AXI_S_BRIDGE_CLK>;
> +
> +			clock-names = "iface",
> +				      "axi_m",
> +				      "axi_s",
> +				      "ahb",
> +				      "aux",
> +				      "axi_bridge";
> +
> +			resets = <&gcc GCC_PCIE1_PIPE_ARES>,
> +				 <&gcc GCC_PCIE1_SLEEP_ARES>,
> +				 <&gcc GCC_PCIE1_CORE_STICKY_ARES>,
> +				 <&gcc GCC_PCIE1_AXI_MASTER_ARES>,
> +				 <&gcc GCC_PCIE1_AXI_SLAVE_ARES>,
> +				 <&gcc GCC_PCIE1_AHB_ARES>,
> +				 <&gcc GCC_PCIE1_AXI_MASTER_STICKY_ARES>,
> +				 <&gcc GCC_PCIE1_AXI_SLAVE_STICKY_ARES>;
> +
> +			reset-names = "pipe",
> +				      "sleep",
> +				      "sticky",
> +				      "axi_m",
> +				      "axi_s",
> +				      "ahb",
> +				      "axi_m_sticky",
> +				      "axi_s_sticky";
> +
> +			msi-map = <0x0 &v2m0 0x0 0xff8>;
> +			status = "disabled";

Please add the rootport node also as like other SoCs.

Above comments applies to below PCIe node.

- Mani

> +		};
> +
> +		pcie1: pci at a0000000 {
> +			compatible = "qcom,pcie-ipq5018";
> +			reg =  <0xa0000000 0xf1d>,
> +			       <0xa0000f20 0xa8>,
> +			       <0xa0001000 0x1000>,
> +			       <0x00080000 0x3000>,
> +			       <0xa0100000 0x1000>;
> +			reg-names = "dbi", "elbi", "atu", "parf", "config";
> +			device_type = "pci";
> +			linux,pci-domain = <1>;
> +			bus-range = <0x00 0xff>;
> +			num-lanes = <2>;
> +			max-link-speed = <2>;
> +			#address-cells = <3>;
> +			#size-cells = <2>;
> +
> +			phys = <&pcie_x2phy>;
> +			phy-names ="pciephy";
> +
> +			ranges = <0x01000000 0 0xa0200000 0xa0200000 0 0x00100000
> +				  0x02000000 0 0xa0300000 0xa0300000 0 0x10000000>;
> +
> +			#interrupt-cells = <1>;
> +			interrupt-map-mask = <0 0 0 0x7>;
> +			interrupt-map = <0 0 0 1 &intc 0 0 75 IRQ_TYPE_LEVEL_HIGH>,
> +					<0 0 0 2 &intc 0 0 78 IRQ_TYPE_LEVEL_HIGH>,
> +					<0 0 0 3 &intc 0 0 79 IRQ_TYPE_LEVEL_HIGH>,
> +					<0 0 0 4 &intc 0 0 83 IRQ_TYPE_LEVEL_HIGH>;
> +
> +			interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
> +			interrupt-names = "global_irq";
> +
> +			clocks = <&gcc GCC_SYS_NOC_PCIE0_AXI_CLK>,
> +				 <&gcc GCC_PCIE0_AXI_M_CLK>,
> +				 <&gcc GCC_PCIE0_AXI_S_CLK>,
> +				 <&gcc GCC_PCIE0_AHB_CLK>,
> +				 <&gcc GCC_PCIE0_AUX_CLK>,
> +				 <&gcc GCC_PCIE0_AXI_S_BRIDGE_CLK>;
> +
> +			clock-names = "iface",
> +				      "axi_m",
> +				      "axi_s",
> +				      "ahb",
> +				      "aux",
> +				      "axi_bridge";
> +
> +			resets = <&gcc GCC_PCIE0_PIPE_ARES>,
> +				 <&gcc GCC_PCIE0_SLEEP_ARES>,
> +				 <&gcc GCC_PCIE0_CORE_STICKY_ARES>,
> +				 <&gcc GCC_PCIE0_AXI_MASTER_ARES>,
> +				 <&gcc GCC_PCIE0_AXI_SLAVE_ARES>,
> +				 <&gcc GCC_PCIE0_AHB_ARES>,
> +				 <&gcc GCC_PCIE0_AXI_MASTER_STICKY_ARES>,
> +				 <&gcc GCC_PCIE0_AXI_SLAVE_STICKY_ARES>;
> +
> +			reset-names = "pipe",
> +				      "sleep",
> +				      "sticky",
> +				      "axi_m",
> +				      "axi_s",
> +				      "ahb",
> +				      "axi_m_sticky",
> +				      "axi_s_sticky";
> +
> +			msi-map = <0x0 &v2m0 0x0 0xff8>;
> +			status = "disabled";
> +		};
> +
>  	};
>  
>  	timer {
> -- 
> 2.34.1
> 

-- 
????????? ????????


From krzk at kernel.org  Fri Aug 30 03:01:27 2024
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Fri, 30 Aug 2024 12:01:27 +0200
Subject: [PATCH v3 0/2] phy: qcom: qmp-pcie: Add support for Gen4 4-lane
 mode for X1E80100
In-Reply-To: <172495833400.405683.4328817324548517864.b4-ty@kernel.org>
References: <20240823-x1e80100-phy-add-gen4x4-v3-0-b7765631ca01@linaro.org>
 <172495833400.405683.4328817324548517864.b4-ty@kernel.org>
Message-ID: <4ab9dcb6-4a0b-493c-943b-5de05457c592@kernel.org>

On 29/08/2024 21:05, Vinod Koul wrote:
> 
> On Fri, 23 Aug 2024 10:04:14 +0300, Abel Vesa wrote:
>> On all X Elite boards currently supported upstream, the NVMe sits
>> on the PCIe 6. Until now that has been configured in dual lane mode
>> only. The schematics reveal that the NVMe is actually using 4 lanes.
>> So add support for the 4-lane mode and document the compatible for it.
>>
>> This patchset depends on:
>> https://lore.kernel.org/all/20240805-phy-qcom-qmp-pcie-write-all-tbls-second-port-v3-1-6967c6bf61d1 at linaro.org/
>>
>> [...]
> 
> Applied, thanks!
> 
> [1/2] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Document the X1E80100 QMP PCIe PHY Gen4 x4
>       commit: 0c5f4d23f77631f657b60ef660676303f7620688

Heh, we discussed yesterday on IRC that this should wait.

Why do we keep discussing things in private...

Best regards,
Krzysztof



From ulf.hansson at linaro.org  Fri Aug 30 03:14:33 2024
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Fri, 30 Aug 2024 12:14:33 +0200
Subject: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
In-Reply-To: <99bef301-9f6c-4797-b47e-c83e56dfbda9@tuxon.dev>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
 <CAPDyKFrS4Dhd7DZa2zz=oPro1TiTJFix0awzzzp8Qatm-8Z2Ug@mail.gmail.com> <99bef301-9f6c-4797-b47e-c83e56dfbda9@tuxon.dev>
Message-ID: <CAPDyKFrVS2vpsJqTvjKCJ7ADqXc4D4k2eeCBsaK4T+=pXDnKUA@mail.gmail.com>

On Fri, 30 Aug 2024 at 10:22, claudiu beznea <claudiu.beznea at tuxon.dev> wrote:
>
> Hi, Ulf,
>
> On 29.08.2024 18:26, Ulf Hansson wrote:
> > On Thu, 22 Aug 2024 at 17:28, Claudiu <claudiu.beznea at tuxon.dev> wrote:
> >>
> >> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> >>
> >> Hi,
> >>
> >> Series adds initial USB support for the Renesas RZ/G3S SoC.
> >>
> >> Series is split as follows:
> >>
> >> - patch 01/16           - add clock reset and power domain support for USB
> >> - patch 02-04/16        - add reset control support for a USB signal
> >>                           that need to be controlled before/after
> >>                           the power to USB area is turned on/off.
> >>
> >>                           Philipp, Ulf, Geert, all,
> >>
> >>                           I detailed my approach for this in patch
> >>                           04/16, please have a look and let me know
> >>                           your input.
> >
> > I have looked briefly. Your suggested approach may work, but I have a
> > few thoughts, see below.
> >
> > If I understand correctly, it is the consumer driver for the device
> > that is attached to the USB power domain that becomes responsible for
> > asserting/de-asserting this new signal. Right?
>
> Right!
>
> >
> > In this regard, please note that the consumer driver doesn't really
> > know when the power domain really gets powered-on/off. Calling
> > pm_runtime_get|put*() is dealing with the reference counting. For
> > example, a call to pm_runtime_get*() just makes sure that the PM
> > domain gets-or-remains powered-on. Could this be a problem from the
> > reset-signal point of view?
>
> It should be safe. From the HW manual I understand the hardware block is
> something like the following:
>
>
>                   USB area
>          +-------------------------+
>          |                         |
>          | PHY --->USB controller  |
> SYSC --> |  ^                      |
>          |  |                      |
>          | PHY reset               |
>          +-------------------------+
>
> Where:
> - SYSC is the system controller that controls the new signal for which
>   I'm requesting opinions in this series
> - PHY reset: is the block controlling the PHYs
> - PHY: is the block controlling the USB PHYs
> - USB controller: is the USB controller
>
> Currently, I passed the SYSC signal handling to the PHY reset driver; w/o
> PHY reset the rest of the USB logic cannot work (neither PHY block nor USB
> controller).
>
> Currently, the PHY reset driver call pm_runtime_resume_and_get() in probe
> and pm_runtime_put() in remove. The struct reset_control_ops::{assert,
> deassert} only set specific bits in registers (no pm_runtime* calls).

Thanks for clarifying!

For my understanding, in what register range do these bits belong? Is
it the USB logic or in the PM domain logic, or something else.

>
> The PHY driver is taking its PHY reset in probe and release it in remove().
> With this approach the newly introduced SYSC signal will be
> de-asserted/asserted only in the PHY reset probe/remove (either if it is
> handled though PM domain or reset control signal).
>
> If the SYSC signal would be passed to all the blocks in the USB area (and
> it would be handled though PM domains) it should be no problem either,
> AFAICT, because of reference counting the pm_runtime_get|put*() is taking
> care of. As the PHY reset is the root node the in the devices node tree for
> USB the reference counting should work, too (I may miss something though,
> please correct me if I'm wrong).
>
> If the SYSC signal would be handled though a reset control driver (as
> proposed in this series) and we want to pass this reference to all the
> blocks in the USB area then we can request the reset signal as shared and,
> AFAIK, this is also reference counted. The devices node tree should help
> with the order, too, if I'm not wrong.

Reference counting a reset signal sounds a bit weird to me, but I
guess it can work. :-)

To sum up from my side;

As long as it's fine that we may end up asserting/de-asserting the
reset-signal, without actually knowing if the PM domain is getting
turn-on/off, then using a reset-control like what you propose seems
okay to me.

If not, there are two other options that can be considered I think.
*) Using the genpd on/off notifiers, to really allow the consumer
driver of the reset-control to know when the PM domain gets turned
on/off.
**) Move the entire reset handling into the PM domain provider, as it
obviously knows when the domain is getting turned on/off.

Thanks again for your explanations!

Kind regards
Uffe


From dmitry.baryshkov at linaro.org  Fri Aug 30 03:42:10 2024
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Fri, 30 Aug 2024 13:42:10 +0300
Subject: [PATCH v3 1/2] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy:
 Document the X1E80100 QMP PCIe PHY Gen4 x4
In-Reply-To: <20240823-x1e80100-phy-add-gen4x4-v3-1-b7765631ca01@linaro.org>
References: <20240823-x1e80100-phy-add-gen4x4-v3-0-b7765631ca01@linaro.org>
 <20240823-x1e80100-phy-add-gen4x4-v3-1-b7765631ca01@linaro.org>
Message-ID: <gvx3sdsdxigel3iwu7vgvvgxohvnaqq6suogsqojeumobhwhdk@5qct23m5ncda>

On Fri, Aug 23, 2024 at 10:04:15AM GMT, Abel Vesa wrote:
> The sixth PCIe instance on X1E80100 can be used in either 4-lane mode or
> 2-lane mode. Document the 4-lane mode as a separate compatible.

As the patches were merged, it's too late for this series, but as a
note: we should think of a way to describe the PHY configuration without
changing the compatibility strings. The hardware stays the same, it's
just the number of lanes being wired that changes.

The obvious way to handle platform-specific differences is by using
num-lanes property of the PCIe host and then passing required
configuration (num lanes, max speed, etc.) to the PCIe PHY via
phy_configure() call.

> 
> Reviewed-by: Krzysztof Kozlowski <krzk at kernel.org>
> Reviewed-by: Johan Hovold <johan+linaro at kernel.org>
> Signed-off-by: Abel Vesa <abel.vesa at linaro.org>
> ---
>  Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> index 03dbd02cf9e7..dcf4fa55fbba 100644
> --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> @@ -40,6 +40,7 @@ properties:
>        - qcom,sm8650-qmp-gen4x2-pcie-phy
>        - qcom,x1e80100-qmp-gen3x2-pcie-phy
>        - qcom,x1e80100-qmp-gen4x2-pcie-phy
> +      - qcom,x1e80100-qmp-gen4x4-pcie-phy
>  
>    reg:
>      minItems: 1
> @@ -118,6 +119,7 @@ allOf:
>            contains:
>              enum:
>                - qcom,sc8280xp-qmp-gen3x4-pcie-phy
> +              - qcom,x1e80100-qmp-gen4x4-pcie-phy
>      then:
>        properties:
>          reg:
> @@ -169,6 +171,7 @@ allOf:
>                - qcom,sc8280xp-qmp-gen3x1-pcie-phy
>                - qcom,sc8280xp-qmp-gen3x2-pcie-phy
>                - qcom,sc8280xp-qmp-gen3x4-pcie-phy
> +              - qcom,x1e80100-qmp-gen4x4-pcie-phy
>      then:
>        properties:
>          clocks:
> 
> -- 
> 2.34.1
> 

-- 
With best wishes
Dmitry


From s-vadapalli at ti.com  Fri Aug 30 03:53:16 2024
From: s-vadapalli at ti.com (Siddharth Vadapalli)
Date: Fri, 30 Aug 2024 16:23:16 +0530
Subject: [PATCH] dt-bindings: phy: cadence-sierra: Allow PHY types QSGMII and SGMII
Message-ID: <20240830105316.1824319-1-s-vadapalli@ti.com>

The Sierra SERDES can be configured for QSGMII and SGMII protocols. Hence,
update the bindings to treat "PHY_TYPE_QSGMII" and "PHY_TYPE_SGMII" as
valid values for the "cdns,phy-type" property.

Signed-off-by: Siddharth Vadapalli <s-vadapalli at ti.com>
---

Hello,

This patch is based on linux-next tagged next-20240830.

Regards,
Siddharth.

 Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml b/Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml
index 37f028f7a095..137ac5703853 100644
--- a/Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml
+++ b/Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml
@@ -96,7 +96,7 @@ patternProperties:
           Specifies the type of PHY for which the group of PHY lanes is used.
           Refer include/dt-bindings/phy/phy.h. Constants from the header should be used.
         $ref: /schemas/types.yaml#/definitions/uint32
-        enum: [2, 4]
+        enum: [2, 4, 8, 9]
 
       cdns,num-lanes:
         description:
-- 
2.40.1



From claudiu.beznea at tuxon.dev  Fri Aug 30 04:32:06 2024
From: claudiu.beznea at tuxon.dev (claudiu beznea)
Date: Fri, 30 Aug 2024 14:32:06 +0300
Subject: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
In-Reply-To: <CAPDyKFrVS2vpsJqTvjKCJ7ADqXc4D4k2eeCBsaK4T+=pXDnKUA@mail.gmail.com>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
 <CAPDyKFrS4Dhd7DZa2zz=oPro1TiTJFix0awzzzp8Qatm-8Z2Ug@mail.gmail.com>
 <99bef301-9f6c-4797-b47e-c83e56dfbda9@tuxon.dev>
 <CAPDyKFrVS2vpsJqTvjKCJ7ADqXc4D4k2eeCBsaK4T+=pXDnKUA@mail.gmail.com>
Message-ID: <fa9b3449-ea3e-4482-b7eb-96999445cea5@tuxon.dev>



On 30.08.2024 13:14, Ulf Hansson wrote:
> On Fri, 30 Aug 2024 at 10:22, claudiu beznea <claudiu.beznea at tuxon.dev> wrote:
>>
>> Hi, Ulf,
>>
>> On 29.08.2024 18:26, Ulf Hansson wrote:
>>> On Thu, 22 Aug 2024 at 17:28, Claudiu <claudiu.beznea at tuxon.dev> wrote:
>>>>
>>>> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>>>>
>>>> Hi,
>>>>
>>>> Series adds initial USB support for the Renesas RZ/G3S SoC.
>>>>
>>>> Series is split as follows:
>>>>
>>>> - patch 01/16           - add clock reset and power domain support for USB
>>>> - patch 02-04/16        - add reset control support for a USB signal
>>>>                           that need to be controlled before/after
>>>>                           the power to USB area is turned on/off.
>>>>
>>>>                           Philipp, Ulf, Geert, all,
>>>>
>>>>                           I detailed my approach for this in patch
>>>>                           04/16, please have a look and let me know
>>>>                           your input.
>>>
>>> I have looked briefly. Your suggested approach may work, but I have a
>>> few thoughts, see below.
>>>
>>> If I understand correctly, it is the consumer driver for the device
>>> that is attached to the USB power domain that becomes responsible for
>>> asserting/de-asserting this new signal. Right?
>>
>> Right!
>>
>>>
>>> In this regard, please note that the consumer driver doesn't really
>>> know when the power domain really gets powered-on/off. Calling
>>> pm_runtime_get|put*() is dealing with the reference counting. For
>>> example, a call to pm_runtime_get*() just makes sure that the PM
>>> domain gets-or-remains powered-on. Could this be a problem from the
>>> reset-signal point of view?
>>
>> It should be safe. From the HW manual I understand the hardware block is
>> something like the following:
>>
>>
>>                   USB area
>>          +-------------------------+
>>          |                         |
>>          | PHY --->USB controller  |
>> SYSC --> |  ^                      |
>>          |  |                      |
>>          | PHY reset               |
>>          +-------------------------+
>>
>> Where:
>> - SYSC is the system controller that controls the new signal for which
>>   I'm requesting opinions in this series
>> - PHY reset: is the block controlling the PHYs
>> - PHY: is the block controlling the USB PHYs
>> - USB controller: is the USB controller
>>
>> Currently, I passed the SYSC signal handling to the PHY reset driver; w/o
>> PHY reset the rest of the USB logic cannot work (neither PHY block nor USB
>> controller).
>>
>> Currently, the PHY reset driver call pm_runtime_resume_and_get() in probe
>> and pm_runtime_put() in remove. The struct reset_control_ops::{assert,
>> deassert} only set specific bits in registers (no pm_runtime* calls).
> 
> Thanks for clarifying!
> 
> For my understanding, in what register range do these bits belong? Is
> it the USB logic or in the PM domain logic, or something else.

The PHY reset block is an individual hardware block with its own address
space, clocks and reset signals.

The PHY block may reside in the same address space with USB controller but
it can provide PHY support for an external USB controller, something like:

+--------------------------+
|  PHY ---> USB controller |
|   |                      |
+---|----------------------+
   \/
+---------------+
| USB controller|
+---------------+

Because of this the PHY block is modeled in Linux as a standalone driver.

And SYSC is an individual HW block with its own address space. This is
where it resides the control of the signal for which I'm asking for directions.

> 
>>
>> The PHY driver is taking its PHY reset in probe and release it in remove().
>> With this approach the newly introduced SYSC signal will be
>> de-asserted/asserted only in the PHY reset probe/remove (either if it is
>> handled though PM domain or reset control signal).
>>
>> If the SYSC signal would be passed to all the blocks in the USB area (and
>> it would be handled though PM domains) it should be no problem either,
>> AFAICT, because of reference counting the pm_runtime_get|put*() is taking
>> care of. As the PHY reset is the root node the in the devices node tree for
>> USB the reference counting should work, too (I may miss something though,
>> please correct me if I'm wrong).
>>
>> If the SYSC signal would be handled though a reset control driver (as
>> proposed in this series) and we want to pass this reference to all the
>> blocks in the USB area then we can request the reset signal as shared and,
>> AFAIK, this is also reference counted. The devices node tree should help
>> with the order, too, if I'm not wrong.
> 
> Reference counting a reset signal sounds a bit weird to me, but I
> guess it can work. :-)
> 
> To sum up from my side;
> 
> As long as it's fine that we may end up asserting/de-asserting the
> reset-signal, without actually knowing if the PM domain is getting
> turn-on/off, 

With my understanding of it, that should not happen, at least not with the
current implementation of the drivers involved in this.

> then using a reset-control like what you propose seems
> okay to me.

I would prefer this option, too.

> 
> If not, there are two other options that can be considered I think.
> *) Using the genpd on/off notifiers, to really allow the consumer
> driver of the reset-control to know when the PM domain gets turned
> on/off.
> **) Move the entire reset handling into the PM domain provider, as it
> obviously knows when the domain is getting turned on/off.

This option is what I've explored, tested on my side.

I explored it in 2 ways:

1/ SYSC modeled as an individual PM domain provider (this is more
   appropriate to how HW manual described the hardware) with this the PHY
   reset DT node would have to get 2 PM domains handlers (one for the
   current PM domain provider and the other one for SYSC):

+               phyrst: usbphy-ctrl at 11e00000 {
+                       compatible = "renesas,r9a08g045-usbphy-ctrl";
+                       reg = <0 0x11e00000 0 0x10000>;
+                       clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>;
+                       resets = <&cpg R9A08G045_USB_PRESETN>;
+                       power-domain-names = "cpg", "sysc";
+                       power-domains = <&cpg R9A08G045_PD_USB_PHY>, <&sysc
R9A08G045_SYSC_PD_USB>;
+                       #reset-cells = <1>;
+                       status = "disabled";
+
+                       usb0_vbus_otg: regulator-vbus {
+                               regulator-name = "vbus";
+                       };
+               };
+

and the PHY reset driver will get bulky with powering on/off both of these,
at least with my current implementation, something like (and the following
code is in probe()):

+       if (priv->set_power) {
+               priv->cpg_genpd_dev = dev_pm_domain_attach_by_name(dev, "cpg");
+               if (IS_ERR(priv->cpg_genpd_dev)) {
+                       dev_err_probe(dev, error, "Failed to attach CPG PM
domain!");
+                       error = PTR_ERR(priv->cpg_genpd_dev);
+                       goto err_pm_runtime_put;
+               }
+
+               priv->sysc_genpd_dev = dev_pm_domain_attach_by_name(dev,
"sysc");
+               if (IS_ERR(priv->sysc_genpd_dev)) {
+                       dev_err_probe(dev, error, "Failed to attach sysc PM
domain!");
+                       error = PTR_ERR(priv->sysc_genpd_dev);
+                       goto err_genpd_cpg_detach;
+               }
+
+               priv->cpg_genpd_dl = device_link_add(dev, priv->cpg_genpd_dev,
+                                                    DL_FLAG_PM_RUNTIME |
+                                                    DL_FLAG_STATELESS);
+               if (!priv->cpg_genpd_dl) {
+                       dev_err_probe(dev, -ENOMEM, "Failed to add CPG
genpd device link!");
+                       goto err_genpd_sysc_detach;
+               }
+
+               priv->sysc_genpd_dl = device_link_add(dev,
priv->sysc_genpd_dev,
+                                                     DL_FLAG_PM_RUNTIME |
+                                                     DL_FLAG_STATELESS);
+               if (!priv->sysc_genpd_dl) {
+                       dev_err_probe(dev, -ENOMEM, "Failed to add sysc
genpd device link!");
+                       goto err_genpd_cpg_dl_del;
+               }
+
+
+               error = pm_runtime_resume_and_get(priv->cpg_genpd_dev);
+               if (error) {
+                       dev_err_probe(dev, error, "Failed to runtime resume
cpg PM domain!");
+                       goto err_genpd_sysc_dl_del;
+               }
+
+               error = pm_runtime_resume_and_get(priv->sysc_genpd_dev);
+               if (error) {
+                       dev_err_probe(dev, error, "Failed to runtime resume
sysc PM domain!");
+                       goto err_genpd_cpg_off;
+               }
+       }
+

2/ SYSC being a PM domain provider parent of the CPG (current PM domain
   provider). With this the phy reset node is like proposed in this series
   (powered by CPG PM domain):

+               phyrst: usbphy-ctrl at 11e00000 {
+                       compatible = "renesas,r9a08g045-usbphy-ctrl",
+                                    "renesas,rzg2l-usbphy-ctrl";
+                       reg = <0 0x11e00000 0 0x10000>;
+                       clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>;
+                       resets = <&cpg R9A08G045_USB_PRESETN>;
+                       power-domains = <&cpg R9A08G045_PD_USB_PHY>;
+                       #reset-cells = <1>;
+                       status = "disabled";
+
+                       usb0_vbus_otg: regulator-vbus {
+                               regulator-name = "vbus";
+                       };
+               };

And the USB SYSC PM domain is parent for all USB PM domains provided by CPG
(3 in this case). With this there should be some glue code b/w CPG (code in
drivers/clk/renesas/{rzg2l-cpg.c, r9a08g045-cpg.c}) and SYSC drivers (I
have something ugly locally, haven't tried to detach CPG code from SYSC
code at the moment).


> 
> Thanks again for your explanations!

Thank you, also, for looking into this,
Claudiu Beznea

> 
> Kind regards
> Uffe


From johan at kernel.org  Fri Aug 30 05:09:25 2024
From: johan at kernel.org (Johan Hovold)
Date: Fri, 30 Aug 2024 14:09:25 +0200
Subject: [PATCH v3 1/2] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy:
 Document the X1E80100 QMP PCIe PHY Gen4 x4
In-Reply-To: <gvx3sdsdxigel3iwu7vgvvgxohvnaqq6suogsqojeumobhwhdk@5qct23m5ncda>
References: <20240823-x1e80100-phy-add-gen4x4-v3-0-b7765631ca01@linaro.org>
 <20240823-x1e80100-phy-add-gen4x4-v3-1-b7765631ca01@linaro.org>
 <gvx3sdsdxigel3iwu7vgvvgxohvnaqq6suogsqojeumobhwhdk@5qct23m5ncda>
Message-ID: <ZtG2dUVkdwBpBbix@hovoldconsulting.com>

On Fri, Aug 30, 2024 at 01:42:10PM +0300, Dmitry Baryshkov wrote:
> On Fri, Aug 23, 2024 at 10:04:15AM GMT, Abel Vesa wrote:
> > The sixth PCIe instance on X1E80100 can be used in either 4-lane mode or
> > 2-lane mode. Document the 4-lane mode as a separate compatible.
> 
> As the patches were merged, it's too late for this series, but as a
> note: we should think of a way to describe the PHY configuration without
> changing the compatibility strings. The hardware stays the same, it's
> just the number of lanes being wired that changes.

No, this is not about configuration and we need two separate compatibles
as the two PHY instances are distinct and only one of them can be used
in 4-lane mode.

The mistake was to ever describe pcie6a as 2-lane in the x1e80100 dtsi
(and possibly also in the ambiguous commit message above). Whether
pcie6a is used in 4-lane or 2-lane mode is determined by a TCSR
register.

Johan


From christian.bruel at foss.st.com  Fri Aug 30 05:53:15 2024
From: christian.bruel at foss.st.com (Christian Bruel)
Date: Fri, 30 Aug 2024 14:53:15 +0200
Subject: [PATCH v4 1/5] dt-bindings: phy: Add STM32MP25 COMBOPHY bindings
In-Reply-To: <20240829-manifesto-tray-65443d6e7e6e@spud>
References: <20240828143452.1407532-1-christian.bruel@foss.st.com>
 <20240828143452.1407532-2-christian.bruel@foss.st.com>
 <20240828-handsfree-overarch-cd1af26cb0c5@spud>
 <005a2f7d-ab46-46c8-a0cc-b343685caf7c@foss.st.com>
 <20240829-manifesto-tray-65443d6e7e6e@spud>
Message-ID: <777a92d9-ed52-4fa1-b235-e3a4a6321634@foss.st.com>


On 8/29/24 18:44, Conor Dooley wrote:
> On Thu, Aug 29, 2024 at 01:06:53PM +0200, Christian Bruel wrote:
>> On 8/28/24 18:11, Conor Dooley wrote:
>>> On Wed, Aug 28, 2024 at 04:34:48PM +0200, Christian Bruel wrote:
>>>> Document the bindings for STM32 COMBOPHY interface, used to support
>>>> the PCIe and USB3 stm32mp25 drivers.
>>>> Following entries can be used to tune caracterisation parameters
>>>>    - st,output-micro-ohms and st,output-vswing-microvolt bindings entries
>>>> to tune the impedance and voltage swing using discrete simulation results
>>>>    - st,rx-equalizer register to set the internal rx equalizer filter value.
>>>>
>>>> Signed-off-by: Christian Bruel <christian.bruel at foss.st.com>
>>>> ---
>>>>    .../bindings/phy/st,stm32mp25-combophy.yaml   | 128 ++++++++++++++++++
>>>>    1 file changed, 128 insertions(+)
>>>>    create mode 100644 Documentation/devicetree/bindings/phy/st,stm32mp25-combophy.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/phy/st,stm32mp25-combophy.yaml b/Documentation/devicetree/bindings/phy/st,stm32mp25-combophy.yaml
>>>> new file mode 100644
>>>> index 000000000000..8d4a40b94507
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/phy/st,stm32mp25-combophy.yaml
>>>> @@ -0,0 +1,128 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/phy/st,stm32mp25-combophy.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: STMicroelectronics STM32MP25 USB3/PCIe COMBOPHY
>>>> +
>>>> +maintainers:
>>>> +  - Christian Bruel <christian.bruel at foss.st.com>
>>>> +
>>>> +description:
>>>> +  Single lane PHY shared (exclusive) between the USB3 and PCIe controllers.
>>>> +  Supports 5Gbit/s for USB3 and PCIe gen2 or 2.5Gbit/s for PCIe gen1.
>>>> +
>>>> +properties:
>>>> +  compatible:
>>>> +    const: st,stm32mp25-combophy
>>>> +
>>>> +  reg:
>>>> +    maxItems: 1
>>>> +
>>>> +  "#phy-cells":
>>>> +    const: 1
>>>> +
>>>> +  clocks:
>>>> +    minItems: 2
>>>> +    items:
>>>> +      - description: apb Bus clock mandatory to access registers.
>>>> +      - description: ker Internal RCC reference clock for USB3 or PCIe
>>>> +      - description: pad Optional on board clock input for PCIe only. Typically an
>>>> +                     external 100Mhz oscillator wired on dedicated CLKIN pad. Used as reference
>>>> +                     clock input instead of the ker
>>>> +
>>>> +  clock-names:
>>>> +    minItems: 2
>>>> +    items:
>>>> +      - const: apb
>>>> +      - const: ker
>>>> +      - const: pad
>>>> +
>>>> +  resets:
>>>> +    maxItems: 1
>>>> +
>>>> +  reset-names:
>>>> +    const: phy
>>>> +
>>>> +  power-domains:
>>>> +    maxItems: 1
>>>> +
>>>> +  wakeup-source: true
>>>> +
>>>> +  interrupts:
>>>> +    maxItems: 1
>>>> +    description: interrupt used for wakeup
>>>> +
>>>> +  access-controllers:
>>>> +    minItems: 1
>>>> +    maxItems: 2
>>> Can you please describe the items here?
>> I can specialize the description: "Phandle to the rifsc firewall device to check access right."
> Right, but there are potentially two access controllers here. You need
> to describe which is which, so that people can hook them up in the
> correct order. In what case are there two? Your dts patch only has one.

(sorry, resent in plain test)

yes, we don't have more than 1 controller in the current setup,

I'll use maxItems: 1

>> otherwise described in access-controllers/access-controllers.yaml, see also bindings/bus/st,stm32mp25-rifsc.yaml
>>
>>>> +  st,syscfg:
>>>> +    $ref: /schemas/types.yaml#/definitions/phandle
>>>> +    description: Phandle to the SYSCON entry required for configuring PCIe
>>>> +      or USB3.
>>> Why is a phandle required for this lookup, rather than doing it by
>>> compatible?
>> the phandle is used to select the sysconf SoC configuration register
>> depending on the PCIe/USB3 mode (selected by?xlate function), so it's not
>> like a lookup here.
> If "syscon_regmap_lookup_by_phandle()" is not a lookup, then I do not
> know what is. An example justification for it would be that there are
> multiple combophys on the same soc, each using a different sysconf
> region. Your dts suggests that is not the case though, since you have
> st,syscfg = <&syscfg>; in it, rather than st,syscfg = <&syscfg0>;.

I didn't get your suggestion earlier to use "syscon_regmap_lookup_by_compatible()".

We have several other syscon in the other. That's why we choose a direct syscfg phandle

>
>> This sysconf register is also used for other settings
>> such as the PLL, Reference clock selection, ...
>>
>>>> +
>>>> +  st,ssc-on:
>>>> +    type: boolean
>>> flag, not boolean, for presence based stuff. And in the driver,
>>> s/of_property_read_bool/of_property_present/.
>> ok
>>
>>>> +    description:
>>>> +      A boolean property whose presence indicates that the SSC for common clock
>>>> +      needs to be set.
>>> And what, may I ask, does "SSC" mean? "Common clock" is also a bit of a
>>> "linuxism", what does this actually do in the hardware block?
>> SSC for Spread Spectrum Clocking. It is an hardware setting for the 100Mhz PCIe reference common clock,
> Ah, so not really a "common clock" linuxism at all.
>
>> I will rephrase the description
> How is someone supposed to decide between on and off? Is it always on
> for PCIe, or only on in some configurations? Or maybe only (or always?) on
> if the pad clock is provided?

SSC is off by default and available for the PCIe pad clock. it must be defined for USB3

thanks

Christian

>
> Cheers,
> Conor.


From aford173 at gmail.com  Fri Aug 30 06:05:37 2024
From: aford173 at gmail.com (Adam Ford)
Date: Fri, 30 Aug 2024 08:05:37 -0500
Subject: [RFC V2 2/2] phy: freescale: fsl-samsung-hdmi: Support dynamic
 integer divider
In-Reply-To: <ZtF69NSHFtAwDupq@vaman>
References: <20240829021256.787615-1-aford173@gmail.com> <20240829021256.787615-2-aford173@gmail.com>
 <ZtC2LhYAAdPdSRpz@vaman> <CAHCN7xKW=zxips+J73913eEfS+p_e3dN9BWU08=poj599JbUxA@mail.gmail.com>
 <ZtF69NSHFtAwDupq@vaman>
Message-ID: <CAHCN7xKsH4Rau23t_pmsjTsNS7Hz32Xb+GBydjLFDpgtni7w2A@mail.gmail.com>

On Fri, Aug 30, 2024 at 2:55?AM Vinod Koul <vkoul at kernel.org> wrote:
>
> On 29-08-24, 13:30, Adam Ford wrote:
> > On Thu, Aug 29, 2024 at 12:56?PM Vinod Koul <vkoul at kernel.org> wrote:
> > >
> > > On 28-08-24, 21:12, Adam Ford wrote:
> > > > There is currently a look-up table for a variety of resolutions.
> > > > Since the phy has the ability to dynamically calculate the values
> > > > necessary to use the intger divider which should allow more
> > > > resolutions without having to update the look-up-table.  If the
> > > > integer calculator cannot get an exact frequency, it falls back
> > > > to the look-up-table.  Because the LUT algorithm does some
> > > > rounding, I did not remove integer entries from the LUT.
> > >
> > > Any reason why this is RFC?
> >
> > Someone was asking for functionality, but I'm not 100% sure this is
> > the right approach or it would even work.  I am waiting for feedback
> > from Dominique to determine if this helps solve the display for that
> > particular display.
> >
> > >
> > > >
> > > > Signed-off-by: Adam Ford <aford173 at gmail.com>
> > > >
> > > > diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > > > index bc5d3625ece6..76e0899c6006 100644
> > > > --- a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > > > +++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > > > @@ -16,6 +16,8 @@
> > > >
> > > >  #define PHY_REG(reg)         (reg * 4)
> > > >
> > > > +#define REG01_PMS_P_MASK     GENMASK(3, 0)
> > > > +#define REG03_PMS_S_MASK     GENMASK(7, 4)
> > > >  #define REG12_CK_DIV_MASK    GENMASK(5, 4)
> > > >  #define REG13_TG_CODE_LOW_MASK       GENMASK(7, 0)
> > > >  #define REG14_TOL_MASK               GENMASK(7, 4)
> > > > @@ -31,11 +33,17 @@
> > > >
> > > >  #define PHY_PLL_DIV_REGS_NUM 6
> > > >
> > > > +#ifndef MHZ
> > > > +#define MHZ  (1000UL * 1000UL)
> > > > +#endif
> > > > +
> > > >  struct phy_config {
> > > >       u32     pixclk;
> > > >       u8      pll_div_regs[PHY_PLL_DIV_REGS_NUM];
> > > >  };
> > > >
> > > > +static struct phy_config custom_phy_pll_cfg;
> > > > +
> > > >  static const struct phy_config phy_pll_cfg[] = {
> > > >       {
> > > >               .pixclk = 22250000,
> > > > @@ -440,10 +448,83 @@ fsl_samsung_hdmi_phy_configure_pll_lock_det(struct fsl_samsung_hdmi_phy *phy,
> > > >              phy->regs + PHY_REG(14));
> > > >  }
> > > >
> > > > +static unsigned long fsl_samsung_hdmi_phy_find_pms(unsigned long fout, u8 *p, u16 *m, u8 *s)
> > > > +{
> > > > +     unsigned long best_freq = 0;
> > > > +     u32 min_delta = 0xffffffff;
> > >
> > > > +     u8 _p, best_p;
> > > > +     u16 _m, best_m;
> > > > +     u8 _s, best_s;
> > > > +
> > > > +     for (_p = 1; _p <= 11; ++_p) {
> > >
> > > starts with 1 to 11.. why?
> >
> > According to Rev 2 of the 8MP Reference Manual, the Previder range is
> > between 1 and 11.
>
> Would be better to document these assumptions, am sure if someone asks
> you this next year, it would be hard to recall :-)

I updated the note n V3.

Dominique confirmed V3 appears to be working, so I'll investigate his
suggestions, and submit a patch based on my V3 without the RFC.

adam
>
> --
> ~Vinod


From conor at kernel.org  Fri Aug 30 06:32:22 2024
From: conor at kernel.org (Conor Dooley)
Date: Fri, 30 Aug 2024 14:32:22 +0100
Subject: [PATCH] dt-bindings: phy: cadence-sierra: Allow PHY types QSGMII
 and SGMII
In-Reply-To: <20240830105316.1824319-1-s-vadapalli@ti.com>
References: <20240830105316.1824319-1-s-vadapalli@ti.com>
Message-ID: <20240830-juncture-observant-f979caae1c52@spud>

On Fri, Aug 30, 2024 at 04:23:16PM +0530, Siddharth Vadapalli wrote:
> The Sierra SERDES can be configured for QSGMII and SGMII protocols. Hence,
> update the bindings to treat "PHY_TYPE_QSGMII" and "PHY_TYPE_SGMII" as
> valid values for the "cdns,phy-type" property.
> 
> Signed-off-by: Siddharth Vadapalli <s-vadapalli at ti.com>

Acked-by: Conor Dooley <conor.dooley at microchip.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-phy/attachments/20240830/26b2a151/attachment-0001.sig>

From conor at kernel.org  Fri Aug 30 07:55:06 2024
From: conor at kernel.org (Conor Dooley)
Date: Fri, 30 Aug 2024 15:55:06 +0100
Subject: [PATCH v4 1/5] dt-bindings: phy: Add STM32MP25 COMBOPHY bindings
In-Reply-To: <777a92d9-ed52-4fa1-b235-e3a4a6321634@foss.st.com>
References: <20240828143452.1407532-1-christian.bruel@foss.st.com>
 <20240828143452.1407532-2-christian.bruel@foss.st.com>
 <20240828-handsfree-overarch-cd1af26cb0c5@spud>
 <005a2f7d-ab46-46c8-a0cc-b343685caf7c@foss.st.com>
 <20240829-manifesto-tray-65443d6e7e6e@spud>
 <777a92d9-ed52-4fa1-b235-e3a4a6321634@foss.st.com>
Message-ID: <20240830-jumbo-wriggly-39c84108371b@spud>

On Fri, Aug 30, 2024 at 02:53:15PM +0200, Christian Bruel wrote:
> 
> On 8/29/24 18:44, Conor Dooley wrote:
> > On Thu, Aug 29, 2024 at 01:06:53PM +0200, Christian Bruel wrote:
> > > On 8/28/24 18:11, Conor Dooley wrote:
> > > > On Wed, Aug 28, 2024 at 04:34:48PM +0200, Christian Bruel wrote:

> > > > > +  st,syscfg:
> > > > > +    $ref: /schemas/types.yaml#/definitions/phandle
> > > > > +    description: Phandle to the SYSCON entry required for configuring PCIe
> > > > > +      or USB3.
> > > > Why is a phandle required for this lookup, rather than doing it by
> > > > compatible?
> > > the phandle is used to select the sysconf SoC configuration register
> > > depending on the PCIe/USB3 mode (selected by?xlate function), so it's not
> > > like a lookup here.
> > If "syscon_regmap_lookup_by_phandle()" is not a lookup, then I do not
> > know what is. An example justification for it would be that there are
> > multiple combophys on the same soc, each using a different sysconf
> > region. Your dts suggests that is not the case though, since you have
> > st,syscfg = <&syscfg>; in it, rather than st,syscfg = <&syscfg0>;.
> 
> I didn't get your suggestion earlier to use "syscon_regmap_lookup_by_compatible()".
> 
> We have several other syscon in the other. That's why we choose a direct syscfg phandle

In the other what? SoCs?

Way I see it, if you're going to support different socs in the same
driver, it's almost a certainty that the offsets within a syscon that
particular features lie at are going to change between socs, so even if
you have a phandle you're going to need to have the offsets in your
match data. And if you're going to have offsets in match data, you may
as well have the compatibles for the syscon in match data too.
If the layout of the syscon hasn't changed between devices, then you
should have a fallback compatible for the syscon too, making
syscon_regmap_lookup_by_compatible() function without changes to the
driver.

If you do have multiple syscons, but they do different things, they
should have different compatibles, so having multiple syscons doesn't
justify using a property for this either in and of itself. If you have
multiple syscons with the same layout (and therefore the same
compatible) then a phandle makes sense, but if that's the case then you
almost certainly have multiple combophys too! Otherwise, if you have one
syscon, but the controls for more than one combophy are in it, then
having a phandle _with an offset_ makes sense.

If you know there are other SoCs with more than one combo phy, do they
use different syscons, or is the same syscon used for more than one
combophy?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-phy/attachments/20240830/02537a96/attachment.sig>

From dmitry.baryshkov at linaro.org  Fri Aug 30 08:02:34 2024
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Fri, 30 Aug 2024 18:02:34 +0300
Subject: [PATCH v3 1/2] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy:
 Document the X1E80100 QMP PCIe PHY Gen4 x4
In-Reply-To: <ZtG2dUVkdwBpBbix@hovoldconsulting.com>
References: <20240823-x1e80100-phy-add-gen4x4-v3-0-b7765631ca01@linaro.org>
 <20240823-x1e80100-phy-add-gen4x4-v3-1-b7765631ca01@linaro.org>
 <gvx3sdsdxigel3iwu7vgvvgxohvnaqq6suogsqojeumobhwhdk@5qct23m5ncda> <ZtG2dUVkdwBpBbix@hovoldconsulting.com>
Message-ID: <CAA8EJpqD1XYbw35oxP4hWutbGs8nRTSwOsBAJcYGos8FBbAHew@mail.gmail.com>

On Fri, 30 Aug 2024 at 15:09, Johan Hovold <johan at kernel.org> wrote:
>
> On Fri, Aug 30, 2024 at 01:42:10PM +0300, Dmitry Baryshkov wrote:
> > On Fri, Aug 23, 2024 at 10:04:15AM GMT, Abel Vesa wrote:
> > > The sixth PCIe instance on X1E80100 can be used in either 4-lane mode or
> > > 2-lane mode. Document the 4-lane mode as a separate compatible.
> >
> > As the patches were merged, it's too late for this series, but as a
> > note: we should think of a way to describe the PHY configuration without
> > changing the compatibility strings. The hardware stays the same, it's
> > just the number of lanes being wired that changes.
>
> No, this is not about configuration and we need two separate compatibles
> as the two PHY instances are distinct and only one of them can be used
> in 4-lane mode.

Ack, makes sense.

> The mistake was to ever describe pcie6a as 2-lane in the x1e80100 dtsi
> (and possibly also in the ambiguous commit message above). Whether
> pcie6a is used in 4-lane or 2-lane mode is determined by a TCSR
> register.

Yes, I was confused by the commit message. I assumed that the
compatible string is used to switch PHY modes. Had the patchset come
with the DT patch, it would be easier to understand what was going on.

-- 
With best wishes
Dmitry


From aford173 at gmail.com  Fri Aug 30 08:04:41 2024
From: aford173 at gmail.com (Adam Ford)
Date: Fri, 30 Aug 2024 10:04:41 -0500
Subject: [RFC V3 3/3] phy: freescale: fsl-samsung-hdmi: Support dynamic integer
In-Reply-To: <ZtFfBs4HEShmJKsi@atmark-techno.com>
References: <20240830032442.226031-1-aford173@gmail.com> <20240830032442.226031-3-aford173@gmail.com>
 <ZtFfBs4HEShmJKsi@atmark-techno.com>
Message-ID: <CAHCN7x+xy+Y6o++Y5NdZaBJUsHV9Ru_2PwuH6G-2oz1juO=+rQ@mail.gmail.com>

On Fri, Aug 30, 2024 at 12:56?AM Dominique Martinet
<dominique.martinet at atmark-techno.com> wrote:
>
> Adam Ford wrote on Thu, Aug 29, 2024 at 10:24:27PM -0500:
> > There is currently a look-up table for a variety of resolutions.
> > Since the phy has the ability to dynamically calculate the values
> > necessary to use the intger divider which should allow more
> > resolutions without having to update the look-up-table.
> >
> > If the lookup table cannot find an exact match, fall back to the
> > dynamic calculator of the integer divider.
> >
> > Previously, the value of P was hard-coded to 1, this required an
> > update to the phy_pll_cfg table to add in the extra value into the
> > table, so if the value of P is calculated to be something else
> > by the PMS calculator, the calculated_phy_pll_cfg structure
> > can be used instead without having to keep track of which method
> > was used.
>
> Thank you!
>
> I've updated to v3 and we must have missed something fiddling with v1
> but our 31.5MHz-only screen turns on with this!
>
> Unfortunately among the other odd devices we support, there's one
> whose native resolution only supports 83.5MHz, and that doesn't come out
> right with the integer divider (that function returns 83.2MHz, which is
> 0.4%off)
> If we force the round/set rate functions to prefer the calculated value
> and allow that in imx8mp_hdmi_check_clk_rate (dw_hdmi-imx.c) then it
> also works, so I don't think we actually need to affine the model...
> Coming back to what Lucas replied to my initial mail HDMI would also a
> rate mismatch of ?0.5%, so the integer calculator works for all the
> frequencies we've currently added manually if we fix the check to allow
> that as well:
> 32000000: found 32000000 (100.0% match): p 1 / m 80 / s 12
> 51200000: found 51200000 (100.0% match): p 1 / m 64 / s 6
> 65000000: found 64800000 (99.6% match): p 1 / m 54 / s 4
> 71000000: found 70800000 (99.7% match): p 1 / m 59 / s 4
> 83500000: found 83200000 (99.6% match): p 1 / m 104 / s 6
>
> (only actually tested 51.2 and 83.5 here, we don't have all the hardware
> available; I'll try to play with normal monitors that support more modes
> once the patch gets further finalized)
>
>
> So, as far as I'm concerned I'd be happy to move forward with that and
> will backport this to our tree/remove our kludged values, would "just"
> need to properly pick the closest value if no exact match instead of
> always falling back to the table (or just remove the table altogether if
> we can test a few monitors?)

I took that step on my local build machine to remove the integer
divider stuff from the LUT since it can be found automatically.  I
haven't committed them yet, but I'll likely add it to the series once
submit it without the RFC.

I am also likely to update the rounding function to look at the delta
between the closest LUT clock value and the closest integer clock
value and use whichever is closest to the desired value.


>
> A couple of style nitpicks below
>
> > diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > index a700a300dc6f..3fab40cde40d 100644
> > --- a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > +++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > @@ -16,6 +16,8 @@
> >
> >  #define PHY_REG(reg)         (reg * 4)
> >
> > +#define REG01_PMS_P_MASK     GENMASK(3, 0)
> > +#define REG03_PMS_S_MASK     GENMASK(7, 4)
> >  #define REG12_CK_DIV_MASK    GENMASK(5, 4)
> >  #define REG13_TG_CODE_LOW_MASK       GENMASK(7, 0)
> >  #define REG14_TOL_MASK               GENMASK(7, 4)
> > @@ -29,281 +31,296 @@
> >  #define REG34_PLL_LOCK               BIT(6)
> >  #define REG34_PHY_CLK_READY  BIT(5)
> >
> > -#define PHY_PLL_DIV_REGS_NUM 6
> > +#ifndef MHZ
> > +#define MHZ  (1000UL * 1000UL)
> > +#endif
> > +
> > +#define PHY_PLL_DIV_REGS_NUM 7
> >
> >  struct phy_config {
> >       u32     pixclk;
> >       u8      pll_div_regs[PHY_PLL_DIV_REGS_NUM];
> >  };
> >
> > +/*
> > + * The calculated_phy_pll_cfg only handles integer divider for PMS only,
> > + * meaning the last four entries will be fixed, but the first three will
> > + * be calculated by the PMS calculator
> > + */
> > +static struct phy_config calculated_phy_pll_cfg = {
>
> I'd change cur_cfg from pointer to the struct itself like this (partial
> patch that probably won't even apply on your branch:)
> ----
> diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> index 9048cdc760c2..d7124604819c 100644
> --- a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> +++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> @@ -402,7 +402,7 @@ struct fsl_samsung_hdmi_phy {
>
>         /* clk provider */
>         struct clk_hw hw;
> -       const struct phy_config *cur_cfg;
> +       struct phy_config cur_cfg;
>  };
>
>  static inline struct fsl_samsung_hdmi_phy *
> @@ -562,9 +562,9 @@ static int phy_clk_set_rate(struct clk_hw *hw,
>         if (i < 0)
>                 return -EINVAL;
>
> -       phy->cur_cfg = &phy_pll_cfg[i];
> +       phy->cur_cfg = phy_pll_cfg[i];
>
> -       return fsl_samsung_hdmi_phy_configure(phy, phy->cur_cfg);
> +       return fsl_samsung_hdmi_phy_configure(phy, &phy->cur_cfg);
>  }
>
>  static const struct clk_ops phy_clk_ops = {
> ----
>
> Then you can just set it directly for calculated values.
> But conceptually it's the same, just one less indirection.

I was thinking about that, but I wasn't sure the impact of
un-const-ing would have on the LUT.

Using the extra indirection minimizes the impact of changes to the LUT
and how its handled by the compiler.

adam
>
> > @@ -406,6 +424,76 @@ fsl_samsung_hdmi_phy_configure_pll_lock_det(struct fsl_samsung_hdmi_phy *phy,
> >              phy->regs + PHY_REG(14));
> >  }
> >
> > +static unsigned long fsl_samsung_hdmi_phy_find_pms(unsigned long fout, u8 *p, u16 *m, u8 *s)
> > +{
> > +     unsigned long best_freq = 0;
> > +     u32 min_delta = 0xffffffff;
> > +     u8 _p, best_p;
> > +     u16 _m, best_m;
> > +     u8 _s, best_s;
> > +
> > +     /* The ref manual states the values of 'P' rannge from 1 to 11 */
>
> typo: range
>
> > +     for (_p = 1; _p <= 11; ++_p) {
> > +             for (_s = 1; _s <= 16; ++_s) {
> > +                     u64 tmp;
> > +                     u32 delta;
> > +
> > +                     /* s must be one or even */
> > +                     if (_s > 1 && (_s & 0x01) == 1)
> > +                             _s++;
> > +
> > +                     /* _s cannot be 14 per the TRM */
> > +                     if (_s == 14)
> > +                             continue;
> > +
> > +                     /*
> > +                      * TODO: Ref Manual doesn't state the range of _m
> > +                      * so this should be further refined if possible.
> > +                      * This range was set based on the original values
> > +                      * in the look-up table
> > +                      */
> > +                     tmp = (u64)fout * (_p * _s);
> > +                     do_div(tmp, 24 * MHZ);
> > +                     _m = tmp;
> > +                     if (_m < 0x30 || _m > 0x7b)
> > +                             continue;
> > +
> > +                     /*
> > +                      * Rev 2 of the Ref Manual states the
> > +                      * VCO can range between 750MHz and
> > +                      * 3GHz.  The VCO is assumed to be _m x
> > +                      * the reference frequency of 24MHz divided
> > +                      * by the prescaler, _p
> > +                      */
> > +                     tmp = (u64)_m * 24 * MHZ;
> > +                     do_div(tmp, _p);
> > +                     if (tmp < 750 * MHZ ||
> > +                         tmp > 3000 * MHZ)
> > +                             continue;
> > +
> > +                     tmp = (u64)_m * 24 * MHZ;
> > +                     do_div(tmp, _p * _s);
> > +
> > +                     delta = abs(fout - tmp);
> > +                     if (delta < min_delta) {
> > +                             best_p = _p;
> > +                             best_s = _s;
> > +                             best_m = _m;
> > +                             min_delta = delta;
> > +                             best_freq = tmp;
> > +                     }
> > +             }
> > +     }
> > +
> > +     if (best_freq) {
> > +             *p = best_p;
> > +             *m = best_m;
> > +             *s = best_s;
> > +     }
> > +
> > +     return best_freq;
> > +}
> > +
> >  static int fsl_samsung_hdmi_phy_configure(struct fsl_samsung_hdmi_phy *phy,
> >                                         const struct phy_config *cfg)
> >  {
> > @@ -419,13 +507,13 @@ static int fsl_samsung_hdmi_phy_configure(struct fsl_samsung_hdmi_phy *phy,
> >       for (i = 0; i < ARRAY_SIZE(common_phy_cfg); i++)
> >               writeb(common_phy_cfg[i].val, phy->regs + common_phy_cfg[i].reg);
> >
> > -     /* set individual PLL registers PHY_REG2 ... PHY_REG7 */
> > +     /* set individual PLL registers PHY_REG1 ... PHY_REG7 */
> >       for (i = 0; i < PHY_PLL_DIV_REGS_NUM; i++)
> > -             writeb(cfg->pll_div_regs[i], phy->regs + PHY_REG(2) + i * 4);
> > +             writeb(cfg->pll_div_regs[i], phy->regs + PHY_REG(1) + i * 4);
> >
> > -     /* High nibble of pll_div_regs[1] contains S which also gets written to REG21 */
> > +     /* High nibble of PHY_REG3 and low nibble of PHY_REG21 both contain 'S' */
> >       writeb(REG21_SEL_TX_CK_INV | FIELD_PREP(REG21_PMS_S_MASK,
> > -            cfg->pll_div_regs[1] >> 4), phy->regs + PHY_REG(21));
> > +            cfg->pll_div_regs[2] >> 4), phy->regs + PHY_REG(21));
> >
> >       fsl_samsung_hdmi_phy_configure_pll_lock_det(phy, cfg);
> >
> > @@ -453,29 +541,70 @@ static unsigned long phy_clk_recalc_rate(struct clk_hw *hw,
> >  static long phy_clk_round_rate(struct clk_hw *hw,
> >                              unsigned long rate, unsigned long *parent_rate)
> >  {
> > +     u32 int_div_clk;
> >       int i;
> > +     u16 m;
> > +     u8 p, s;
> > +
> > +     /* If the clock is out of range return error instead of searching */
> > +     if (rate > 297000000 || rate < 22250000)
> > +             return -EINVAL;
> >
> > +     /* Check the look-up table */
> >       for (i = ARRAY_SIZE(phy_pll_cfg) - 1; i >= 0; i--)
> >               if (phy_pll_cfg[i].pixclk <= rate)
> > -                     return phy_pll_cfg[i].pixclk;
> > +                     break;
> > +     /* If the rate is an exact match, return it now */
> > +     if (rate == phy_pll_cfg[i].pixclk)
> > +             return phy_pll_cfg[i].pixclk;
> > +
> > +     /*
> > +      * The math on the lookup table shows the PMS math yields a
> > +      * frequency 5 x pixclk.
> > +      * When we check the integer divider against the desired rate,
> > +      * multiply the rate x 5 and then divide the outcome by 5.
> > +      */
> > +     int_div_clk = fsl_samsung_hdmi_phy_find_pms(rate * 5, &p, &m, &s) / 5;
>
> I'd move that comment and both multiplication and division inside
> fsl_samsung_hdmi_phy_find_pms, since it's a property of the computation
> (not having the comment made me ask last time, with the comment it's
> fine -- thanks for adding these comments, very helpful.)
>
> --
> Dominique
>
>


From christian.bruel at foss.st.com  Fri Aug 30 10:11:45 2024
From: christian.bruel at foss.st.com (Christian Bruel)
Date: Fri, 30 Aug 2024 19:11:45 +0200
Subject: [PATCH v4 1/5] dt-bindings: phy: Add STM32MP25 COMBOPHY bindings
In-Reply-To: <20240830-jumbo-wriggly-39c84108371b@spud>
References: <20240828143452.1407532-1-christian.bruel@foss.st.com>
 <20240828143452.1407532-2-christian.bruel@foss.st.com>
 <20240828-handsfree-overarch-cd1af26cb0c5@spud>
 <005a2f7d-ab46-46c8-a0cc-b343685caf7c@foss.st.com>
 <20240829-manifesto-tray-65443d6e7e6e@spud>
 <777a92d9-ed52-4fa1-b235-e3a4a6321634@foss.st.com>
 <20240830-jumbo-wriggly-39c84108371b@spud>
Message-ID: <4ae91d0f-e37b-4325-a5aa-8448b95db431@foss.st.com>


On 8/30/24 16:55, Conor Dooley wrote:
> On Fri, Aug 30, 2024 at 02:53:15PM +0200, Christian Bruel wrote:
>> On 8/29/24 18:44, Conor Dooley wrote:
>>> On Thu, Aug 29, 2024 at 01:06:53PM +0200, Christian Bruel wrote:
>>>> On 8/28/24 18:11, Conor Dooley wrote:
>>>>> On Wed, Aug 28, 2024 at 04:34:48PM +0200, Christian Bruel wrote:
>>>>>> +  st,syscfg:
>>>>>> +    $ref: /schemas/types.yaml#/definitions/phandle
>>>>>> +    description: Phandle to the SYSCON entry required for configuring PCIe
>>>>>> +      or USB3.
>>>>> Why is a phandle required for this lookup, rather than doing it by
>>>>> compatible?
>>>> the phandle is used to select the sysconf SoC configuration register
>>>> depending on the PCIe/USB3 mode (selected by?xlate function), so it's not
>>>> like a lookup here.
>>> If "syscon_regmap_lookup_by_phandle()" is not a lookup, then I do not
>>> know what is. An example justification for it would be that there are
>>> multiple combophys on the same soc, each using a different sysconf
>>> region. Your dts suggests that is not the case though, since you have
>>> st,syscfg = <&syscfg>; in it, rather than st,syscfg = <&syscfg0>;.
>> I didn't get your suggestion earlier to use "syscon_regmap_lookup_by_compatible()".
>>
>> We have several other syscon in the other. That's why we choose a direct syscfg phandle
> In the other what? SoCs?
>
> Way I see it, if you're going to support different socs in the same
> driver, it's almost a certainty that the offsets within a syscon that
> particular features lie at are going to change between socs, so even if
> you have a phandle you're going to need to have the offsets in your
> match data. And if you're going to have offsets in match data, you may
> as well have the compatibles for the syscon in match data too.
> If the layout of the syscon hasn't changed between devices, then you
> should have a fallback compatible for the syscon too, making
> syscon_regmap_lookup_by_compatible() function without changes to the
> driver.
>
> If you do have multiple syscons, but they do different things, they
> should have different compatibles, so having multiple syscons doesn't
> justify using a property for this either in and of itself. If you have
> multiple syscons with the same layout (and therefore the same
> compatible) then a phandle makes sense, but if that's the case then you
> almost certainly have multiple combophys too! Otherwise, if you have one
> syscon, but the controls for more than one combophy are in it, then
> having a phandle _with an offset_ makes sense.
>
> If you know there are other SoCs with more than one combo phy, do they
> use different syscons, or is the same syscon used for more than one
> combophy?

we have other syscon for other subsystem in the same SoC,?but I not the same layout

We indeed have a different compatible for the syscfg top (not the COMBOPHY registers), I can use
"syscon_regmap_lookup_by_compatible(st,stm32mp25-syscfg)" effectively

one justification I had in mind for using a phandle is that we can use an argument to the
COMBOPHY registers offset in the syscfg. Having this DT flexibility to adjust the offset
for new SoC revisions using the same driver looked like a nice to have.
For the time being the lookup_by_compatible pointing the syscfg syscon is OK

thanks for the clarification.

Christian



From quic_songxue at quicinc.com  Fri Aug 30 16:13:07 2024
From: quic_songxue at quicinc.com (Song Xue)
Date: Sat, 31 Aug 2024 07:13:07 +0800
Subject: [PATCH v2 2/2] phy: add NXP PTN3222 eUSB2 to USB2 redriver
In-Reply-To: <20240830-nxp-ptn3222-v2-2-4c6d8535cf6c@linaro.org>
References: <20240830-nxp-ptn3222-v2-0-4c6d8535cf6c@linaro.org>
 <20240830-nxp-ptn3222-v2-2-4c6d8535cf6c@linaro.org>
Message-ID: <6fcaa893-70a4-44f4-afc0-853799e30774@quicinc.com>



On 8/30/2024 4:20 PM, Dmitry Baryshkov wrote:
> The NXP PTN3222 is the single-port eUSB2 to USB2 redriver that performs
> translation between eUSB2 and USB2 signalling schemes. It supports all
> three data rates: Low Speed, Full Speed and High Speed.
> 
> The reset state enables autonegotiation of the PHY role and of the data
> rate, so no additional programming is required.
> 
> Reviewed-by: Neil Armstrong <neil.armstrong at linaro.org>
> Tested-by: Konrad Dybcio <konradybcio at kernel.org>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
> ---
>   drivers/phy/Kconfig           |  11 ++++
>   drivers/phy/Makefile          |   1 +
>   drivers/phy/phy-nxp-ptn3222.c | 123 ++++++++++++++++++++++++++++++++++++++++++
>   3 files changed, 135 insertions(+)
> 
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index dfab1c66b3e5..cb06a7f79740 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -82,6 +82,17 @@ config PHY_AIROHA_PCIE
>   	  This driver create the basic PHY instance and provides initialize
>   	  callback for PCIe GEN3 port.
>   
> +config PHY_NXP_PTN3222
> +	tristate "NXP PTN3222 1-port eUSB2 to USB2 redriver"
> +	depends on I2C
> +	depends on OF
> +	select GENERIC_PHY
> +	help
> +	  Enable this to support NXP PTN3222 1-port eUSB2 to USB2 Redriver.
> +	  This redriver performs translation between eUSB2 and USB2 signalling
> +	  schemes. It supports all three USB 2.0 data rates: Low Speed, Full
> +	  Speed and High Speed.
> +
>   source "drivers/phy/allwinner/Kconfig"
>   source "drivers/phy/amlogic/Kconfig"
>   source "drivers/phy/broadcom/Kconfig"
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 5fcbce5f9ab1..b64247046575 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -11,6 +11,7 @@ obj-$(CONFIG_PHY_XGENE)			+= phy-xgene.o
>   obj-$(CONFIG_PHY_PISTACHIO_USB)		+= phy-pistachio-usb.o
>   obj-$(CONFIG_USB_LGM_PHY)		+= phy-lgm-usb.o
>   obj-$(CONFIG_PHY_AIROHA_PCIE)		+= phy-airoha-pcie.o
> +obj-$(CONFIG_PHY_NXP_PTN3222)		+= phy-nxp-ptn3222.o
>   obj-y					+= allwinner/	\
>   					   amlogic/	\
>   					   broadcom/	\
> diff --git a/drivers/phy/phy-nxp-ptn3222.c b/drivers/phy/phy-nxp-ptn3222.c
> new file mode 100644
> index 000000000000..c6179d8701e6
> --- /dev/null
> +++ b/drivers/phy/phy-nxp-ptn3222.c
> @@ -0,0 +1,123 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2024, Linaro Limited
> + */
> +
> +#include <linux/gpio/consumer.h>
> +#include <linux/i2c.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/phy/phy.h>
> +#include <linux/regmap.h>
> +#include <linux/regulator/consumer.h>
> +
> +#define NUM_SUPPLIES 2
> +
> +struct ptn3222 {
> +	struct i2c_client *client;
> +	struct phy *phy;
> +	struct gpio_desc *reset_gpio;
> +	struct regulator_bulk_data *supplies;
> +};
> +
> +static int ptn3222_init(struct phy *phy)
> +{
> +	struct ptn3222 *ptn3222 = phy_get_drvdata(phy);
> +	int ret;
> +
> +	ret = regulator_bulk_enable(NUM_SUPPLIES, ptn3222->supplies);
> +	if (ret)
> +		return ret;
> +
> +	gpiod_set_value_cansleep(ptn3222->reset_gpio, 0);
> +
> +	return 0;
> +}
> +
> +static int ptn3222_exit(struct phy *phy)
> +{
> +	struct ptn3222 *ptn3222 = phy_get_drvdata(phy);
> +
> +	gpiod_set_value_cansleep(ptn3222->reset_gpio, 1);
> +
> +	return regulator_bulk_disable(NUM_SUPPLIES, ptn3222->supplies);
> +}
> +
> +static const struct phy_ops ptn3222_ops = {
> +	.init		= ptn3222_init,
> +	.exit		= ptn3222_exit,
> +	.owner		= THIS_MODULE,
> +};
> +
> +static const struct regulator_bulk_data ptn3222_supplies[NUM_SUPPLIES] = {
> +	{
> +		.supply = "vdd3v3",
> +		.init_load_uA = 11000,
> +	}, {
> +		.supply = "vdd1v8",
> +		.init_load_uA = 55000,
> +	}
> +};
> +
> +static int ptn3222_probe(struct i2c_client *client)
> +{
> +	struct device *dev = &client->dev;
> +	struct phy_provider *phy_provider;
> +	struct ptn3222 *ptn3222;
> +	int ret;
> +
> +	ptn3222 = devm_kzalloc(dev, sizeof(*ptn3222), GFP_KERNEL);
> +	if (!ptn3222)
> +		return -ENOMEM;
> +
> +	ptn3222->client = client;
> +
> +	ptn3222->reset_gpio = devm_gpiod_get_optional(dev, "reset",
> +						      GPIOD_OUT_HIGH);
> +	if (IS_ERR(ptn3222->reset_gpio))
> +		return dev_err_probe(dev, PTR_ERR(ptn3222->reset_gpio),
> +				     "unable to acquire reset gpio\n");
> +
> +	ret = devm_regulator_bulk_get_const(dev, NUM_SUPPLIES, ptn3222_supplies,
> +					    &ptn3222->supplies);
> +	if (ret)
> +		return ret;
> +
> +	ptn3222->phy = devm_phy_create(dev, dev->of_node, &ptn3222_ops);
> +	if (IS_ERR(ptn3222->phy)) {
> +		dev_err(dev, "failed to create PHY: %d\n", ret);
> +		return PTR_ERR(ptn3222->phy);
> +	}
> +
> +	phy_set_drvdata(ptn3222->phy, ptn3222);
> +
> +	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
> +
> +	return PTR_ERR_OR_ZERO(phy_provider);
> +}
> +
> +static const struct i2c_device_id ptn3222_table[] = {
> +	{ "ptn3222" },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(i2c, ptn3222_table);
> +
> +static const struct of_device_id ptn3222_of_table[] = {
> +	{ .compatible = "nxp,ptn3222" },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(of, ptn3222_of_table);
> +
> +static struct i2c_driver ptn3222_driver = {
> +	.driver = {
> +		.name = "ptn3222",
> +		.of_match_table = ptn3222_of_table,
> +	},
> +	.probe = ptn3222_probe,
> +	.id_table = ptn3222_table,
> +};
> +
> +module_i2c_driver(ptn3222_driver)
> +
> +MODULE_DESCRIPTION("NXP PTN3222 eUSB2 Redriver driver");
> +MODULE_LICENSE("GPL");
> 
The I2C driver just realizes the function on reset and PWR. What about 
other I2C driver function like I2C interface operations, auto-suspend, 
remote wakeup, memory maps etc. Who will enable these? I think it is not 
incomplete I2C driver, if on someday, ptn3222 is used as I2C device.

Regards,
Song Xue



From dmitry.baryshkov at linaro.org  Fri Aug 30 16:45:05 2024
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Sat, 31 Aug 2024 02:45:05 +0300
Subject: [PATCH v2 2/2] phy: add NXP PTN3222 eUSB2 to USB2 redriver
In-Reply-To: <6fcaa893-70a4-44f4-afc0-853799e30774@quicinc.com>
References: <20240830-nxp-ptn3222-v2-0-4c6d8535cf6c@linaro.org>
 <20240830-nxp-ptn3222-v2-2-4c6d8535cf6c@linaro.org> <6fcaa893-70a4-44f4-afc0-853799e30774@quicinc.com>
Message-ID: <CAA8EJpoTb_-HtBPv2=FecHvtHYQD4ipqfq3C98ky=qXEXB=_6Q@mail.gmail.com>

On Sat, 31 Aug 2024 at 02:13, Song Xue <quic_songxue at quicinc.com> wrote:
> On 8/30/2024 4:20 PM, Dmitry Baryshkov wrote:
> > The NXP PTN3222 is the single-port eUSB2 to USB2 redriver that performs
> > translation between eUSB2 and USB2 signalling schemes. It supports all
> > three data rates: Low Speed, Full Speed and High Speed.
> >
> > The reset state enables autonegotiation of the PHY role and of the data
> > rate, so no additional programming is required.
> >
> > Reviewed-by: Neil Armstrong <neil.armstrong at linaro.org>
> > Tested-by: Konrad Dybcio <konradybcio at kernel.org>
> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
> > ---
> >   drivers/phy/Kconfig           |  11 ++++
> >   drivers/phy/Makefile          |   1 +
> >   drivers/phy/phy-nxp-ptn3222.c | 123 ++++++++++++++++++++++++++++++++++++++++++
> >   3 files changed, 135 insertions(+)

[trimmed]

> > +
> > +MODULE_DESCRIPTION("NXP PTN3222 eUSB2 Redriver driver");
> > +MODULE_LICENSE("GPL");
> >
> The I2C driver just realizes the function on reset and PWR. What about
> other I2C driver function like I2C interface operations,

I don't quite understand what you mean by this. Could you please clarify?

>  auto-suspend,

I think you mean pm_runtime here. It's a valid case, but granted that
it should stay enabled when USB controller is enabled, the gain should
be pretty limited. I'll consider a followup patch implementing
pm_runtime for the sake of being able to disable I2C host if DWC3
controller disables the PHY.

> remote wakeup,

Not supported by design. PTN3222 doesn't have IRQ pins to report
events to the host.

> memory maps etc.

huh?

>  Who will enable these? I think it is not
> incomplete I2C driver, if on someday, ptn3222 is used as I2C device.

Well, I'm using it as an I2C device.

-- 
With best wishes
Dmitry


From biju.das.jz at bp.renesas.com  Fri Aug 30 22:13:38 2024
From: biju.das.jz at bp.renesas.com (Biju Das)
Date: Sat, 31 Aug 2024 05:13:38 +0000
Subject: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
In-Reply-To: <99bef301-9f6c-4797-b47e-c83e56dfbda9@tuxon.dev>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
 <CAPDyKFrS4Dhd7DZa2zz=oPro1TiTJFix0awzzzp8Qatm-8Z2Ug@mail.gmail.com>
 <99bef301-9f6c-4797-b47e-c83e56dfbda9@tuxon.dev>
Message-ID: <TY3PR01MB1134652F9587CFA0ADE851CA486902@TY3PR01MB11346.jpnprd01.prod.outlook.com>

Hi Claudiu,

> -----Original Message-----
> From: claudiu beznea <claudiu.beznea at tuxon.dev>
> Sent: Friday, August 30, 2024 9:23 AM
> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
> 
> Hi, Ulf,
> 
> On 29.08.2024 18:26, Ulf Hansson wrote:
> > On Thu, 22 Aug 2024 at 17:28, Claudiu <claudiu.beznea at tuxon.dev> wrote:
> >>
> >> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> >>
> >> Hi,
> >>
> >> Series adds initial USB support for the Renesas RZ/G3S SoC.
> >>
> >> Series is split as follows:
> >>
> >> - patch 01/16           - add clock reset and power domain support for USB
> >> - patch 02-04/16        - add reset control support for a USB signal
> >>                           that need to be controlled before/after
> >>                           the power to USB area is turned on/off.
> >>
> >>                           Philipp, Ulf, Geert, all,
> >>
> >>                           I detailed my approach for this in patch
> >>                           04/16, please have a look and let me know
> >>                           your input.
> >
> > I have looked briefly. Your suggested approach may work, but I have a
> > few thoughts, see below.
> >
> > If I understand correctly, it is the consumer driver for the device
> > that is attached to the USB power domain that becomes responsible for
> > asserting/de-asserting this new signal. Right?
> 
> Right!
> 
> >
> > In this regard, please note that the consumer driver doesn't really
> > know when the power domain really gets powered-on/off. Calling
> > pm_runtime_get|put*() is dealing with the reference counting. For
> > example, a call to pm_runtime_get*() just makes sure that the PM
> > domain gets-or-remains powered-on. Could this be a problem from the
> > reset-signal point of view?
> 
> It should be safe. From the HW manual I understand the hardware block is something like the following:
> 
> 
>                   USB area
>          +-------------------------+
>          |                         |
>          | PHY --->USB controller  |
> SYSC --> |  ^                      |
>          |  |                      |
>          | PHY reset               |
>          +-------------------------+

How USB PWRRDY signal is connected to USB? 

USB block consists of PHY control, PHY, USB HOST and USB OTG Controller IPs.

Is it connected to top level block or connected to each IP's for turning off the USB region power?

? Or Just PHY (HW manual mentions for AWO, the USB PWRRDY signal->USB PHY PWRRDY signal control)? 

If the USBPWRRDY signal is connected across modules with this reset signal approach
then you may need to update bindings [1] with that reset signal

[1] https://patchwork.kernel.org/project/linux-renesas-soc/patch/20240822152801.602318-12-claudiu.beznea.uj at bp.renesas.com/
 

Cheers,
Biju

> 
> Where:
> - SYSC is the system controller that controls the new signal for which
>   I'm requesting opinions in this series
> - PHY reset: is the block controlling the PHYs
> - PHY: is the block controlling the USB PHYs
> - USB controller: is the USB controller
> 
> Currently, I passed the SYSC signal handling to the PHY reset driver; w/o PHY reset the rest of the
> USB logic cannot work (neither PHY block nor USB controller).
> 
> Currently, the PHY reset driver call pm_runtime_resume_and_get() in probe and pm_runtime_put() in
> remove. The struct reset_control_ops::{assert, deassert} only set specific bits in registers (no
> pm_runtime* calls).
> 
> The PHY driver is taking its PHY reset in probe and release it in remove().
> With this approach the newly introduced SYSC signal will be de-asserted/asserted only in the PHY reset
> probe/remove (either if it is handled though PM domain or reset control signal).
> 
> If the SYSC signal would be passed to all the blocks in the USB area (and it would be handled though
> PM domains) it should be no problem either, AFAICT, because of reference counting the
> pm_runtime_get|put*() is taking care of. As the PHY reset is the root node the in the devices node
> tree for USB the reference counting should work, too (I may miss something though, please correct me
> if I'm wrong).
> 
> If the SYSC signal would be handled though a reset control driver (as proposed in this series) and we
> want to pass this reference to all the blocks in the USB area then we can request the reset signal as
> shared and, AFAIK, this is also reference counted. The devices node tree should help with the order,
> too, if I'm not wrong.
> 
> Thank you for looking at this,
> Claudiu Beznea
> 
> >
> > [...]
> >
> > Kind regards
> > Uffe

From dmitry.baryshkov at linaro.org  Sat Aug 31 03:26:49 2024
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Sat, 31 Aug 2024 13:26:49 +0300
Subject: [PATCH v7 4/6] drm/msm: add msm8998 hdmi phy/pll support
In-Reply-To: <20240724-hdmi-tx-v7-4-e44a20553464@freebox.fr>
References: <20240724-hdmi-tx-v7-0-e44a20553464@freebox.fr>
 <20240724-hdmi-tx-v7-4-e44a20553464@freebox.fr>
Message-ID: <2009ea50-c82e-45ee-afd2-b6f5e0435dba@linaro.org>

On 24/07/2024 18:01, Marc Gonzalez wrote:
> From: Arnaud Vrac <avrac at freebox.fr>
> 
> Add support for the HDMI PHY as present on the Qualcomm MSM8998 SoC.
> This code is mostly copy & paste of the vendor code from msm-4.4
> kernel.lnx.4.4.r38-rel.
> 
> Signed-off-by: Arnaud Vrac <avrac at freebox.fr>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
> Signed-off-by: Marc Gonzalez <mgonzalez at freebox.fr>
> ---
>   drivers/gpu/drm/msm/Makefile                   |   1 +
>   drivers/gpu/drm/msm/hdmi/hdmi.h                |   8 +
>   drivers/gpu/drm/msm/hdmi/hdmi_phy.c            |   5 +
>   drivers/gpu/drm/msm/hdmi/hdmi_phy_8998.c       | 779 +++++++++++++++++++++++++
>   drivers/gpu/drm/msm/registers/display/hdmi.xml |  89 +++
>   5 files changed, 882 insertions(+)
> 
> diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
> index eb788921ff4fe..b9a5dc8c33ede 100644
> --- a/drivers/gpu/drm/msm/Makefile
> +++ b/drivers/gpu/drm/msm/Makefile
> @@ -32,6 +32,7 @@ msm-display-$(CONFIG_DRM_MSM_HDMI) += \
>   	hdmi/hdmi_phy.o \
>   	hdmi/hdmi_phy_8960.o \
>   	hdmi/hdmi_phy_8996.o \
> +	hdmi/hdmi_phy_8998.o \
>   	hdmi/hdmi_phy_8x60.o \
>   	hdmi/hdmi_phy_8x74.o \
>   	hdmi/hdmi_pll_8960.o \
> diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.h b/drivers/gpu/drm/msm/hdmi/hdmi.h
> index 4586baf364151..a62d2aedfbb72 100644
> --- a/drivers/gpu/drm/msm/hdmi/hdmi.h
> +++ b/drivers/gpu/drm/msm/hdmi/hdmi.h
> @@ -137,6 +137,7 @@ enum hdmi_phy_type {
>   	MSM_HDMI_PHY_8960,
>   	MSM_HDMI_PHY_8x74,
>   	MSM_HDMI_PHY_8996,
> +	MSM_HDMI_PHY_8998,
>   	MSM_HDMI_PHY_MAX,
>   };
>   
> @@ -154,6 +155,7 @@ extern const struct hdmi_phy_cfg msm_hdmi_phy_8x60_cfg;
>   extern const struct hdmi_phy_cfg msm_hdmi_phy_8960_cfg;
>   extern const struct hdmi_phy_cfg msm_hdmi_phy_8x74_cfg;
>   extern const struct hdmi_phy_cfg msm_hdmi_phy_8996_cfg;
> +extern const struct hdmi_phy_cfg msm_hdmi_phy_8998_cfg;
>   
>   struct hdmi_phy {
>   	struct platform_device *pdev;
> @@ -184,6 +186,7 @@ void __exit msm_hdmi_phy_driver_unregister(void);
>   #ifdef CONFIG_COMMON_CLK
>   int msm_hdmi_pll_8960_init(struct platform_device *pdev);
>   int msm_hdmi_pll_8996_init(struct platform_device *pdev);
> +int msm_hdmi_pll_8998_init(struct platform_device *pdev);
>   #else
>   static inline int msm_hdmi_pll_8960_init(struct platform_device *pdev)
>   {
> @@ -194,6 +197,11 @@ static inline int msm_hdmi_pll_8996_init(struct platform_device *pdev)
>   {
>   	return -ENODEV;
>   }
> +
> +static inline int msm_hdmi_pll_8998_init(struct platform_device *pdev)
> +{
> +	return -ENODEV;
> +}
>   #endif
>   
>   /*
> diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_phy.c b/drivers/gpu/drm/msm/hdmi/hdmi_phy.c
> index 88a3423b7f24d..95b3f7535d840 100644
> --- a/drivers/gpu/drm/msm/hdmi/hdmi_phy.c
> +++ b/drivers/gpu/drm/msm/hdmi/hdmi_phy.c
> @@ -118,6 +118,9 @@ static int msm_hdmi_phy_pll_init(struct platform_device *pdev,
>   	case MSM_HDMI_PHY_8996:
>   		ret = msm_hdmi_pll_8996_init(pdev);
>   		break;
> +	case MSM_HDMI_PHY_8998:
> +		ret = msm_hdmi_pll_8998_init(pdev);
> +		break;
>   	/*
>   	 * we don't have PLL support for these, don't report an error for now
>   	 */
> @@ -193,6 +196,8 @@ static const struct of_device_id msm_hdmi_phy_dt_match[] = {
>   	  .data = &msm_hdmi_phy_8x74_cfg },
>   	{ .compatible = "qcom,hdmi-phy-8996",
>   	  .data = &msm_hdmi_phy_8996_cfg },
> +	{ .compatible = "qcom,hdmi-phy-8998",
> +	  .data = &msm_hdmi_phy_8998_cfg },
>   	{}
>   };
>   
> diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_phy_8998.c b/drivers/gpu/drm/msm/hdmi/hdmi_phy_8998.c
> new file mode 100644
> index 0000000000000..9a3b005fa391a
> --- /dev/null
> +++ b/drivers/gpu/drm/msm/hdmi/hdmi_phy_8998.c
> @@ -0,0 +1,779 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2016, The Linux Foundation. All rights reserved.
> + * Copyright (c) 2024 Freebox SAS
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/delay.h>
> +
> +#include "hdmi.h"
> +
> +#define HDMI_VCO_MAX_FREQ			12000000000UL
> +#define HDMI_VCO_MIN_FREQ			8000000000UL
> +
> +#define HDMI_PCLK_MAX_FREQ			600000000
> +#define HDMI_PCLK_MIN_FREQ			25000000
> +
> +#define HDMI_HIGH_FREQ_BIT_CLK_THRESHOLD	3400000000UL
> +#define HDMI_DIG_FREQ_BIT_CLK_THRESHOLD		1500000000UL
> +#define HDMI_MID_FREQ_BIT_CLK_THRESHOLD		750000000UL
> +#define HDMI_CORECLK_DIV			5
> +#define HDMI_DEFAULT_REF_CLOCK			19200000
> +#define HDMI_PLL_CMP_CNT			1024
> +
> +#define HDMI_PLL_POLL_MAX_READS			100
> +#define HDMI_PLL_POLL_TIMEOUT_US		150
> +
> +#define HDMI_NUM_TX_CHANNEL			4
> +
> +struct hdmi_pll_8998 {
> +	struct platform_device *pdev;
> +	struct clk_hw clk_hw;
> +	unsigned long rate;
> +
> +	/* pll mmio base */
> +	void __iomem *mmio_qserdes_com;
> +	/* tx channel base */
> +	void __iomem *mmio_qserdes_tx[HDMI_NUM_TX_CHANNEL];
> +};
> +
> +#define hw_clk_to_pll(x) container_of(x, struct hdmi_pll_8998, clk_hw)
> +
> +struct hdmi_8998_phy_pll_reg_cfg {
> +	u32 com_svs_mode_clk_sel;
> +	u32 com_hsclk_sel;
> +	u32 com_pll_cctrl_mode0;
> +	u32 com_pll_rctrl_mode0;
> +	u32 com_cp_ctrl_mode0;
> +	u32 com_dec_start_mode0;
> +	u32 com_div_frac_start1_mode0;
> +	u32 com_div_frac_start2_mode0;
> +	u32 com_div_frac_start3_mode0;
> +	u32 com_integloop_gain0_mode0;
> +	u32 com_integloop_gain1_mode0;
> +	u32 com_lock_cmp_en;
> +	u32 com_lock_cmp1_mode0;
> +	u32 com_lock_cmp2_mode0;
> +	u32 com_lock_cmp3_mode0;
> +	u32 com_core_clk_en;
> +	u32 com_coreclk_div_mode0;
> +
> +	u32 tx_lx_tx_band[HDMI_NUM_TX_CHANNEL];
> +	u32 tx_lx_tx_drv_lvl[HDMI_NUM_TX_CHANNEL];
> +	u32 tx_lx_tx_emp_post1_lvl[HDMI_NUM_TX_CHANNEL];
> +	u32 tx_lx_pre_driver_1[HDMI_NUM_TX_CHANNEL];
> +	u32 tx_lx_pre_driver_2[HDMI_NUM_TX_CHANNEL];
> +	u32 tx_lx_res_code_offset[HDMI_NUM_TX_CHANNEL];
> +
> +	u32 phy_mode;
> +};
> +
> +struct hdmi_8998_post_divider {
> +	u64 vco_freq;
> +	int hsclk_divsel;
> +	int vco_ratio;
> +	int tx_band_sel;
> +	int half_rate_mode;
> +};
> +
> +static inline struct hdmi_phy *pll_get_phy(struct hdmi_pll_8998 *pll)
> +{
> +	return platform_get_drvdata(pll->pdev);
> +}
> +
> +static inline void hdmi_pll_write(struct hdmi_pll_8998 *pll, int offset,
> +				  u32 data)
> +{
> +	writel(data, pll->mmio_qserdes_com + offset);
> +}
> +
> +static inline u32 hdmi_pll_read(struct hdmi_pll_8998 *pll, int offset)
> +{
> +	return readl(pll->mmio_qserdes_com + offset);
> +}
> +
> +static inline void hdmi_tx_chan_write(struct hdmi_pll_8998 *pll, int channel,
> +				      int offset, int data)
> +{
> +	 writel(data, pll->mmio_qserdes_tx[channel] + offset);
> +}
> +
> +static inline u32 pll_get_cpctrl(u64 frac_start, unsigned long ref_clk,
> +				 bool gen_ssc)
> +{
> +	if ((frac_start != 0) || gen_ssc)
> +		return 0x8;
> +
> +	return 0x30;
> +}
> +
> +static inline u32 pll_get_rctrl(u64 frac_start, bool gen_ssc)
> +{
> +	if ((frac_start != 0) || gen_ssc)
> +		return 0x16;
> +
> +	return 0x18;
> +}
> +
> +static inline u32 pll_get_cctrl(u64 frac_start, bool gen_ssc)
> +{
> +	if ((frac_start != 0) || gen_ssc)
> +		return 0x34;
> +
> +	return 0x2;
> +}
> +
> +static inline u32 pll_get_integloop_gain(u64 frac_start, u64 bclk, u32 ref_clk,
> +					 bool gen_ssc)
> +{
> +	int digclk_divsel = bclk > HDMI_DIG_FREQ_BIT_CLK_THRESHOLD ? 1 : 2;
> +	u64 base;
> +
> +	if ((frac_start != 0) || gen_ssc)
> +		base = 0x3F;
> +	else
> +		base = 0xC4;
> +
> +	base <<= (digclk_divsel == 2 ? 1 : 0);
> +
> +	return (base <= 2046 ? base : 2046);
> +}
> +
> +static inline u32 pll_get_pll_cmp(u64 fdata, unsigned long ref_clk)
> +{
> +	u64 dividend = HDMI_PLL_CMP_CNT * fdata;
> +	u32 divisor = ref_clk * 10;
> +	u32 rem;
> +
> +	rem = do_div(dividend, divisor);
> +	if (rem > (divisor >> 1))
> +		dividend++;
> +
> +	return dividend - 1;
> +}
> +
> +static inline u64 pll_cmp_to_fdata(u32 pll_cmp, unsigned long ref_clk)
> +{
> +	u64 fdata = ((u64)pll_cmp) * ref_clk * 10;
> +
> +	do_div(fdata, HDMI_PLL_CMP_CNT);
> +
> +	return fdata;
> +}
> +
> +#define HDMI_REF_CLOCK_HZ ((u64)19200000)
> +#define HDMI_MHZ_TO_HZ ((u64)1000000)
> +static int pll_get_post_div(struct hdmi_8998_post_divider *pd, u64 bclk)
> +{
> +	u32 const ratio_list[] = {1, 2, 3, 4, 5, 6,
> +				     9, 10, 12, 15, 25};
> +	u32 const band_list[] = {0, 1, 2, 3};
> +	u32 const sz_ratio = ARRAY_SIZE(ratio_list);
> +	u32 const sz_band = ARRAY_SIZE(band_list);
> +	u32 const cmp_cnt = 1024;
> +	u32 const th_min = 500, th_max = 1000;
> +	u32 half_rate_mode = 0;
> +	u32 list_elements;
> +	int optimal_index;
> +	u32 i, j, k;
> +	u32 found_hsclk_divsel = 0, found_vco_ratio;
> +	u32 found_tx_band_sel;
> +	u64 const min_freq = HDMI_VCO_MIN_FREQ, max_freq = HDMI_VCO_MAX_FREQ;
> +	u64 freq_list[ARRAY_SIZE(ratio_list) * ARRAY_SIZE(band_list)];
> +	u64 found_vco_freq;
> +	u64 freq_optimal;
> +
> +find_optimal_index:
> +	freq_optimal = max_freq;
> +	optimal_index = -1;
> +	list_elements = 0;
> +
> +	for (i = 0; i < sz_ratio; i++) {
> +		for (j = 0; j < sz_band; j++) {
> +			u64 freq = div_u64(bclk, (1 << half_rate_mode));
> +
> +			freq *= (ratio_list[i] * (1 << band_list[j]));
> +			freq_list[list_elements++] = freq;
> +		}
> +	}
> +
> +	for (k = 0; k < ARRAY_SIZE(freq_list); k++) {
> +		u32 const clks_pll_div = 2, core_clk_div = 5;
> +		u32 const rng1 = 16, rng2 = 8;
> +		u32 th1, th2;
> +		u64 core_clk, rvar1, rem;
> +
> +		core_clk = (((freq_list[k] /
> +			      ratio_list[k / sz_band]) /
> +			      clks_pll_div) / core_clk_div);

This causes linking errors on arm32:

/usr/bin/arm-linux-gnueabi-ld: drivers/gpu/drm/msm/hdmi/hdmi_phy_8998.o: 
in function `pll_get_post_div':
drivers/gpu/drm/msm/hdmi/hdmi_phy_8998.c:207: undefined reference to 
`__aeabi_uldivmod'

I'll replace this with div_u64. If it results in wrong frequencies being 
selected, please post a separate fix for 6.12-rc

-- 
With best wishes
Dmitry



From ulf.hansson at linaro.org  Sat Aug 31 03:32:02 2024
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Sat, 31 Aug 2024 12:32:02 +0200
Subject: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
In-Reply-To: <fa9b3449-ea3e-4482-b7eb-96999445cea5@tuxon.dev>
References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com>
 <CAPDyKFrS4Dhd7DZa2zz=oPro1TiTJFix0awzzzp8Qatm-8Z2Ug@mail.gmail.com>
 <99bef301-9f6c-4797-b47e-c83e56dfbda9@tuxon.dev> <CAPDyKFrVS2vpsJqTvjKCJ7ADqXc4D4k2eeCBsaK4T+=pXDnKUA@mail.gmail.com>
 <fa9b3449-ea3e-4482-b7eb-96999445cea5@tuxon.dev>
Message-ID: <CAPDyKFrkkASq7rfRN=9sEet-p8T8t+f__PdnSNRN3bMNipnNNw@mail.gmail.com>

[...]

> >
> > If not, there are two other options that can be considered I think.
> > *) Using the genpd on/off notifiers, to really allow the consumer
> > driver of the reset-control to know when the PM domain gets turned
> > on/off.
> > **) Move the entire reset handling into the PM domain provider, as it
> > obviously knows when the domain is getting turned on/off.
>
> This option is what I've explored, tested on my side.
>
> I explored it in 2 ways:
>
> 1/ SYSC modeled as an individual PM domain provider (this is more
>    appropriate to how HW manual described the hardware) with this the PHY
>    reset DT node would have to get 2 PM domains handlers (one for the
>    current PM domain provider and the other one for SYSC):
>
> +               phyrst: usbphy-ctrl at 11e00000 {
> +                       compatible = "renesas,r9a08g045-usbphy-ctrl";
> +                       reg = <0 0x11e00000 0 0x10000>;
> +                       clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>;
> +                       resets = <&cpg R9A08G045_USB_PRESETN>;
> +                       power-domain-names = "cpg", "sysc";
> +                       power-domains = <&cpg R9A08G045_PD_USB_PHY>, <&sysc
> R9A08G045_SYSC_PD_USB>;
> +                       #reset-cells = <1>;
> +                       status = "disabled";
> +
> +                       usb0_vbus_otg: regulator-vbus {
> +                               regulator-name = "vbus";
> +                       };
> +               };
> +

According to what you have described earlier/above, modelling the SYSC
as a PM domain provider seems like a better description of the HW to
me. Although, as I said earlier, if you prefer the reset approach, I
would not object to that.

>
> and the PHY reset driver will get bulky with powering on/off both of these,
> at least with my current implementation, something like (and the following
> code is in probe()):
>
> +       if (priv->set_power) {
> +               priv->cpg_genpd_dev = dev_pm_domain_attach_by_name(dev, "cpg");
> +               if (IS_ERR(priv->cpg_genpd_dev)) {
> +                       dev_err_probe(dev, error, "Failed to attach CPG PM
> domain!");
> +                       error = PTR_ERR(priv->cpg_genpd_dev);
> +                       goto err_pm_runtime_put;
> +               }
> +
> +               priv->sysc_genpd_dev = dev_pm_domain_attach_by_name(dev,
> "sysc");
> +               if (IS_ERR(priv->sysc_genpd_dev)) {
> +                       dev_err_probe(dev, error, "Failed to attach sysc PM
> domain!");
> +                       error = PTR_ERR(priv->sysc_genpd_dev);
> +                       goto err_genpd_cpg_detach;
> +               }
> +
> +               priv->cpg_genpd_dl = device_link_add(dev, priv->cpg_genpd_dev,
> +                                                    DL_FLAG_PM_RUNTIME |
> +                                                    DL_FLAG_STATELESS);
> +               if (!priv->cpg_genpd_dl) {
> +                       dev_err_probe(dev, -ENOMEM, "Failed to add CPG
> genpd device link!");
> +                       goto err_genpd_sysc_detach;
> +               }
> +
> +               priv->sysc_genpd_dl = device_link_add(dev,
> priv->sysc_genpd_dev,
> +                                                     DL_FLAG_PM_RUNTIME |
> +                                                     DL_FLAG_STATELESS);
> +               if (!priv->sysc_genpd_dl) {
> +                       dev_err_probe(dev, -ENOMEM, "Failed to add sysc
> genpd device link!");
> +                       goto err_genpd_cpg_dl_del;
> +               }
> +
> +
> +               error = pm_runtime_resume_and_get(priv->cpg_genpd_dev);
> +               if (error) {
> +                       dev_err_probe(dev, error, "Failed to runtime resume
> cpg PM domain!");
> +                       goto err_genpd_sysc_dl_del;
> +               }
> +
> +               error = pm_runtime_resume_and_get(priv->sysc_genpd_dev);
> +               if (error) {
> +                       dev_err_probe(dev, error, "Failed to runtime resume
> sysc PM domain!");
> +                       goto err_genpd_cpg_off;
> +               }
> +       }

Indeed, the code above looks bulky.

Fortunately, we now have dev|devm_pm_domain_attach_list(), which
replaces all of the code above.

[...]

Kind regards
Uffe


From hdegoede at redhat.com  Sat Aug 31 07:20:33 2024
From: hdegoede at redhat.com (Hans de Goede)
Date: Sat, 31 Aug 2024 16:20:33 +0200
Subject: [PATCH 0/6] power: supply: Change usb_types from an array into a bitmask
Message-ID: <20240831142039.28830-1-hdegoede@redhat.com>

Hi All,

When support for the "charge_behaviour" property was added the list of
available values was made a bitmask in power_supply_desc.

"usb_types" is very similar in that:
1. It is an enum
2. The list of available values is stored in power_supply_desc
3. When shown it shows all available values, with the active one surrounded
   by square brackets.

But "usb_types" uses an array with valid enum values instead of a bitmask.
This uses more memory then the bitmap approach and it makes it impossible
to have a shared generic show() function for properties which show
available values, with the active one surrounded by square brackets.

This patch-set moves "usb_types" over to a bitmask in power_supply_desc
to indicate the available values.

Patches 1 - 3:

It turns out that the ucs1002-power driver contained a surprise in that
it supports writing to "usb_type" even though the ABI doc says it is
read-only. Since we cannot break shipped userspace API, the ship has sailed
on this one. The first patch documents that writing "usb_type" is allowed,
but only for power-supply devices which provide USB power rather then
consume it.

Enum properties accept writing the FOO_TEXT[] string values, passing
the enum value matching the FOO_TEXT entry to set_property(), the second
patch adjusts ucs1002_set_usb_type() to directly accept enum values.

The rt9467 driver was another driver which allowed writing to "usb_type"
but there the use made no sense, so it is simply dropped.

Patches 4 - 6:

These patches implement the actual moving of usb_types to a bitmask.

Patch 6 is a bit of a bigbang patch moving all drivers over in one go,
touching a couple of drivers outside drivers/power/supply: 1 in
drivers/extcon/ 1 in drivers/phy/ and 5 in drivers/usb/typec/ since
the changes outside of drivers/power/supply are small I've chosen to
make all the changes in one go rather then have some sort of
intermediate state where both ways are supported.

For merging this I believe it would be best for an immutable branch / tag
to be created on the linux-power-supply tree and then send a pull-request
to the extcon, phy and usb-typec maintainers to merge the tag.

extcon, phy and typec maintainers can you please give your Acked-by for
patch 6/6 for merging these changes through the linux-power-supply tree?

This set is based on top of the latest linux-power-supply/for-next.

Regards,

Hans


Hans de Goede (6):
  power: supply: "usb_type" property may be written to
  power: supply: ucs1002: Adjust ucs1002_set_usb_type() to accept string
    values
  power: supply: rt9467-charger: Remove "usb_type" property write
    support
  power: supply: sysfs: Add power_supply_show_enum_with_available()
    helper
  power: supply: sysfs: Move power_supply_show_enum_with_available() up
  power: supply: Change usb_types from an array into a bitmask

 Documentation/ABI/testing/sysfs-class-power   |  7 +-
 drivers/extcon/extcon-intel-cht-wc.c          | 15 ++---
 drivers/phy/ti/phy-tusb1210.c                 | 11 +---
 drivers/power/supply/axp20x_usb_power.c       | 13 ++--
 drivers/power/supply/bq256xx_charger.c        | 15 ++---
 drivers/power/supply/cros_usbpd-charger.c     | 22 +++----
 .../power/supply/lenovo_yoga_c630_battery.c   |  7 +-
 drivers/power/supply/mp2629_charger.c         | 15 ++---
 drivers/power/supply/mt6360_charger.c         | 13 ++--
 drivers/power/supply/mt6370-charger.c         | 13 ++--
 drivers/power/supply/power_supply_core.c      |  4 --
 drivers/power/supply/power_supply_sysfs.c     | 66 ++++++-------------
 drivers/power/supply/qcom_battmgr.c           | 37 ++++++-----
 drivers/power/supply/qcom_pmi8998_charger.c   | 13 ++--
 drivers/power/supply/rk817_charger.c          |  9 +--
 drivers/power/supply/rn5t618_power.c          | 13 ++--
 drivers/power/supply/rt9467-charger.c         | 16 ++---
 drivers/power/supply/rt9471.c                 | 15 ++---
 drivers/power/supply/ucs1002_power.c          | 26 ++++----
 drivers/usb/typec/anx7411.c                   | 11 +---
 drivers/usb/typec/rt1719.c                    | 11 +---
 drivers/usb/typec/tcpm/tcpm.c                 | 11 +---
 drivers/usb/typec/tipd/core.c                 |  9 +--
 drivers/usb/typec/ucsi/psy.c                  | 11 +---
 include/linux/power_supply.h                  |  3 +-
 25 files changed, 132 insertions(+), 254 deletions(-)

-- 
2.46.0



From hdegoede at redhat.com  Sat Aug 31 07:20:34 2024
From: hdegoede at redhat.com (Hans de Goede)
Date: Sat, 31 Aug 2024 16:20:34 +0200
Subject: [PATCH 1/6] power: supply: "usb_type" property may be written to
In-Reply-To: <20240831142039.28830-1-hdegoede@redhat.com>
References: <20240831142039.28830-1-hdegoede@redhat.com>
Message-ID: <20240831142039.28830-2-hdegoede@redhat.com>

According to Documentation/ABI/testing/sysfs-class-power the "usb_type"
property is Read-Only.

For power-supplies which consume USB power such as battery charger chips,
this is correct.

But the UCS1002 USB Port Power Controller driver which is a driver
for a chip which is a power-source for USB-A charging ports "usb_type"
is actually writable to configure the type of USB charger emulated
by the USB-A port.

Adjust the docs and the power_supply_sysfs.c code to adjust for this
new writeable use of "usb_type":

1. Update Documentation/ABI/testing/sysfs-class-power to document that
"usb_type" may be writable

2. Change the power_supply_attr type in power_supply_sysfs.c from
POWER_SUPPLY_ATTR() into POWER_SUPPLY_ENUM_ATTR() so that the various
usb_type string values from POWER_SUPPLY_TYPE_TEXT[] such as e.g.
"SDP" and "USB_PD" can be written to the "usb_type" attribute instead
of only accepting integer values.

Cc: Enric Balletbo Serra <enric.balletbo at collabora.com>
Cc: Andrey Smirnov <andrew.smirnov at gmail.com>
Signed-off-by: Hans de Goede <hdegoede at redhat.com>
---
 Documentation/ABI/testing/sysfs-class-power | 7 ++++++-
 drivers/power/supply/power_supply_sysfs.c   | 2 +-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-class-power b/Documentation/ABI/testing/sysfs-class-power
index 84973f66b42c..45180b62d426 100644
--- a/Documentation/ABI/testing/sysfs-class-power
+++ b/Documentation/ABI/testing/sysfs-class-power
@@ -608,7 +608,12 @@ Description:
 		the supply, for example it can show if USB-PD capable source
 		is attached.
 
-		Access: Read-Only
+		Access: For power-supplies which consume USB power such
+		as battery charger chips, this indicates the type of
+		the connected USB power source and is Read-Only.
+
+		For power-supplies which act as a USB power-source such as
+		e.g. the UCS1002 USB Port Power Controller this is writable.
 
 		Valid values:
 			      "Unknown", "SDP", "DCP", "CDP", "ACA", "C", "PD",
diff --git a/drivers/power/supply/power_supply_sysfs.c b/drivers/power/supply/power_supply_sysfs.c
index 3e63d165b2f7..ff7e423edd57 100644
--- a/drivers/power/supply/power_supply_sysfs.c
+++ b/drivers/power/supply/power_supply_sysfs.c
@@ -209,7 +209,7 @@ static struct power_supply_attr power_supply_attrs[] = {
 	POWER_SUPPLY_ATTR(TIME_TO_FULL_NOW),
 	POWER_SUPPLY_ATTR(TIME_TO_FULL_AVG),
 	POWER_SUPPLY_ENUM_ATTR(TYPE),
-	POWER_SUPPLY_ATTR(USB_TYPE),
+	POWER_SUPPLY_ENUM_ATTR(USB_TYPE),
 	POWER_SUPPLY_ENUM_ATTR(SCOPE),
 	POWER_SUPPLY_ATTR(PRECHARGE_CURRENT),
 	POWER_SUPPLY_ATTR(CHARGE_TERM_CURRENT),
-- 
2.46.0



From hdegoede at redhat.com  Sat Aug 31 07:20:35 2024
From: hdegoede at redhat.com (Hans de Goede)
Date: Sat, 31 Aug 2024 16:20:35 +0200
Subject: [PATCH 2/6] power: supply: ucs1002: Adjust ucs1002_set_usb_type() to accept string values
In-Reply-To: <20240831142039.28830-1-hdegoede@redhat.com>
References: <20240831142039.28830-1-hdegoede@redhat.com>
Message-ID: <20240831142039.28830-3-hdegoede@redhat.com>

power_supply_sysfs.c accept wrrites of strings to "usb_type" for strings
values matching an entry in POWER_SUPPLY_USB_TYPE_TEXT[]. If such a
string value is written then the int value passed to ucs1002_set_property()
will be an enum power_supply_usb_type value.

Before this change ucs1002_set_usb_type() expected the value to be an index
into ucs1002_usb_types[]. Adjust ucs1002_set_usb_type() to use the enum
value directly so that writing string values works.

The list of supported types in ucs1002_usb_types[] is: PD, SDP, DCP, CDP.
The [POWER_SUPPLY_USB_TYPE_]SDP, DCP and CDP enum labels have a value of
1, 2 and 3. So userspace selecting SDP, DCP or CDP by writing 1, 2 or 3
will keep working. POWER_SUPPLY_USB_TYPE_PD which is mapped to the ucs1002
dedicated mode however has a value of 6. Before this change writing 0 would
select the dedicated mode. To preserve userspace API compatibility also map
POWER_SUPPLY_USB_TYPE_UNKNOWN (which is 0) to the dedicated mode.

Cc: Enric Balletbo Serra <enric.balletbo at collabora.com>
Cc: Andrey Smirnov <andrew.smirnov at gmail.com>
Signed-off-by: Hans de Goede <hdegoede at redhat.com>
---
 drivers/power/supply/ucs1002_power.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/power/supply/ucs1002_power.c b/drivers/power/supply/ucs1002_power.c
index 7970843a4f48..b67d5b03d93e 100644
--- a/drivers/power/supply/ucs1002_power.c
+++ b/drivers/power/supply/ucs1002_power.c
@@ -308,10 +308,13 @@ static int ucs1002_set_usb_type(struct ucs1002_info *info, int val)
 {
 	unsigned int mode;
 
-	if (val < 0 || val >= ARRAY_SIZE(ucs1002_usb_types))
-		return -EINVAL;
-
-	switch (ucs1002_usb_types[val]) {
+	switch (val) {
+	/*
+	 * POWER_SUPPLY_USB_TYPE_UNKNOWN == 0, map this to dedicated for
+	 * userspace API compatibility with older versions of this driver
+	 * which mapped 0 to dedicated.
+	 */
+	case POWER_SUPPLY_USB_TYPE_UNKNOWN:
 	case POWER_SUPPLY_USB_TYPE_PD:
 		mode = V_SET_ACTIVE_MODE_DEDICATED;
 		break;
-- 
2.46.0



From hdegoede at redhat.com  Sat Aug 31 07:20:36 2024
From: hdegoede at redhat.com (Hans de Goede)
Date: Sat, 31 Aug 2024 16:20:36 +0200
Subject: [PATCH 3/6] power: supply: rt9467-charger: Remove "usb_type" property write support
In-Reply-To: <20240831142039.28830-1-hdegoede@redhat.com>
References: <20240831142039.28830-1-hdegoede@redhat.com>
Message-ID: <20240831142039.28830-4-hdegoede@redhat.com>

The "usb_type" property must be read-only for charger power-supply devices,
see: Documentation/ABI/testing/sysfs-class-power.

But the rt9467 driver allows writing 0/1 to it to disable/enable charging.
Other charger drivers use the "status" property for this and the rt9467
code also allows writing 0/1 to its "status" property and this does
the exact same thing as writing 0/1 to its "usb_type" property.

Drop write support for the "usb_type" property making it readonly to match
the ABI documentation. If userspace wants to disable/enable charging it
can use the "status" property for this.

Signed-off-by: Hans de Goede <hdegoede at redhat.com>
---
 drivers/power/supply/rt9467-charger.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/power/supply/rt9467-charger.c b/drivers/power/supply/rt9467-charger.c
index fdfdc83ab045..f935bd761ac1 100644
--- a/drivers/power/supply/rt9467-charger.c
+++ b/drivers/power/supply/rt9467-charger.c
@@ -745,8 +745,6 @@ static int rt9467_psy_set_property(struct power_supply *psy,
 						    RT9467_RANGE_IPREC, val->intval);
 	case POWER_SUPPLY_PROP_CHARGE_TERM_CURRENT:
 		return rt9467_psy_set_ieoc(data, val->intval);
-	case POWER_SUPPLY_PROP_USB_TYPE:
-		return regmap_field_write(data->rm_field[F_USBCHGEN], val->intval);
 	default:
 		return -EINVAL;
 	}
@@ -764,7 +762,6 @@ static int rt9467_chg_prop_is_writeable(struct power_supply *psy,
 	case POWER_SUPPLY_PROP_INPUT_VOLTAGE_LIMIT:
 	case POWER_SUPPLY_PROP_CHARGE_TERM_CURRENT:
 	case POWER_SUPPLY_PROP_PRECHARGE_CURRENT:
-	case POWER_SUPPLY_PROP_USB_TYPE:
 		return 1;
 	default:
 		return 0;
-- 
2.46.0



From hdegoede at redhat.com  Sat Aug 31 07:20:37 2024
From: hdegoede at redhat.com (Hans de Goede)
Date: Sat, 31 Aug 2024 16:20:37 +0200
Subject: [PATCH 4/6] power: supply: sysfs: Add power_supply_show_enum_with_available() helper
In-Reply-To: <20240831142039.28830-1-hdegoede@redhat.com>
References: <20240831142039.28830-1-hdegoede@redhat.com>
Message-ID: <20240831142039.28830-5-hdegoede@redhat.com>

Turn power_supply_charge_behaviour_show() into a generic function for
showing enum values with their available (for writing) values shown
and the current value shown surrounded by sqaure-brackets like
the show() output for "usb_type" and "charge_behaviour".

This is a preparation patch for refactoring the "usb_type" property
handling to use a bitmask indicating available usb-types + this new
generic function.

Signed-off-by: Hans de Goede <hdegoede at redhat.com>
---
 drivers/power/supply/power_supply_sysfs.c | 32 ++++++++++++++---------
 1 file changed, 20 insertions(+), 12 deletions(-)

diff --git a/drivers/power/supply/power_supply_sysfs.c b/drivers/power/supply/power_supply_sysfs.c
index ff7e423edd57..9f21b0b54caf 100644
--- a/drivers/power/supply/power_supply_sysfs.c
+++ b/drivers/power/supply/power_supply_sysfs.c
@@ -518,31 +518,28 @@ int power_supply_uevent(const struct device *dev, struct kobj_uevent_env *env)
 	return ret;
 }
 
-ssize_t power_supply_charge_behaviour_show(struct device *dev,
-					   unsigned int available_behaviours,
-					   enum power_supply_charge_behaviour current_behaviour,
-					   char *buf)
+static ssize_t power_supply_show_enum_with_available(
+			struct device *dev, const char * const labels[], int label_count,
+			unsigned int available_values, int value, char *buf)
 {
 	bool match = false, available, active;
 	ssize_t count = 0;
 	int i;
 
-	for (i = 0; i < ARRAY_SIZE(POWER_SUPPLY_CHARGE_BEHAVIOUR_TEXT); i++) {
-		available = available_behaviours & BIT(i);
-		active = i == current_behaviour;
+	for (i = 0; i < label_count; i++) {
+		available = available_values & BIT(i);
+		active = i == value;
 
 		if (available && active) {
-			count += sysfs_emit_at(buf, count, "[%s] ",
-					       POWER_SUPPLY_CHARGE_BEHAVIOUR_TEXT[i]);
+			count += sysfs_emit_at(buf, count, "[%s] ", labels[i]);
 			match = true;
 		} else if (available) {
-			count += sysfs_emit_at(buf, count, "%s ",
-					       POWER_SUPPLY_CHARGE_BEHAVIOUR_TEXT[i]);
+			count += sysfs_emit_at(buf, count, "%s ", labels[i]);
 		}
 	}
 
 	if (!match) {
-		dev_warn(dev, "driver reporting unsupported charge behaviour\n");
+		dev_warn(dev, "driver reporting unavailable enum value %d\n", value);
 		return -EINVAL;
 	}
 
@@ -551,6 +548,17 @@ ssize_t power_supply_charge_behaviour_show(struct device *dev,
 
 	return count;
 }
+
+ssize_t power_supply_charge_behaviour_show(struct device *dev,
+					   unsigned int available_behaviours,
+					   enum power_supply_charge_behaviour current_behaviour,
+					   char *buf)
+{
+	return power_supply_show_enum_with_available(
+				dev, POWER_SUPPLY_CHARGE_BEHAVIOUR_TEXT,
+				ARRAY_SIZE(POWER_SUPPLY_CHARGE_BEHAVIOUR_TEXT),
+				available_behaviours, current_behaviour, buf);
+}
 EXPORT_SYMBOL_GPL(power_supply_charge_behaviour_show);
 
 int power_supply_charge_behaviour_parse(unsigned int available_behaviours, const char *buf)
-- 
2.46.0



From hdegoede at redhat.com  Sat Aug 31 07:20:38 2024
From: hdegoede at redhat.com (Hans de Goede)
Date: Sat, 31 Aug 2024 16:20:38 +0200
Subject: [PATCH 5/6] power: supply: sysfs: Move power_supply_show_enum_with_available() up
In-Reply-To: <20240831142039.28830-1-hdegoede@redhat.com>
References: <20240831142039.28830-1-hdegoede@redhat.com>
Message-ID: <20240831142039.28830-6-hdegoede@redhat.com>

Move power_supply_show_enum_with_available() higher up in
the power_supply_sysfs.c file.

This is a preparation patch to avoid needing a forward declaration
when replacing power_supply_show_usb_type() with it later on.

This commit only moves the function, there are no changes to it.

Signed-off-by: Hans de Goede <hdegoede at redhat.com>
---
 drivers/power/supply/power_supply_sysfs.c | 62 +++++++++++------------
 1 file changed, 31 insertions(+), 31 deletions(-)

diff --git a/drivers/power/supply/power_supply_sysfs.c b/drivers/power/supply/power_supply_sysfs.c
index 9f21b0b54caf..c98a6de59d3b 100644
--- a/drivers/power/supply/power_supply_sysfs.c
+++ b/drivers/power/supply/power_supply_sysfs.c
@@ -237,6 +237,37 @@ static enum power_supply_property dev_attr_psp(struct device_attribute *attr)
 	return  to_ps_attr(attr) - power_supply_attrs;
 }
 
+static ssize_t power_supply_show_enum_with_available(
+			struct device *dev, const char * const labels[], int label_count,
+			unsigned int available_values, int value, char *buf)
+{
+	bool match = false, available, active;
+	ssize_t count = 0;
+	int i;
+
+	for (i = 0; i < label_count; i++) {
+		available = available_values & BIT(i);
+		active = i == value;
+
+		if (available && active) {
+			count += sysfs_emit_at(buf, count, "[%s] ", labels[i]);
+			match = true;
+		} else if (available) {
+			count += sysfs_emit_at(buf, count, "%s ", labels[i]);
+		}
+	}
+
+	if (!match) {
+		dev_warn(dev, "driver reporting unavailable enum value %d\n", value);
+		return -EINVAL;
+	}
+
+	if (count)
+		buf[count - 1] = '\n';
+
+	return count;
+}
+
 static ssize_t power_supply_show_usb_type(struct device *dev,
 					  const struct power_supply_desc *desc,
 					  union power_supply_propval *value,
@@ -518,37 +549,6 @@ int power_supply_uevent(const struct device *dev, struct kobj_uevent_env *env)
 	return ret;
 }
 
-static ssize_t power_supply_show_enum_with_available(
-			struct device *dev, const char * const labels[], int label_count,
-			unsigned int available_values, int value, char *buf)
-{
-	bool match = false, available, active;
-	ssize_t count = 0;
-	int i;
-
-	for (i = 0; i < label_count; i++) {
-		available = available_values & BIT(i);
-		active = i == value;
-
-		if (available && active) {
-			count += sysfs_emit_at(buf, count, "[%s] ", labels[i]);
-			match = true;
-		} else if (available) {
-			count += sysfs_emit_at(buf, count, "%s ", labels[i]);
-		}
-	}
-
-	if (!match) {
-		dev_warn(dev, "driver reporting unavailable enum value %d\n", value);
-		return -EINVAL;
-	}
-
-	if (count)
-		buf[count - 1] = '\n';
-
-	return count;
-}
-
 ssize_t power_supply_charge_behaviour_show(struct device *dev,
 					   unsigned int available_behaviours,
 					   enum power_supply_charge_behaviour current_behaviour,
-- 
2.46.0



From hdegoede at redhat.com  Sat Aug 31 07:20:39 2024
From: hdegoede at redhat.com (Hans de Goede)
Date: Sat, 31 Aug 2024 16:20:39 +0200
Subject: [PATCH 6/6] power: supply: Change usb_types from an array into a bitmask
In-Reply-To: <20240831142039.28830-1-hdegoede@redhat.com>
References: <20240831142039.28830-1-hdegoede@redhat.com>
Message-ID: <20240831142039.28830-7-hdegoede@redhat.com>

The bit_types array just hold a list of valid enum power_supply_usb_type
values which map to 0 - 9. This can easily be represented as a bitmap.

This reduces the size of struct power_supply_desc and further reduces
the data section size by drivers no longer needing to store the array.

This also unifies how usb_types are handled with charge_behaviours,
which allows power_supply_show_usb_type() to be removed.

Signed-off-by: Hans de Goede <hdegoede at redhat.com>
---
 drivers/extcon/extcon-intel-cht-wc.c          | 15 +++----
 drivers/phy/ti/phy-tusb1210.c                 | 11 ++---
 drivers/power/supply/axp20x_usb_power.c       | 13 ++----
 drivers/power/supply/bq256xx_charger.c        | 15 +++----
 drivers/power/supply/cros_usbpd-charger.c     | 22 ++++------
 .../power/supply/lenovo_yoga_c630_battery.c   |  7 +---
 drivers/power/supply/mp2629_charger.c         | 15 +++----
 drivers/power/supply/mt6360_charger.c         | 13 ++----
 drivers/power/supply/mt6370-charger.c         | 13 ++----
 drivers/power/supply/power_supply_core.c      |  4 --
 drivers/power/supply/power_supply_sysfs.c     | 40 ++-----------------
 drivers/power/supply/qcom_battmgr.c           | 37 +++++++++--------
 drivers/power/supply/qcom_pmi8998_charger.c   | 13 ++----
 drivers/power/supply/rk817_charger.c          |  9 +----
 drivers/power/supply/rn5t618_power.c          | 13 ++----
 drivers/power/supply/rt9467-charger.c         | 13 ++----
 drivers/power/supply/rt9471.c                 | 15 +++----
 drivers/power/supply/ucs1002_power.c          | 15 +++----
 drivers/usb/typec/anx7411.c                   | 11 ++---
 drivers/usb/typec/rt1719.c                    | 11 ++---
 drivers/usb/typec/tcpm/tcpm.c                 | 11 ++---
 drivers/usb/typec/tipd/core.c                 |  9 +----
 drivers/usb/typec/ucsi/psy.c                  | 11 ++---
 include/linux/power_supply.h                  |  3 +-
 24 files changed, 102 insertions(+), 237 deletions(-)

diff --git a/drivers/extcon/extcon-intel-cht-wc.c b/drivers/extcon/extcon-intel-cht-wc.c
index 733c470c3102..93552dc3c895 100644
--- a/drivers/extcon/extcon-intel-cht-wc.c
+++ b/drivers/extcon/extcon-intel-cht-wc.c
@@ -461,14 +461,6 @@ static int cht_wc_extcon_psy_get_prop(struct power_supply *psy,
 	return 0;
 }
 
-static const enum power_supply_usb_type cht_wc_extcon_psy_usb_types[] = {
-	POWER_SUPPLY_USB_TYPE_SDP,
-	POWER_SUPPLY_USB_TYPE_CDP,
-	POWER_SUPPLY_USB_TYPE_DCP,
-	POWER_SUPPLY_USB_TYPE_ACA,
-	POWER_SUPPLY_USB_TYPE_UNKNOWN,
-};
-
 static const enum power_supply_property cht_wc_extcon_psy_props[] = {
 	POWER_SUPPLY_PROP_USB_TYPE,
 	POWER_SUPPLY_PROP_ONLINE,
@@ -477,8 +469,11 @@ static const enum power_supply_property cht_wc_extcon_psy_props[] = {
 static const struct power_supply_desc cht_wc_extcon_psy_desc = {
 	.name = "cht_wcove_pwrsrc",
 	.type = POWER_SUPPLY_TYPE_USB,
-	.usb_types = cht_wc_extcon_psy_usb_types,
-	.num_usb_types = ARRAY_SIZE(cht_wc_extcon_psy_usb_types),
+	.usb_types = BIT(POWER_SUPPLY_USB_TYPE_SDP) |
+		     BIT(POWER_SUPPLY_USB_TYPE_CDP) |
+		     BIT(POWER_SUPPLY_USB_TYPE_DCP) |
+		     BIT(POWER_SUPPLY_USB_TYPE_ACA) |
+		     BIT(POWER_SUPPLY_USB_TYPE_UNKNOWN),
 	.properties = cht_wc_extcon_psy_props,
 	.num_properties = ARRAY_SIZE(cht_wc_extcon_psy_props),
 	.get_property = cht_wc_extcon_psy_get_prop,
diff --git a/drivers/phy/ti/phy-tusb1210.c b/drivers/phy/ti/phy-tusb1210.c
index 751fecd466e3..c3ae9d7948d7 100644
--- a/drivers/phy/ti/phy-tusb1210.c
+++ b/drivers/phy/ti/phy-tusb1210.c
@@ -411,12 +411,6 @@ static int tusb1210_psy_get_prop(struct power_supply *psy,
 	return 0;
 }
 
-static const enum power_supply_usb_type tusb1210_psy_usb_types[] = {
-	POWER_SUPPLY_USB_TYPE_SDP,
-	POWER_SUPPLY_USB_TYPE_DCP,
-	POWER_SUPPLY_USB_TYPE_UNKNOWN,
-};
-
 static const enum power_supply_property tusb1210_psy_props[] = {
 	POWER_SUPPLY_PROP_ONLINE,
 	POWER_SUPPLY_PROP_USB_TYPE,
@@ -426,8 +420,9 @@ static const enum power_supply_property tusb1210_psy_props[] = {
 static const struct power_supply_desc tusb1210_psy_desc = {
 	.name = "tusb1211-charger-detect",
 	.type = POWER_SUPPLY_TYPE_USB,
-	.usb_types = tusb1210_psy_usb_types,
-	.num_usb_types = ARRAY_SIZE(tusb1210_psy_usb_types),
+	.usb_types = BIT(POWER_SUPPLY_USB_TYPE_SDP) |
+		     BIT(POWER_SUPPLY_USB_TYPE_DCP) |
+		     BIT(POWER_SUPPLY_USB_TYPE_UNKNOWN),
 	.properties = tusb1210_psy_props,
 	.num_properties = ARRAY_SIZE(tusb1210_psy_props),
 	.get_property = tusb1210_psy_get_prop,
diff --git a/drivers/power/supply/axp20x_usb_power.c b/drivers/power/supply/axp20x_usb_power.c
index 69fbb5861934..7b1bf6766ff7 100644
--- a/drivers/power/supply/axp20x_usb_power.c
+++ b/drivers/power/supply/axp20x_usb_power.c
@@ -456,13 +456,6 @@ static enum power_supply_property axp813_usb_power_properties[] = {
 	POWER_SUPPLY_PROP_USB_TYPE,
 };
 
-static enum power_supply_usb_type axp813_usb_types[] = {
-	POWER_SUPPLY_USB_TYPE_SDP,
-	POWER_SUPPLY_USB_TYPE_DCP,
-	POWER_SUPPLY_USB_TYPE_CDP,
-	POWER_SUPPLY_USB_TYPE_UNKNOWN,
-};
-
 static const struct power_supply_desc axp20x_usb_power_desc = {
 	.name = "axp20x-usb",
 	.type = POWER_SUPPLY_TYPE_USB,
@@ -491,8 +484,10 @@ static const struct power_supply_desc axp813_usb_power_desc = {
 	.property_is_writeable = axp20x_usb_power_prop_writeable,
 	.get_property = axp20x_usb_power_get_property,
 	.set_property = axp20x_usb_power_set_property,
-	.usb_types = axp813_usb_types,
-	.num_usb_types = ARRAY_SIZE(axp813_usb_types),
+	.usb_types = BIT(POWER_SUPPLY_USB_TYPE_SDP) |
+		     BIT(POWER_SUPPLY_USB_TYPE_CDP) |
+		     BIT(POWER_SUPPLY_USB_TYPE_DCP) |
+		     BIT(POWER_SUPPLY_USB_TYPE_UNKNOWN),
 };
 
 static const char * const axp20x_irq_names[] = {
diff --git a/drivers/power/supply/bq256xx_charger.c b/drivers/power/supply/bq256xx_charger.c
index 1a935bc88510..5514d1896bb8 100644
--- a/drivers/power/supply/bq256xx_charger.c
+++ b/drivers/power/supply/bq256xx_charger.c
@@ -334,14 +334,6 @@ static const int bq25618_619_ichg_values[] = {
 	1290000, 1360000, 1430000, 1500000
 };
 
-static enum power_supply_usb_type bq256xx_usb_type[] = {
-	POWER_SUPPLY_USB_TYPE_SDP,
-	POWER_SUPPLY_USB_TYPE_CDP,
-	POWER_SUPPLY_USB_TYPE_DCP,
-	POWER_SUPPLY_USB_TYPE_UNKNOWN,
-	POWER_SUPPLY_USB_TYPE_ACA,
-};
-
 static int bq256xx_array_parse(int array_size, int val, const int array[])
 {
 	int i = 0;
@@ -1252,8 +1244,11 @@ static int bq256xx_property_is_writeable(struct power_supply *psy,
 static const struct power_supply_desc bq256xx_power_supply_desc = {
 	.name = "bq256xx-charger",
 	.type = POWER_SUPPLY_TYPE_USB,
-	.usb_types = bq256xx_usb_type,
-	.num_usb_types = ARRAY_SIZE(bq256xx_usb_type),
+	.usb_types = BIT(POWER_SUPPLY_USB_TYPE_SDP) |
+		     BIT(POWER_SUPPLY_USB_TYPE_CDP) |
+		     BIT(POWER_SUPPLY_USB_TYPE_DCP) |
+		     BIT(POWER_SUPPLY_USB_TYPE_ACA) |
+		     BIT(POWER_SUPPLY_USB_TYPE_UNKNOWN),
 	.properties = bq256xx_power_supply_props,
 	.num_properties = ARRAY_SIZE(bq256xx_power_supply_props),
 	.get_property = bq256xx_get_charger_property,
diff --git a/drivers/power/supply/cros_usbpd-charger.c b/drivers/power/supply/cros_usbpd-charger.c
index 8008e31c0c09..bed3e2e9bfea 100644
--- a/drivers/power/supply/cros_usbpd-charger.c
+++ b/drivers/power/supply/cros_usbpd-charger.c
@@ -73,17 +73,6 @@ static enum power_supply_property cros_usbpd_dedicated_charger_props[] = {
 	POWER_SUPPLY_PROP_VOLTAGE_NOW,
 };
 
-static enum power_supply_usb_type cros_usbpd_charger_usb_types[] = {
-	POWER_SUPPLY_USB_TYPE_UNKNOWN,
-	POWER_SUPPLY_USB_TYPE_SDP,
-	POWER_SUPPLY_USB_TYPE_DCP,
-	POWER_SUPPLY_USB_TYPE_CDP,
-	POWER_SUPPLY_USB_TYPE_C,
-	POWER_SUPPLY_USB_TYPE_PD,
-	POWER_SUPPLY_USB_TYPE_PD_DRP,
-	POWER_SUPPLY_USB_TYPE_APPLE_BRICK_ID
-};
-
 /* Input voltage/current limit in mV/mA. Default to none. */
 static u16 input_voltage_limit = EC_POWER_LIMIT_NONE;
 static u16 input_current_limit = EC_POWER_LIMIT_NONE;
@@ -643,9 +632,14 @@ static int cros_usbpd_charger_probe(struct platform_device *pd)
 			psy_desc->properties = cros_usbpd_charger_props;
 			psy_desc->num_properties =
 				ARRAY_SIZE(cros_usbpd_charger_props);
-			psy_desc->usb_types = cros_usbpd_charger_usb_types;
-			psy_desc->num_usb_types =
-				ARRAY_SIZE(cros_usbpd_charger_usb_types);
+			psy_desc->usb_types = BIT(POWER_SUPPLY_USB_TYPE_UNKNOWN) |
+					      BIT(POWER_SUPPLY_USB_TYPE_SDP)     |
+					      BIT(POWER_SUPPLY_USB_TYPE_DCP)     |
+					      BIT(POWER_SUPPLY_USB_TYPE_CDP)     |
+					      BIT(POWER_SUPPLY_USB_TYPE_C)       |
+					      BIT(POWER_SUPPLY_USB_TYPE_PD)      |
+					      BIT(POWER_SUPPLY_USB_TYPE_PD_DRP)  |
+					      BIT(POWER_SUPPLY_USB_TYPE_APPLE_BRICK_ID);
 		}
 
 		psy_desc->name = port->name;
diff --git a/drivers/power/supply/lenovo_yoga_c630_battery.c b/drivers/power/supply/lenovo_yoga_c630_battery.c
index d4d422cc5353..f98f65e00831 100644
--- a/drivers/power/supply/lenovo_yoga_c630_battery.c
+++ b/drivers/power/supply/lenovo_yoga_c630_battery.c
@@ -353,15 +353,10 @@ static enum power_supply_property yoga_c630_psy_adpt_properties[] = {
 	POWER_SUPPLY_PROP_USB_TYPE,
 };
 
-static const enum power_supply_usb_type yoga_c630_psy_adpt_usb_type[] = {
-	POWER_SUPPLY_USB_TYPE_C,
-};
-
 static const struct power_supply_desc yoga_c630_psy_adpt_psy_desc = {
 	.name = "yoga-c630-adapter",
 	.type = POWER_SUPPLY_TYPE_USB,
-	.usb_types = yoga_c630_psy_adpt_usb_type,
-	.num_usb_types = ARRAY_SIZE(yoga_c630_psy_adpt_usb_type),
+	.usb_types = BIT(POWER_SUPPLY_USB_TYPE_C),
 	.properties = yoga_c630_psy_adpt_properties,
 	.num_properties = ARRAY_SIZE(yoga_c630_psy_adpt_properties),
 	.get_property = yoga_c630_psy_adpt_get_property,
diff --git a/drivers/power/supply/mp2629_charger.c b/drivers/power/supply/mp2629_charger.c
index 3a2a28fbba73..d281c1059629 100644
--- a/drivers/power/supply/mp2629_charger.c
+++ b/drivers/power/supply/mp2629_charger.c
@@ -94,14 +94,6 @@ struct mp2629_prop {
 	int shift;
 };
 
-static enum power_supply_usb_type mp2629_usb_types[] = {
-	POWER_SUPPLY_USB_TYPE_SDP,
-	POWER_SUPPLY_USB_TYPE_DCP,
-	POWER_SUPPLY_USB_TYPE_CDP,
-	POWER_SUPPLY_USB_TYPE_PD_DRP,
-	POWER_SUPPLY_USB_TYPE_UNKNOWN
-};
-
 static enum power_supply_property mp2629_charger_usb_props[] = {
 	POWER_SUPPLY_PROP_ONLINE,
 	POWER_SUPPLY_PROP_USB_TYPE,
@@ -487,8 +479,11 @@ static irqreturn_t mp2629_irq_handler(int irq, void *dev_id)
 static const struct power_supply_desc mp2629_usb_desc = {
 	.name		= "mp2629_usb",
 	.type		= POWER_SUPPLY_TYPE_USB,
-	.usb_types      = mp2629_usb_types,
-	.num_usb_types  = ARRAY_SIZE(mp2629_usb_types),
+	.usb_types	= BIT(POWER_SUPPLY_USB_TYPE_SDP) |
+			  BIT(POWER_SUPPLY_USB_TYPE_CDP) |
+			  BIT(POWER_SUPPLY_USB_TYPE_DCP) |
+			  BIT(POWER_SUPPLY_USB_TYPE_PD_DRP) |
+			  BIT(POWER_SUPPLY_USB_TYPE_UNKNOWN),
 	.properties	= mp2629_charger_usb_props,
 	.num_properties	= ARRAY_SIZE(mp2629_charger_usb_props),
 	.get_property	= mp2629_charger_usb_get_prop,
diff --git a/drivers/power/supply/mt6360_charger.c b/drivers/power/supply/mt6360_charger.c
index aca123783efc..e99e55148976 100644
--- a/drivers/power/supply/mt6360_charger.c
+++ b/drivers/power/supply/mt6360_charger.c
@@ -154,13 +154,6 @@ enum mt6360_pmu_chg_type {
 	MT6360_CHG_TYPE_MAX,
 };
 
-static enum power_supply_usb_type mt6360_charger_usb_types[] = {
-	POWER_SUPPLY_USB_TYPE_UNKNOWN,
-	POWER_SUPPLY_USB_TYPE_SDP,
-	POWER_SUPPLY_USB_TYPE_DCP,
-	POWER_SUPPLY_USB_TYPE_CDP,
-};
-
 static int mt6360_get_chrdet_ext_stat(struct mt6360_chg_info *mci,
 					     bool *pwr_rdy)
 {
@@ -574,8 +567,10 @@ static const struct power_supply_desc mt6360_charger_desc = {
 	.get_property		= mt6360_charger_get_property,
 	.set_property		= mt6360_charger_set_property,
 	.property_is_writeable	= mt6360_charger_property_is_writeable,
-	.usb_types		= mt6360_charger_usb_types,
-	.num_usb_types		= ARRAY_SIZE(mt6360_charger_usb_types),
+	.usb_types		= BIT(POWER_SUPPLY_USB_TYPE_SDP) |
+				  BIT(POWER_SUPPLY_USB_TYPE_CDP) |
+				  BIT(POWER_SUPPLY_USB_TYPE_DCP) |
+				  BIT(POWER_SUPPLY_USB_TYPE_UNKNOWN),
 };
 
 static const struct regulator_ops mt6360_chg_otg_ops = {
diff --git a/drivers/power/supply/mt6370-charger.c b/drivers/power/supply/mt6370-charger.c
index e24fce087d80..ad8793bf997e 100644
--- a/drivers/power/supply/mt6370-charger.c
+++ b/drivers/power/supply/mt6370-charger.c
@@ -624,13 +624,6 @@ static enum power_supply_property mt6370_chg_properties[] = {
 	POWER_SUPPLY_PROP_USB_TYPE,
 };
 
-static enum power_supply_usb_type mt6370_chg_usb_types[] = {
-	POWER_SUPPLY_USB_TYPE_UNKNOWN,
-	POWER_SUPPLY_USB_TYPE_SDP,
-	POWER_SUPPLY_USB_TYPE_CDP,
-	POWER_SUPPLY_USB_TYPE_DCP,
-};
-
 static const struct power_supply_desc mt6370_chg_psy_desc = {
 	.name = "mt6370-charger",
 	.type = POWER_SUPPLY_TYPE_USB,
@@ -639,8 +632,10 @@ static const struct power_supply_desc mt6370_chg_psy_desc = {
 	.get_property = mt6370_chg_get_property,
 	.set_property = mt6370_chg_set_property,
 	.property_is_writeable = mt6370_chg_property_is_writeable,
-	.usb_types = mt6370_chg_usb_types,
-	.num_usb_types = ARRAY_SIZE(mt6370_chg_usb_types),
+	.usb_types = BIT(POWER_SUPPLY_USB_TYPE_SDP) |
+		     BIT(POWER_SUPPLY_USB_TYPE_CDP) |
+		     BIT(POWER_SUPPLY_USB_TYPE_DCP) |
+		     BIT(POWER_SUPPLY_USB_TYPE_UNKNOWN),
 };
 
 static const struct regulator_ops mt6370_chg_otg_ops = {
diff --git a/drivers/power/supply/power_supply_core.c b/drivers/power/supply/power_supply_core.c
index 3614d263ddad..0417fb34e846 100644
--- a/drivers/power/supply/power_supply_core.c
+++ b/drivers/power/supply/power_supply_core.c
@@ -1360,10 +1360,6 @@ __power_supply_register(struct device *parent,
 		pr_warn("%s: Expected proper parent device for '%s'\n",
 			__func__, desc->name);
 
-	if (psy_has_property(desc, POWER_SUPPLY_PROP_USB_TYPE) &&
-	    (!desc->usb_types || !desc->num_usb_types))
-		return ERR_PTR(-EINVAL);
-
 	psy = kzalloc(sizeof(*psy), GFP_KERNEL);
 	if (!psy)
 		return ERR_PTR(-ENOMEM);
diff --git a/drivers/power/supply/power_supply_sysfs.c b/drivers/power/supply/power_supply_sysfs.c
index c98a6de59d3b..16b3c5880cd8 100644
--- a/drivers/power/supply/power_supply_sysfs.c
+++ b/drivers/power/supply/power_supply_sysfs.c
@@ -268,40 +268,6 @@ static ssize_t power_supply_show_enum_with_available(
 	return count;
 }
 
-static ssize_t power_supply_show_usb_type(struct device *dev,
-					  const struct power_supply_desc *desc,
-					  union power_supply_propval *value,
-					  char *buf)
-{
-	enum power_supply_usb_type usb_type;
-	ssize_t count = 0;
-	bool match = false;
-	int i;
-
-	for (i = 0; i < desc->num_usb_types; ++i) {
-		usb_type = desc->usb_types[i];
-
-		if (value->intval == usb_type) {
-			count += sysfs_emit_at(buf, count, "[%s] ",
-					 POWER_SUPPLY_USB_TYPE_TEXT[usb_type]);
-			match = true;
-		} else {
-			count += sysfs_emit_at(buf, count, "%s ",
-					 POWER_SUPPLY_USB_TYPE_TEXT[usb_type]);
-		}
-	}
-
-	if (!match) {
-		dev_warn(dev, "driver reporting unsupported connected type\n");
-		return -EINVAL;
-	}
-
-	if (count)
-		buf[count - 1] = '\n';
-
-	return count;
-}
-
 static ssize_t power_supply_show_property(struct device *dev,
 					  struct device_attribute *attr,
 					  char *buf) {
@@ -331,8 +297,10 @@ static ssize_t power_supply_show_property(struct device *dev,
 
 	switch (psp) {
 	case POWER_SUPPLY_PROP_USB_TYPE:
-		ret = power_supply_show_usb_type(dev, psy->desc,
-						&value, buf);
+		ret = power_supply_show_enum_with_available(
+				dev, POWER_SUPPLY_USB_TYPE_TEXT,
+				ARRAY_SIZE(POWER_SUPPLY_USB_TYPE_TEXT),
+				psy->desc->usb_types, value.intval, buf);
 		break;
 	case POWER_SUPPLY_PROP_CHARGE_BEHAVIOUR:
 		ret = power_supply_charge_behaviour_show(dev, psy->desc->charge_behaviours,
diff --git a/drivers/power/supply/qcom_battmgr.c b/drivers/power/supply/qcom_battmgr.c
index 46f36dcb185c..56c8021383da 100644
--- a/drivers/power/supply/qcom_battmgr.c
+++ b/drivers/power/supply/qcom_battmgr.c
@@ -786,19 +786,6 @@ static int qcom_battmgr_usb_get_property(struct power_supply *psy,
 	return 0;
 }
 
-static const enum power_supply_usb_type usb_psy_supported_types[] = {
-	POWER_SUPPLY_USB_TYPE_UNKNOWN,
-	POWER_SUPPLY_USB_TYPE_SDP,
-	POWER_SUPPLY_USB_TYPE_DCP,
-	POWER_SUPPLY_USB_TYPE_CDP,
-	POWER_SUPPLY_USB_TYPE_ACA,
-	POWER_SUPPLY_USB_TYPE_C,
-	POWER_SUPPLY_USB_TYPE_PD,
-	POWER_SUPPLY_USB_TYPE_PD_DRP,
-	POWER_SUPPLY_USB_TYPE_PD_PPS,
-	POWER_SUPPLY_USB_TYPE_APPLE_BRICK_ID,
-};
-
 static const enum power_supply_property sc8280xp_usb_props[] = {
 	POWER_SUPPLY_PROP_ONLINE,
 };
@@ -809,8 +796,16 @@ static const struct power_supply_desc sc8280xp_usb_psy_desc = {
 	.properties = sc8280xp_usb_props,
 	.num_properties = ARRAY_SIZE(sc8280xp_usb_props),
 	.get_property = qcom_battmgr_usb_get_property,
-	.usb_types = usb_psy_supported_types,
-	.num_usb_types = ARRAY_SIZE(usb_psy_supported_types),
+	.usb_types = BIT(POWER_SUPPLY_USB_TYPE_UNKNOWN) |
+		     BIT(POWER_SUPPLY_USB_TYPE_SDP)     |
+		     BIT(POWER_SUPPLY_USB_TYPE_DCP)     |
+		     BIT(POWER_SUPPLY_USB_TYPE_CDP)     |
+		     BIT(POWER_SUPPLY_USB_TYPE_ACA)     |
+		     BIT(POWER_SUPPLY_USB_TYPE_C)       |
+		     BIT(POWER_SUPPLY_USB_TYPE_PD)      |
+		     BIT(POWER_SUPPLY_USB_TYPE_PD_DRP)  |
+		     BIT(POWER_SUPPLY_USB_TYPE_PD_PPS)  |
+		     BIT(POWER_SUPPLY_USB_TYPE_APPLE_BRICK_ID),
 };
 
 static const enum power_supply_property sm8350_usb_props[] = {
@@ -829,8 +824,16 @@ static const struct power_supply_desc sm8350_usb_psy_desc = {
 	.properties = sm8350_usb_props,
 	.num_properties = ARRAY_SIZE(sm8350_usb_props),
 	.get_property = qcom_battmgr_usb_get_property,
-	.usb_types = usb_psy_supported_types,
-	.num_usb_types = ARRAY_SIZE(usb_psy_supported_types),
+	.usb_types = BIT(POWER_SUPPLY_USB_TYPE_UNKNOWN) |
+		     BIT(POWER_SUPPLY_USB_TYPE_SDP)     |
+		     BIT(POWER_SUPPLY_USB_TYPE_DCP)     |
+		     BIT(POWER_SUPPLY_USB_TYPE_CDP)     |
+		     BIT(POWER_SUPPLY_USB_TYPE_ACA)     |
+		     BIT(POWER_SUPPLY_USB_TYPE_C)       |
+		     BIT(POWER_SUPPLY_USB_TYPE_PD)      |
+		     BIT(POWER_SUPPLY_USB_TYPE_PD_DRP)  |
+		     BIT(POWER_SUPPLY_USB_TYPE_PD_PPS)  |
+		     BIT(POWER_SUPPLY_USB_TYPE_APPLE_BRICK_ID),
 };
 
 static const u8 sm8350_wls_prop_map[] = {
diff --git a/drivers/power/supply/qcom_pmi8998_charger.c b/drivers/power/supply/qcom_pmi8998_charger.c
index 9bb777406013..81acbd8b2169 100644
--- a/drivers/power/supply/qcom_pmi8998_charger.c
+++ b/drivers/power/supply/qcom_pmi8998_charger.c
@@ -411,13 +411,6 @@ static enum power_supply_property smb2_properties[] = {
 	POWER_SUPPLY_PROP_USB_TYPE,
 };
 
-static enum power_supply_usb_type smb2_usb_types[] = {
-	POWER_SUPPLY_USB_TYPE_UNKNOWN,
-	POWER_SUPPLY_USB_TYPE_SDP,
-	POWER_SUPPLY_USB_TYPE_DCP,
-	POWER_SUPPLY_USB_TYPE_CDP,
-};
-
 static int smb2_get_prop_usb_online(struct smb2_chip *chip, int *val)
 {
 	unsigned int stat;
@@ -775,8 +768,10 @@ static irqreturn_t smb2_handle_wdog_bark(int irq, void *data)
 static const struct power_supply_desc smb2_psy_desc = {
 	.name = "pmi8998_charger",
 	.type = POWER_SUPPLY_TYPE_USB,
-	.usb_types = smb2_usb_types,
-	.num_usb_types = ARRAY_SIZE(smb2_usb_types),
+	.usb_types = BIT(POWER_SUPPLY_USB_TYPE_SDP) |
+		     BIT(POWER_SUPPLY_USB_TYPE_CDP) |
+		     BIT(POWER_SUPPLY_USB_TYPE_DCP) |
+		     BIT(POWER_SUPPLY_USB_TYPE_UNKNOWN),
 	.properties = smb2_properties,
 	.num_properties = ARRAY_SIZE(smb2_properties),
 	.get_property = smb2_get_property,
diff --git a/drivers/power/supply/rk817_charger.c b/drivers/power/supply/rk817_charger.c
index 7ca91739c6cc..a3d377a32b49 100644
--- a/drivers/power/supply/rk817_charger.c
+++ b/drivers/power/supply/rk817_charger.c
@@ -673,11 +673,6 @@ static enum power_supply_property rk817_chg_props[] = {
 	POWER_SUPPLY_PROP_VOLTAGE_AVG,
 };
 
-static enum power_supply_usb_type rk817_usb_type[] = {
-	POWER_SUPPLY_USB_TYPE_DCP,
-	POWER_SUPPLY_USB_TYPE_UNKNOWN,
-};
-
 static const struct power_supply_desc rk817_bat_desc = {
 	.name = "rk817-battery",
 	.type = POWER_SUPPLY_TYPE_BATTERY,
@@ -689,8 +684,8 @@ static const struct power_supply_desc rk817_bat_desc = {
 static const struct power_supply_desc rk817_chg_desc = {
 	.name = "rk817-charger",
 	.type = POWER_SUPPLY_TYPE_USB,
-	.usb_types = rk817_usb_type,
-	.num_usb_types = ARRAY_SIZE(rk817_usb_type),
+	.usb_types = BIT(POWER_SUPPLY_USB_TYPE_DCP) |
+		     BIT(POWER_SUPPLY_USB_TYPE_UNKNOWN),
 	.properties = rk817_chg_props,
 	.num_properties = ARRAY_SIZE(rk817_chg_props),
 	.get_property = rk817_chg_get_prop,
diff --git a/drivers/power/supply/rn5t618_power.c b/drivers/power/supply/rn5t618_power.c
index ebea3522a2ac..40dec55a9f73 100644
--- a/drivers/power/supply/rn5t618_power.c
+++ b/drivers/power/supply/rn5t618_power.c
@@ -70,13 +70,6 @@ struct rn5t618_power_info {
 	int irq;
 };
 
-static enum power_supply_usb_type rn5t618_usb_types[] = {
-	POWER_SUPPLY_USB_TYPE_SDP,
-	POWER_SUPPLY_USB_TYPE_DCP,
-	POWER_SUPPLY_USB_TYPE_CDP,
-	POWER_SUPPLY_USB_TYPE_UNKNOWN
-};
-
 static enum power_supply_property rn5t618_usb_props[] = {
 	/* input current limit is not very accurate */
 	POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT,
@@ -681,8 +674,10 @@ static const struct power_supply_desc rn5t618_adp_desc = {
 static const struct power_supply_desc rn5t618_usb_desc = {
 	.name                   = "rn5t618-usb",
 	.type                   = POWER_SUPPLY_TYPE_USB,
-	.usb_types		= rn5t618_usb_types,
-	.num_usb_types		= ARRAY_SIZE(rn5t618_usb_types),
+	.usb_types		= BIT(POWER_SUPPLY_USB_TYPE_SDP) |
+				  BIT(POWER_SUPPLY_USB_TYPE_CDP) |
+				  BIT(POWER_SUPPLY_USB_TYPE_DCP) |
+				  BIT(POWER_SUPPLY_USB_TYPE_UNKNOWN),
 	.properties             = rn5t618_usb_props,
 	.num_properties         = ARRAY_SIZE(rn5t618_usb_props),
 	.get_property           = rn5t618_usb_get_property,
diff --git a/drivers/power/supply/rt9467-charger.c b/drivers/power/supply/rt9467-charger.c
index f935bd761ac1..235169c85c5d 100644
--- a/drivers/power/supply/rt9467-charger.c
+++ b/drivers/power/supply/rt9467-charger.c
@@ -630,13 +630,6 @@ static int rt9467_psy_set_ieoc(struct rt9467_chg_data *data, int microamp)
 	return ret;
 }
 
-static const enum power_supply_usb_type rt9467_chg_usb_types[] = {
-	POWER_SUPPLY_USB_TYPE_UNKNOWN,
-	POWER_SUPPLY_USB_TYPE_SDP,
-	POWER_SUPPLY_USB_TYPE_DCP,
-	POWER_SUPPLY_USB_TYPE_CDP,
-};
-
 static const enum power_supply_property rt9467_chg_properties[] = {
 	POWER_SUPPLY_PROP_STATUS,
 	POWER_SUPPLY_PROP_ONLINE,
@@ -771,8 +764,10 @@ static int rt9467_chg_prop_is_writeable(struct power_supply *psy,
 static const struct power_supply_desc rt9467_chg_psy_desc = {
 	.name = "rt9467-charger",
 	.type = POWER_SUPPLY_TYPE_USB,
-	.usb_types = rt9467_chg_usb_types,
-	.num_usb_types = ARRAY_SIZE(rt9467_chg_usb_types),
+	.usb_types = BIT(POWER_SUPPLY_USB_TYPE_SDP) |
+		     BIT(POWER_SUPPLY_USB_TYPE_CDP) |
+		     BIT(POWER_SUPPLY_USB_TYPE_DCP) |
+		     BIT(POWER_SUPPLY_USB_TYPE_UNKNOWN),
 	.properties = rt9467_chg_properties,
 	.num_properties = ARRAY_SIZE(rt9467_chg_properties),
 	.property_is_writeable = rt9467_chg_prop_is_writeable,
diff --git a/drivers/power/supply/rt9471.c b/drivers/power/supply/rt9471.c
index 868b0703d15c..c04af1ee89c6 100644
--- a/drivers/power/supply/rt9471.c
+++ b/drivers/power/supply/rt9471.c
@@ -333,14 +333,6 @@ static enum power_supply_property rt9471_charger_properties[] = {
 	POWER_SUPPLY_PROP_MANUFACTURER,
 };
 
-static enum power_supply_usb_type rt9471_charger_usb_types[] = {
-	POWER_SUPPLY_USB_TYPE_UNKNOWN,
-	POWER_SUPPLY_USB_TYPE_SDP,
-	POWER_SUPPLY_USB_TYPE_DCP,
-	POWER_SUPPLY_USB_TYPE_CDP,
-	POWER_SUPPLY_USB_TYPE_APPLE_BRICK_ID,
-};
-
 static int rt9471_charger_property_is_writeable(struct power_supply *psy,
 						enum power_supply_property psp)
 {
@@ -726,8 +718,11 @@ static int rt9471_register_psy(struct rt9471_chip *chip)
 
 	desc->name = psy_name;
 	desc->type = POWER_SUPPLY_TYPE_USB;
-	desc->usb_types = rt9471_charger_usb_types;
-	desc->num_usb_types = ARRAY_SIZE(rt9471_charger_usb_types);
+	desc->usb_types = BIT(POWER_SUPPLY_USB_TYPE_SDP) |
+			  BIT(POWER_SUPPLY_USB_TYPE_CDP) |
+			  BIT(POWER_SUPPLY_USB_TYPE_DCP) |
+			  BIT(POWER_SUPPLY_USB_TYPE_APPLE_BRICK_ID) |
+			  BIT(POWER_SUPPLY_USB_TYPE_UNKNOWN);
 	desc->properties = rt9471_charger_properties;
 	desc->num_properties = ARRAY_SIZE(rt9471_charger_properties);
 	desc->get_property = rt9471_charger_get_property;
diff --git a/drivers/power/supply/ucs1002_power.c b/drivers/power/supply/ucs1002_power.c
index b67d5b03d93e..7382bec6a43c 100644
--- a/drivers/power/supply/ucs1002_power.c
+++ b/drivers/power/supply/ucs1002_power.c
@@ -296,14 +296,6 @@ static int ucs1002_set_max_current(struct ucs1002_info *info, u32 val)
 	return 0;
 }
 
-static enum power_supply_usb_type ucs1002_usb_types[] = {
-	POWER_SUPPLY_USB_TYPE_PD,
-	POWER_SUPPLY_USB_TYPE_SDP,
-	POWER_SUPPLY_USB_TYPE_DCP,
-	POWER_SUPPLY_USB_TYPE_CDP,
-	POWER_SUPPLY_USB_TYPE_UNKNOWN,
-};
-
 static int ucs1002_set_usb_type(struct ucs1002_info *info, int val)
 {
 	unsigned int mode;
@@ -431,8 +423,11 @@ static int ucs1002_property_is_writeable(struct power_supply *psy,
 static const struct power_supply_desc ucs1002_charger_desc = {
 	.name			= "ucs1002",
 	.type			= POWER_SUPPLY_TYPE_USB,
-	.usb_types		= ucs1002_usb_types,
-	.num_usb_types		= ARRAY_SIZE(ucs1002_usb_types),
+	.usb_types		= BIT(POWER_SUPPLY_USB_TYPE_SDP) |
+				  BIT(POWER_SUPPLY_USB_TYPE_CDP) |
+				  BIT(POWER_SUPPLY_USB_TYPE_DCP) |
+				  BIT(POWER_SUPPLY_USB_TYPE_PD)  |
+				  BIT(POWER_SUPPLY_USB_TYPE_UNKNOWN),
 	.get_property		= ucs1002_get_property,
 	.set_property		= ucs1002_set_property,
 	.property_is_writeable	= ucs1002_property_is_writeable,
diff --git a/drivers/usb/typec/anx7411.c b/drivers/usb/typec/anx7411.c
index 5a5bf3532ad7..31e3e9544bc0 100644
--- a/drivers/usb/typec/anx7411.c
+++ b/drivers/usb/typec/anx7411.c
@@ -1339,12 +1339,6 @@ static void anx7411_get_gpio_irq(struct anx7411_data *ctx)
 		dev_err(dev, "failed to get GPIO IRQ\n");
 }
 
-static enum power_supply_usb_type anx7411_psy_usb_types[] = {
-	POWER_SUPPLY_USB_TYPE_C,
-	POWER_SUPPLY_USB_TYPE_PD,
-	POWER_SUPPLY_USB_TYPE_PD_PPS,
-};
-
 static enum power_supply_property anx7411_psy_props[] = {
 	POWER_SUPPLY_PROP_USB_TYPE,
 	POWER_SUPPLY_PROP_ONLINE,
@@ -1422,8 +1416,9 @@ static int anx7411_psy_register(struct anx7411_data *ctx)
 
 	psy_desc->name = psy_name;
 	psy_desc->type = POWER_SUPPLY_TYPE_USB;
-	psy_desc->usb_types = anx7411_psy_usb_types;
-	psy_desc->num_usb_types = ARRAY_SIZE(anx7411_psy_usb_types);
+	psy_desc->usb_types = BIT(POWER_SUPPLY_USB_TYPE_C)  |
+			      BIT(POWER_SUPPLY_USB_TYPE_PD) |
+			      BIT(POWER_SUPPLY_USB_TYPE_PD_PPS);
 	psy_desc->properties = anx7411_psy_props;
 	psy_desc->num_properties = ARRAY_SIZE(anx7411_psy_props);
 
diff --git a/drivers/usb/typec/rt1719.c b/drivers/usb/typec/rt1719.c
index be02d420920e..0b0c23a0b014 100644
--- a/drivers/usb/typec/rt1719.c
+++ b/drivers/usb/typec/rt1719.c
@@ -109,12 +109,6 @@ struct rt1719_data {
 	u16 conn_stat;
 };
 
-static const enum power_supply_usb_type rt1719_psy_usb_types[] = {
-	POWER_SUPPLY_USB_TYPE_C,
-	POWER_SUPPLY_USB_TYPE_PD,
-	POWER_SUPPLY_USB_TYPE_PD_PPS
-};
-
 static const enum power_supply_property rt1719_psy_properties[] = {
 	POWER_SUPPLY_PROP_ONLINE,
 	POWER_SUPPLY_PROP_USB_TYPE,
@@ -572,8 +566,9 @@ static int devm_rt1719_psy_register(struct rt1719_data *data)
 
 	data->psy_desc.name = psy_name;
 	data->psy_desc.type = POWER_SUPPLY_TYPE_USB;
-	data->psy_desc.usb_types = rt1719_psy_usb_types;
-	data->psy_desc.num_usb_types = ARRAY_SIZE(rt1719_psy_usb_types);
+	data->psy_desc.usb_types = BIT(POWER_SUPPLY_USB_TYPE_C)  |
+				   BIT(POWER_SUPPLY_USB_TYPE_PD) |
+				   BIT(POWER_SUPPLY_USB_TYPE_PD_PPS);
 	data->psy_desc.properties = rt1719_psy_properties;
 	data->psy_desc.num_properties = ARRAY_SIZE(rt1719_psy_properties);
 	data->psy_desc.get_property = rt1719_psy_get_property;
diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
index 26f9006e95e1..0bd9c9569fb7 100644
--- a/drivers/usb/typec/tcpm/tcpm.c
+++ b/drivers/usb/typec/tcpm/tcpm.c
@@ -7484,12 +7484,6 @@ static int tcpm_psy_prop_writeable(struct power_supply *psy,
 	}
 }
 
-static enum power_supply_usb_type tcpm_psy_usb_types[] = {
-	POWER_SUPPLY_USB_TYPE_C,
-	POWER_SUPPLY_USB_TYPE_PD,
-	POWER_SUPPLY_USB_TYPE_PD_PPS,
-};
-
 static const char *tcpm_psy_name_prefix = "tcpm-source-psy-";
 
 static int devm_tcpm_psy_register(struct tcpm_port *port)
@@ -7510,8 +7504,9 @@ static int devm_tcpm_psy_register(struct tcpm_port *port)
 		 port_dev_name);
 	port->psy_desc.name = psy_name;
 	port->psy_desc.type = POWER_SUPPLY_TYPE_USB;
-	port->psy_desc.usb_types = tcpm_psy_usb_types;
-	port->psy_desc.num_usb_types = ARRAY_SIZE(tcpm_psy_usb_types);
+	port->psy_desc.usb_types = BIT(POWER_SUPPLY_USB_TYPE_C)  |
+				   BIT(POWER_SUPPLY_USB_TYPE_PD) |
+				   BIT(POWER_SUPPLY_USB_TYPE_PD_PPS);
 	port->psy_desc.properties = tcpm_psy_props;
 	port->psy_desc.num_properties = ARRAY_SIZE(tcpm_psy_props);
 	port->psy_desc.get_property = tcpm_psy_get_prop;
diff --git a/drivers/usb/typec/tipd/core.c b/drivers/usb/typec/tipd/core.c
index ea768b19a7f1..7512f0c3f6cb 100644
--- a/drivers/usb/typec/tipd/core.c
+++ b/drivers/usb/typec/tipd/core.c
@@ -150,11 +150,6 @@ static enum power_supply_property tps6598x_psy_props[] = {
 	POWER_SUPPLY_PROP_ONLINE,
 };
 
-static enum power_supply_usb_type tps6598x_psy_usb_types[] = {
-	POWER_SUPPLY_USB_TYPE_C,
-	POWER_SUPPLY_USB_TYPE_PD,
-};
-
 static const char *tps6598x_psy_name_prefix = "tps6598x-source-psy-";
 
 /*
@@ -827,8 +822,8 @@ static int devm_tps6598_psy_register(struct tps6598x *tps)
 
 	tps->psy_desc.name = psy_name;
 	tps->psy_desc.type = POWER_SUPPLY_TYPE_USB;
-	tps->psy_desc.usb_types = tps6598x_psy_usb_types;
-	tps->psy_desc.num_usb_types = ARRAY_SIZE(tps6598x_psy_usb_types);
+	tps->psy_desc.usb_types = BIT(POWER_SUPPLY_USB_TYPE_C) |
+				  BIT(POWER_SUPPLY_USB_TYPE_PD);
 	tps->psy_desc.properties = tps6598x_psy_props;
 	tps->psy_desc.num_properties = ARRAY_SIZE(tps6598x_psy_props);
 	tps->psy_desc.get_property = tps6598x_psy_get_prop;
diff --git a/drivers/usb/typec/ucsi/psy.c b/drivers/usb/typec/ucsi/psy.c
index e623d80e177c..1c631c7855a9 100644
--- a/drivers/usb/typec/ucsi/psy.c
+++ b/drivers/usb/typec/ucsi/psy.c
@@ -254,12 +254,6 @@ static int ucsi_psy_get_prop(struct power_supply *psy,
 	}
 }
 
-static enum power_supply_usb_type ucsi_psy_usb_types[] = {
-	POWER_SUPPLY_USB_TYPE_C,
-	POWER_SUPPLY_USB_TYPE_PD,
-	POWER_SUPPLY_USB_TYPE_PD_PPS,
-};
-
 int ucsi_register_port_psy(struct ucsi_connector *con)
 {
 	struct power_supply_config psy_cfg = {};
@@ -276,8 +270,9 @@ int ucsi_register_port_psy(struct ucsi_connector *con)
 
 	con->psy_desc.name = psy_name;
 	con->psy_desc.type = POWER_SUPPLY_TYPE_USB;
-	con->psy_desc.usb_types = ucsi_psy_usb_types;
-	con->psy_desc.num_usb_types = ARRAY_SIZE(ucsi_psy_usb_types);
+	con->psy_desc.usb_types = BIT(POWER_SUPPLY_USB_TYPE_C)  |
+				  BIT(POWER_SUPPLY_USB_TYPE_PD) |
+				  BIT(POWER_SUPPLY_USB_TYPE_PD_PPS);
 	con->psy_desc.properties = ucsi_psy_props;
 	con->psy_desc.num_properties = ARRAY_SIZE(ucsi_psy_props);
 	con->psy_desc.get_property = ucsi_psy_get_prop;
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index 72dc7e45c90c..910d407ebe63 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -243,8 +243,7 @@ struct power_supply_desc {
 	const char *name;
 	enum power_supply_type type;
 	u8 charge_behaviours;
-	const enum power_supply_usb_type *usb_types;
-	size_t num_usb_types;
+	u32 usb_types;
 	const enum power_supply_property *properties;
 	size_t num_properties;
 
-- 
2.46.0



