[PATCH v5 0/6] Rx mode support for Cadence DPHY

[PATCH v5 0/6] Rx mode support for Cadence DPHY

[Pratyush Yadav]

Hi,

This series adds support for Rx mode on Cadence DPHY driver. It has been
split off from [0] to facilitate easier merging. I have still kept the
version number to maintain continuity with the previous patches. This
series also includes conversion to YAML binding.

Tested on TI's J721E with OV5640 sensor.

[0] https://patchwork.linuxtv.org/project/linux-media/list/?series=5526&state=%2A&archive=both

Changes in v5:
- Based on Laurent's suggestion, add cdns_dphy_info which contains the
  phy_ops and cdns_dphy_tx_ops (renamed from cdns_dphy_ops). This lets us
  get rid of the phy ops wrappers.
- Move probe() and remove() into cdns_dphy_common_ops() since they can
  be used by both modes. Drop the check in power_on().
- Get the clocks in the tx ops probe to make sure they are mandatory for
  Tx mode but not for Rx mode.
- Use the new cdns_dphy_info to specify PHY ops.
- Re-order include in alphabetical order.
- Make bands const.
- Drop num_bands.
- Make i, lanes unsigned.
- Drop the maximum check in cdns_dphy_rx_get_band_ctrl(). Let the loop
  complete and return -EOPNOTSUPP when we reach the end.
- Drop the "rate < bands[i].min_rate" check since the bands are in
  ascending order.
- Move data_lane_ctrl to start of function and make it static const.
- Make clocks a required property based on the compatible.
- Use enum instead.

Changes in v4:
- Instead of having both Rx and Tx modes in the same driver data, keep
  them separate since the op selection is based on compatible now. For
  that reason, the cdns_dphy_driver_data struct is no longer needed.
- Rename ref_dphy_ops to tx_ref_dphy_ops to clarify their purpose.
- Drop submode checks in validate() hook.
- Drop the submode parts. Use a different compatible for the Rx ops.
- Make bands and num_bands static.
- Drop the submode patches. Use a different compatible for Rx mode DPHY
instead.

Changes in v3:
- Use a table to select the band.
- Use a table to poll the data lane ready bits.
- Multiply the DPHY HS clock rate by 2 to get the bit rate since the
  clock is DDR.
- Add Rob's R-by.

Changes in v2:
- Drop reg description.
- Add a description for each DPHY clock.
- Rename dphy@... to phy@... in example.
- Add Laurent's R-by.
- Re-order subject prefixes.
- Re-order subject prefixes.
- Add power-domain to the example.
- Add Laurent's R-by.
- Re-order subject prefixes.

Pratyush Yadav (6):
  phy: cdns-dphy: Prepare for Rx support
  phy: cdns-dphy: Add Rx support
  phy: dt-bindings: Convert Cadence DPHY binding to YAML
  phy: dt-bindings: cdns,dphy: make clocks optional for Rx mode
  phy: dt-bindings: cdns,dphy: add power-domains property
  phy: dt-bindings: cdns,dphy: add Rx DPHY compatible

 .../devicetree/bindings/phy/cdns,dphy.txt     |  20 -
 .../devicetree/bindings/phy/cdns,dphy.yaml    |  66 ++++
 drivers/phy/cadence/cdns-dphy.c               | 351 +++++++++++++++---
 3 files changed, 356 insertions(+), 81 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy.txt
 create mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy.yaml

-- 
2.33.0

[PATCH v5 0/6] Rx mode support for Cadence DPHY

[Pratyush Yadav]

Hi,

This series adds support for Rx mode on Cadence DPHY driver. It has been
split off from [0] to facilitate easier merging. I have still kept the
version number to maintain continuity with the previous patches. This
series also includes conversion to YAML binding.

Tested on TI's J721E with OV5640 sensor.

[0] https://patchwork.linuxtv.org/project/linux-media/list/?series=5526&state=%2A&archive=both

Changes in v5:
- Based on Laurent's suggestion, add cdns_dphy_info which contains the
  phy_ops and cdns_dphy_tx_ops (renamed from cdns_dphy_ops). This lets us
  get rid of the phy ops wrappers.
- Move probe() and remove() into cdns_dphy_common_ops() since they can
  be used by both modes. Drop the check in power_on().
- Get the clocks in the tx ops probe to make sure they are mandatory for
  Tx mode but not for Rx mode.
- Use the new cdns_dphy_info to specify PHY ops.
- Re-order include in alphabetical order.
- Make bands const.
- Drop num_bands.
- Make i, lanes unsigned.
- Drop the maximum check in cdns_dphy_rx_get_band_ctrl(). Let the loop
  complete and return -EOPNOTSUPP when we reach the end.
- Drop the "rate < bands[i].min_rate" check since the bands are in
  ascending order.
- Move data_lane_ctrl to start of function and make it static const.
- Make clocks a required property based on the compatible.
- Use enum instead.

Changes in v4:
- Instead of having both Rx and Tx modes in the same driver data, keep
  them separate since the op selection is based on compatible now. For
  that reason, the cdns_dphy_driver_data struct is no longer needed.
- Rename ref_dphy_ops to tx_ref_dphy_ops to clarify their purpose.
- Drop submode checks in validate() hook.
- Drop the submode parts. Use a different compatible for the Rx ops.
- Make bands and num_bands static.
- Drop the submode patches. Use a different compatible for Rx mode DPHY
instead.

Changes in v3:
- Use a table to select the band.
- Use a table to poll the data lane ready bits.
- Multiply the DPHY HS clock rate by 2 to get the bit rate since the
  clock is DDR.
- Add Rob's R-by.

Changes in v2:
- Drop reg description.
- Add a description for each DPHY clock.
- Rename dphy@... to phy@... in example.
- Add Laurent's R-by.
- Re-order subject prefixes.
- Re-order subject prefixes.
- Add power-domain to the example.
- Add Laurent's R-by.
- Re-order subject prefixes.

Pratyush Yadav (6):
  phy: cdns-dphy: Prepare for Rx support
  phy: cdns-dphy: Add Rx support
  phy: dt-bindings: Convert Cadence DPHY binding to YAML
  phy: dt-bindings: cdns,dphy: make clocks optional for Rx mode
  phy: dt-bindings: cdns,dphy: add power-domains property
  phy: dt-bindings: cdns,dphy: add Rx DPHY compatible

 .../devicetree/bindings/phy/cdns,dphy.txt     |  20 -
 .../devicetree/bindings/phy/cdns,dphy.yaml    |  66 ++++
 drivers/phy/cadence/cdns-dphy.c               | 351 +++++++++++++++---
 3 files changed, 356 insertions(+), 81 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy.txt
 create mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy.yaml

-- 
2.33.0


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

[PATCH v5 1/6] phy: cdns-dphy: Prepare for Rx support

[Pratyush Yadav]

The Rx programming sequence differs from the Tx programming sequence.
Currently only Tx mode is supported. For example, the power on and off,
validation, and configuration procedures are all different between Rx
and Tx DPHYs. Currently they are only written from a Tx point of view
and they won't work with an Rx DPHY.

Set the PHY ops from driver data, which makes it possible to use
different PHY callbacks for Rx and Tx modes. Rename cdns_dphy_ops to
cdns_dphy_tx_ops since they are only used by the Tx path. Also move
probe() and remove() to a new struct called cdns_dphy_common_ops. These
can be used by both Rx and Tx paths. cdns_dphy_rx_ops is not added since
it is not needed by the reference Rx mode implementation as of now. It
can be added later if needed.

The clocks "psm" and "pll_ref" are not used by the Rx path so check for
them in the Tx path's probe() callback.

Signed-off-by: Pratyush Yadav <p.yadav@ti.com>

---

Changes in v5:
- Based on Laurent's suggestion, add cdns_dphy_info which contains the
  phy_ops and cdns_dphy_tx_ops (renamed from cdns_dphy_ops). This lets us
  get rid of the phy ops wrappers.
- Move probe() and remove() into cdns_dphy_common_ops() since they can
  be used by both modes. Drop the check in power_on().
- Get the clocks in the tx ops probe to make sure they are mandatory for
  Tx mode but not for Rx mode.

Changes in v4:
- Instead of having both Rx and Tx modes in the same driver data, keep
  them separate since the op selection is based on compatible now. For
  that reason, the cdns_dphy_driver_data struct is no longer needed.
- Rename ref_dphy_ops to tx_ref_dphy_ops to clarify their purpose.
- Drop submode checks in validate() hook.

 drivers/phy/cadence/cdns-dphy.c | 169 ++++++++++++++++++++------------
 1 file changed, 108 insertions(+), 61 deletions(-)

diff --git a/drivers/phy/cadence/cdns-dphy.c b/drivers/phy/cadence/cdns-dphy.c
index ba042e39cfaf..e2c2b27c6539 100644
--- a/drivers/phy/cadence/cdns-dphy.c
+++ b/drivers/phy/cadence/cdns-dphy.c
@@ -72,9 +72,13 @@ enum cdns_dphy_clk_lane_cfg {
 };
 
 struct cdns_dphy;
-struct cdns_dphy_ops {
+
+struct cdns_dphy_common_ops {
 	int (*probe)(struct cdns_dphy *dphy);
 	void (*remove)(struct cdns_dphy *dphy);
+};
+
+struct cdns_dphy_tx_ops {
 	void (*set_psm_div)(struct cdns_dphy *dphy, u8 div);
 	void (*set_clk_lane_cfg)(struct cdns_dphy *dphy,
 				 enum cdns_dphy_clk_lane_cfg cfg);
@@ -83,12 +87,21 @@ struct cdns_dphy_ops {
 	unsigned long (*get_wakeup_time_ns)(struct cdns_dphy *dphy);
 };
 
+struct cdns_dphy_info {
+	const struct phy_ops *phy_ops;
+	const struct cdns_dphy_common_ops *common_ops;
+
+	/* Only set when DPHY is to be used in Tx mode. */
+	const struct cdns_dphy_tx_ops *tx_ops;
+};
+
 struct cdns_dphy {
 	struct cdns_dphy_cfg cfg;
 	void __iomem *regs;
+	struct device *dev;
 	struct clk *psm_clk;
 	struct clk *pll_ref_clk;
-	const struct cdns_dphy_ops *ops;
+	const struct cdns_dphy_info *info;
 	struct phy *phy;
 };
 
@@ -135,6 +148,7 @@ static int cdns_dsi_get_dphy_pll_cfg(struct cdns_dphy *dphy,
 
 static int cdns_dphy_setup_psm(struct cdns_dphy *dphy)
 {
+	const struct cdns_dphy_tx_ops *ops = dphy->info->tx_ops;
 	unsigned long psm_clk_hz = clk_get_rate(dphy->psm_clk);
 	unsigned long psm_div;
 
@@ -142,8 +156,8 @@ static int cdns_dphy_setup_psm(struct cdns_dphy *dphy)
 		return -EINVAL;
 
 	psm_div = DIV_ROUND_CLOSEST(psm_clk_hz, 1000000);
-	if (dphy->ops->set_psm_div)
-		dphy->ops->set_psm_div(dphy, psm_div);
+	if (ops && ops->set_psm_div)
+		ops->set_psm_div(dphy, psm_div);
 
 	return 0;
 }
@@ -151,20 +165,31 @@ static int cdns_dphy_setup_psm(struct cdns_dphy *dphy)
 static void cdns_dphy_set_clk_lane_cfg(struct cdns_dphy *dphy,
 				       enum cdns_dphy_clk_lane_cfg cfg)
 {
-	if (dphy->ops->set_clk_lane_cfg)
-		dphy->ops->set_clk_lane_cfg(dphy, cfg);
+	const struct cdns_dphy_tx_ops *ops = dphy->info->tx_ops;
+
+	if (ops && ops->set_clk_lane_cfg)
+		ops->set_clk_lane_cfg(dphy, cfg);
 }
 
 static void cdns_dphy_set_pll_cfg(struct cdns_dphy *dphy,
 				  const struct cdns_dphy_cfg *cfg)
 {
-	if (dphy->ops->set_pll_cfg)
-		dphy->ops->set_pll_cfg(dphy, cfg);
+	const struct cdns_dphy_tx_ops *ops = dphy->info->tx_ops;
+
+	if (ops && ops->set_pll_cfg)
+		ops->set_pll_cfg(dphy, cfg);
 }
 
 static unsigned long cdns_dphy_get_wakeup_time_ns(struct cdns_dphy *dphy)
 {
-	return dphy->ops->get_wakeup_time_ns(dphy);
+	const struct cdns_dphy_tx_ops *ops = dphy->info->tx_ops;
+
+	if (!ops || !ops->get_wakeup_time_ns) {
+		dev_err(dphy->dev, "get_wakeup_time_ns() is required\n");
+		return 0;
+	}
+
+	return ops->get_wakeup_time_ns(dphy);
 }
 
 static unsigned long cdns_dphy_ref_get_wakeup_time_ns(struct cdns_dphy *dphy)
@@ -199,20 +224,9 @@ static void cdns_dphy_ref_set_psm_div(struct cdns_dphy *dphy, u8 div)
 	       dphy->regs + DPHY_PSM_CFG);
 }
 
-/*
- * This is the reference implementation of DPHY hooks. Specific integration of
- * this IP may have to re-implement some of them depending on how they decided
- * to wire things in the SoC.
- */
-static const struct cdns_dphy_ops ref_dphy_ops = {
-	.get_wakeup_time_ns = cdns_dphy_ref_get_wakeup_time_ns,
-	.set_pll_cfg = cdns_dphy_ref_set_pll_cfg,
-	.set_psm_div = cdns_dphy_ref_set_psm_div,
-};
-
-static int cdns_dphy_config_from_opts(struct phy *phy,
-				      struct phy_configure_opts_mipi_dphy *opts,
-				      struct cdns_dphy_cfg *cfg)
+static int cdns_dphy_tx_config_from_opts(struct phy *phy,
+					 struct phy_configure_opts_mipi_dphy *opts,
+					 struct cdns_dphy_cfg *cfg)
 {
 	struct cdns_dphy *dphy = phy_get_drvdata(phy);
 	unsigned int dsi_hfp_ext = 0;
@@ -232,24 +246,14 @@ static int cdns_dphy_config_from_opts(struct phy *phy,
 	return 0;
 }
 
-static int cdns_dphy_validate(struct phy *phy, enum phy_mode mode, int submode,
-			      union phy_configure_opts *opts)
-{
-	struct cdns_dphy_cfg cfg = { 0 };
-
-	if (mode != PHY_MODE_MIPI_DPHY)
-		return -EINVAL;
-
-	return cdns_dphy_config_from_opts(phy, &opts->mipi_dphy, &cfg);
-}
-
-static int cdns_dphy_configure(struct phy *phy, union phy_configure_opts *opts)
+static int cdns_dphy_tx_configure(struct phy *phy,
+				  union phy_configure_opts *opts)
 {
 	struct cdns_dphy *dphy = phy_get_drvdata(phy);
 	struct cdns_dphy_cfg cfg = { 0 };
 	int ret;
 
-	ret = cdns_dphy_config_from_opts(phy, &opts->mipi_dphy, &cfg);
+	ret = cdns_dphy_tx_config_from_opts(dphy->phy, &opts->mipi_dphy, &cfg);
 	if (ret)
 		return ret;
 
@@ -279,7 +283,19 @@ static int cdns_dphy_configure(struct phy *phy, union phy_configure_opts *opts)
 	return 0;
 }
 
-static int cdns_dphy_power_on(struct phy *phy)
+static int cdns_dphy_tx_validate(struct phy *phy, enum phy_mode mode,
+				 int submode, union phy_configure_opts *opts)
+{
+	struct cdns_dphy *dphy = phy_get_drvdata(phy);
+	struct cdns_dphy_cfg cfg = { 0 };
+
+	if (mode != PHY_MODE_MIPI_DPHY)
+		return -EINVAL;
+
+	return cdns_dphy_tx_config_from_opts(dphy->phy, &opts->mipi_dphy, &cfg);
+}
+
+static int cdns_dphy_tx_power_on(struct phy *phy)
 {
 	struct cdns_dphy *dphy = phy_get_drvdata(phy);
 
@@ -293,7 +309,7 @@ static int cdns_dphy_power_on(struct phy *phy)
 	return 0;
 }
 
-static int cdns_dphy_power_off(struct phy *phy)
+static int cdns_dphy_tx_power_off(struct phy *phy)
 {
 	struct cdns_dphy *dphy = phy_get_drvdata(phy);
 
@@ -303,16 +319,51 @@ static int cdns_dphy_power_off(struct phy *phy)
 	return 0;
 }
 
-static const struct phy_ops cdns_dphy_ops = {
-	.configure	= cdns_dphy_configure,
-	.validate	= cdns_dphy_validate,
-	.power_on	= cdns_dphy_power_on,
-	.power_off	= cdns_dphy_power_off,
+static int cdns_dphy_tx_probe(struct cdns_dphy *dphy)
+{
+	dphy->psm_clk = devm_clk_get(dphy->dev, "psm");
+	if (IS_ERR(dphy->psm_clk))
+		return PTR_ERR(dphy->psm_clk);
+
+	dphy->pll_ref_clk = devm_clk_get(dphy->dev, "pll_ref");
+	if (IS_ERR(dphy->pll_ref_clk))
+		return PTR_ERR(dphy->pll_ref_clk);
+
+	return 0;
+}
+
+/*
+ * This is the reference implementation of DPHY hooks. Specific integration of
+ * this IP may have to re-implement some of them depending on how they decided
+ * to wire things in the SoC.
+ */
+static const struct cdns_dphy_tx_ops tx_ref_dphy_ops = {
+	.get_wakeup_time_ns = cdns_dphy_ref_get_wakeup_time_ns,
+	.set_pll_cfg = cdns_dphy_ref_set_pll_cfg,
+	.set_psm_div = cdns_dphy_ref_set_psm_div,
+};
+
+static const struct cdns_dphy_common_ops tx_ref_common_ops = {
+	.probe = cdns_dphy_tx_probe,
+};
+
+static const struct phy_ops tx_ref_phy_ops = {
+	.power_on = cdns_dphy_tx_power_on,
+	.power_off = cdns_dphy_tx_power_off,
+	.validate = cdns_dphy_tx_validate,
+	.configure = cdns_dphy_tx_configure,
+};
+
+static const struct cdns_dphy_info tx_ref_info = {
+	.phy_ops = &tx_ref_phy_ops,
+	.common_ops = &tx_ref_common_ops,
+	.tx_ops = &tx_ref_dphy_ops,
 };
 
 static int cdns_dphy_probe(struct platform_device *pdev)
 {
 	struct phy_provider *phy_provider;
+	const struct cdns_dphy_info *info;
 	struct cdns_dphy *dphy;
 	int ret;
 
@@ -320,34 +371,29 @@ static int cdns_dphy_probe(struct platform_device *pdev)
 	if (!dphy)
 		return -ENOMEM;
 	dev_set_drvdata(&pdev->dev, dphy);
+	dphy->dev = &pdev->dev;
 
-	dphy->ops = of_device_get_match_data(&pdev->dev);
-	if (!dphy->ops)
+	info = of_device_get_match_data(&pdev->dev);
+	if (!info)
 		return -EINVAL;
 
+	dphy->info = info;
+
 	dphy->regs = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(dphy->regs))
 		return PTR_ERR(dphy->regs);
 
-	dphy->psm_clk = devm_clk_get(&pdev->dev, "psm");
-	if (IS_ERR(dphy->psm_clk))
-		return PTR_ERR(dphy->psm_clk);
-
-	dphy->pll_ref_clk = devm_clk_get(&pdev->dev, "pll_ref");
-	if (IS_ERR(dphy->pll_ref_clk))
-		return PTR_ERR(dphy->pll_ref_clk);
-
-	if (dphy->ops->probe) {
-		ret = dphy->ops->probe(dphy);
+	if (info->common_ops && info->common_ops->probe) {
+		ret = info->common_ops->probe(dphy);
 		if (ret)
 			return ret;
 	}
 
-	dphy->phy = devm_phy_create(&pdev->dev, NULL, &cdns_dphy_ops);
+	dphy->phy = devm_phy_create(&pdev->dev, NULL, info->phy_ops);
 	if (IS_ERR(dphy->phy)) {
 		dev_err(&pdev->dev, "failed to create PHY\n");
-		if (dphy->ops->remove)
-			dphy->ops->remove(dphy);
+		if (info->common_ops && info->common_ops->remove)
+			info->common_ops->remove(dphy);
 		return PTR_ERR(dphy->phy);
 	}
 
@@ -361,15 +407,16 @@ static int cdns_dphy_probe(struct platform_device *pdev)
 static int cdns_dphy_remove(struct platform_device *pdev)
 {
 	struct cdns_dphy *dphy = dev_get_drvdata(&pdev->dev);
+	const struct cdns_dphy_info *info = dphy->info;
 
-	if (dphy->ops->remove)
-		dphy->ops->remove(dphy);
+	if (info->common_ops && info->common_ops->remove)
+		info->common_ops->remove(dphy);
 
 	return 0;
 }
 
 static const struct of_device_id cdns_dphy_of_match[] = {
-	{ .compatible = "cdns,dphy", .data = &ref_dphy_ops },
+	{ .compatible = "cdns,dphy", .data = &tx_ref_info },
 	{ /* sentinel */ },
 };
 MODULE_DEVICE_TABLE(of, cdns_dphy_of_match);
-- 
2.33.0

[PATCH v5 1/6] phy: cdns-dphy: Prepare for Rx support

[Pratyush Yadav]

The Rx programming sequence differs from the Tx programming sequence.
Currently only Tx mode is supported. For example, the power on and off,
validation, and configuration procedures are all different between Rx
and Tx DPHYs. Currently they are only written from a Tx point of view
and they won't work with an Rx DPHY.

Set the PHY ops from driver data, which makes it possible to use
different PHY callbacks for Rx and Tx modes. Rename cdns_dphy_ops to
cdns_dphy_tx_ops since they are only used by the Tx path. Also move
probe() and remove() to a new struct called cdns_dphy_common_ops. These
can be used by both Rx and Tx paths. cdns_dphy_rx_ops is not added since
it is not needed by the reference Rx mode implementation as of now. It
can be added later if needed.

The clocks "psm" and "pll_ref" are not used by the Rx path so check for
them in the Tx path's probe() callback.

Signed-off-by: Pratyush Yadav <p.yadav@ti.com>

---

Changes in v5:
- Based on Laurent's suggestion, add cdns_dphy_info which contains the
  phy_ops and cdns_dphy_tx_ops (renamed from cdns_dphy_ops). This lets us
  get rid of the phy ops wrappers.
- Move probe() and remove() into cdns_dphy_common_ops() since they can
  be used by both modes. Drop the check in power_on().
- Get the clocks in the tx ops probe to make sure they are mandatory for
  Tx mode but not for Rx mode.

Changes in v4:
- Instead of having both Rx and Tx modes in the same driver data, keep
  them separate since the op selection is based on compatible now. For
  that reason, the cdns_dphy_driver_data struct is no longer needed.
- Rename ref_dphy_ops to tx_ref_dphy_ops to clarify their purpose.
- Drop submode checks in validate() hook.

 drivers/phy/cadence/cdns-dphy.c | 169 ++++++++++++++++++++------------
 1 file changed, 108 insertions(+), 61 deletions(-)

diff --git a/drivers/phy/cadence/cdns-dphy.c b/drivers/phy/cadence/cdns-dphy.c
index ba042e39cfaf..e2c2b27c6539 100644
--- a/drivers/phy/cadence/cdns-dphy.c
+++ b/drivers/phy/cadence/cdns-dphy.c
@@ -72,9 +72,13 @@ enum cdns_dphy_clk_lane_cfg {
 };
 
 struct cdns_dphy;
-struct cdns_dphy_ops {
+
+struct cdns_dphy_common_ops {
 	int (*probe)(struct cdns_dphy *dphy);
 	void (*remove)(struct cdns_dphy *dphy);
+};
+
+struct cdns_dphy_tx_ops {
 	void (*set_psm_div)(struct cdns_dphy *dphy, u8 div);
 	void (*set_clk_lane_cfg)(struct cdns_dphy *dphy,
 				 enum cdns_dphy_clk_lane_cfg cfg);
@@ -83,12 +87,21 @@ struct cdns_dphy_ops {
 	unsigned long (*get_wakeup_time_ns)(struct cdns_dphy *dphy);
 };
 
+struct cdns_dphy_info {
+	const struct phy_ops *phy_ops;
+	const struct cdns_dphy_common_ops *common_ops;
+
+	/* Only set when DPHY is to be used in Tx mode. */
+	const struct cdns_dphy_tx_ops *tx_ops;
+};
+
 struct cdns_dphy {
 	struct cdns_dphy_cfg cfg;
 	void __iomem *regs;
+	struct device *dev;
 	struct clk *psm_clk;
 	struct clk *pll_ref_clk;
-	const struct cdns_dphy_ops *ops;
+	const struct cdns_dphy_info *info;
 	struct phy *phy;
 };
 
@@ -135,6 +148,7 @@ static int cdns_dsi_get_dphy_pll_cfg(struct cdns_dphy *dphy,
 
 static int cdns_dphy_setup_psm(struct cdns_dphy *dphy)
 {
+	const struct cdns_dphy_tx_ops *ops = dphy->info->tx_ops;
 	unsigned long psm_clk_hz = clk_get_rate(dphy->psm_clk);
 	unsigned long psm_div;
 
@@ -142,8 +156,8 @@ static int cdns_dphy_setup_psm(struct cdns_dphy *dphy)
 		return -EINVAL;
 
 	psm_div = DIV_ROUND_CLOSEST(psm_clk_hz, 1000000);
-	if (dphy->ops->set_psm_div)
-		dphy->ops->set_psm_div(dphy, psm_div);
+	if (ops && ops->set_psm_div)
+		ops->set_psm_div(dphy, psm_div);
 
 	return 0;
 }
@@ -151,20 +165,31 @@ static int cdns_dphy_setup_psm(struct cdns_dphy *dphy)
 static void cdns_dphy_set_clk_lane_cfg(struct cdns_dphy *dphy,
 				       enum cdns_dphy_clk_lane_cfg cfg)
 {
-	if (dphy->ops->set_clk_lane_cfg)
-		dphy->ops->set_clk_lane_cfg(dphy, cfg);
+	const struct cdns_dphy_tx_ops *ops = dphy->info->tx_ops;
+
+	if (ops && ops->set_clk_lane_cfg)
+		ops->set_clk_lane_cfg(dphy, cfg);
 }
 
 static void cdns_dphy_set_pll_cfg(struct cdns_dphy *dphy,
 				  const struct cdns_dphy_cfg *cfg)
 {
-	if (dphy->ops->set_pll_cfg)
-		dphy->ops->set_pll_cfg(dphy, cfg);
+	const struct cdns_dphy_tx_ops *ops = dphy->info->tx_ops;
+
+	if (ops && ops->set_pll_cfg)
+		ops->set_pll_cfg(dphy, cfg);
 }
 
 static unsigned long cdns_dphy_get_wakeup_time_ns(struct cdns_dphy *dphy)
 {
-	return dphy->ops->get_wakeup_time_ns(dphy);
+	const struct cdns_dphy_tx_ops *ops = dphy->info->tx_ops;
+
+	if (!ops || !ops->get_wakeup_time_ns) {
+		dev_err(dphy->dev, "get_wakeup_time_ns() is required\n");
+		return 0;
+	}
+
+	return ops->get_wakeup_time_ns(dphy);
 }
 
 static unsigned long cdns_dphy_ref_get_wakeup_time_ns(struct cdns_dphy *dphy)
@@ -199,20 +224,9 @@ static void cdns_dphy_ref_set_psm_div(struct cdns_dphy *dphy, u8 div)
 	       dphy->regs + DPHY_PSM_CFG);
 }
 
-/*
- * This is the reference implementation of DPHY hooks. Specific integration of
- * this IP may have to re-implement some of them depending on how they decided
- * to wire things in the SoC.
- */
-static const struct cdns_dphy_ops ref_dphy_ops = {
-	.get_wakeup_time_ns = cdns_dphy_ref_get_wakeup_time_ns,
-	.set_pll_cfg = cdns_dphy_ref_set_pll_cfg,
-	.set_psm_div = cdns_dphy_ref_set_psm_div,
-};
-
-static int cdns_dphy_config_from_opts(struct phy *phy,
-				      struct phy_configure_opts_mipi_dphy *opts,
-				      struct cdns_dphy_cfg *cfg)
+static int cdns_dphy_tx_config_from_opts(struct phy *phy,
+					 struct phy_configure_opts_mipi_dphy *opts,
+					 struct cdns_dphy_cfg *cfg)
 {
 	struct cdns_dphy *dphy = phy_get_drvdata(phy);
 	unsigned int dsi_hfp_ext = 0;
@@ -232,24 +246,14 @@ static int cdns_dphy_config_from_opts(struct phy *phy,
 	return 0;
 }
 
-static int cdns_dphy_validate(struct phy *phy, enum phy_mode mode, int submode,
-			      union phy_configure_opts *opts)
-{
-	struct cdns_dphy_cfg cfg = { 0 };
-
-	if (mode != PHY_MODE_MIPI_DPHY)
-		return -EINVAL;
-
-	return cdns_dphy_config_from_opts(phy, &opts->mipi_dphy, &cfg);
-}
-
-static int cdns_dphy_configure(struct phy *phy, union phy_configure_opts *opts)
+static int cdns_dphy_tx_configure(struct phy *phy,
+				  union phy_configure_opts *opts)
 {
 	struct cdns_dphy *dphy = phy_get_drvdata(phy);
 	struct cdns_dphy_cfg cfg = { 0 };
 	int ret;
 
-	ret = cdns_dphy_config_from_opts(phy, &opts->mipi_dphy, &cfg);
+	ret = cdns_dphy_tx_config_from_opts(dphy->phy, &opts->mipi_dphy, &cfg);
 	if (ret)
 		return ret;
 
@@ -279,7 +283,19 @@ static int cdns_dphy_configure(struct phy *phy, union phy_configure_opts *opts)
 	return 0;
 }
 
-static int cdns_dphy_power_on(struct phy *phy)
+static int cdns_dphy_tx_validate(struct phy *phy, enum phy_mode mode,
+				 int submode, union phy_configure_opts *opts)
+{
+	struct cdns_dphy *dphy = phy_get_drvdata(phy);
+	struct cdns_dphy_cfg cfg = { 0 };
+
+	if (mode != PHY_MODE_MIPI_DPHY)
+		return -EINVAL;
+
+	return cdns_dphy_tx_config_from_opts(dphy->phy, &opts->mipi_dphy, &cfg);
+}
+
+static int cdns_dphy_tx_power_on(struct phy *phy)
 {
 	struct cdns_dphy *dphy = phy_get_drvdata(phy);
 
@@ -293,7 +309,7 @@ static int cdns_dphy_power_on(struct phy *phy)
 	return 0;
 }
 
-static int cdns_dphy_power_off(struct phy *phy)
+static int cdns_dphy_tx_power_off(struct phy *phy)
 {
 	struct cdns_dphy *dphy = phy_get_drvdata(phy);
 
@@ -303,16 +319,51 @@ static int cdns_dphy_power_off(struct phy *phy)
 	return 0;
 }
 
-static const struct phy_ops cdns_dphy_ops = {
-	.configure	= cdns_dphy_configure,
-	.validate	= cdns_dphy_validate,
-	.power_on	= cdns_dphy_power_on,
-	.power_off	= cdns_dphy_power_off,
+static int cdns_dphy_tx_probe(struct cdns_dphy *dphy)
+{
+	dphy->psm_clk = devm_clk_get(dphy->dev, "psm");
+	if (IS_ERR(dphy->psm_clk))
+		return PTR_ERR(dphy->psm_clk);
+
+	dphy->pll_ref_clk = devm_clk_get(dphy->dev, "pll_ref");
+	if (IS_ERR(dphy->pll_ref_clk))
+		return PTR_ERR(dphy->pll_ref_clk);
+
+	return 0;
+}
+
+/*
+ * This is the reference implementation of DPHY hooks. Specific integration of
+ * this IP may have to re-implement some of them depending on how they decided
+ * to wire things in the SoC.
+ */
+static const struct cdns_dphy_tx_ops tx_ref_dphy_ops = {
+	.get_wakeup_time_ns = cdns_dphy_ref_get_wakeup_time_ns,
+	.set_pll_cfg = cdns_dphy_ref_set_pll_cfg,
+	.set_psm_div = cdns_dphy_ref_set_psm_div,
+};
+
+static const struct cdns_dphy_common_ops tx_ref_common_ops = {
+	.probe = cdns_dphy_tx_probe,
+};
+
+static const struct phy_ops tx_ref_phy_ops = {
+	.power_on = cdns_dphy_tx_power_on,
+	.power_off = cdns_dphy_tx_power_off,
+	.validate = cdns_dphy_tx_validate,
+	.configure = cdns_dphy_tx_configure,
+};
+
+static const struct cdns_dphy_info tx_ref_info = {
+	.phy_ops = &tx_ref_phy_ops,
+	.common_ops = &tx_ref_common_ops,
+	.tx_ops = &tx_ref_dphy_ops,
 };
 
 static int cdns_dphy_probe(struct platform_device *pdev)
 {
 	struct phy_provider *phy_provider;
+	const struct cdns_dphy_info *info;
 	struct cdns_dphy *dphy;
 	int ret;
 
@@ -320,34 +371,29 @@ static int cdns_dphy_probe(struct platform_device *pdev)
 	if (!dphy)
 		return -ENOMEM;
 	dev_set_drvdata(&pdev->dev, dphy);
+	dphy->dev = &pdev->dev;
 
-	dphy->ops = of_device_get_match_data(&pdev->dev);
-	if (!dphy->ops)
+	info = of_device_get_match_data(&pdev->dev);
+	if (!info)
 		return -EINVAL;
 
+	dphy->info = info;
+
 	dphy->regs = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(dphy->regs))
 		return PTR_ERR(dphy->regs);
 
-	dphy->psm_clk = devm_clk_get(&pdev->dev, "psm");
-	if (IS_ERR(dphy->psm_clk))
-		return PTR_ERR(dphy->psm_clk);
-
-	dphy->pll_ref_clk = devm_clk_get(&pdev->dev, "pll_ref");
-	if (IS_ERR(dphy->pll_ref_clk))
-		return PTR_ERR(dphy->pll_ref_clk);
-
-	if (dphy->ops->probe) {
-		ret = dphy->ops->probe(dphy);
+	if (info->common_ops && info->common_ops->probe) {
+		ret = info->common_ops->probe(dphy);
 		if (ret)
 			return ret;
 	}
 
-	dphy->phy = devm_phy_create(&pdev->dev, NULL, &cdns_dphy_ops);
+	dphy->phy = devm_phy_create(&pdev->dev, NULL, info->phy_ops);
 	if (IS_ERR(dphy->phy)) {
 		dev_err(&pdev->dev, "failed to create PHY\n");
-		if (dphy->ops->remove)
-			dphy->ops->remove(dphy);
+		if (info->common_ops && info->common_ops->remove)
+			info->common_ops->remove(dphy);
 		return PTR_ERR(dphy->phy);
 	}
 
@@ -361,15 +407,16 @@ static int cdns_dphy_probe(struct platform_device *pdev)
 static int cdns_dphy_remove(struct platform_device *pdev)
 {
 	struct cdns_dphy *dphy = dev_get_drvdata(&pdev->dev);
+	const struct cdns_dphy_info *info = dphy->info;
 
-	if (dphy->ops->remove)
-		dphy->ops->remove(dphy);
+	if (info->common_ops && info->common_ops->remove)
+		info->common_ops->remove(dphy);
 
 	return 0;
 }
 
 static const struct of_device_id cdns_dphy_of_match[] = {
-	{ .compatible = "cdns,dphy", .data = &ref_dphy_ops },
+	{ .compatible = "cdns,dphy", .data = &tx_ref_info },
 	{ /* sentinel */ },
 };
 MODULE_DEVICE_TABLE(of, cdns_dphy_of_match);
-- 
2.33.0


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

[PATCH v5 2/6] phy: cdns-dphy: Add Rx support

[Pratyush Yadav]

The Cadence DPHY can be used to receive image data over the CSI-2
protocol. Add support for Rx mode. The programming sequence differs from
the Tx mode so it is added as a separate set of hooks to isolate the two
paths. The mode in which the DPHY has to be used is selected based on
the compatible.

Signed-off-by: Pratyush Yadav <p.yadav@ti.com>

---

Changes in v5:
- Use the new cdns_dphy_info to specify PHY ops.
- Re-order include in alphabetical order.
- Make bands const.
- Drop num_bands.
- Make i, lanes unsigned.
- Drop the maximum check in cdns_dphy_rx_get_band_ctrl(). Let the loop
  complete and return -EOPNOTSUPP when we reach the end.
- Drop the "rate < bands[i].min_rate" check since the bands are in
  ascending order.
- Move data_lane_ctrl to start of function and make it static const.

Changes in v4:
- Drop the submode parts. Use a different compatible for the Rx ops.
- Make bands and num_bands static.

Changes in v3:
- Use a table to select the band.
- Use a table to poll the data lane ready bits.
- Multiply the DPHY HS clock rate by 2 to get the bit rate since the
  clock is DDR.

 drivers/phy/cadence/cdns-dphy.c | 182 ++++++++++++++++++++++++++++++++
 1 file changed, 182 insertions(+)

diff --git a/drivers/phy/cadence/cdns-dphy.c b/drivers/phy/cadence/cdns-dphy.c
index e2c2b27c6539..9a4c1c684e9a 100644
--- a/drivers/phy/cadence/cdns-dphy.c
+++ b/drivers/phy/cadence/cdns-dphy.c
@@ -1,11 +1,14 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
  * Copyright: 2017-2018 Cadence Design Systems, Inc.
+ * Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com/
  */
 
+#include <linux/bitfield.h>
 #include <linux/bitops.h>
 #include <linux/clk.h>
 #include <linux/io.h>
+#include <linux/iopoll.h>
 #include <linux/module.h>
 #include <linux/of_address.h>
 #include <linux/of_device.h>
@@ -25,10 +28,14 @@
 #define DPHY_PMA_RCLK(reg)		(0x600 + (reg))
 #define DPHY_PMA_RDATA(lane, reg)	(0x700 + ((lane) * 0x100) + (reg))
 #define DPHY_PCS(reg)			(0xb00 + (reg))
+#define DPHY_ISO(reg)			(0xc00 + (reg))
 
 #define DPHY_CMN_SSM			DPHY_PMA_CMN(0x20)
 #define DPHY_CMN_SSM_EN			BIT(0)
+#define DPHY_CMN_RX_BANDGAP_TIMER_MASK	GENMASK(8, 1)
 #define DPHY_CMN_TX_MODE_EN		BIT(9)
+#define DPHY_CMN_RX_MODE_EN		BIT(10)
+#define DPHY_CMN_RX_BANDGAP_TIMER	0x14
 
 #define DPHY_CMN_PWM			DPHY_PMA_CMN(0x40)
 #define DPHY_CMN_PWM_DIV(x)		((x) << 20)
@@ -45,10 +52,27 @@
 #define DPHY_CMN_OPDIV_FROM_REG		BIT(6)
 #define DPHY_CMN_OPDIV(x)		((x) << 7)
 
+#define DPHY_BAND_CFG			DPHY_PCS(0x0)
+#define DPHY_BAND_CFG_LEFT_BAND		GENMASK(4, 0)
+#define DPHY_BAND_CFG_RIGHT_BAND	GENMASK(9, 5)
+
 #define DPHY_PSM_CFG			DPHY_PCS(0x4)
 #define DPHY_PSM_CFG_FROM_REG		BIT(0)
 #define DPHY_PSM_CLK_DIV(x)		((x) << 1)
 
+#define DPHY_POWER_ISLAND_EN_DATA	DPHY_PCS(0x8)
+#define DPHY_POWER_ISLAND_EN_DATA_VAL	0xaaaaaaaa
+#define DPHY_POWER_ISLAND_EN_CLK	DPHY_PCS(0xc)
+#define DPHY_POWER_ISLAND_EN_CLK_VAL	0xaa
+
+#define DPHY_ISO_CL_CTRL_L		DPHY_ISO(0x10)
+#define DPHY_ISO_DL_CTRL_L0		DPHY_ISO(0x14)
+#define DPHY_ISO_DL_CTRL_L1		DPHY_ISO(0x20)
+#define DPHY_ISO_DL_CTRL_L2		DPHY_ISO(0x30)
+#define DPHY_ISO_DL_CTRL_L3		DPHY_ISO(0x3c)
+#define DPHY_ISO_LANE_READY_BIT		0
+#define DPHY_ISO_LANE_READY_TIMEOUT_MS	100UL
+
 #define DSI_HBP_FRAME_OVERHEAD		12
 #define DSI_HSA_FRAME_OVERHEAD		14
 #define DSI_HFP_FRAME_OVERHEAD		6
@@ -57,6 +81,9 @@
 #define DSI_NULL_FRAME_OVERHEAD		6
 #define DSI_EOT_PKT_SIZE		4
 
+#define DPHY_LANES_MIN			1
+#define DPHY_LANES_MAX			4
+
 struct cdns_dphy_cfg {
 	u8 pll_ipdiv;
 	u8 pll_opdiv;
@@ -105,6 +132,20 @@ struct cdns_dphy {
 	struct phy *phy;
 };
 
+struct cdns_dphy_rx_band {
+	unsigned int min_rate;
+	unsigned int max_rate;
+};
+
+/* Order of bands is important since the index is the band number. */
+static const struct cdns_dphy_rx_band bands[] = {
+	{80, 100}, {100, 120}, {120, 160}, {160, 200}, {200, 240},
+	{240, 280}, {280, 320}, {320, 360}, {360, 400}, {400, 480},
+	{480, 560}, {560, 640}, {640, 720}, {720, 800}, {800, 880},
+	{880, 1040}, {1040, 1200}, {1200, 1350}, {1350, 1500}, {1500, 1750},
+	{1750, 2000}, {2000, 2250}, {2250, 2500}
+};
+
 static int cdns_dsi_get_dphy_pll_cfg(struct cdns_dphy *dphy,
 				     struct cdns_dphy_cfg *cfg,
 				     struct phy_configure_opts_mipi_dphy *opts,
@@ -360,6 +401,145 @@ static const struct cdns_dphy_info tx_ref_info = {
 	.tx_ops = &tx_ref_dphy_ops,
 };
 
+static int cdns_dphy_rx_power_on(struct phy *phy)
+{
+	struct cdns_dphy *dphy = phy_get_drvdata(phy);
+
+	/* Start RX state machine. */
+	writel(DPHY_CMN_SSM_EN | DPHY_CMN_RX_MODE_EN |
+	       FIELD_PREP(DPHY_CMN_RX_BANDGAP_TIMER_MASK,
+			  DPHY_CMN_RX_BANDGAP_TIMER),
+	       dphy->regs + DPHY_CMN_SSM);
+
+	return 0;
+}
+
+static int cdns_dphy_rx_power_off(struct phy *phy)
+{
+	struct cdns_dphy *dphy = phy_get_drvdata(phy);
+
+	writel(0, dphy->regs + DPHY_CMN_SSM);
+
+	return 0;
+}
+
+static int cdns_dphy_rx_get_band_ctrl(unsigned long hs_clk_rate)
+{
+	unsigned int rate, i;
+
+	rate = hs_clk_rate / 1000000UL;
+	/* Since CSI-2 clock is DDR, the bit rate is twice the clock rate. */
+	rate *= 2;
+
+	if (rate < bands[0].min_rate)
+		return -EOPNOTSUPP;
+
+	for (i = 0; i < ARRAY_SIZE(bands); i++) {
+		if (rate < bands[i].max_rate)
+			return i;
+	}
+
+	return -EOPNOTSUPP;
+}
+
+static int cdns_dphy_rx_wait_for_bit(void __iomem *addr, unsigned int bit)
+{
+	u32 val;
+
+	return readl_relaxed_poll_timeout(addr, val, val & BIT(bit), 10,
+					  DPHY_ISO_LANE_READY_TIMEOUT_MS * 1000);
+}
+
+static int cdns_dphy_rx_wait_lane_ready(struct cdns_dphy *dphy,
+					unsigned int lanes)
+{
+	static const u32 data_lane_ctrl[] = {DPHY_ISO_DL_CTRL_L0,
+					     DPHY_ISO_DL_CTRL_L1,
+					     DPHY_ISO_DL_CTRL_L2,
+					     DPHY_ISO_DL_CTRL_L3};
+	void __iomem *reg = dphy->regs;
+	unsigned int i;
+	int ret;
+
+	/* Data lanes. Minimum one lane is mandatory. */
+	if (lanes < DPHY_LANES_MIN || lanes > DPHY_LANES_MAX)
+		return -EINVAL;
+
+	/* Clock lane */
+	ret = cdns_dphy_rx_wait_for_bit(reg + DPHY_ISO_CL_CTRL_L,
+					DPHY_ISO_LANE_READY_BIT);
+	if (ret)
+		return ret;
+
+	for (i = 0; i < lanes; i++) {
+		ret = cdns_dphy_rx_wait_for_bit(reg + data_lane_ctrl[i],
+						DPHY_ISO_LANE_READY_BIT);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
+static int cdns_dphy_rx_configure(struct phy *phy,
+				  union phy_configure_opts *opts)
+{
+	struct cdns_dphy *dphy = phy_get_drvdata(phy);
+	unsigned int reg;
+	int band_ctrl, ret;
+
+	band_ctrl = cdns_dphy_rx_get_band_ctrl(opts->mipi_dphy.hs_clk_rate);
+	if (band_ctrl < 0)
+		return band_ctrl;
+
+	reg = FIELD_PREP(DPHY_BAND_CFG_LEFT_BAND, band_ctrl) |
+	      FIELD_PREP(DPHY_BAND_CFG_RIGHT_BAND, band_ctrl);
+	writel(reg, dphy->regs + DPHY_BAND_CFG);
+
+	/*
+	 * Set the required power island phase 2 time. This is mandated by DPHY
+	 * specs.
+	 */
+	reg = DPHY_POWER_ISLAND_EN_DATA_VAL;
+	writel(reg, dphy->regs + DPHY_POWER_ISLAND_EN_DATA);
+	reg = DPHY_POWER_ISLAND_EN_CLK_VAL;
+	writel(reg, dphy->regs + DPHY_POWER_ISLAND_EN_CLK);
+
+	ret = cdns_dphy_rx_wait_lane_ready(dphy, opts->mipi_dphy.lanes);
+	if (ret) {
+		dev_err(dphy->dev, "DPHY wait for lane ready timeout\n");
+		return ret;
+	}
+
+	return 0;
+}
+
+static int cdns_dphy_rx_validate(struct phy *phy, enum phy_mode mode,
+				 int submode, union phy_configure_opts *opts)
+{
+	int ret;
+
+	if (mode != PHY_MODE_MIPI_DPHY)
+		return -EINVAL;
+
+	ret = cdns_dphy_rx_get_band_ctrl(opts->mipi_dphy.hs_clk_rate);
+	if (ret < 0)
+		return ret;
+
+	return phy_mipi_dphy_config_validate(&opts->mipi_dphy);
+}
+
+static const struct phy_ops rx_ref_phy_ops = {
+	.power_on = cdns_dphy_rx_power_on,
+	.power_off = cdns_dphy_rx_power_off,
+	.configure = cdns_dphy_rx_configure,
+	.validate = cdns_dphy_rx_validate,
+};
+
+static const struct cdns_dphy_info rx_ref_info = {
+	.phy_ops = &rx_ref_phy_ops,
+};
+
 static int cdns_dphy_probe(struct platform_device *pdev)
 {
 	struct phy_provider *phy_provider;
@@ -417,6 +597,7 @@ static int cdns_dphy_remove(struct platform_device *pdev)
 
 static const struct of_device_id cdns_dphy_of_match[] = {
 	{ .compatible = "cdns,dphy", .data = &tx_ref_info },
+	{ .compatible = "cdns,dphy-rx", .data = &rx_ref_info },
 	{ /* sentinel */ },
 };
 MODULE_DEVICE_TABLE(of, cdns_dphy_of_match);
@@ -432,5 +613,6 @@ static struct platform_driver cdns_dphy_platform_driver = {
 module_platform_driver(cdns_dphy_platform_driver);
 
 MODULE_AUTHOR("Maxime Ripard <maxime.ripard@bootlin.com>");
+MODULE_AUTHOR("Pratyush Yadav <p.yadav@ti.com>");
 MODULE_DESCRIPTION("Cadence MIPI D-PHY Driver");
 MODULE_LICENSE("GPL");
-- 
2.33.0

[PATCH v5 2/6] phy: cdns-dphy: Add Rx support

[Pratyush Yadav]

The Cadence DPHY can be used to receive image data over the CSI-2
protocol. Add support for Rx mode. The programming sequence differs from
the Tx mode so it is added as a separate set of hooks to isolate the two
paths. The mode in which the DPHY has to be used is selected based on
the compatible.

Signed-off-by: Pratyush Yadav <p.yadav@ti.com>

---

Changes in v5:
- Use the new cdns_dphy_info to specify PHY ops.
- Re-order include in alphabetical order.
- Make bands const.
- Drop num_bands.
- Make i, lanes unsigned.
- Drop the maximum check in cdns_dphy_rx_get_band_ctrl(). Let the loop
  complete and return -EOPNOTSUPP when we reach the end.
- Drop the "rate < bands[i].min_rate" check since the bands are in
  ascending order.
- Move data_lane_ctrl to start of function and make it static const.

Changes in v4:
- Drop the submode parts. Use a different compatible for the Rx ops.
- Make bands and num_bands static.

Changes in v3:
- Use a table to select the band.
- Use a table to poll the data lane ready bits.
- Multiply the DPHY HS clock rate by 2 to get the bit rate since the
  clock is DDR.

 drivers/phy/cadence/cdns-dphy.c | 182 ++++++++++++++++++++++++++++++++
 1 file changed, 182 insertions(+)

diff --git a/drivers/phy/cadence/cdns-dphy.c b/drivers/phy/cadence/cdns-dphy.c
index e2c2b27c6539..9a4c1c684e9a 100644
--- a/drivers/phy/cadence/cdns-dphy.c
+++ b/drivers/phy/cadence/cdns-dphy.c
@@ -1,11 +1,14 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
  * Copyright: 2017-2018 Cadence Design Systems, Inc.
+ * Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com/
  */
 
+#include <linux/bitfield.h>
 #include <linux/bitops.h>
 #include <linux/clk.h>
 #include <linux/io.h>
+#include <linux/iopoll.h>
 #include <linux/module.h>
 #include <linux/of_address.h>
 #include <linux/of_device.h>
@@ -25,10 +28,14 @@
 #define DPHY_PMA_RCLK(reg)		(0x600 + (reg))
 #define DPHY_PMA_RDATA(lane, reg)	(0x700 + ((lane) * 0x100) + (reg))
 #define DPHY_PCS(reg)			(0xb00 + (reg))
+#define DPHY_ISO(reg)			(0xc00 + (reg))
 
 #define DPHY_CMN_SSM			DPHY_PMA_CMN(0x20)
 #define DPHY_CMN_SSM_EN			BIT(0)
+#define DPHY_CMN_RX_BANDGAP_TIMER_MASK	GENMASK(8, 1)
 #define DPHY_CMN_TX_MODE_EN		BIT(9)
+#define DPHY_CMN_RX_MODE_EN		BIT(10)
+#define DPHY_CMN_RX_BANDGAP_TIMER	0x14
 
 #define DPHY_CMN_PWM			DPHY_PMA_CMN(0x40)
 #define DPHY_CMN_PWM_DIV(x)		((x) << 20)
@@ -45,10 +52,27 @@
 #define DPHY_CMN_OPDIV_FROM_REG		BIT(6)
 #define DPHY_CMN_OPDIV(x)		((x) << 7)
 
+#define DPHY_BAND_CFG			DPHY_PCS(0x0)
+#define DPHY_BAND_CFG_LEFT_BAND		GENMASK(4, 0)
+#define DPHY_BAND_CFG_RIGHT_BAND	GENMASK(9, 5)
+
 #define DPHY_PSM_CFG			DPHY_PCS(0x4)
 #define DPHY_PSM_CFG_FROM_REG		BIT(0)
 #define DPHY_PSM_CLK_DIV(x)		((x) << 1)
 
+#define DPHY_POWER_ISLAND_EN_DATA	DPHY_PCS(0x8)
+#define DPHY_POWER_ISLAND_EN_DATA_VAL	0xaaaaaaaa
+#define DPHY_POWER_ISLAND_EN_CLK	DPHY_PCS(0xc)
+#define DPHY_POWER_ISLAND_EN_CLK_VAL	0xaa
+
+#define DPHY_ISO_CL_CTRL_L		DPHY_ISO(0x10)
+#define DPHY_ISO_DL_CTRL_L0		DPHY_ISO(0x14)
+#define DPHY_ISO_DL_CTRL_L1		DPHY_ISO(0x20)
+#define DPHY_ISO_DL_CTRL_L2		DPHY_ISO(0x30)
+#define DPHY_ISO_DL_CTRL_L3		DPHY_ISO(0x3c)
+#define DPHY_ISO_LANE_READY_BIT		0
+#define DPHY_ISO_LANE_READY_TIMEOUT_MS	100UL
+
 #define DSI_HBP_FRAME_OVERHEAD		12
 #define DSI_HSA_FRAME_OVERHEAD		14
 #define DSI_HFP_FRAME_OVERHEAD		6
@@ -57,6 +81,9 @@
 #define DSI_NULL_FRAME_OVERHEAD		6
 #define DSI_EOT_PKT_SIZE		4
 
+#define DPHY_LANES_MIN			1
+#define DPHY_LANES_MAX			4
+
 struct cdns_dphy_cfg {
 	u8 pll_ipdiv;
 	u8 pll_opdiv;
@@ -105,6 +132,20 @@ struct cdns_dphy {
 	struct phy *phy;
 };
 
+struct cdns_dphy_rx_band {
+	unsigned int min_rate;
+	unsigned int max_rate;
+};
+
+/* Order of bands is important since the index is the band number. */
+static const struct cdns_dphy_rx_band bands[] = {
+	{80, 100}, {100, 120}, {120, 160}, {160, 200}, {200, 240},
+	{240, 280}, {280, 320}, {320, 360}, {360, 400}, {400, 480},
+	{480, 560}, {560, 640}, {640, 720}, {720, 800}, {800, 880},
+	{880, 1040}, {1040, 1200}, {1200, 1350}, {1350, 1500}, {1500, 1750},
+	{1750, 2000}, {2000, 2250}, {2250, 2500}
+};
+
 static int cdns_dsi_get_dphy_pll_cfg(struct cdns_dphy *dphy,
 				     struct cdns_dphy_cfg *cfg,
 				     struct phy_configure_opts_mipi_dphy *opts,
@@ -360,6 +401,145 @@ static const struct cdns_dphy_info tx_ref_info = {
 	.tx_ops = &tx_ref_dphy_ops,
 };
 
+static int cdns_dphy_rx_power_on(struct phy *phy)
+{
+	struct cdns_dphy *dphy = phy_get_drvdata(phy);
+
+	/* Start RX state machine. */
+	writel(DPHY_CMN_SSM_EN | DPHY_CMN_RX_MODE_EN |
+	       FIELD_PREP(DPHY_CMN_RX_BANDGAP_TIMER_MASK,
+			  DPHY_CMN_RX_BANDGAP_TIMER),
+	       dphy->regs + DPHY_CMN_SSM);
+
+	return 0;
+}
+
+static int cdns_dphy_rx_power_off(struct phy *phy)
+{
+	struct cdns_dphy *dphy = phy_get_drvdata(phy);
+
+	writel(0, dphy->regs + DPHY_CMN_SSM);
+
+	return 0;
+}
+
+static int cdns_dphy_rx_get_band_ctrl(unsigned long hs_clk_rate)
+{
+	unsigned int rate, i;
+
+	rate = hs_clk_rate / 1000000UL;
+	/* Since CSI-2 clock is DDR, the bit rate is twice the clock rate. */
+	rate *= 2;
+
+	if (rate < bands[0].min_rate)
+		return -EOPNOTSUPP;
+
+	for (i = 0; i < ARRAY_SIZE(bands); i++) {
+		if (rate < bands[i].max_rate)
+			return i;
+	}
+
+	return -EOPNOTSUPP;
+}
+
+static int cdns_dphy_rx_wait_for_bit(void __iomem *addr, unsigned int bit)
+{
+	u32 val;
+
+	return readl_relaxed_poll_timeout(addr, val, val & BIT(bit), 10,
+					  DPHY_ISO_LANE_READY_TIMEOUT_MS * 1000);
+}
+
+static int cdns_dphy_rx_wait_lane_ready(struct cdns_dphy *dphy,
+					unsigned int lanes)
+{
+	static const u32 data_lane_ctrl[] = {DPHY_ISO_DL_CTRL_L0,
+					     DPHY_ISO_DL_CTRL_L1,
+					     DPHY_ISO_DL_CTRL_L2,
+					     DPHY_ISO_DL_CTRL_L3};
+	void __iomem *reg = dphy->regs;
+	unsigned int i;
+	int ret;
+
+	/* Data lanes. Minimum one lane is mandatory. */
+	if (lanes < DPHY_LANES_MIN || lanes > DPHY_LANES_MAX)
+		return -EINVAL;
+
+	/* Clock lane */
+	ret = cdns_dphy_rx_wait_for_bit(reg + DPHY_ISO_CL_CTRL_L,
+					DPHY_ISO_LANE_READY_BIT);
+	if (ret)
+		return ret;
+
+	for (i = 0; i < lanes; i++) {
+		ret = cdns_dphy_rx_wait_for_bit(reg + data_lane_ctrl[i],
+						DPHY_ISO_LANE_READY_BIT);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
+static int cdns_dphy_rx_configure(struct phy *phy,
+				  union phy_configure_opts *opts)
+{
+	struct cdns_dphy *dphy = phy_get_drvdata(phy);
+	unsigned int reg;
+	int band_ctrl, ret;
+
+	band_ctrl = cdns_dphy_rx_get_band_ctrl(opts->mipi_dphy.hs_clk_rate);
+	if (band_ctrl < 0)
+		return band_ctrl;
+
+	reg = FIELD_PREP(DPHY_BAND_CFG_LEFT_BAND, band_ctrl) |
+	      FIELD_PREP(DPHY_BAND_CFG_RIGHT_BAND, band_ctrl);
+	writel(reg, dphy->regs + DPHY_BAND_CFG);
+
+	/*
+	 * Set the required power island phase 2 time. This is mandated by DPHY
+	 * specs.
+	 */
+	reg = DPHY_POWER_ISLAND_EN_DATA_VAL;
+	writel(reg, dphy->regs + DPHY_POWER_ISLAND_EN_DATA);
+	reg = DPHY_POWER_ISLAND_EN_CLK_VAL;
+	writel(reg, dphy->regs + DPHY_POWER_ISLAND_EN_CLK);
+
+	ret = cdns_dphy_rx_wait_lane_ready(dphy, opts->mipi_dphy.lanes);
+	if (ret) {
+		dev_err(dphy->dev, "DPHY wait for lane ready timeout\n");
+		return ret;
+	}
+
+	return 0;
+}
+
+static int cdns_dphy_rx_validate(struct phy *phy, enum phy_mode mode,
+				 int submode, union phy_configure_opts *opts)
+{
+	int ret;
+
+	if (mode != PHY_MODE_MIPI_DPHY)
+		return -EINVAL;
+
+	ret = cdns_dphy_rx_get_band_ctrl(opts->mipi_dphy.hs_clk_rate);
+	if (ret < 0)
+		return ret;
+
+	return phy_mipi_dphy_config_validate(&opts->mipi_dphy);
+}
+
+static const struct phy_ops rx_ref_phy_ops = {
+	.power_on = cdns_dphy_rx_power_on,
+	.power_off = cdns_dphy_rx_power_off,
+	.configure = cdns_dphy_rx_configure,
+	.validate = cdns_dphy_rx_validate,
+};
+
+static const struct cdns_dphy_info rx_ref_info = {
+	.phy_ops = &rx_ref_phy_ops,
+};
+
 static int cdns_dphy_probe(struct platform_device *pdev)
 {
 	struct phy_provider *phy_provider;
@@ -417,6 +597,7 @@ static int cdns_dphy_remove(struct platform_device *pdev)
 
 static const struct of_device_id cdns_dphy_of_match[] = {
 	{ .compatible = "cdns,dphy", .data = &tx_ref_info },
+	{ .compatible = "cdns,dphy-rx", .data = &rx_ref_info },
 	{ /* sentinel */ },
 };
 MODULE_DEVICE_TABLE(of, cdns_dphy_of_match);
@@ -432,5 +613,6 @@ static struct platform_driver cdns_dphy_platform_driver = {
 module_platform_driver(cdns_dphy_platform_driver);
 
 MODULE_AUTHOR("Maxime Ripard <maxime.ripard@bootlin.com>");
+MODULE_AUTHOR("Pratyush Yadav <p.yadav@ti.com>");
 MODULE_DESCRIPTION("Cadence MIPI D-PHY Driver");
 MODULE_LICENSE("GPL");
-- 
2.33.0


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

[PATCH v5 3/6] phy: dt-bindings: Convert Cadence DPHY binding to YAML

[Pratyush Yadav]

Convert Cadence DPHY binding to YAML.

Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Rob Herring <robh@kernel.org>

---

(no changes since v3)

Changes in v3:
- Add Rob's R-by.

Changes in v2:
- Drop reg description.
- Add a description for each DPHY clock.
- Rename dphy@... to phy@... in example.
- Add Laurent's R-by.
- Re-order subject prefixes.

 .../devicetree/bindings/phy/cdns,dphy.txt     | 20 --------
 .../devicetree/bindings/phy/cdns,dphy.yaml    | 51 +++++++++++++++++++
 2 files changed, 51 insertions(+), 20 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy.txt
 create mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy.yaml

diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy.txt b/Documentation/devicetree/bindings/phy/cdns,dphy.txt
deleted file mode 100644
index 1095bc4e72d9..000000000000
--- a/Documentation/devicetree/bindings/phy/cdns,dphy.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-Cadence DPHY
-============
-
-Cadence DPHY block.
-
-Required properties:
-- compatible: should be set to "cdns,dphy".
-- reg: physical base address and length of the DPHY registers.
-- clocks: DPHY reference clocks.
-- clock-names: must contain "psm" and "pll_ref".
-- #phy-cells: must be set to 0.
-
-Example:
-	dphy0: dphy@fd0e0000{
-		compatible = "cdns,dphy";
-		reg = <0x0 0xfd0e0000 0x0 0x1000>;
-		clocks = <&psm_clk>, <&pll_ref_clk>;
-		clock-names = "psm", "pll_ref";
-		#phy-cells = <0>;
-	};
diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
new file mode 100644
index 000000000000..b90a58773bf2
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/cdns,dphy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cadence DPHY Device Tree Bindings
+
+maintainers:
+  - Pratyush Yadav <p.yadav@ti.com>
+
+properties:
+  compatible:
+    items:
+      - const: cdns,dphy
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    items:
+      - description: PMA state machine clock
+      - description: PLL reference clock
+
+  clock-names:
+    items:
+      - const: psm
+      - const: pll_ref
+
+  "#phy-cells":
+    const: 0
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+  - |
+
+    dphy0: phy@fd0e0000{
+        compatible = "cdns,dphy";
+        reg = <0xfd0e0000 0x1000>;
+        clocks = <&psm_clk>, <&pll_ref_clk>;
+        clock-names = "psm", "pll_ref";
+        #phy-cells = <0>;
+    };
-- 
2.33.0

[PATCH v5 3/6] phy: dt-bindings: Convert Cadence DPHY binding to YAML

[Pratyush Yadav]

Convert Cadence DPHY binding to YAML.

Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Rob Herring <robh@kernel.org>

---

(no changes since v3)

Changes in v3:
- Add Rob's R-by.

Changes in v2:
- Drop reg description.
- Add a description for each DPHY clock.
- Rename dphy@... to phy@... in example.
- Add Laurent's R-by.
- Re-order subject prefixes.

 .../devicetree/bindings/phy/cdns,dphy.txt     | 20 --------
 .../devicetree/bindings/phy/cdns,dphy.yaml    | 51 +++++++++++++++++++
 2 files changed, 51 insertions(+), 20 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy.txt
 create mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy.yaml

diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy.txt b/Documentation/devicetree/bindings/phy/cdns,dphy.txt
deleted file mode 100644
index 1095bc4e72d9..000000000000
--- a/Documentation/devicetree/bindings/phy/cdns,dphy.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-Cadence DPHY
-============
-
-Cadence DPHY block.
-
-Required properties:
-- compatible: should be set to "cdns,dphy".
-- reg: physical base address and length of the DPHY registers.
-- clocks: DPHY reference clocks.
-- clock-names: must contain "psm" and "pll_ref".
-- #phy-cells: must be set to 0.
-
-Example:
-	dphy0: dphy@fd0e0000{
-		compatible = "cdns,dphy";
-		reg = <0x0 0xfd0e0000 0x0 0x1000>;
-		clocks = <&psm_clk>, <&pll_ref_clk>;
-		clock-names = "psm", "pll_ref";
-		#phy-cells = <0>;
-	};
diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
new file mode 100644
index 000000000000..b90a58773bf2
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/cdns,dphy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cadence DPHY Device Tree Bindings
+
+maintainers:
+  - Pratyush Yadav <p.yadav@ti.com>
+
+properties:
+  compatible:
+    items:
+      - const: cdns,dphy
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    items:
+      - description: PMA state machine clock
+      - description: PLL reference clock
+
+  clock-names:
+    items:
+      - const: psm
+      - const: pll_ref
+
+  "#phy-cells":
+    const: 0
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+  - |
+
+    dphy0: phy@fd0e0000{
+        compatible = "cdns,dphy";
+        reg = <0xfd0e0000 0x1000>;
+        clocks = <&psm_clk>, <&pll_ref_clk>;
+        clock-names = "psm", "pll_ref";
+        #phy-cells = <0>;
+    };
-- 
2.33.0


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

[PATCH v5 4/6] phy: dt-bindings: cdns,dphy: make clocks optional for Rx mode

[Pratyush Yadav]

The clocks are not used by the DPHY when used in Rx mode so make them
optional for it by using a conditional based on compatible.

Signed-off-by: Pratyush Yadav <p.yadav@ti.com>

---

Changes in v5:
- Make clocks a required property based on the compatible.

Changes in v3:
- Add Rob's Ack.

Changes in v2:
- Re-order subject prefixes.

 .../devicetree/bindings/phy/cdns,dphy.yaml          | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
index b90a58773bf2..558f110fda9e 100644
--- a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
+++ b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
@@ -33,10 +33,19 @@ properties:
 required:
   - compatible
   - reg
-  - clocks
-  - clock-names
   - "#phy-cells"
 
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: cdns,dphy
+    then:
+      required:
+        - clocks
+        - clock-names
+
 additionalProperties: false
 
 examples:
-- 
2.33.0

[PATCH v5 4/6] phy: dt-bindings: cdns, dphy: make clocks optional for Rx mode

[Pratyush Yadav]

The clocks are not used by the DPHY when used in Rx mode so make them
optional for it by using a conditional based on compatible.

Signed-off-by: Pratyush Yadav <p.yadav@ti.com>

---

Changes in v5:
- Make clocks a required property based on the compatible.

Changes in v3:
- Add Rob's Ack.

Changes in v2:
- Re-order subject prefixes.

 .../devicetree/bindings/phy/cdns,dphy.yaml          | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
index b90a58773bf2..558f110fda9e 100644
--- a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
+++ b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
@@ -33,10 +33,19 @@ properties:
 required:
   - compatible
   - reg
-  - clocks
-  - clock-names
   - "#phy-cells"
 
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: cdns,dphy
+    then:
+      required:
+        - clocks
+        - clock-names
+
 additionalProperties: false
 
 examples:
-- 
2.33.0


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

[PATCH v5 5/6] phy: dt-bindings: cdns,dphy: add power-domains property

[Pratyush Yadav]

This property is needed on TI platforms to enable the PD of the DPHY
before it can be used.

Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Rob Herring <robh@kernel.org>

---

(no changes since v3)

Changes in v3:
- Add Rob's Ack.

Changes in v2:
- Add power-domain to the example.
- Add Laurent's R-by.
- Re-order subject prefixes.

 Documentation/devicetree/bindings/phy/cdns,dphy.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
index 558f110fda9e..5293c2771b7f 100644
--- a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
+++ b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
@@ -30,6 +30,9 @@ properties:
   "#phy-cells":
     const: 0
 
+  power-domains:
+    maxItems: 1
+
 required:
   - compatible
   - reg
@@ -50,11 +53,13 @@ additionalProperties: false
 
 examples:
   - |
+    #include <dt-bindings/soc/ti,sci_pm_domain.h>
 
     dphy0: phy@fd0e0000{
         compatible = "cdns,dphy";
         reg = <0xfd0e0000 0x1000>;
         clocks = <&psm_clk>, <&pll_ref_clk>;
         clock-names = "psm", "pll_ref";
+        power-domains = <&k3_pds 147 TI_SCI_PD_EXCLUSIVE>;
         #phy-cells = <0>;
     };
-- 
2.33.0

[PATCH v5 5/6] phy: dt-bindings: cdns, dphy: add power-domains property

[Pratyush Yadav]

This property is needed on TI platforms to enable the PD of the DPHY
before it can be used.

Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Rob Herring <robh@kernel.org>

---

(no changes since v3)

Changes in v3:
- Add Rob's Ack.

Changes in v2:
- Add power-domain to the example.
- Add Laurent's R-by.
- Re-order subject prefixes.

 Documentation/devicetree/bindings/phy/cdns,dphy.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
index 558f110fda9e..5293c2771b7f 100644
--- a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
+++ b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
@@ -30,6 +30,9 @@ properties:
   "#phy-cells":
     const: 0
 
+  power-domains:
+    maxItems: 1
+
 required:
   - compatible
   - reg
@@ -50,11 +53,13 @@ additionalProperties: false
 
 examples:
   - |
+    #include <dt-bindings/soc/ti,sci_pm_domain.h>
 
     dphy0: phy@fd0e0000{
         compatible = "cdns,dphy";
         reg = <0xfd0e0000 0x1000>;
         clocks = <&psm_clk>, <&pll_ref_clk>;
         clock-names = "psm", "pll_ref";
+        power-domains = <&k3_pds 147 TI_SCI_PD_EXCLUSIVE>;
         #phy-cells = <0>;
     };
-- 
2.33.0


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

[PATCH v5 6/6] phy: dt-bindings: cdns,dphy: add Rx DPHY compatible

[Pratyush Yadav]

The DPHY is treated to be in Tx mode by default. Add a new compatible
for Rx mode DPHYs.

Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

---

Changes in v5:
- Use enum instead.
- Add Laurent's R-by.

Changes in v4:
- New in v4.

 Documentation/devicetree/bindings/phy/cdns,dphy.yaml | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
index 5293c2771b7f..2d86d9e860ba 100644
--- a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
+++ b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
@@ -11,8 +11,9 @@ maintainers:
 
 properties:
   compatible:
-    items:
-      - const: cdns,dphy
+    enum:
+      - cdns,dphy
+      - cdns,dphy-rx
 
   reg:
     maxItems: 1
-- 
2.33.0

[PATCH v5 6/6] phy: dt-bindings: cdns,dphy: add Rx DPHY compatible

[Pratyush Yadav]

The DPHY is treated to be in Tx mode by default. Add a new compatible
for Rx mode DPHYs.

Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

---

Changes in v5:
- Use enum instead.
- Add Laurent's R-by.

Changes in v4:
- New in v4.

 Documentation/devicetree/bindings/phy/cdns,dphy.yaml | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
index 5293c2771b7f..2d86d9e860ba 100644
--- a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
+++ b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
@@ -11,8 +11,9 @@ maintainers:
 
 properties:
   compatible:
-    items:
-      - const: cdns,dphy
+    enum:
+      - cdns,dphy
+      - cdns,dphy-rx
 
   reg:
     maxItems: 1
-- 
2.33.0


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v5 4/6] phy: dt-bindings: cdns,dphy: make clocks optional for Rx mode

[Rob Herring]

On Fri, 03 Sep 2021 00:25:41 +0530, Pratyush Yadav wrote:
> The clocks are not used by the DPHY when used in Rx mode so make them
> optional for it by using a conditional based on compatible.
> 
> Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
> 
> ---
> 
> Changes in v5:
> - Make clocks a required property based on the compatible.
> 
> Changes in v3:
> - Add Rob's Ack.
> 
> Changes in v2:
> - Re-order subject prefixes.
> 
>  .../devicetree/bindings/phy/cdns,dphy.yaml          | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 

Reviewed-by: Rob Herring <robh@kernel.org>

Re: [PATCH v5 4/6] phy: dt-bindings: cdns, dphy: make clocks optional for Rx mode

[Rob Herring]

On Fri, 03 Sep 2021 00:25:41 +0530, Pratyush Yadav wrote:
> The clocks are not used by the DPHY when used in Rx mode so make them
> optional for it by using a conditional based on compatible.
> 
> Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
> 
> ---
> 
> Changes in v5:
> - Make clocks a required property based on the compatible.
> 
> Changes in v3:
> - Add Rob's Ack.
> 
> Changes in v2:
> - Re-order subject prefixes.
> 
>  .../devicetree/bindings/phy/cdns,dphy.yaml          | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 

Reviewed-by: Rob Herring <robh@kernel.org>

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v5 6/6] phy: dt-bindings: cdns,dphy: add Rx DPHY compatible

[Rob Herring]

On Fri, 03 Sep 2021 00:25:43 +0530, Pratyush Yadav wrote:
> The DPHY is treated to be in Tx mode by default. Add a new compatible
> for Rx mode DPHYs.
> 
> Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> 
> ---
> 
> Changes in v5:
> - Use enum instead.
> - Add Laurent's R-by.
> 
> Changes in v4:
> - New in v4.
> 
>  Documentation/devicetree/bindings/phy/cdns,dphy.yaml | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 

Acked-by: Rob Herring <robh@kernel.org>

Re: [PATCH v5 6/6] phy: dt-bindings: cdns,dphy: add Rx DPHY compatible

[Rob Herring]

On Fri, 03 Sep 2021 00:25:43 +0530, Pratyush Yadav wrote:
> The DPHY is treated to be in Tx mode by default. Add a new compatible
> for Rx mode DPHYs.
> 
> Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> 
> ---
> 
> Changes in v5:
> - Use enum instead.
> - Add Laurent's R-by.
> 
> Changes in v4:
> - New in v4.
> 
>  Documentation/devicetree/bindings/phy/cdns,dphy.yaml | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 

Acked-by: Rob Herring <robh@kernel.org>

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v5 2/6] phy: cdns-dphy: Add Rx support

[Paul Kocialkowski]

[-- Attachment #1: Type: text/plain, Size: 10465 bytes --]

Hi,

On Fri 03 Sep 21, 00:25, Pratyush Yadav wrote:
> The Cadence DPHY can be used to receive image data over the CSI-2
> protocol. Add support for Rx mode. The programming sequence differs from
> the Tx mode so it is added as a separate set of hooks to isolate the two
> paths. The mode in which the DPHY has to be used is selected based on
> the compatible.

I just realized that I didn't follow-up on a previous revision on the debate
about using the phy sub-mode to distinguish between rx/tx.

I see that you've been using a dedicated compatible, but I'm not sure this is a
good fit either. My understanding is that the compatible should describe a group
of register-compatible revisions of a hardware component, not how the hardware
is used specifically. I guess the distinction between rx/tx falls under
the latter rather than the former.

I just sent out a patch in my Allwinner MIPI CSI-2+ISP series adding
a specific direction property:
- https://lists.infradead.org/pipermail/linux-phy/2021-September/001420.html
- https://lists.infradead.org/pipermail/linux-phy/2021-September/001421.html

Which I feel is a more appropriate solution to implement the distinction.

What do you think?

Cheers,

Paul
 
> Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
> 
> ---
> 
> Changes in v5:
> - Use the new cdns_dphy_info to specify PHY ops.
> - Re-order include in alphabetical order.
> - Make bands const.
> - Drop num_bands.
> - Make i, lanes unsigned.
> - Drop the maximum check in cdns_dphy_rx_get_band_ctrl(). Let the loop
>   complete and return -EOPNOTSUPP when we reach the end.
> - Drop the "rate < bands[i].min_rate" check since the bands are in
>   ascending order.
> - Move data_lane_ctrl to start of function and make it static const.
> 
> Changes in v4:
> - Drop the submode parts. Use a different compatible for the Rx ops.
> - Make bands and num_bands static.
> 
> Changes in v3:
> - Use a table to select the band.
> - Use a table to poll the data lane ready bits.
> - Multiply the DPHY HS clock rate by 2 to get the bit rate since the
>   clock is DDR.
> 
>  drivers/phy/cadence/cdns-dphy.c | 182 ++++++++++++++++++++++++++++++++
>  1 file changed, 182 insertions(+)
> 
> diff --git a/drivers/phy/cadence/cdns-dphy.c b/drivers/phy/cadence/cdns-dphy.c
> index e2c2b27c6539..9a4c1c684e9a 100644
> --- a/drivers/phy/cadence/cdns-dphy.c
> +++ b/drivers/phy/cadence/cdns-dphy.c
> @@ -1,11 +1,14 @@
>  // SPDX-License-Identifier: GPL-2.0+
>  /*
>   * Copyright: 2017-2018 Cadence Design Systems, Inc.
> + * Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com/
>   */
>  
> +#include <linux/bitfield.h>
>  #include <linux/bitops.h>
>  #include <linux/clk.h>
>  #include <linux/io.h>
> +#include <linux/iopoll.h>
>  #include <linux/module.h>
>  #include <linux/of_address.h>
>  #include <linux/of_device.h>
> @@ -25,10 +28,14 @@
>  #define DPHY_PMA_RCLK(reg)		(0x600 + (reg))
>  #define DPHY_PMA_RDATA(lane, reg)	(0x700 + ((lane) * 0x100) + (reg))
>  #define DPHY_PCS(reg)			(0xb00 + (reg))
> +#define DPHY_ISO(reg)			(0xc00 + (reg))
>  
>  #define DPHY_CMN_SSM			DPHY_PMA_CMN(0x20)
>  #define DPHY_CMN_SSM_EN			BIT(0)
> +#define DPHY_CMN_RX_BANDGAP_TIMER_MASK	GENMASK(8, 1)
>  #define DPHY_CMN_TX_MODE_EN		BIT(9)
> +#define DPHY_CMN_RX_MODE_EN		BIT(10)
> +#define DPHY_CMN_RX_BANDGAP_TIMER	0x14
>  
>  #define DPHY_CMN_PWM			DPHY_PMA_CMN(0x40)
>  #define DPHY_CMN_PWM_DIV(x)		((x) << 20)
> @@ -45,10 +52,27 @@
>  #define DPHY_CMN_OPDIV_FROM_REG		BIT(6)
>  #define DPHY_CMN_OPDIV(x)		((x) << 7)
>  
> +#define DPHY_BAND_CFG			DPHY_PCS(0x0)
> +#define DPHY_BAND_CFG_LEFT_BAND		GENMASK(4, 0)
> +#define DPHY_BAND_CFG_RIGHT_BAND	GENMASK(9, 5)
> +
>  #define DPHY_PSM_CFG			DPHY_PCS(0x4)
>  #define DPHY_PSM_CFG_FROM_REG		BIT(0)
>  #define DPHY_PSM_CLK_DIV(x)		((x) << 1)
>  
> +#define DPHY_POWER_ISLAND_EN_DATA	DPHY_PCS(0x8)
> +#define DPHY_POWER_ISLAND_EN_DATA_VAL	0xaaaaaaaa
> +#define DPHY_POWER_ISLAND_EN_CLK	DPHY_PCS(0xc)
> +#define DPHY_POWER_ISLAND_EN_CLK_VAL	0xaa
> +
> +#define DPHY_ISO_CL_CTRL_L		DPHY_ISO(0x10)
> +#define DPHY_ISO_DL_CTRL_L0		DPHY_ISO(0x14)
> +#define DPHY_ISO_DL_CTRL_L1		DPHY_ISO(0x20)
> +#define DPHY_ISO_DL_CTRL_L2		DPHY_ISO(0x30)
> +#define DPHY_ISO_DL_CTRL_L3		DPHY_ISO(0x3c)
> +#define DPHY_ISO_LANE_READY_BIT		0
> +#define DPHY_ISO_LANE_READY_TIMEOUT_MS	100UL
> +
>  #define DSI_HBP_FRAME_OVERHEAD		12
>  #define DSI_HSA_FRAME_OVERHEAD		14
>  #define DSI_HFP_FRAME_OVERHEAD		6
> @@ -57,6 +81,9 @@
>  #define DSI_NULL_FRAME_OVERHEAD		6
>  #define DSI_EOT_PKT_SIZE		4
>  
> +#define DPHY_LANES_MIN			1
> +#define DPHY_LANES_MAX			4
> +
>  struct cdns_dphy_cfg {
>  	u8 pll_ipdiv;
>  	u8 pll_opdiv;
> @@ -105,6 +132,20 @@ struct cdns_dphy {
>  	struct phy *phy;
>  };
>  
> +struct cdns_dphy_rx_band {
> +	unsigned int min_rate;
> +	unsigned int max_rate;
> +};
> +
> +/* Order of bands is important since the index is the band number. */
> +static const struct cdns_dphy_rx_band bands[] = {
> +	{80, 100}, {100, 120}, {120, 160}, {160, 200}, {200, 240},
> +	{240, 280}, {280, 320}, {320, 360}, {360, 400}, {400, 480},
> +	{480, 560}, {560, 640}, {640, 720}, {720, 800}, {800, 880},
> +	{880, 1040}, {1040, 1200}, {1200, 1350}, {1350, 1500}, {1500, 1750},
> +	{1750, 2000}, {2000, 2250}, {2250, 2500}
> +};
> +
>  static int cdns_dsi_get_dphy_pll_cfg(struct cdns_dphy *dphy,
>  				     struct cdns_dphy_cfg *cfg,
>  				     struct phy_configure_opts_mipi_dphy *opts,
> @@ -360,6 +401,145 @@ static const struct cdns_dphy_info tx_ref_info = {
>  	.tx_ops = &tx_ref_dphy_ops,
>  };
>  
> +static int cdns_dphy_rx_power_on(struct phy *phy)
> +{
> +	struct cdns_dphy *dphy = phy_get_drvdata(phy);
> +
> +	/* Start RX state machine. */
> +	writel(DPHY_CMN_SSM_EN | DPHY_CMN_RX_MODE_EN |
> +	       FIELD_PREP(DPHY_CMN_RX_BANDGAP_TIMER_MASK,
> +			  DPHY_CMN_RX_BANDGAP_TIMER),
> +	       dphy->regs + DPHY_CMN_SSM);
> +
> +	return 0;
> +}
> +
> +static int cdns_dphy_rx_power_off(struct phy *phy)
> +{
> +	struct cdns_dphy *dphy = phy_get_drvdata(phy);
> +
> +	writel(0, dphy->regs + DPHY_CMN_SSM);
> +
> +	return 0;
> +}
> +
> +static int cdns_dphy_rx_get_band_ctrl(unsigned long hs_clk_rate)
> +{
> +	unsigned int rate, i;
> +
> +	rate = hs_clk_rate / 1000000UL;
> +	/* Since CSI-2 clock is DDR, the bit rate is twice the clock rate. */
> +	rate *= 2;
> +
> +	if (rate < bands[0].min_rate)
> +		return -EOPNOTSUPP;
> +
> +	for (i = 0; i < ARRAY_SIZE(bands); i++) {
> +		if (rate < bands[i].max_rate)
> +			return i;
> +	}
> +
> +	return -EOPNOTSUPP;
> +}
> +
> +static int cdns_dphy_rx_wait_for_bit(void __iomem *addr, unsigned int bit)
> +{
> +	u32 val;
> +
> +	return readl_relaxed_poll_timeout(addr, val, val & BIT(bit), 10,
> +					  DPHY_ISO_LANE_READY_TIMEOUT_MS * 1000);
> +}
> +
> +static int cdns_dphy_rx_wait_lane_ready(struct cdns_dphy *dphy,
> +					unsigned int lanes)
> +{
> +	static const u32 data_lane_ctrl[] = {DPHY_ISO_DL_CTRL_L0,
> +					     DPHY_ISO_DL_CTRL_L1,
> +					     DPHY_ISO_DL_CTRL_L2,
> +					     DPHY_ISO_DL_CTRL_L3};
> +	void __iomem *reg = dphy->regs;
> +	unsigned int i;
> +	int ret;
> +
> +	/* Data lanes. Minimum one lane is mandatory. */
> +	if (lanes < DPHY_LANES_MIN || lanes > DPHY_LANES_MAX)
> +		return -EINVAL;
> +
> +	/* Clock lane */
> +	ret = cdns_dphy_rx_wait_for_bit(reg + DPHY_ISO_CL_CTRL_L,
> +					DPHY_ISO_LANE_READY_BIT);
> +	if (ret)
> +		return ret;
> +
> +	for (i = 0; i < lanes; i++) {
> +		ret = cdns_dphy_rx_wait_for_bit(reg + data_lane_ctrl[i],
> +						DPHY_ISO_LANE_READY_BIT);
> +		if (ret)
> +			return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static int cdns_dphy_rx_configure(struct phy *phy,
> +				  union phy_configure_opts *opts)
> +{
> +	struct cdns_dphy *dphy = phy_get_drvdata(phy);
> +	unsigned int reg;
> +	int band_ctrl, ret;
> +
> +	band_ctrl = cdns_dphy_rx_get_band_ctrl(opts->mipi_dphy.hs_clk_rate);
> +	if (band_ctrl < 0)
> +		return band_ctrl;
> +
> +	reg = FIELD_PREP(DPHY_BAND_CFG_LEFT_BAND, band_ctrl) |
> +	      FIELD_PREP(DPHY_BAND_CFG_RIGHT_BAND, band_ctrl);
> +	writel(reg, dphy->regs + DPHY_BAND_CFG);
> +
> +	/*
> +	 * Set the required power island phase 2 time. This is mandated by DPHY
> +	 * specs.
> +	 */
> +	reg = DPHY_POWER_ISLAND_EN_DATA_VAL;
> +	writel(reg, dphy->regs + DPHY_POWER_ISLAND_EN_DATA);
> +	reg = DPHY_POWER_ISLAND_EN_CLK_VAL;
> +	writel(reg, dphy->regs + DPHY_POWER_ISLAND_EN_CLK);
> +
> +	ret = cdns_dphy_rx_wait_lane_ready(dphy, opts->mipi_dphy.lanes);
> +	if (ret) {
> +		dev_err(dphy->dev, "DPHY wait for lane ready timeout\n");
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static int cdns_dphy_rx_validate(struct phy *phy, enum phy_mode mode,
> +				 int submode, union phy_configure_opts *opts)
> +{
> +	int ret;
> +
> +	if (mode != PHY_MODE_MIPI_DPHY)
> +		return -EINVAL;
> +
> +	ret = cdns_dphy_rx_get_band_ctrl(opts->mipi_dphy.hs_clk_rate);
> +	if (ret < 0)
> +		return ret;
> +
> +	return phy_mipi_dphy_config_validate(&opts->mipi_dphy);
> +}
> +
> +static const struct phy_ops rx_ref_phy_ops = {
> +	.power_on = cdns_dphy_rx_power_on,
> +	.power_off = cdns_dphy_rx_power_off,
> +	.configure = cdns_dphy_rx_configure,
> +	.validate = cdns_dphy_rx_validate,
> +};
> +
> +static const struct cdns_dphy_info rx_ref_info = {
> +	.phy_ops = &rx_ref_phy_ops,
> +};
> +
>  static int cdns_dphy_probe(struct platform_device *pdev)
>  {
>  	struct phy_provider *phy_provider;
> @@ -417,6 +597,7 @@ static int cdns_dphy_remove(struct platform_device *pdev)
>  
>  static const struct of_device_id cdns_dphy_of_match[] = {
>  	{ .compatible = "cdns,dphy", .data = &tx_ref_info },
> +	{ .compatible = "cdns,dphy-rx", .data = &rx_ref_info },
>  	{ /* sentinel */ },
>  };
>  MODULE_DEVICE_TABLE(of, cdns_dphy_of_match);
> @@ -432,5 +613,6 @@ static struct platform_driver cdns_dphy_platform_driver = {
>  module_platform_driver(cdns_dphy_platform_driver);
>  
>  MODULE_AUTHOR("Maxime Ripard <maxime.ripard@bootlin.com>");
> +MODULE_AUTHOR("Pratyush Yadav <p.yadav@ti.com>");
>  MODULE_DESCRIPTION("Cadence MIPI D-PHY Driver");
>  MODULE_LICENSE("GPL");
> -- 
> 2.33.0
> 

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v5 2/6] phy: cdns-dphy: Add Rx support

[Paul Kocialkowski]

[-- Attachment #1.1: Type: text/plain, Size: 10465 bytes --]

Hi,

On Fri 03 Sep 21, 00:25, Pratyush Yadav wrote:
> The Cadence DPHY can be used to receive image data over the CSI-2
> protocol. Add support for Rx mode. The programming sequence differs from
> the Tx mode so it is added as a separate set of hooks to isolate the two
> paths. The mode in which the DPHY has to be used is selected based on
> the compatible.

I just realized that I didn't follow-up on a previous revision on the debate
about using the phy sub-mode to distinguish between rx/tx.

I see that you've been using a dedicated compatible, but I'm not sure this is a
good fit either. My understanding is that the compatible should describe a group
of register-compatible revisions of a hardware component, not how the hardware
is used specifically. I guess the distinction between rx/tx falls under
the latter rather than the former.

I just sent out a patch in my Allwinner MIPI CSI-2+ISP series adding
a specific direction property:
- https://lists.infradead.org/pipermail/linux-phy/2021-September/001420.html
- https://lists.infradead.org/pipermail/linux-phy/2021-September/001421.html

Which I feel is a more appropriate solution to implement the distinction.

What do you think?

Cheers,

Paul
 
> Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
> 
> ---
> 
> Changes in v5:
> - Use the new cdns_dphy_info to specify PHY ops.
> - Re-order include in alphabetical order.
> - Make bands const.
> - Drop num_bands.
> - Make i, lanes unsigned.
> - Drop the maximum check in cdns_dphy_rx_get_band_ctrl(). Let the loop
>   complete and return -EOPNOTSUPP when we reach the end.
> - Drop the "rate < bands[i].min_rate" check since the bands are in
>   ascending order.
> - Move data_lane_ctrl to start of function and make it static const.
> 
> Changes in v4:
> - Drop the submode parts. Use a different compatible for the Rx ops.
> - Make bands and num_bands static.
> 
> Changes in v3:
> - Use a table to select the band.
> - Use a table to poll the data lane ready bits.
> - Multiply the DPHY HS clock rate by 2 to get the bit rate since the
>   clock is DDR.
> 
>  drivers/phy/cadence/cdns-dphy.c | 182 ++++++++++++++++++++++++++++++++
>  1 file changed, 182 insertions(+)
> 
> diff --git a/drivers/phy/cadence/cdns-dphy.c b/drivers/phy/cadence/cdns-dphy.c
> index e2c2b27c6539..9a4c1c684e9a 100644
> --- a/drivers/phy/cadence/cdns-dphy.c
> +++ b/drivers/phy/cadence/cdns-dphy.c
> @@ -1,11 +1,14 @@
>  // SPDX-License-Identifier: GPL-2.0+
>  /*
>   * Copyright: 2017-2018 Cadence Design Systems, Inc.
> + * Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com/
>   */
>  
> +#include <linux/bitfield.h>
>  #include <linux/bitops.h>
>  #include <linux/clk.h>
>  #include <linux/io.h>
> +#include <linux/iopoll.h>
>  #include <linux/module.h>
>  #include <linux/of_address.h>
>  #include <linux/of_device.h>
> @@ -25,10 +28,14 @@
>  #define DPHY_PMA_RCLK(reg)		(0x600 + (reg))
>  #define DPHY_PMA_RDATA(lane, reg)	(0x700 + ((lane) * 0x100) + (reg))
>  #define DPHY_PCS(reg)			(0xb00 + (reg))
> +#define DPHY_ISO(reg)			(0xc00 + (reg))
>  
>  #define DPHY_CMN_SSM			DPHY_PMA_CMN(0x20)
>  #define DPHY_CMN_SSM_EN			BIT(0)
> +#define DPHY_CMN_RX_BANDGAP_TIMER_MASK	GENMASK(8, 1)
>  #define DPHY_CMN_TX_MODE_EN		BIT(9)
> +#define DPHY_CMN_RX_MODE_EN		BIT(10)
> +#define DPHY_CMN_RX_BANDGAP_TIMER	0x14
>  
>  #define DPHY_CMN_PWM			DPHY_PMA_CMN(0x40)
>  #define DPHY_CMN_PWM_DIV(x)		((x) << 20)
> @@ -45,10 +52,27 @@
>  #define DPHY_CMN_OPDIV_FROM_REG		BIT(6)
>  #define DPHY_CMN_OPDIV(x)		((x) << 7)
>  
> +#define DPHY_BAND_CFG			DPHY_PCS(0x0)
> +#define DPHY_BAND_CFG_LEFT_BAND		GENMASK(4, 0)
> +#define DPHY_BAND_CFG_RIGHT_BAND	GENMASK(9, 5)
> +
>  #define DPHY_PSM_CFG			DPHY_PCS(0x4)
>  #define DPHY_PSM_CFG_FROM_REG		BIT(0)
>  #define DPHY_PSM_CLK_DIV(x)		((x) << 1)
>  
> +#define DPHY_POWER_ISLAND_EN_DATA	DPHY_PCS(0x8)
> +#define DPHY_POWER_ISLAND_EN_DATA_VAL	0xaaaaaaaa
> +#define DPHY_POWER_ISLAND_EN_CLK	DPHY_PCS(0xc)
> +#define DPHY_POWER_ISLAND_EN_CLK_VAL	0xaa
> +
> +#define DPHY_ISO_CL_CTRL_L		DPHY_ISO(0x10)
> +#define DPHY_ISO_DL_CTRL_L0		DPHY_ISO(0x14)
> +#define DPHY_ISO_DL_CTRL_L1		DPHY_ISO(0x20)
> +#define DPHY_ISO_DL_CTRL_L2		DPHY_ISO(0x30)
> +#define DPHY_ISO_DL_CTRL_L3		DPHY_ISO(0x3c)
> +#define DPHY_ISO_LANE_READY_BIT		0
> +#define DPHY_ISO_LANE_READY_TIMEOUT_MS	100UL
> +
>  #define DSI_HBP_FRAME_OVERHEAD		12
>  #define DSI_HSA_FRAME_OVERHEAD		14
>  #define DSI_HFP_FRAME_OVERHEAD		6
> @@ -57,6 +81,9 @@
>  #define DSI_NULL_FRAME_OVERHEAD		6
>  #define DSI_EOT_PKT_SIZE		4
>  
> +#define DPHY_LANES_MIN			1
> +#define DPHY_LANES_MAX			4
> +
>  struct cdns_dphy_cfg {
>  	u8 pll_ipdiv;
>  	u8 pll_opdiv;
> @@ -105,6 +132,20 @@ struct cdns_dphy {
>  	struct phy *phy;
>  };
>  
> +struct cdns_dphy_rx_band {
> +	unsigned int min_rate;
> +	unsigned int max_rate;
> +};
> +
> +/* Order of bands is important since the index is the band number. */
> +static const struct cdns_dphy_rx_band bands[] = {
> +	{80, 100}, {100, 120}, {120, 160}, {160, 200}, {200, 240},
> +	{240, 280}, {280, 320}, {320, 360}, {360, 400}, {400, 480},
> +	{480, 560}, {560, 640}, {640, 720}, {720, 800}, {800, 880},
> +	{880, 1040}, {1040, 1200}, {1200, 1350}, {1350, 1500}, {1500, 1750},
> +	{1750, 2000}, {2000, 2250}, {2250, 2500}
> +};
> +
>  static int cdns_dsi_get_dphy_pll_cfg(struct cdns_dphy *dphy,
>  				     struct cdns_dphy_cfg *cfg,
>  				     struct phy_configure_opts_mipi_dphy *opts,
> @@ -360,6 +401,145 @@ static const struct cdns_dphy_info tx_ref_info = {
>  	.tx_ops = &tx_ref_dphy_ops,
>  };
>  
> +static int cdns_dphy_rx_power_on(struct phy *phy)
> +{
> +	struct cdns_dphy *dphy = phy_get_drvdata(phy);
> +
> +	/* Start RX state machine. */
> +	writel(DPHY_CMN_SSM_EN | DPHY_CMN_RX_MODE_EN |
> +	       FIELD_PREP(DPHY_CMN_RX_BANDGAP_TIMER_MASK,
> +			  DPHY_CMN_RX_BANDGAP_TIMER),
> +	       dphy->regs + DPHY_CMN_SSM);
> +
> +	return 0;
> +}
> +
> +static int cdns_dphy_rx_power_off(struct phy *phy)
> +{
> +	struct cdns_dphy *dphy = phy_get_drvdata(phy);
> +
> +	writel(0, dphy->regs + DPHY_CMN_SSM);
> +
> +	return 0;
> +}
> +
> +static int cdns_dphy_rx_get_band_ctrl(unsigned long hs_clk_rate)
> +{
> +	unsigned int rate, i;
> +
> +	rate = hs_clk_rate / 1000000UL;
> +	/* Since CSI-2 clock is DDR, the bit rate is twice the clock rate. */
> +	rate *= 2;
> +
> +	if (rate < bands[0].min_rate)
> +		return -EOPNOTSUPP;
> +
> +	for (i = 0; i < ARRAY_SIZE(bands); i++) {
> +		if (rate < bands[i].max_rate)
> +			return i;
> +	}
> +
> +	return -EOPNOTSUPP;
> +}
> +
> +static int cdns_dphy_rx_wait_for_bit(void __iomem *addr, unsigned int bit)
> +{
> +	u32 val;
> +
> +	return readl_relaxed_poll_timeout(addr, val, val & BIT(bit), 10,
> +					  DPHY_ISO_LANE_READY_TIMEOUT_MS * 1000);
> +}
> +
> +static int cdns_dphy_rx_wait_lane_ready(struct cdns_dphy *dphy,
> +					unsigned int lanes)
> +{
> +	static const u32 data_lane_ctrl[] = {DPHY_ISO_DL_CTRL_L0,
> +					     DPHY_ISO_DL_CTRL_L1,
> +					     DPHY_ISO_DL_CTRL_L2,
> +					     DPHY_ISO_DL_CTRL_L3};
> +	void __iomem *reg = dphy->regs;
> +	unsigned int i;
> +	int ret;
> +
> +	/* Data lanes. Minimum one lane is mandatory. */
> +	if (lanes < DPHY_LANES_MIN || lanes > DPHY_LANES_MAX)
> +		return -EINVAL;
> +
> +	/* Clock lane */
> +	ret = cdns_dphy_rx_wait_for_bit(reg + DPHY_ISO_CL_CTRL_L,
> +					DPHY_ISO_LANE_READY_BIT);
> +	if (ret)
> +		return ret;
> +
> +	for (i = 0; i < lanes; i++) {
> +		ret = cdns_dphy_rx_wait_for_bit(reg + data_lane_ctrl[i],
> +						DPHY_ISO_LANE_READY_BIT);
> +		if (ret)
> +			return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static int cdns_dphy_rx_configure(struct phy *phy,
> +				  union phy_configure_opts *opts)
> +{
> +	struct cdns_dphy *dphy = phy_get_drvdata(phy);
> +	unsigned int reg;
> +	int band_ctrl, ret;
> +
> +	band_ctrl = cdns_dphy_rx_get_band_ctrl(opts->mipi_dphy.hs_clk_rate);
> +	if (band_ctrl < 0)
> +		return band_ctrl;
> +
> +	reg = FIELD_PREP(DPHY_BAND_CFG_LEFT_BAND, band_ctrl) |
> +	      FIELD_PREP(DPHY_BAND_CFG_RIGHT_BAND, band_ctrl);
> +	writel(reg, dphy->regs + DPHY_BAND_CFG);
> +
> +	/*
> +	 * Set the required power island phase 2 time. This is mandated by DPHY
> +	 * specs.
> +	 */
> +	reg = DPHY_POWER_ISLAND_EN_DATA_VAL;
> +	writel(reg, dphy->regs + DPHY_POWER_ISLAND_EN_DATA);
> +	reg = DPHY_POWER_ISLAND_EN_CLK_VAL;
> +	writel(reg, dphy->regs + DPHY_POWER_ISLAND_EN_CLK);
> +
> +	ret = cdns_dphy_rx_wait_lane_ready(dphy, opts->mipi_dphy.lanes);
> +	if (ret) {
> +		dev_err(dphy->dev, "DPHY wait for lane ready timeout\n");
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static int cdns_dphy_rx_validate(struct phy *phy, enum phy_mode mode,
> +				 int submode, union phy_configure_opts *opts)
> +{
> +	int ret;
> +
> +	if (mode != PHY_MODE_MIPI_DPHY)
> +		return -EINVAL;
> +
> +	ret = cdns_dphy_rx_get_band_ctrl(opts->mipi_dphy.hs_clk_rate);
> +	if (ret < 0)
> +		return ret;
> +
> +	return phy_mipi_dphy_config_validate(&opts->mipi_dphy);
> +}
> +
> +static const struct phy_ops rx_ref_phy_ops = {
> +	.power_on = cdns_dphy_rx_power_on,
> +	.power_off = cdns_dphy_rx_power_off,
> +	.configure = cdns_dphy_rx_configure,
> +	.validate = cdns_dphy_rx_validate,
> +};
> +
> +static const struct cdns_dphy_info rx_ref_info = {
> +	.phy_ops = &rx_ref_phy_ops,
> +};
> +
>  static int cdns_dphy_probe(struct platform_device *pdev)
>  {
>  	struct phy_provider *phy_provider;
> @@ -417,6 +597,7 @@ static int cdns_dphy_remove(struct platform_device *pdev)
>  
>  static const struct of_device_id cdns_dphy_of_match[] = {
>  	{ .compatible = "cdns,dphy", .data = &tx_ref_info },
> +	{ .compatible = "cdns,dphy-rx", .data = &rx_ref_info },
>  	{ /* sentinel */ },
>  };
>  MODULE_DEVICE_TABLE(of, cdns_dphy_of_match);
> @@ -432,5 +613,6 @@ static struct platform_driver cdns_dphy_platform_driver = {
>  module_platform_driver(cdns_dphy_platform_driver);
>  
>  MODULE_AUTHOR("Maxime Ripard <maxime.ripard@bootlin.com>");
> +MODULE_AUTHOR("Pratyush Yadav <p.yadav@ti.com>");
>  MODULE_DESCRIPTION("Cadence MIPI D-PHY Driver");
>  MODULE_LICENSE("GPL");
> -- 
> 2.33.0
> 

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 112 bytes --]

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v5 2/6] phy: cdns-dphy: Add Rx support

[Pratyush Yadav]

+Rob

On 16/09/21 12:22PM, Paul Kocialkowski wrote:
> Hi,
> 
> On Fri 03 Sep 21, 00:25, Pratyush Yadav wrote:
> > The Cadence DPHY can be used to receive image data over the CSI-2
> > protocol. Add support for Rx mode. The programming sequence differs from
> > the Tx mode so it is added as a separate set of hooks to isolate the two
> > paths. The mode in which the DPHY has to be used is selected based on
> > the compatible.
> 
> I just realized that I didn't follow-up on a previous revision on the debate
> about using the phy sub-mode to distinguish between rx/tx.
> 
> I see that you've been using a dedicated compatible, but I'm not sure this is a
> good fit either. My understanding is that the compatible should describe a group
> of register-compatible revisions of a hardware component, not how the hardware
> is used specifically. I guess the distinction between rx/tx falls under
> the latter rather than the former.

I am not sure if that is the case. For example, we use "ti,am654-ospi" 
for Cadence Quadspi controller. The default compatible, "cdns,qspi-nor", 
only supports Quad SPI (4 lines). The "ti,am654-ospi" compatible also 
supports Octal SPI (8 lines).

In addition, I feel like the Rx DPHY is almost a different type of 
device from a Tx DPHY. The programming sequence is completely different, 
the clocks required are different, etc. So I think using a different 
compatible for Rx mode makes sense.

Rob, what do you think?

> 
> I just sent out a patch in my Allwinner MIPI CSI-2+ISP series adding
> a specific direction property:
> - https://lists.infradead.org/pipermail/linux-phy/2021-September/001420.html
> - https://lists.infradead.org/pipermail/linux-phy/2021-September/001421.html
> 
> Which I feel is a more appropriate solution to implement the distinction.
> 
> What do you think?
> 
> Cheers,
> 
> Paul
>  
> > Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
> > 
> > ---
> > 
> > Changes in v5:
> > - Use the new cdns_dphy_info to specify PHY ops.
> > - Re-order include in alphabetical order.
> > - Make bands const.
> > - Drop num_bands.
> > - Make i, lanes unsigned.
> > - Drop the maximum check in cdns_dphy_rx_get_band_ctrl(). Let the loop
> >   complete and return -EOPNOTSUPP when we reach the end.
> > - Drop the "rate < bands[i].min_rate" check since the bands are in
> >   ascending order.
> > - Move data_lane_ctrl to start of function and make it static const.
> > 
> > Changes in v4:
> > - Drop the submode parts. Use a different compatible for the Rx ops.
> > - Make bands and num_bands static.
> > 
> > Changes in v3:
> > - Use a table to select the band.
> > - Use a table to poll the data lane ready bits.
> > - Multiply the DPHY HS clock rate by 2 to get the bit rate since the
> >   clock is DDR.
> > 
> >  drivers/phy/cadence/cdns-dphy.c | 182 ++++++++++++++++++++++++++++++++
> >  1 file changed, 182 insertions(+)
> > 
> > diff --git a/drivers/phy/cadence/cdns-dphy.c b/drivers/phy/cadence/cdns-dphy.c
> > index e2c2b27c6539..9a4c1c684e9a 100644
> > --- a/drivers/phy/cadence/cdns-dphy.c
> > +++ b/drivers/phy/cadence/cdns-dphy.c
> > @@ -1,11 +1,14 @@
> >  // SPDX-License-Identifier: GPL-2.0+
> >  /*
> >   * Copyright: 2017-2018 Cadence Design Systems, Inc.
> > + * Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com/
> >   */
> >  
> > +#include <linux/bitfield.h>
> >  #include <linux/bitops.h>
> >  #include <linux/clk.h>
> >  #include <linux/io.h>
> > +#include <linux/iopoll.h>
> >  #include <linux/module.h>
> >  #include <linux/of_address.h>
> >  #include <linux/of_device.h>
> > @@ -25,10 +28,14 @@
> >  #define DPHY_PMA_RCLK(reg)		(0x600 + (reg))
> >  #define DPHY_PMA_RDATA(lane, reg)	(0x700 + ((lane) * 0x100) + (reg))
> >  #define DPHY_PCS(reg)			(0xb00 + (reg))
> > +#define DPHY_ISO(reg)			(0xc00 + (reg))
> >  
> >  #define DPHY_CMN_SSM			DPHY_PMA_CMN(0x20)
> >  #define DPHY_CMN_SSM_EN			BIT(0)
> > +#define DPHY_CMN_RX_BANDGAP_TIMER_MASK	GENMASK(8, 1)
> >  #define DPHY_CMN_TX_MODE_EN		BIT(9)
> > +#define DPHY_CMN_RX_MODE_EN		BIT(10)
> > +#define DPHY_CMN_RX_BANDGAP_TIMER	0x14
> >  
> >  #define DPHY_CMN_PWM			DPHY_PMA_CMN(0x40)
> >  #define DPHY_CMN_PWM_DIV(x)		((x) << 20)
> > @@ -45,10 +52,27 @@
> >  #define DPHY_CMN_OPDIV_FROM_REG		BIT(6)
> >  #define DPHY_CMN_OPDIV(x)		((x) << 7)
> >  
> > +#define DPHY_BAND_CFG			DPHY_PCS(0x0)
> > +#define DPHY_BAND_CFG_LEFT_BAND		GENMASK(4, 0)
> > +#define DPHY_BAND_CFG_RIGHT_BAND	GENMASK(9, 5)
> > +
> >  #define DPHY_PSM_CFG			DPHY_PCS(0x4)
> >  #define DPHY_PSM_CFG_FROM_REG		BIT(0)
> >  #define DPHY_PSM_CLK_DIV(x)		((x) << 1)
> >  
> > +#define DPHY_POWER_ISLAND_EN_DATA	DPHY_PCS(0x8)
> > +#define DPHY_POWER_ISLAND_EN_DATA_VAL	0xaaaaaaaa
> > +#define DPHY_POWER_ISLAND_EN_CLK	DPHY_PCS(0xc)
> > +#define DPHY_POWER_ISLAND_EN_CLK_VAL	0xaa
> > +
> > +#define DPHY_ISO_CL_CTRL_L		DPHY_ISO(0x10)
> > +#define DPHY_ISO_DL_CTRL_L0		DPHY_ISO(0x14)
> > +#define DPHY_ISO_DL_CTRL_L1		DPHY_ISO(0x20)
> > +#define DPHY_ISO_DL_CTRL_L2		DPHY_ISO(0x30)
> > +#define DPHY_ISO_DL_CTRL_L3		DPHY_ISO(0x3c)
> > +#define DPHY_ISO_LANE_READY_BIT		0
> > +#define DPHY_ISO_LANE_READY_TIMEOUT_MS	100UL
> > +
> >  #define DSI_HBP_FRAME_OVERHEAD		12
> >  #define DSI_HSA_FRAME_OVERHEAD		14
> >  #define DSI_HFP_FRAME_OVERHEAD		6
> > @@ -57,6 +81,9 @@
> >  #define DSI_NULL_FRAME_OVERHEAD		6
> >  #define DSI_EOT_PKT_SIZE		4
> >  
> > +#define DPHY_LANES_MIN			1
> > +#define DPHY_LANES_MAX			4
> > +
> >  struct cdns_dphy_cfg {
> >  	u8 pll_ipdiv;
> >  	u8 pll_opdiv;
> > @@ -105,6 +132,20 @@ struct cdns_dphy {
> >  	struct phy *phy;
> >  };
> >  
> > +struct cdns_dphy_rx_band {
> > +	unsigned int min_rate;
> > +	unsigned int max_rate;
> > +};
> > +
> > +/* Order of bands is important since the index is the band number. */
> > +static const struct cdns_dphy_rx_band bands[] = {
> > +	{80, 100}, {100, 120}, {120, 160}, {160, 200}, {200, 240},
> > +	{240, 280}, {280, 320}, {320, 360}, {360, 400}, {400, 480},
> > +	{480, 560}, {560, 640}, {640, 720}, {720, 800}, {800, 880},
> > +	{880, 1040}, {1040, 1200}, {1200, 1350}, {1350, 1500}, {1500, 1750},
> > +	{1750, 2000}, {2000, 2250}, {2250, 2500}
> > +};
> > +
> >  static int cdns_dsi_get_dphy_pll_cfg(struct cdns_dphy *dphy,
> >  				     struct cdns_dphy_cfg *cfg,
> >  				     struct phy_configure_opts_mipi_dphy *opts,
> > @@ -360,6 +401,145 @@ static const struct cdns_dphy_info tx_ref_info = {
> >  	.tx_ops = &tx_ref_dphy_ops,
> >  };
> >  
> > +static int cdns_dphy_rx_power_on(struct phy *phy)
> > +{
> > +	struct cdns_dphy *dphy = phy_get_drvdata(phy);
> > +
> > +	/* Start RX state machine. */
> > +	writel(DPHY_CMN_SSM_EN | DPHY_CMN_RX_MODE_EN |
> > +	       FIELD_PREP(DPHY_CMN_RX_BANDGAP_TIMER_MASK,
> > +			  DPHY_CMN_RX_BANDGAP_TIMER),
> > +	       dphy->regs + DPHY_CMN_SSM);
> > +
> > +	return 0;
> > +}
> > +
> > +static int cdns_dphy_rx_power_off(struct phy *phy)
> > +{
> > +	struct cdns_dphy *dphy = phy_get_drvdata(phy);
> > +
> > +	writel(0, dphy->regs + DPHY_CMN_SSM);
> > +
> > +	return 0;
> > +}
> > +
> > +static int cdns_dphy_rx_get_band_ctrl(unsigned long hs_clk_rate)
> > +{
> > +	unsigned int rate, i;
> > +
> > +	rate = hs_clk_rate / 1000000UL;
> > +	/* Since CSI-2 clock is DDR, the bit rate is twice the clock rate. */
> > +	rate *= 2;
> > +
> > +	if (rate < bands[0].min_rate)
> > +		return -EOPNOTSUPP;
> > +
> > +	for (i = 0; i < ARRAY_SIZE(bands); i++) {
> > +		if (rate < bands[i].max_rate)
> > +			return i;
> > +	}
> > +
> > +	return -EOPNOTSUPP;
> > +}
> > +
> > +static int cdns_dphy_rx_wait_for_bit(void __iomem *addr, unsigned int bit)
> > +{
> > +	u32 val;
> > +
> > +	return readl_relaxed_poll_timeout(addr, val, val & BIT(bit), 10,
> > +					  DPHY_ISO_LANE_READY_TIMEOUT_MS * 1000);
> > +}
> > +
> > +static int cdns_dphy_rx_wait_lane_ready(struct cdns_dphy *dphy,
> > +					unsigned int lanes)
> > +{
> > +	static const u32 data_lane_ctrl[] = {DPHY_ISO_DL_CTRL_L0,
> > +					     DPHY_ISO_DL_CTRL_L1,
> > +					     DPHY_ISO_DL_CTRL_L2,
> > +					     DPHY_ISO_DL_CTRL_L3};
> > +	void __iomem *reg = dphy->regs;
> > +	unsigned int i;
> > +	int ret;
> > +
> > +	/* Data lanes. Minimum one lane is mandatory. */
> > +	if (lanes < DPHY_LANES_MIN || lanes > DPHY_LANES_MAX)
> > +		return -EINVAL;
> > +
> > +	/* Clock lane */
> > +	ret = cdns_dphy_rx_wait_for_bit(reg + DPHY_ISO_CL_CTRL_L,
> > +					DPHY_ISO_LANE_READY_BIT);
> > +	if (ret)
> > +		return ret;
> > +
> > +	for (i = 0; i < lanes; i++) {
> > +		ret = cdns_dphy_rx_wait_for_bit(reg + data_lane_ctrl[i],
> > +						DPHY_ISO_LANE_READY_BIT);
> > +		if (ret)
> > +			return ret;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +static int cdns_dphy_rx_configure(struct phy *phy,
> > +				  union phy_configure_opts *opts)
> > +{
> > +	struct cdns_dphy *dphy = phy_get_drvdata(phy);
> > +	unsigned int reg;
> > +	int band_ctrl, ret;
> > +
> > +	band_ctrl = cdns_dphy_rx_get_band_ctrl(opts->mipi_dphy.hs_clk_rate);
> > +	if (band_ctrl < 0)
> > +		return band_ctrl;
> > +
> > +	reg = FIELD_PREP(DPHY_BAND_CFG_LEFT_BAND, band_ctrl) |
> > +	      FIELD_PREP(DPHY_BAND_CFG_RIGHT_BAND, band_ctrl);
> > +	writel(reg, dphy->regs + DPHY_BAND_CFG);
> > +
> > +	/*
> > +	 * Set the required power island phase 2 time. This is mandated by DPHY
> > +	 * specs.
> > +	 */
> > +	reg = DPHY_POWER_ISLAND_EN_DATA_VAL;
> > +	writel(reg, dphy->regs + DPHY_POWER_ISLAND_EN_DATA);
> > +	reg = DPHY_POWER_ISLAND_EN_CLK_VAL;
> > +	writel(reg, dphy->regs + DPHY_POWER_ISLAND_EN_CLK);
> > +
> > +	ret = cdns_dphy_rx_wait_lane_ready(dphy, opts->mipi_dphy.lanes);
> > +	if (ret) {
> > +		dev_err(dphy->dev, "DPHY wait for lane ready timeout\n");
> > +		return ret;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +static int cdns_dphy_rx_validate(struct phy *phy, enum phy_mode mode,
> > +				 int submode, union phy_configure_opts *opts)
> > +{
> > +	int ret;
> > +
> > +	if (mode != PHY_MODE_MIPI_DPHY)
> > +		return -EINVAL;
> > +
> > +	ret = cdns_dphy_rx_get_band_ctrl(opts->mipi_dphy.hs_clk_rate);
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	return phy_mipi_dphy_config_validate(&opts->mipi_dphy);
> > +}
> > +
> > +static const struct phy_ops rx_ref_phy_ops = {
> > +	.power_on = cdns_dphy_rx_power_on,
> > +	.power_off = cdns_dphy_rx_power_off,
> > +	.configure = cdns_dphy_rx_configure,
> > +	.validate = cdns_dphy_rx_validate,
> > +};
> > +
> > +static const struct cdns_dphy_info rx_ref_info = {
> > +	.phy_ops = &rx_ref_phy_ops,
> > +};
> > +
> >  static int cdns_dphy_probe(struct platform_device *pdev)
> >  {
> >  	struct phy_provider *phy_provider;
> > @@ -417,6 +597,7 @@ static int cdns_dphy_remove(struct platform_device *pdev)
> >  
> >  static const struct of_device_id cdns_dphy_of_match[] = {
> >  	{ .compatible = "cdns,dphy", .data = &tx_ref_info },
> > +	{ .compatible = "cdns,dphy-rx", .data = &rx_ref_info },
> >  	{ /* sentinel */ },
> >  };
> >  MODULE_DEVICE_TABLE(of, cdns_dphy_of_match);
> > @@ -432,5 +613,6 @@ static struct platform_driver cdns_dphy_platform_driver = {
> >  module_platform_driver(cdns_dphy_platform_driver);
> >  
> >  MODULE_AUTHOR("Maxime Ripard <maxime.ripard@bootlin.com>");
> > +MODULE_AUTHOR("Pratyush Yadav <p.yadav@ti.com>");
> >  MODULE_DESCRIPTION("Cadence MIPI D-PHY Driver");
> >  MODULE_LICENSE("GPL");
> > -- 
> > 2.33.0
> > 
> 
> -- 
> Paul Kocialkowski, Bootlin
> Embedded Linux and kernel engineering
> https://bootlin.com



-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.

Re: [PATCH v5 2/6] phy: cdns-dphy: Add Rx support

[Pratyush Yadav]

+Rob

On 16/09/21 12:22PM, Paul Kocialkowski wrote:
> Hi,
> 
> On Fri 03 Sep 21, 00:25, Pratyush Yadav wrote:
> > The Cadence DPHY can be used to receive image data over the CSI-2
> > protocol. Add support for Rx mode. The programming sequence differs from
> > the Tx mode so it is added as a separate set of hooks to isolate the two
> > paths. The mode in which the DPHY has to be used is selected based on
> > the compatible.
> 
> I just realized that I didn't follow-up on a previous revision on the debate
> about using the phy sub-mode to distinguish between rx/tx.
> 
> I see that you've been using a dedicated compatible, but I'm not sure this is a
> good fit either. My understanding is that the compatible should describe a group
> of register-compatible revisions of a hardware component, not how the hardware
> is used specifically. I guess the distinction between rx/tx falls under
> the latter rather than the former.

I am not sure if that is the case. For example, we use "ti,am654-ospi" 
for Cadence Quadspi controller. The default compatible, "cdns,qspi-nor", 
only supports Quad SPI (4 lines). The "ti,am654-ospi" compatible also 
supports Octal SPI (8 lines).

In addition, I feel like the Rx DPHY is almost a different type of 
device from a Tx DPHY. The programming sequence is completely different, 
the clocks required are different, etc. So I think using a different 
compatible for Rx mode makes sense.

Rob, what do you think?

> 
> I just sent out a patch in my Allwinner MIPI CSI-2+ISP series adding
> a specific direction property:
> - https://lists.infradead.org/pipermail/linux-phy/2021-September/001420.html
> - https://lists.infradead.org/pipermail/linux-phy/2021-September/001421.html
> 
> Which I feel is a more appropriate solution to implement the distinction.
> 
> What do you think?
> 
> Cheers,
> 
> Paul
>  
> > Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
> > 
> > ---
> > 
> > Changes in v5:
> > - Use the new cdns_dphy_info to specify PHY ops.
> > - Re-order include in alphabetical order.
> > - Make bands const.
> > - Drop num_bands.
> > - Make i, lanes unsigned.
> > - Drop the maximum check in cdns_dphy_rx_get_band_ctrl(). Let the loop
> >   complete and return -EOPNOTSUPP when we reach the end.
> > - Drop the "rate < bands[i].min_rate" check since the bands are in
> >   ascending order.
> > - Move data_lane_ctrl to start of function and make it static const.
> > 
> > Changes in v4:
> > - Drop the submode parts. Use a different compatible for the Rx ops.
> > - Make bands and num_bands static.
> > 
> > Changes in v3:
> > - Use a table to select the band.
> > - Use a table to poll the data lane ready bits.
> > - Multiply the DPHY HS clock rate by 2 to get the bit rate since the
> >   clock is DDR.
> > 
> >  drivers/phy/cadence/cdns-dphy.c | 182 ++++++++++++++++++++++++++++++++
> >  1 file changed, 182 insertions(+)
> > 
> > diff --git a/drivers/phy/cadence/cdns-dphy.c b/drivers/phy/cadence/cdns-dphy.c
> > index e2c2b27c6539..9a4c1c684e9a 100644
> > --- a/drivers/phy/cadence/cdns-dphy.c
> > +++ b/drivers/phy/cadence/cdns-dphy.c
> > @@ -1,11 +1,14 @@
> >  // SPDX-License-Identifier: GPL-2.0+
> >  /*
> >   * Copyright: 2017-2018 Cadence Design Systems, Inc.
> > + * Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com/
> >   */
> >  
> > +#include <linux/bitfield.h>
> >  #include <linux/bitops.h>
> >  #include <linux/clk.h>
> >  #include <linux/io.h>
> > +#include <linux/iopoll.h>
> >  #include <linux/module.h>
> >  #include <linux/of_address.h>
> >  #include <linux/of_device.h>
> > @@ -25,10 +28,14 @@
> >  #define DPHY_PMA_RCLK(reg)		(0x600 + (reg))
> >  #define DPHY_PMA_RDATA(lane, reg)	(0x700 + ((lane) * 0x100) + (reg))
> >  #define DPHY_PCS(reg)			(0xb00 + (reg))
> > +#define DPHY_ISO(reg)			(0xc00 + (reg))
> >  
> >  #define DPHY_CMN_SSM			DPHY_PMA_CMN(0x20)
> >  #define DPHY_CMN_SSM_EN			BIT(0)
> > +#define DPHY_CMN_RX_BANDGAP_TIMER_MASK	GENMASK(8, 1)
> >  #define DPHY_CMN_TX_MODE_EN		BIT(9)
> > +#define DPHY_CMN_RX_MODE_EN		BIT(10)
> > +#define DPHY_CMN_RX_BANDGAP_TIMER	0x14
> >  
> >  #define DPHY_CMN_PWM			DPHY_PMA_CMN(0x40)
> >  #define DPHY_CMN_PWM_DIV(x)		((x) << 20)
> > @@ -45,10 +52,27 @@
> >  #define DPHY_CMN_OPDIV_FROM_REG		BIT(6)
> >  #define DPHY_CMN_OPDIV(x)		((x) << 7)
> >  
> > +#define DPHY_BAND_CFG			DPHY_PCS(0x0)
> > +#define DPHY_BAND_CFG_LEFT_BAND		GENMASK(4, 0)
> > +#define DPHY_BAND_CFG_RIGHT_BAND	GENMASK(9, 5)
> > +
> >  #define DPHY_PSM_CFG			DPHY_PCS(0x4)
> >  #define DPHY_PSM_CFG_FROM_REG		BIT(0)
> >  #define DPHY_PSM_CLK_DIV(x)		((x) << 1)
> >  
> > +#define DPHY_POWER_ISLAND_EN_DATA	DPHY_PCS(0x8)
> > +#define DPHY_POWER_ISLAND_EN_DATA_VAL	0xaaaaaaaa
> > +#define DPHY_POWER_ISLAND_EN_CLK	DPHY_PCS(0xc)
> > +#define DPHY_POWER_ISLAND_EN_CLK_VAL	0xaa
> > +
> > +#define DPHY_ISO_CL_CTRL_L		DPHY_ISO(0x10)
> > +#define DPHY_ISO_DL_CTRL_L0		DPHY_ISO(0x14)
> > +#define DPHY_ISO_DL_CTRL_L1		DPHY_ISO(0x20)
> > +#define DPHY_ISO_DL_CTRL_L2		DPHY_ISO(0x30)
> > +#define DPHY_ISO_DL_CTRL_L3		DPHY_ISO(0x3c)
> > +#define DPHY_ISO_LANE_READY_BIT		0
> > +#define DPHY_ISO_LANE_READY_TIMEOUT_MS	100UL
> > +
> >  #define DSI_HBP_FRAME_OVERHEAD		12
> >  #define DSI_HSA_FRAME_OVERHEAD		14
> >  #define DSI_HFP_FRAME_OVERHEAD		6
> > @@ -57,6 +81,9 @@
> >  #define DSI_NULL_FRAME_OVERHEAD		6
> >  #define DSI_EOT_PKT_SIZE		4
> >  
> > +#define DPHY_LANES_MIN			1
> > +#define DPHY_LANES_MAX			4
> > +
> >  struct cdns_dphy_cfg {
> >  	u8 pll_ipdiv;
> >  	u8 pll_opdiv;
> > @@ -105,6 +132,20 @@ struct cdns_dphy {
> >  	struct phy *phy;
> >  };
> >  
> > +struct cdns_dphy_rx_band {
> > +	unsigned int min_rate;
> > +	unsigned int max_rate;
> > +};
> > +
> > +/* Order of bands is important since the index is the band number. */
> > +static const struct cdns_dphy_rx_band bands[] = {
> > +	{80, 100}, {100, 120}, {120, 160}, {160, 200}, {200, 240},
> > +	{240, 280}, {280, 320}, {320, 360}, {360, 400}, {400, 480},
> > +	{480, 560}, {560, 640}, {640, 720}, {720, 800}, {800, 880},
> > +	{880, 1040}, {1040, 1200}, {1200, 1350}, {1350, 1500}, {1500, 1750},
> > +	{1750, 2000}, {2000, 2250}, {2250, 2500}
> > +};
> > +
> >  static int cdns_dsi_get_dphy_pll_cfg(struct cdns_dphy *dphy,
> >  				     struct cdns_dphy_cfg *cfg,
> >  				     struct phy_configure_opts_mipi_dphy *opts,
> > @@ -360,6 +401,145 @@ static const struct cdns_dphy_info tx_ref_info = {
> >  	.tx_ops = &tx_ref_dphy_ops,
> >  };
> >  
> > +static int cdns_dphy_rx_power_on(struct phy *phy)
> > +{
> > +	struct cdns_dphy *dphy = phy_get_drvdata(phy);
> > +
> > +	/* Start RX state machine. */
> > +	writel(DPHY_CMN_SSM_EN | DPHY_CMN_RX_MODE_EN |
> > +	       FIELD_PREP(DPHY_CMN_RX_BANDGAP_TIMER_MASK,
> > +			  DPHY_CMN_RX_BANDGAP_TIMER),
> > +	       dphy->regs + DPHY_CMN_SSM);
> > +
> > +	return 0;
> > +}
> > +
> > +static int cdns_dphy_rx_power_off(struct phy *phy)
> > +{
> > +	struct cdns_dphy *dphy = phy_get_drvdata(phy);
> > +
> > +	writel(0, dphy->regs + DPHY_CMN_SSM);
> > +
> > +	return 0;
> > +}
> > +
> > +static int cdns_dphy_rx_get_band_ctrl(unsigned long hs_clk_rate)
> > +{
> > +	unsigned int rate, i;
> > +
> > +	rate = hs_clk_rate / 1000000UL;
> > +	/* Since CSI-2 clock is DDR, the bit rate is twice the clock rate. */
> > +	rate *= 2;
> > +
> > +	if (rate < bands[0].min_rate)
> > +		return -EOPNOTSUPP;
> > +
> > +	for (i = 0; i < ARRAY_SIZE(bands); i++) {
> > +		if (rate < bands[i].max_rate)
> > +			return i;
> > +	}
> > +
> > +	return -EOPNOTSUPP;
> > +}
> > +
> > +static int cdns_dphy_rx_wait_for_bit(void __iomem *addr, unsigned int bit)
> > +{
> > +	u32 val;
> > +
> > +	return readl_relaxed_poll_timeout(addr, val, val & BIT(bit), 10,
> > +					  DPHY_ISO_LANE_READY_TIMEOUT_MS * 1000);
> > +}
> > +
> > +static int cdns_dphy_rx_wait_lane_ready(struct cdns_dphy *dphy,
> > +					unsigned int lanes)
> > +{
> > +	static const u32 data_lane_ctrl[] = {DPHY_ISO_DL_CTRL_L0,
> > +					     DPHY_ISO_DL_CTRL_L1,
> > +					     DPHY_ISO_DL_CTRL_L2,
> > +					     DPHY_ISO_DL_CTRL_L3};
> > +	void __iomem *reg = dphy->regs;
> > +	unsigned int i;
> > +	int ret;
> > +
> > +	/* Data lanes. Minimum one lane is mandatory. */
> > +	if (lanes < DPHY_LANES_MIN || lanes > DPHY_LANES_MAX)
> > +		return -EINVAL;
> > +
> > +	/* Clock lane */
> > +	ret = cdns_dphy_rx_wait_for_bit(reg + DPHY_ISO_CL_CTRL_L,
> > +					DPHY_ISO_LANE_READY_BIT);
> > +	if (ret)
> > +		return ret;
> > +
> > +	for (i = 0; i < lanes; i++) {
> > +		ret = cdns_dphy_rx_wait_for_bit(reg + data_lane_ctrl[i],
> > +						DPHY_ISO_LANE_READY_BIT);
> > +		if (ret)
> > +			return ret;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +static int cdns_dphy_rx_configure(struct phy *phy,
> > +				  union phy_configure_opts *opts)
> > +{
> > +	struct cdns_dphy *dphy = phy_get_drvdata(phy);
> > +	unsigned int reg;
> > +	int band_ctrl, ret;
> > +
> > +	band_ctrl = cdns_dphy_rx_get_band_ctrl(opts->mipi_dphy.hs_clk_rate);
> > +	if (band_ctrl < 0)
> > +		return band_ctrl;
> > +
> > +	reg = FIELD_PREP(DPHY_BAND_CFG_LEFT_BAND, band_ctrl) |
> > +	      FIELD_PREP(DPHY_BAND_CFG_RIGHT_BAND, band_ctrl);
> > +	writel(reg, dphy->regs + DPHY_BAND_CFG);
> > +
> > +	/*
> > +	 * Set the required power island phase 2 time. This is mandated by DPHY
> > +	 * specs.
> > +	 */
> > +	reg = DPHY_POWER_ISLAND_EN_DATA_VAL;
> > +	writel(reg, dphy->regs + DPHY_POWER_ISLAND_EN_DATA);
> > +	reg = DPHY_POWER_ISLAND_EN_CLK_VAL;
> > +	writel(reg, dphy->regs + DPHY_POWER_ISLAND_EN_CLK);
> > +
> > +	ret = cdns_dphy_rx_wait_lane_ready(dphy, opts->mipi_dphy.lanes);
> > +	if (ret) {
> > +		dev_err(dphy->dev, "DPHY wait for lane ready timeout\n");
> > +		return ret;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +static int cdns_dphy_rx_validate(struct phy *phy, enum phy_mode mode,
> > +				 int submode, union phy_configure_opts *opts)
> > +{
> > +	int ret;
> > +
> > +	if (mode != PHY_MODE_MIPI_DPHY)
> > +		return -EINVAL;
> > +
> > +	ret = cdns_dphy_rx_get_band_ctrl(opts->mipi_dphy.hs_clk_rate);
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	return phy_mipi_dphy_config_validate(&opts->mipi_dphy);
> > +}
> > +
> > +static const struct phy_ops rx_ref_phy_ops = {
> > +	.power_on = cdns_dphy_rx_power_on,
> > +	.power_off = cdns_dphy_rx_power_off,
> > +	.configure = cdns_dphy_rx_configure,
> > +	.validate = cdns_dphy_rx_validate,
> > +};
> > +
> > +static const struct cdns_dphy_info rx_ref_info = {
> > +	.phy_ops = &rx_ref_phy_ops,
> > +};
> > +
> >  static int cdns_dphy_probe(struct platform_device *pdev)
> >  {
> >  	struct phy_provider *phy_provider;
> > @@ -417,6 +597,7 @@ static int cdns_dphy_remove(struct platform_device *pdev)
> >  
> >  static const struct of_device_id cdns_dphy_of_match[] = {
> >  	{ .compatible = "cdns,dphy", .data = &tx_ref_info },
> > +	{ .compatible = "cdns,dphy-rx", .data = &rx_ref_info },
> >  	{ /* sentinel */ },
> >  };
> >  MODULE_DEVICE_TABLE(of, cdns_dphy_of_match);
> > @@ -432,5 +613,6 @@ static struct platform_driver cdns_dphy_platform_driver = {
> >  module_platform_driver(cdns_dphy_platform_driver);
> >  
> >  MODULE_AUTHOR("Maxime Ripard <maxime.ripard@bootlin.com>");
> > +MODULE_AUTHOR("Pratyush Yadav <p.yadav@ti.com>");
> >  MODULE_DESCRIPTION("Cadence MIPI D-PHY Driver");
> >  MODULE_LICENSE("GPL");
> > -- 
> > 2.33.0
> > 
> 
> -- 
> Paul Kocialkowski, Bootlin
> Embedded Linux and kernel engineering
> https://bootlin.com



-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v5 2/6] phy: cdns-dphy: Add Rx support

[Pratyush Yadav]

On 17/09/21 10:58PM, Pratyush Yadav wrote:
> +Rob
> 
> On 16/09/21 12:22PM, Paul Kocialkowski wrote:
> > Hi,
> > 
> > On Fri 03 Sep 21, 00:25, Pratyush Yadav wrote:
> > > The Cadence DPHY can be used to receive image data over the CSI-2
> > > protocol. Add support for Rx mode. The programming sequence differs from
> > > the Tx mode so it is added as a separate set of hooks to isolate the two
> > > paths. The mode in which the DPHY has to be used is selected based on
> > > the compatible.
> > 
> > I just realized that I didn't follow-up on a previous revision on the debate
> > about using the phy sub-mode to distinguish between rx/tx.
> > 
> > I see that you've been using a dedicated compatible, but I'm not sure this is a
> > good fit either. My understanding is that the compatible should describe a group
> > of register-compatible revisions of a hardware component, not how the hardware
> > is used specifically. I guess the distinction between rx/tx falls under
> > the latter rather than the former.
> 
> I am not sure if that is the case. For example, we use "ti,am654-ospi" 
> for Cadence Quadspi controller. The default compatible, "cdns,qspi-nor", 
> only supports Quad SPI (4 lines). The "ti,am654-ospi" compatible also 
> supports Octal SPI (8 lines).
> 
> In addition, I feel like the Rx DPHY is almost a different type of 
> device from a Tx DPHY. The programming sequence is completely different, 
> the clocks required are different, etc. So I think using a different 
> compatible for Rx mode makes sense.
> 
> Rob, what do you think?

Ping. I think my current approach works well. Unless there are any 
objections I would like this series to move forward please.

> 
> > 
> > I just sent out a patch in my Allwinner MIPI CSI-2+ISP series adding
> > a specific direction property:
> > - https://lists.infradead.org/pipermail/linux-phy/2021-September/001420.html
> > - https://lists.infradead.org/pipermail/linux-phy/2021-September/001421.html
> > 
> > Which I feel is a more appropriate solution to implement the distinction.
> > 
> > What do you think?
> > 
> > Cheers,
> > 
> > Paul
> >  
> > > Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
> > > 
> > > ---
> > > 
> > > Changes in v5:
> > > - Use the new cdns_dphy_info to specify PHY ops.
> > > - Re-order include in alphabetical order.
> > > - Make bands const.
> > > - Drop num_bands.
> > > - Make i, lanes unsigned.
> > > - Drop the maximum check in cdns_dphy_rx_get_band_ctrl(). Let the loop
> > >   complete and return -EOPNOTSUPP when we reach the end.
> > > - Drop the "rate < bands[i].min_rate" check since the bands are in
> > >   ascending order.
> > > - Move data_lane_ctrl to start of function and make it static const.
> > > 
> > > Changes in v4:
> > > - Drop the submode parts. Use a different compatible for the Rx ops.
> > > - Make bands and num_bands static.
> > > 
> > > Changes in v3:
> > > - Use a table to select the band.
> > > - Use a table to poll the data lane ready bits.
> > > - Multiply the DPHY HS clock rate by 2 to get the bit rate since the
> > >   clock is DDR.
> > > 
> > >  drivers/phy/cadence/cdns-dphy.c | 182 ++++++++++++++++++++++++++++++++
> > >  1 file changed, 182 insertions(+)
> > > 
> > > diff --git a/drivers/phy/cadence/cdns-dphy.c b/drivers/phy/cadence/cdns-dphy.c
> > > index e2c2b27c6539..9a4c1c684e9a 100644
> > > --- a/drivers/phy/cadence/cdns-dphy.c
> > > +++ b/drivers/phy/cadence/cdns-dphy.c
> > > @@ -1,11 +1,14 @@
> > >  // SPDX-License-Identifier: GPL-2.0+
> > >  /*
> > >   * Copyright: 2017-2018 Cadence Design Systems, Inc.
> > > + * Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com/
> > >   */
> > >  
> > > +#include <linux/bitfield.h>
> > >  #include <linux/bitops.h>
> > >  #include <linux/clk.h>
> > >  #include <linux/io.h>
> > > +#include <linux/iopoll.h>
> > >  #include <linux/module.h>
> > >  #include <linux/of_address.h>
> > >  #include <linux/of_device.h>
> > > @@ -25,10 +28,14 @@
> > >  #define DPHY_PMA_RCLK(reg)		(0x600 + (reg))
> > >  #define DPHY_PMA_RDATA(lane, reg)	(0x700 + ((lane) * 0x100) + (reg))
> > >  #define DPHY_PCS(reg)			(0xb00 + (reg))
> > > +#define DPHY_ISO(reg)			(0xc00 + (reg))
> > >  
> > >  #define DPHY_CMN_SSM			DPHY_PMA_CMN(0x20)
> > >  #define DPHY_CMN_SSM_EN			BIT(0)
> > > +#define DPHY_CMN_RX_BANDGAP_TIMER_MASK	GENMASK(8, 1)
> > >  #define DPHY_CMN_TX_MODE_EN		BIT(9)
> > > +#define DPHY_CMN_RX_MODE_EN		BIT(10)
> > > +#define DPHY_CMN_RX_BANDGAP_TIMER	0x14
> > >  
> > >  #define DPHY_CMN_PWM			DPHY_PMA_CMN(0x40)
> > >  #define DPHY_CMN_PWM_DIV(x)		((x) << 20)
> > > @@ -45,10 +52,27 @@
> > >  #define DPHY_CMN_OPDIV_FROM_REG		BIT(6)
> > >  #define DPHY_CMN_OPDIV(x)		((x) << 7)
> > >  
> > > +#define DPHY_BAND_CFG			DPHY_PCS(0x0)
> > > +#define DPHY_BAND_CFG_LEFT_BAND		GENMASK(4, 0)
> > > +#define DPHY_BAND_CFG_RIGHT_BAND	GENMASK(9, 5)
> > > +
> > >  #define DPHY_PSM_CFG			DPHY_PCS(0x4)
> > >  #define DPHY_PSM_CFG_FROM_REG		BIT(0)
> > >  #define DPHY_PSM_CLK_DIV(x)		((x) << 1)
> > >  
> > > +#define DPHY_POWER_ISLAND_EN_DATA	DPHY_PCS(0x8)
> > > +#define DPHY_POWER_ISLAND_EN_DATA_VAL	0xaaaaaaaa
> > > +#define DPHY_POWER_ISLAND_EN_CLK	DPHY_PCS(0xc)
> > > +#define DPHY_POWER_ISLAND_EN_CLK_VAL	0xaa
> > > +
> > > +#define DPHY_ISO_CL_CTRL_L		DPHY_ISO(0x10)
> > > +#define DPHY_ISO_DL_CTRL_L0		DPHY_ISO(0x14)
> > > +#define DPHY_ISO_DL_CTRL_L1		DPHY_ISO(0x20)
> > > +#define DPHY_ISO_DL_CTRL_L2		DPHY_ISO(0x30)
> > > +#define DPHY_ISO_DL_CTRL_L3		DPHY_ISO(0x3c)
> > > +#define DPHY_ISO_LANE_READY_BIT		0
> > > +#define DPHY_ISO_LANE_READY_TIMEOUT_MS	100UL
> > > +
> > >  #define DSI_HBP_FRAME_OVERHEAD		12
> > >  #define DSI_HSA_FRAME_OVERHEAD		14
> > >  #define DSI_HFP_FRAME_OVERHEAD		6
> > > @@ -57,6 +81,9 @@
> > >  #define DSI_NULL_FRAME_OVERHEAD		6
> > >  #define DSI_EOT_PKT_SIZE		4
> > >  
> > > +#define DPHY_LANES_MIN			1
> > > +#define DPHY_LANES_MAX			4
> > > +
> > >  struct cdns_dphy_cfg {
> > >  	u8 pll_ipdiv;
> > >  	u8 pll_opdiv;
> > > @@ -105,6 +132,20 @@ struct cdns_dphy {
> > >  	struct phy *phy;
> > >  };
> > >  
> > > +struct cdns_dphy_rx_band {
> > > +	unsigned int min_rate;
> > > +	unsigned int max_rate;
> > > +};
> > > +
> > > +/* Order of bands is important since the index is the band number. */
> > > +static const struct cdns_dphy_rx_band bands[] = {
> > > +	{80, 100}, {100, 120}, {120, 160}, {160, 200}, {200, 240},
> > > +	{240, 280}, {280, 320}, {320, 360}, {360, 400}, {400, 480},
> > > +	{480, 560}, {560, 640}, {640, 720}, {720, 800}, {800, 880},
> > > +	{880, 1040}, {1040, 1200}, {1200, 1350}, {1350, 1500}, {1500, 1750},
> > > +	{1750, 2000}, {2000, 2250}, {2250, 2500}
> > > +};
> > > +
> > >  static int cdns_dsi_get_dphy_pll_cfg(struct cdns_dphy *dphy,
> > >  				     struct cdns_dphy_cfg *cfg,
> > >  				     struct phy_configure_opts_mipi_dphy *opts,
> > > @@ -360,6 +401,145 @@ static const struct cdns_dphy_info tx_ref_info = {
> > >  	.tx_ops = &tx_ref_dphy_ops,
> > >  };
> > >  
> > > +static int cdns_dphy_rx_power_on(struct phy *phy)
> > > +{
> > > +	struct cdns_dphy *dphy = phy_get_drvdata(phy);
> > > +
> > > +	/* Start RX state machine. */
> > > +	writel(DPHY_CMN_SSM_EN | DPHY_CMN_RX_MODE_EN |
> > > +	       FIELD_PREP(DPHY_CMN_RX_BANDGAP_TIMER_MASK,
> > > +			  DPHY_CMN_RX_BANDGAP_TIMER),
> > > +	       dphy->regs + DPHY_CMN_SSM);
> > > +
> > > +	return 0;
> > > +}
> > > +
> > > +static int cdns_dphy_rx_power_off(struct phy *phy)
> > > +{
> > > +	struct cdns_dphy *dphy = phy_get_drvdata(phy);
> > > +
> > > +	writel(0, dphy->regs + DPHY_CMN_SSM);
> > > +
> > > +	return 0;
> > > +}
> > > +
> > > +static int cdns_dphy_rx_get_band_ctrl(unsigned long hs_clk_rate)
> > > +{
> > > +	unsigned int rate, i;
> > > +
> > > +	rate = hs_clk_rate / 1000000UL;
> > > +	/* Since CSI-2 clock is DDR, the bit rate is twice the clock rate. */
> > > +	rate *= 2;
> > > +
> > > +	if (rate < bands[0].min_rate)
> > > +		return -EOPNOTSUPP;
> > > +
> > > +	for (i = 0; i < ARRAY_SIZE(bands); i++) {
> > > +		if (rate < bands[i].max_rate)
> > > +			return i;
> > > +	}
> > > +
> > > +	return -EOPNOTSUPP;
> > > +}
> > > +
> > > +static int cdns_dphy_rx_wait_for_bit(void __iomem *addr, unsigned int bit)
> > > +{
> > > +	u32 val;
> > > +
> > > +	return readl_relaxed_poll_timeout(addr, val, val & BIT(bit), 10,
> > > +					  DPHY_ISO_LANE_READY_TIMEOUT_MS * 1000);
> > > +}
> > > +
> > > +static int cdns_dphy_rx_wait_lane_ready(struct cdns_dphy *dphy,
> > > +					unsigned int lanes)
> > > +{
> > > +	static const u32 data_lane_ctrl[] = {DPHY_ISO_DL_CTRL_L0,
> > > +					     DPHY_ISO_DL_CTRL_L1,
> > > +					     DPHY_ISO_DL_CTRL_L2,
> > > +					     DPHY_ISO_DL_CTRL_L3};
> > > +	void __iomem *reg = dphy->regs;
> > > +	unsigned int i;
> > > +	int ret;
> > > +
> > > +	/* Data lanes. Minimum one lane is mandatory. */
> > > +	if (lanes < DPHY_LANES_MIN || lanes > DPHY_LANES_MAX)
> > > +		return -EINVAL;
> > > +
> > > +	/* Clock lane */
> > > +	ret = cdns_dphy_rx_wait_for_bit(reg + DPHY_ISO_CL_CTRL_L,
> > > +					DPHY_ISO_LANE_READY_BIT);
> > > +	if (ret)
> > > +		return ret;
> > > +
> > > +	for (i = 0; i < lanes; i++) {
> > > +		ret = cdns_dphy_rx_wait_for_bit(reg + data_lane_ctrl[i],
> > > +						DPHY_ISO_LANE_READY_BIT);
> > > +		if (ret)
> > > +			return ret;
> > > +	}
> > > +
> > > +	return 0;
> > > +}
> > > +
> > > +static int cdns_dphy_rx_configure(struct phy *phy,
> > > +				  union phy_configure_opts *opts)
> > > +{
> > > +	struct cdns_dphy *dphy = phy_get_drvdata(phy);
> > > +	unsigned int reg;
> > > +	int band_ctrl, ret;
> > > +
> > > +	band_ctrl = cdns_dphy_rx_get_band_ctrl(opts->mipi_dphy.hs_clk_rate);
> > > +	if (band_ctrl < 0)
> > > +		return band_ctrl;
> > > +
> > > +	reg = FIELD_PREP(DPHY_BAND_CFG_LEFT_BAND, band_ctrl) |
> > > +	      FIELD_PREP(DPHY_BAND_CFG_RIGHT_BAND, band_ctrl);
> > > +	writel(reg, dphy->regs + DPHY_BAND_CFG);
> > > +
> > > +	/*
> > > +	 * Set the required power island phase 2 time. This is mandated by DPHY
> > > +	 * specs.
> > > +	 */
> > > +	reg = DPHY_POWER_ISLAND_EN_DATA_VAL;
> > > +	writel(reg, dphy->regs + DPHY_POWER_ISLAND_EN_DATA);
> > > +	reg = DPHY_POWER_ISLAND_EN_CLK_VAL;
> > > +	writel(reg, dphy->regs + DPHY_POWER_ISLAND_EN_CLK);
> > > +
> > > +	ret = cdns_dphy_rx_wait_lane_ready(dphy, opts->mipi_dphy.lanes);
> > > +	if (ret) {
> > > +		dev_err(dphy->dev, "DPHY wait for lane ready timeout\n");
> > > +		return ret;
> > > +	}
> > > +
> > > +	return 0;
> > > +}
> > > +
> > > +static int cdns_dphy_rx_validate(struct phy *phy, enum phy_mode mode,
> > > +				 int submode, union phy_configure_opts *opts)
> > > +{
> > > +	int ret;
> > > +
> > > +	if (mode != PHY_MODE_MIPI_DPHY)
> > > +		return -EINVAL;
> > > +
> > > +	ret = cdns_dphy_rx_get_band_ctrl(opts->mipi_dphy.hs_clk_rate);
> > > +	if (ret < 0)
> > > +		return ret;
> > > +
> > > +	return phy_mipi_dphy_config_validate(&opts->mipi_dphy);
> > > +}
> > > +
> > > +static const struct phy_ops rx_ref_phy_ops = {
> > > +	.power_on = cdns_dphy_rx_power_on,
> > > +	.power_off = cdns_dphy_rx_power_off,
> > > +	.configure = cdns_dphy_rx_configure,
> > > +	.validate = cdns_dphy_rx_validate,
> > > +};
> > > +
> > > +static const struct cdns_dphy_info rx_ref_info = {
> > > +	.phy_ops = &rx_ref_phy_ops,
> > > +};
> > > +
> > >  static int cdns_dphy_probe(struct platform_device *pdev)
> > >  {
> > >  	struct phy_provider *phy_provider;
> > > @@ -417,6 +597,7 @@ static int cdns_dphy_remove(struct platform_device *pdev)
> > >  
> > >  static const struct of_device_id cdns_dphy_of_match[] = {
> > >  	{ .compatible = "cdns,dphy", .data = &tx_ref_info },
> > > +	{ .compatible = "cdns,dphy-rx", .data = &rx_ref_info },
> > >  	{ /* sentinel */ },
> > >  };
> > >  MODULE_DEVICE_TABLE(of, cdns_dphy_of_match);
> > > @@ -432,5 +613,6 @@ static struct platform_driver cdns_dphy_platform_driver = {
> > >  module_platform_driver(cdns_dphy_platform_driver);
> > >  
> > >  MODULE_AUTHOR("Maxime Ripard <maxime.ripard@bootlin.com>");
> > > +MODULE_AUTHOR("Pratyush Yadav <p.yadav@ti.com>");
> > >  MODULE_DESCRIPTION("Cadence MIPI D-PHY Driver");
> > >  MODULE_LICENSE("GPL");
> > > -- 
> > > 2.33.0
> > > 
> > 
> > -- 
> > Paul Kocialkowski, Bootlin
> > Embedded Linux and kernel engineering
> > https://bootlin.com
> 
> 
> 
> -- 
> Regards,
> Pratyush Yadav
> Texas Instruments Inc.

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v5 2/6] phy: cdns-dphy: Add Rx support

[Pratyush Yadav]

On 17/09/21 10:58PM, Pratyush Yadav wrote:
> +Rob
> 
> On 16/09/21 12:22PM, Paul Kocialkowski wrote:
> > Hi,
> > 
> > On Fri 03 Sep 21, 00:25, Pratyush Yadav wrote:
> > > The Cadence DPHY can be used to receive image data over the CSI-2
> > > protocol. Add support for Rx mode. The programming sequence differs from
> > > the Tx mode so it is added as a separate set of hooks to isolate the two
> > > paths. The mode in which the DPHY has to be used is selected based on
> > > the compatible.
> > 
> > I just realized that I didn't follow-up on a previous revision on the debate
> > about using the phy sub-mode to distinguish between rx/tx.
> > 
> > I see that you've been using a dedicated compatible, but I'm not sure this is a
> > good fit either. My understanding is that the compatible should describe a group
> > of register-compatible revisions of a hardware component, not how the hardware
> > is used specifically. I guess the distinction between rx/tx falls under
> > the latter rather than the former.
> 
> I am not sure if that is the case. For example, we use "ti,am654-ospi" 
> for Cadence Quadspi controller. The default compatible, "cdns,qspi-nor", 
> only supports Quad SPI (4 lines). The "ti,am654-ospi" compatible also 
> supports Octal SPI (8 lines).
> 
> In addition, I feel like the Rx DPHY is almost a different type of 
> device from a Tx DPHY. The programming sequence is completely different, 
> the clocks required are different, etc. So I think using a different 
> compatible for Rx mode makes sense.
> 
> Rob, what do you think?

Ping. I think my current approach works well. Unless there are any 
objections I would like this series to move forward please.

> 
> > 
> > I just sent out a patch in my Allwinner MIPI CSI-2+ISP series adding
> > a specific direction property:
> > - https://lists.infradead.org/pipermail/linux-phy/2021-September/001420.html
> > - https://lists.infradead.org/pipermail/linux-phy/2021-September/001421.html
> > 
> > Which I feel is a more appropriate solution to implement the distinction.
> > 
> > What do you think?
> > 
> > Cheers,
> > 
> > Paul
> >  
> > > Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
> > > 
> > > ---
> > > 
> > > Changes in v5:
> > > - Use the new cdns_dphy_info to specify PHY ops.
> > > - Re-order include in alphabetical order.
> > > - Make bands const.
> > > - Drop num_bands.
> > > - Make i, lanes unsigned.
> > > - Drop the maximum check in cdns_dphy_rx_get_band_ctrl(). Let the loop
> > >   complete and return -EOPNOTSUPP when we reach the end.
> > > - Drop the "rate < bands[i].min_rate" check since the bands are in
> > >   ascending order.
> > > - Move data_lane_ctrl to start of function and make it static const.
> > > 
> > > Changes in v4:
> > > - Drop the submode parts. Use a different compatible for the Rx ops.
> > > - Make bands and num_bands static.
> > > 
> > > Changes in v3:
> > > - Use a table to select the band.
> > > - Use a table to poll the data lane ready bits.
> > > - Multiply the DPHY HS clock rate by 2 to get the bit rate since the
> > >   clock is DDR.
> > > 
> > >  drivers/phy/cadence/cdns-dphy.c | 182 ++++++++++++++++++++++++++++++++
> > >  1 file changed, 182 insertions(+)
> > > 
> > > diff --git a/drivers/phy/cadence/cdns-dphy.c b/drivers/phy/cadence/cdns-dphy.c
> > > index e2c2b27c6539..9a4c1c684e9a 100644
> > > --- a/drivers/phy/cadence/cdns-dphy.c
> > > +++ b/drivers/phy/cadence/cdns-dphy.c
> > > @@ -1,11 +1,14 @@
> > >  // SPDX-License-Identifier: GPL-2.0+
> > >  /*
> > >   * Copyright: 2017-2018 Cadence Design Systems, Inc.
> > > + * Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com/
> > >   */
> > >  
> > > +#include <linux/bitfield.h>
> > >  #include <linux/bitops.h>
> > >  #include <linux/clk.h>
> > >  #include <linux/io.h>
> > > +#include <linux/iopoll.h>
> > >  #include <linux/module.h>
> > >  #include <linux/of_address.h>
> > >  #include <linux/of_device.h>
> > > @@ -25,10 +28,14 @@
> > >  #define DPHY_PMA_RCLK(reg)		(0x600 + (reg))
> > >  #define DPHY_PMA_RDATA(lane, reg)	(0x700 + ((lane) * 0x100) + (reg))
> > >  #define DPHY_PCS(reg)			(0xb00 + (reg))
> > > +#define DPHY_ISO(reg)			(0xc00 + (reg))
> > >  
> > >  #define DPHY_CMN_SSM			DPHY_PMA_CMN(0x20)
> > >  #define DPHY_CMN_SSM_EN			BIT(0)
> > > +#define DPHY_CMN_RX_BANDGAP_TIMER_MASK	GENMASK(8, 1)
> > >  #define DPHY_CMN_TX_MODE_EN		BIT(9)
> > > +#define DPHY_CMN_RX_MODE_EN		BIT(10)
> > > +#define DPHY_CMN_RX_BANDGAP_TIMER	0x14
> > >  
> > >  #define DPHY_CMN_PWM			DPHY_PMA_CMN(0x40)
> > >  #define DPHY_CMN_PWM_DIV(x)		((x) << 20)
> > > @@ -45,10 +52,27 @@
> > >  #define DPHY_CMN_OPDIV_FROM_REG		BIT(6)
> > >  #define DPHY_CMN_OPDIV(x)		((x) << 7)
> > >  
> > > +#define DPHY_BAND_CFG			DPHY_PCS(0x0)
> > > +#define DPHY_BAND_CFG_LEFT_BAND		GENMASK(4, 0)
> > > +#define DPHY_BAND_CFG_RIGHT_BAND	GENMASK(9, 5)
> > > +
> > >  #define DPHY_PSM_CFG			DPHY_PCS(0x4)
> > >  #define DPHY_PSM_CFG_FROM_REG		BIT(0)
> > >  #define DPHY_PSM_CLK_DIV(x)		((x) << 1)
> > >  
> > > +#define DPHY_POWER_ISLAND_EN_DATA	DPHY_PCS(0x8)
> > > +#define DPHY_POWER_ISLAND_EN_DATA_VAL	0xaaaaaaaa
> > > +#define DPHY_POWER_ISLAND_EN_CLK	DPHY_PCS(0xc)
> > > +#define DPHY_POWER_ISLAND_EN_CLK_VAL	0xaa
> > > +
> > > +#define DPHY_ISO_CL_CTRL_L		DPHY_ISO(0x10)
> > > +#define DPHY_ISO_DL_CTRL_L0		DPHY_ISO(0x14)
> > > +#define DPHY_ISO_DL_CTRL_L1		DPHY_ISO(0x20)
> > > +#define DPHY_ISO_DL_CTRL_L2		DPHY_ISO(0x30)
> > > +#define DPHY_ISO_DL_CTRL_L3		DPHY_ISO(0x3c)
> > > +#define DPHY_ISO_LANE_READY_BIT		0
> > > +#define DPHY_ISO_LANE_READY_TIMEOUT_MS	100UL
> > > +
> > >  #define DSI_HBP_FRAME_OVERHEAD		12
> > >  #define DSI_HSA_FRAME_OVERHEAD		14
> > >  #define DSI_HFP_FRAME_OVERHEAD		6
> > > @@ -57,6 +81,9 @@
> > >  #define DSI_NULL_FRAME_OVERHEAD		6
> > >  #define DSI_EOT_PKT_SIZE		4
> > >  
> > > +#define DPHY_LANES_MIN			1
> > > +#define DPHY_LANES_MAX			4
> > > +
> > >  struct cdns_dphy_cfg {
> > >  	u8 pll_ipdiv;
> > >  	u8 pll_opdiv;
> > > @@ -105,6 +132,20 @@ struct cdns_dphy {
> > >  	struct phy *phy;
> > >  };
> > >  
> > > +struct cdns_dphy_rx_band {
> > > +	unsigned int min_rate;
> > > +	unsigned int max_rate;
> > > +};
> > > +
> > > +/* Order of bands is important since the index is the band number. */
> > > +static const struct cdns_dphy_rx_band bands[] = {
> > > +	{80, 100}, {100, 120}, {120, 160}, {160, 200}, {200, 240},
> > > +	{240, 280}, {280, 320}, {320, 360}, {360, 400}, {400, 480},
> > > +	{480, 560}, {560, 640}, {640, 720}, {720, 800}, {800, 880},
> > > +	{880, 1040}, {1040, 1200}, {1200, 1350}, {1350, 1500}, {1500, 1750},
> > > +	{1750, 2000}, {2000, 2250}, {2250, 2500}
> > > +};
> > > +
> > >  static int cdns_dsi_get_dphy_pll_cfg(struct cdns_dphy *dphy,
> > >  				     struct cdns_dphy_cfg *cfg,
> > >  				     struct phy_configure_opts_mipi_dphy *opts,
> > > @@ -360,6 +401,145 @@ static const struct cdns_dphy_info tx_ref_info = {
> > >  	.tx_ops = &tx_ref_dphy_ops,
> > >  };
> > >  
> > > +static int cdns_dphy_rx_power_on(struct phy *phy)
> > > +{
> > > +	struct cdns_dphy *dphy = phy_get_drvdata(phy);
> > > +
> > > +	/* Start RX state machine. */
> > > +	writel(DPHY_CMN_SSM_EN | DPHY_CMN_RX_MODE_EN |
> > > +	       FIELD_PREP(DPHY_CMN_RX_BANDGAP_TIMER_MASK,
> > > +			  DPHY_CMN_RX_BANDGAP_TIMER),
> > > +	       dphy->regs + DPHY_CMN_SSM);
> > > +
> > > +	return 0;
> > > +}
> > > +
> > > +static int cdns_dphy_rx_power_off(struct phy *phy)
> > > +{
> > > +	struct cdns_dphy *dphy = phy_get_drvdata(phy);
> > > +
> > > +	writel(0, dphy->regs + DPHY_CMN_SSM);
> > > +
> > > +	return 0;
> > > +}
> > > +
> > > +static int cdns_dphy_rx_get_band_ctrl(unsigned long hs_clk_rate)
> > > +{
> > > +	unsigned int rate, i;
> > > +
> > > +	rate = hs_clk_rate / 1000000UL;
> > > +	/* Since CSI-2 clock is DDR, the bit rate is twice the clock rate. */
> > > +	rate *= 2;
> > > +
> > > +	if (rate < bands[0].min_rate)
> > > +		return -EOPNOTSUPP;
> > > +
> > > +	for (i = 0; i < ARRAY_SIZE(bands); i++) {
> > > +		if (rate < bands[i].max_rate)
> > > +			return i;
> > > +	}
> > > +
> > > +	return -EOPNOTSUPP;
> > > +}
> > > +
> > > +static int cdns_dphy_rx_wait_for_bit(void __iomem *addr, unsigned int bit)
> > > +{
> > > +	u32 val;
> > > +
> > > +	return readl_relaxed_poll_timeout(addr, val, val & BIT(bit), 10,
> > > +					  DPHY_ISO_LANE_READY_TIMEOUT_MS * 1000);
> > > +}
> > > +
> > > +static int cdns_dphy_rx_wait_lane_ready(struct cdns_dphy *dphy,
> > > +					unsigned int lanes)
> > > +{
> > > +	static const u32 data_lane_ctrl[] = {DPHY_ISO_DL_CTRL_L0,
> > > +					     DPHY_ISO_DL_CTRL_L1,
> > > +					     DPHY_ISO_DL_CTRL_L2,
> > > +					     DPHY_ISO_DL_CTRL_L3};
> > > +	void __iomem *reg = dphy->regs;
> > > +	unsigned int i;
> > > +	int ret;
> > > +
> > > +	/* Data lanes. Minimum one lane is mandatory. */
> > > +	if (lanes < DPHY_LANES_MIN || lanes > DPHY_LANES_MAX)
> > > +		return -EINVAL;
> > > +
> > > +	/* Clock lane */
> > > +	ret = cdns_dphy_rx_wait_for_bit(reg + DPHY_ISO_CL_CTRL_L,
> > > +					DPHY_ISO_LANE_READY_BIT);
> > > +	if (ret)
> > > +		return ret;
> > > +
> > > +	for (i = 0; i < lanes; i++) {
> > > +		ret = cdns_dphy_rx_wait_for_bit(reg + data_lane_ctrl[i],
> > > +						DPHY_ISO_LANE_READY_BIT);
> > > +		if (ret)
> > > +			return ret;
> > > +	}
> > > +
> > > +	return 0;
> > > +}
> > > +
> > > +static int cdns_dphy_rx_configure(struct phy *phy,
> > > +				  union phy_configure_opts *opts)
> > > +{
> > > +	struct cdns_dphy *dphy = phy_get_drvdata(phy);
> > > +	unsigned int reg;
> > > +	int band_ctrl, ret;
> > > +
> > > +	band_ctrl = cdns_dphy_rx_get_band_ctrl(opts->mipi_dphy.hs_clk_rate);
> > > +	if (band_ctrl < 0)
> > > +		return band_ctrl;
> > > +
> > > +	reg = FIELD_PREP(DPHY_BAND_CFG_LEFT_BAND, band_ctrl) |
> > > +	      FIELD_PREP(DPHY_BAND_CFG_RIGHT_BAND, band_ctrl);
> > > +	writel(reg, dphy->regs + DPHY_BAND_CFG);
> > > +
> > > +	/*
> > > +	 * Set the required power island phase 2 time. This is mandated by DPHY
> > > +	 * specs.
> > > +	 */
> > > +	reg = DPHY_POWER_ISLAND_EN_DATA_VAL;
> > > +	writel(reg, dphy->regs + DPHY_POWER_ISLAND_EN_DATA);
> > > +	reg = DPHY_POWER_ISLAND_EN_CLK_VAL;
> > > +	writel(reg, dphy->regs + DPHY_POWER_ISLAND_EN_CLK);
> > > +
> > > +	ret = cdns_dphy_rx_wait_lane_ready(dphy, opts->mipi_dphy.lanes);
> > > +	if (ret) {
> > > +		dev_err(dphy->dev, "DPHY wait for lane ready timeout\n");
> > > +		return ret;
> > > +	}
> > > +
> > > +	return 0;
> > > +}
> > > +
> > > +static int cdns_dphy_rx_validate(struct phy *phy, enum phy_mode mode,
> > > +				 int submode, union phy_configure_opts *opts)
> > > +{
> > > +	int ret;
> > > +
> > > +	if (mode != PHY_MODE_MIPI_DPHY)
> > > +		return -EINVAL;
> > > +
> > > +	ret = cdns_dphy_rx_get_band_ctrl(opts->mipi_dphy.hs_clk_rate);
> > > +	if (ret < 0)
> > > +		return ret;
> > > +
> > > +	return phy_mipi_dphy_config_validate(&opts->mipi_dphy);
> > > +}
> > > +
> > > +static const struct phy_ops rx_ref_phy_ops = {
> > > +	.power_on = cdns_dphy_rx_power_on,
> > > +	.power_off = cdns_dphy_rx_power_off,
> > > +	.configure = cdns_dphy_rx_configure,
> > > +	.validate = cdns_dphy_rx_validate,
> > > +};
> > > +
> > > +static const struct cdns_dphy_info rx_ref_info = {
> > > +	.phy_ops = &rx_ref_phy_ops,
> > > +};
> > > +
> > >  static int cdns_dphy_probe(struct platform_device *pdev)
> > >  {
> > >  	struct phy_provider *phy_provider;
> > > @@ -417,6 +597,7 @@ static int cdns_dphy_remove(struct platform_device *pdev)
> > >  
> > >  static const struct of_device_id cdns_dphy_of_match[] = {
> > >  	{ .compatible = "cdns,dphy", .data = &tx_ref_info },
> > > +	{ .compatible = "cdns,dphy-rx", .data = &rx_ref_info },
> > >  	{ /* sentinel */ },
> > >  };
> > >  MODULE_DEVICE_TABLE(of, cdns_dphy_of_match);
> > > @@ -432,5 +613,6 @@ static struct platform_driver cdns_dphy_platform_driver = {
> > >  module_platform_driver(cdns_dphy_platform_driver);
> > >  
> > >  MODULE_AUTHOR("Maxime Ripard <maxime.ripard@bootlin.com>");
> > > +MODULE_AUTHOR("Pratyush Yadav <p.yadav@ti.com>");
> > >  MODULE_DESCRIPTION("Cadence MIPI D-PHY Driver");
> > >  MODULE_LICENSE("GPL");
> > > -- 
> > > 2.33.0
> > > 
> > 
> > -- 
> > Paul Kocialkowski, Bootlin
> > Embedded Linux and kernel engineering
> > https://bootlin.com
> 
> 
> 
> -- 
> Regards,
> Pratyush Yadav
> Texas Instruments Inc.

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.

Re: [PATCH v5 2/6] phy: cdns-dphy: Add Rx support

[Vinod Koul]

Hi Pratyush,

On 17-09-21, 22:58, Pratyush Yadav wrote:
> +Rob
> 
> On 16/09/21 12:22PM, Paul Kocialkowski wrote:
> > Hi,
> > 
> > On Fri 03 Sep 21, 00:25, Pratyush Yadav wrote:
> > > The Cadence DPHY can be used to receive image data over the CSI-2
> > > protocol. Add support for Rx mode. The programming sequence differs from
> > > the Tx mode so it is added as a separate set of hooks to isolate the two
> > > paths. The mode in which the DPHY has to be used is selected based on
> > > the compatible.
> > 
> > I just realized that I didn't follow-up on a previous revision on the debate
> > about using the phy sub-mode to distinguish between rx/tx.
> > 
> > I see that you've been using a dedicated compatible, but I'm not sure this is a
> > good fit either. My understanding is that the compatible should describe a group
> > of register-compatible revisions of a hardware component, not how the hardware
> > is used specifically. I guess the distinction between rx/tx falls under
> > the latter rather than the former.
> 
> I am not sure if that is the case. For example, we use "ti,am654-ospi" 
> for Cadence Quadspi controller. The default compatible, "cdns,qspi-nor", 
> only supports Quad SPI (4 lines). The "ti,am654-ospi" compatible also 
> supports Octal SPI (8 lines).

Those are hardware defaults right?

> In addition, I feel like the Rx DPHY is almost a different type of 
> device from a Tx DPHY. The programming sequence is completely different, 

Is that due to direction or something else..?

> the clocks required are different, etc. So I think using a different 
> compatible for Rx mode makes sense.

Is the underlaying IP not capable of both TX and RX and in the specific
situations you are using it as TX and RX.

I am okay that default being TX but you can use Paul's approach of
direction with this to make it better proposal

-- 
~Vinod

Re: [PATCH v5 2/6] phy: cdns-dphy: Add Rx support

[Vinod Koul]

Hi Pratyush,

On 17-09-21, 22:58, Pratyush Yadav wrote:
> +Rob
> 
> On 16/09/21 12:22PM, Paul Kocialkowski wrote:
> > Hi,
> > 
> > On Fri 03 Sep 21, 00:25, Pratyush Yadav wrote:
> > > The Cadence DPHY can be used to receive image data over the CSI-2
> > > protocol. Add support for Rx mode. The programming sequence differs from
> > > the Tx mode so it is added as a separate set of hooks to isolate the two
> > > paths. The mode in which the DPHY has to be used is selected based on
> > > the compatible.
> > 
> > I just realized that I didn't follow-up on a previous revision on the debate
> > about using the phy sub-mode to distinguish between rx/tx.
> > 
> > I see that you've been using a dedicated compatible, but I'm not sure this is a
> > good fit either. My understanding is that the compatible should describe a group
> > of register-compatible revisions of a hardware component, not how the hardware
> > is used specifically. I guess the distinction between rx/tx falls under
> > the latter rather than the former.
> 
> I am not sure if that is the case. For example, we use "ti,am654-ospi" 
> for Cadence Quadspi controller. The default compatible, "cdns,qspi-nor", 
> only supports Quad SPI (4 lines). The "ti,am654-ospi" compatible also 
> supports Octal SPI (8 lines).

Those are hardware defaults right?

> In addition, I feel like the Rx DPHY is almost a different type of 
> device from a Tx DPHY. The programming sequence is completely different, 

Is that due to direction or something else..?

> the clocks required are different, etc. So I think using a different 
> compatible for Rx mode makes sense.

Is the underlaying IP not capable of both TX and RX and in the specific
situations you are using it as TX and RX.

I am okay that default being TX but you can use Paul's approach of
direction with this to make it better proposal

-- 
~Vinod

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v5 2/6] phy: cdns-dphy: Add Rx support

[Pratyush Yadav]

On 01/10/21 11:53AM, Vinod Koul wrote:
> Hi Pratyush,
> 
> On 17-09-21, 22:58, Pratyush Yadav wrote:
> > +Rob
> > 
> > On 16/09/21 12:22PM, Paul Kocialkowski wrote:
> > > Hi,
> > > 
> > > On Fri 03 Sep 21, 00:25, Pratyush Yadav wrote:
> > > > The Cadence DPHY can be used to receive image data over the CSI-2
> > > > protocol. Add support for Rx mode. The programming sequence differs from
> > > > the Tx mode so it is added as a separate set of hooks to isolate the two
> > > > paths. The mode in which the DPHY has to be used is selected based on
> > > > the compatible.
> > > 
> > > I just realized that I didn't follow-up on a previous revision on the debate
> > > about using the phy sub-mode to distinguish between rx/tx.
> > > 
> > > I see that you've been using a dedicated compatible, but I'm not sure this is a
> > > good fit either. My understanding is that the compatible should describe a group
> > > of register-compatible revisions of a hardware component, not how the hardware
> > > is used specifically. I guess the distinction between rx/tx falls under
> > > the latter rather than the former.
> > 
> > I am not sure if that is the case. For example, we use "ti,am654-ospi" 
> > for Cadence Quadspi controller. The default compatible, "cdns,qspi-nor", 
> > only supports Quad SPI (4 lines). The "ti,am654-ospi" compatible also 
> > supports Octal SPI (8 lines).
> 
> Those are hardware defaults right?
> 
> > In addition, I feel like the Rx DPHY is almost a different type of 
> > device from a Tx DPHY. The programming sequence is completely different, 
> 
> Is that due to direction or something else..?

Yes, it is due to direction. Different settings need to be applied for 
Rx mode.

> 
> > the clocks required are different, etc. So I think using a different 
> > compatible for Rx mode makes sense.
> 
> Is the underlaying IP not capable of both TX and RX and in the specific
> situations you are using it as TX and RX.

Any instance of the underlying IP can only either be TX or RX, it can't 
do both.

> 
> I am okay that default being TX but you can use Paul's approach of
> direction with this to make it better proposal

Ok, will update this patch then.

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.

Re: [PATCH v5 2/6] phy: cdns-dphy: Add Rx support

[Pratyush Yadav]

On 01/10/21 11:53AM, Vinod Koul wrote:
> Hi Pratyush,
> 
> On 17-09-21, 22:58, Pratyush Yadav wrote:
> > +Rob
> > 
> > On 16/09/21 12:22PM, Paul Kocialkowski wrote:
> > > Hi,
> > > 
> > > On Fri 03 Sep 21, 00:25, Pratyush Yadav wrote:
> > > > The Cadence DPHY can be used to receive image data over the CSI-2
> > > > protocol. Add support for Rx mode. The programming sequence differs from
> > > > the Tx mode so it is added as a separate set of hooks to isolate the two
> > > > paths. The mode in which the DPHY has to be used is selected based on
> > > > the compatible.
> > > 
> > > I just realized that I didn't follow-up on a previous revision on the debate
> > > about using the phy sub-mode to distinguish between rx/tx.
> > > 
> > > I see that you've been using a dedicated compatible, but I'm not sure this is a
> > > good fit either. My understanding is that the compatible should describe a group
> > > of register-compatible revisions of a hardware component, not how the hardware
> > > is used specifically. I guess the distinction between rx/tx falls under
> > > the latter rather than the former.
> > 
> > I am not sure if that is the case. For example, we use "ti,am654-ospi" 
> > for Cadence Quadspi controller. The default compatible, "cdns,qspi-nor", 
> > only supports Quad SPI (4 lines). The "ti,am654-ospi" compatible also 
> > supports Octal SPI (8 lines).
> 
> Those are hardware defaults right?
> 
> > In addition, I feel like the Rx DPHY is almost a different type of 
> > device from a Tx DPHY. The programming sequence is completely different, 
> 
> Is that due to direction or something else..?

Yes, it is due to direction. Different settings need to be applied for 
Rx mode.

> 
> > the clocks required are different, etc. So I think using a different 
> > compatible for Rx mode makes sense.
> 
> Is the underlaying IP not capable of both TX and RX and in the specific
> situations you are using it as TX and RX.

Any instance of the underlying IP can only either be TX or RX, it can't 
do both.

> 
> I am okay that default being TX but you can use Paul's approach of
> direction with this to make it better proposal

Ok, will update this patch then.

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v5 4/6] phy: dt-bindings: cdns,dphy: make clocks optional for Rx mode

[Laurent Pinchart]

Hi Pratyush,

Thank you for the patch.

On Fri, Sep 03, 2021 at 12:25:41AM +0530, Pratyush Yadav wrote:
> The clocks are not used by the DPHY when used in Rx mode so make them
> optional for it by using a conditional based on compatible.
> 
> Signed-off-by: Pratyush Yadav <p.yadav@ti.com>

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

> ---
> 
> Changes in v5:
> - Make clocks a required property based on the compatible.
> 
> Changes in v3:
> - Add Rob's Ack.
> 
> Changes in v2:
> - Re-order subject prefixes.
> 
>  .../devicetree/bindings/phy/cdns,dphy.yaml          | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
> index b90a58773bf2..558f110fda9e 100644
> --- a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
> +++ b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
> @@ -33,10 +33,19 @@ properties:
>  required:
>    - compatible
>    - reg
> -  - clocks
> -  - clock-names
>    - "#phy-cells"
>  
> +allOf:
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: cdns,dphy
> +    then:
> +      required:
> +        - clocks
> +        - clock-names
> +
>  additionalProperties: false
>  
>  examples:

-- 
Regards,

Laurent Pinchart

Re: [PATCH v5 4/6] phy: dt-bindings: cdns, dphy: make clocks optional for Rx mode

[Laurent Pinchart]

Hi Pratyush,

Thank you for the patch.

On Fri, Sep 03, 2021 at 12:25:41AM +0530, Pratyush Yadav wrote:
> The clocks are not used by the DPHY when used in Rx mode so make them
> optional for it by using a conditional based on compatible.
> 
> Signed-off-by: Pratyush Yadav <p.yadav@ti.com>

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

> ---
> 
> Changes in v5:
> - Make clocks a required property based on the compatible.
> 
> Changes in v3:
> - Add Rob's Ack.
> 
> Changes in v2:
> - Re-order subject prefixes.
> 
>  .../devicetree/bindings/phy/cdns,dphy.yaml          | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
> index b90a58773bf2..558f110fda9e 100644
> --- a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
> +++ b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
> @@ -33,10 +33,19 @@ properties:
>  required:
>    - compatible
>    - reg
> -  - clocks
> -  - clock-names
>    - "#phy-cells"
>  
> +allOf:
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: cdns,dphy
> +    then:
> +      required:
> +        - clocks
> +        - clock-names
> +
>  additionalProperties: false
>  
>  examples:

-- 
Regards,

Laurent Pinchart

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v5 1/6] phy: cdns-dphy: Prepare for Rx support

[Laurent Pinchart]

Hi Pratyush,

Thank you for the patch.

On Fri, Sep 03, 2021 at 12:25:38AM +0530, Pratyush Yadav wrote:
> The Rx programming sequence differs from the Tx programming sequence.
> Currently only Tx mode is supported. For example, the power on and off,
> validation, and configuration procedures are all different between Rx
> and Tx DPHYs. Currently they are only written from a Tx point of view
> and they won't work with an Rx DPHY.
> 
> Set the PHY ops from driver data, which makes it possible to use
> different PHY callbacks for Rx and Tx modes. Rename cdns_dphy_ops to
> cdns_dphy_tx_ops since they are only used by the Tx path. Also move
> probe() and remove() to a new struct called cdns_dphy_common_ops. These
> can be used by both Rx and Tx paths. cdns_dphy_rx_ops is not added since
> it is not needed by the reference Rx mode implementation as of now. It
> can be added later if needed.
> 
> The clocks "psm" and "pll_ref" are not used by the Rx path so check for
> them in the Tx path's probe() callback.
> 
> Signed-off-by: Pratyush Yadav <p.yadav@ti.com>

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

> 
> ---
> 
> Changes in v5:
> - Based on Laurent's suggestion, add cdns_dphy_info which contains the
>   phy_ops and cdns_dphy_tx_ops (renamed from cdns_dphy_ops). This lets us
>   get rid of the phy ops wrappers.
> - Move probe() and remove() into cdns_dphy_common_ops() since they can
>   be used by both modes. Drop the check in power_on().
> - Get the clocks in the tx ops probe to make sure they are mandatory for
>   Tx mode but not for Rx mode.
> 
> Changes in v4:
> - Instead of having both Rx and Tx modes in the same driver data, keep
>   them separate since the op selection is based on compatible now. For
>   that reason, the cdns_dphy_driver_data struct is no longer needed.
> - Rename ref_dphy_ops to tx_ref_dphy_ops to clarify their purpose.
> - Drop submode checks in validate() hook.
> 
>  drivers/phy/cadence/cdns-dphy.c | 169 ++++++++++++++++++++------------
>  1 file changed, 108 insertions(+), 61 deletions(-)
> 
> diff --git a/drivers/phy/cadence/cdns-dphy.c b/drivers/phy/cadence/cdns-dphy.c
> index ba042e39cfaf..e2c2b27c6539 100644
> --- a/drivers/phy/cadence/cdns-dphy.c
> +++ b/drivers/phy/cadence/cdns-dphy.c
> @@ -72,9 +72,13 @@ enum cdns_dphy_clk_lane_cfg {
>  };
>  
>  struct cdns_dphy;
> -struct cdns_dphy_ops {
> +
> +struct cdns_dphy_common_ops {
>  	int (*probe)(struct cdns_dphy *dphy);
>  	void (*remove)(struct cdns_dphy *dphy);
> +};
> +
> +struct cdns_dphy_tx_ops {
>  	void (*set_psm_div)(struct cdns_dphy *dphy, u8 div);
>  	void (*set_clk_lane_cfg)(struct cdns_dphy *dphy,
>  				 enum cdns_dphy_clk_lane_cfg cfg);
> @@ -83,12 +87,21 @@ struct cdns_dphy_ops {
>  	unsigned long (*get_wakeup_time_ns)(struct cdns_dphy *dphy);
>  };
>  
> +struct cdns_dphy_info {
> +	const struct phy_ops *phy_ops;
> +	const struct cdns_dphy_common_ops *common_ops;
> +
> +	/* Only set when DPHY is to be used in Tx mode. */
> +	const struct cdns_dphy_tx_ops *tx_ops;
> +};
> +
>  struct cdns_dphy {
>  	struct cdns_dphy_cfg cfg;
>  	void __iomem *regs;
> +	struct device *dev;
>  	struct clk *psm_clk;
>  	struct clk *pll_ref_clk;
> -	const struct cdns_dphy_ops *ops;
> +	const struct cdns_dphy_info *info;
>  	struct phy *phy;
>  };
>  
> @@ -135,6 +148,7 @@ static int cdns_dsi_get_dphy_pll_cfg(struct cdns_dphy *dphy,
>  
>  static int cdns_dphy_setup_psm(struct cdns_dphy *dphy)
>  {
> +	const struct cdns_dphy_tx_ops *ops = dphy->info->tx_ops;
>  	unsigned long psm_clk_hz = clk_get_rate(dphy->psm_clk);
>  	unsigned long psm_div;
>  
> @@ -142,8 +156,8 @@ static int cdns_dphy_setup_psm(struct cdns_dphy *dphy)
>  		return -EINVAL;
>  
>  	psm_div = DIV_ROUND_CLOSEST(psm_clk_hz, 1000000);
> -	if (dphy->ops->set_psm_div)
> -		dphy->ops->set_psm_div(dphy, psm_div);
> +	if (ops && ops->set_psm_div)
> +		ops->set_psm_div(dphy, psm_div);
>  
>  	return 0;
>  }
> @@ -151,20 +165,31 @@ static int cdns_dphy_setup_psm(struct cdns_dphy *dphy)
>  static void cdns_dphy_set_clk_lane_cfg(struct cdns_dphy *dphy,
>  				       enum cdns_dphy_clk_lane_cfg cfg)
>  {
> -	if (dphy->ops->set_clk_lane_cfg)
> -		dphy->ops->set_clk_lane_cfg(dphy, cfg);
> +	const struct cdns_dphy_tx_ops *ops = dphy->info->tx_ops;
> +
> +	if (ops && ops->set_clk_lane_cfg)
> +		ops->set_clk_lane_cfg(dphy, cfg);
>  }
>  
>  static void cdns_dphy_set_pll_cfg(struct cdns_dphy *dphy,
>  				  const struct cdns_dphy_cfg *cfg)
>  {
> -	if (dphy->ops->set_pll_cfg)
> -		dphy->ops->set_pll_cfg(dphy, cfg);
> +	const struct cdns_dphy_tx_ops *ops = dphy->info->tx_ops;
> +
> +	if (ops && ops->set_pll_cfg)
> +		ops->set_pll_cfg(dphy, cfg);
>  }
>  
>  static unsigned long cdns_dphy_get_wakeup_time_ns(struct cdns_dphy *dphy)
>  {
> -	return dphy->ops->get_wakeup_time_ns(dphy);
> +	const struct cdns_dphy_tx_ops *ops = dphy->info->tx_ops;
> +
> +	if (!ops || !ops->get_wakeup_time_ns) {
> +		dev_err(dphy->dev, "get_wakeup_time_ns() is required\n");
> +		return 0;
> +	}
> +
> +	return ops->get_wakeup_time_ns(dphy);
>  }
>  
>  static unsigned long cdns_dphy_ref_get_wakeup_time_ns(struct cdns_dphy *dphy)
> @@ -199,20 +224,9 @@ static void cdns_dphy_ref_set_psm_div(struct cdns_dphy *dphy, u8 div)
>  	       dphy->regs + DPHY_PSM_CFG);
>  }
>  
> -/*
> - * This is the reference implementation of DPHY hooks. Specific integration of
> - * this IP may have to re-implement some of them depending on how they decided
> - * to wire things in the SoC.
> - */
> -static const struct cdns_dphy_ops ref_dphy_ops = {
> -	.get_wakeup_time_ns = cdns_dphy_ref_get_wakeup_time_ns,
> -	.set_pll_cfg = cdns_dphy_ref_set_pll_cfg,
> -	.set_psm_div = cdns_dphy_ref_set_psm_div,
> -};
> -
> -static int cdns_dphy_config_from_opts(struct phy *phy,
> -				      struct phy_configure_opts_mipi_dphy *opts,
> -				      struct cdns_dphy_cfg *cfg)
> +static int cdns_dphy_tx_config_from_opts(struct phy *phy,
> +					 struct phy_configure_opts_mipi_dphy *opts,
> +					 struct cdns_dphy_cfg *cfg)
>  {
>  	struct cdns_dphy *dphy = phy_get_drvdata(phy);
>  	unsigned int dsi_hfp_ext = 0;
> @@ -232,24 +246,14 @@ static int cdns_dphy_config_from_opts(struct phy *phy,
>  	return 0;
>  }
>  
> -static int cdns_dphy_validate(struct phy *phy, enum phy_mode mode, int submode,
> -			      union phy_configure_opts *opts)
> -{
> -	struct cdns_dphy_cfg cfg = { 0 };
> -
> -	if (mode != PHY_MODE_MIPI_DPHY)
> -		return -EINVAL;
> -
> -	return cdns_dphy_config_from_opts(phy, &opts->mipi_dphy, &cfg);
> -}
> -
> -static int cdns_dphy_configure(struct phy *phy, union phy_configure_opts *opts)
> +static int cdns_dphy_tx_configure(struct phy *phy,
> +				  union phy_configure_opts *opts)
>  {
>  	struct cdns_dphy *dphy = phy_get_drvdata(phy);
>  	struct cdns_dphy_cfg cfg = { 0 };
>  	int ret;
>  
> -	ret = cdns_dphy_config_from_opts(phy, &opts->mipi_dphy, &cfg);
> +	ret = cdns_dphy_tx_config_from_opts(dphy->phy, &opts->mipi_dphy, &cfg);
>  	if (ret)
>  		return ret;
>  
> @@ -279,7 +283,19 @@ static int cdns_dphy_configure(struct phy *phy, union phy_configure_opts *opts)
>  	return 0;
>  }
>  
> -static int cdns_dphy_power_on(struct phy *phy)
> +static int cdns_dphy_tx_validate(struct phy *phy, enum phy_mode mode,
> +				 int submode, union phy_configure_opts *opts)
> +{
> +	struct cdns_dphy *dphy = phy_get_drvdata(phy);
> +	struct cdns_dphy_cfg cfg = { 0 };
> +
> +	if (mode != PHY_MODE_MIPI_DPHY)
> +		return -EINVAL;
> +
> +	return cdns_dphy_tx_config_from_opts(dphy->phy, &opts->mipi_dphy, &cfg);
> +}
> +
> +static int cdns_dphy_tx_power_on(struct phy *phy)
>  {
>  	struct cdns_dphy *dphy = phy_get_drvdata(phy);
>  
> @@ -293,7 +309,7 @@ static int cdns_dphy_power_on(struct phy *phy)
>  	return 0;
>  }
>  
> -static int cdns_dphy_power_off(struct phy *phy)
> +static int cdns_dphy_tx_power_off(struct phy *phy)
>  {
>  	struct cdns_dphy *dphy = phy_get_drvdata(phy);
>  
> @@ -303,16 +319,51 @@ static int cdns_dphy_power_off(struct phy *phy)
>  	return 0;
>  }
>  
> -static const struct phy_ops cdns_dphy_ops = {
> -	.configure	= cdns_dphy_configure,
> -	.validate	= cdns_dphy_validate,
> -	.power_on	= cdns_dphy_power_on,
> -	.power_off	= cdns_dphy_power_off,
> +static int cdns_dphy_tx_probe(struct cdns_dphy *dphy)
> +{
> +	dphy->psm_clk = devm_clk_get(dphy->dev, "psm");
> +	if (IS_ERR(dphy->psm_clk))
> +		return PTR_ERR(dphy->psm_clk);
> +
> +	dphy->pll_ref_clk = devm_clk_get(dphy->dev, "pll_ref");
> +	if (IS_ERR(dphy->pll_ref_clk))
> +		return PTR_ERR(dphy->pll_ref_clk);
> +
> +	return 0;
> +}
> +
> +/*
> + * This is the reference implementation of DPHY hooks. Specific integration of
> + * this IP may have to re-implement some of them depending on how they decided
> + * to wire things in the SoC.
> + */
> +static const struct cdns_dphy_tx_ops tx_ref_dphy_ops = {
> +	.get_wakeup_time_ns = cdns_dphy_ref_get_wakeup_time_ns,
> +	.set_pll_cfg = cdns_dphy_ref_set_pll_cfg,
> +	.set_psm_div = cdns_dphy_ref_set_psm_div,
> +};
> +
> +static const struct cdns_dphy_common_ops tx_ref_common_ops = {
> +	.probe = cdns_dphy_tx_probe,
> +};
> +
> +static const struct phy_ops tx_ref_phy_ops = {
> +	.power_on = cdns_dphy_tx_power_on,
> +	.power_off = cdns_dphy_tx_power_off,
> +	.validate = cdns_dphy_tx_validate,
> +	.configure = cdns_dphy_tx_configure,
> +};
> +
> +static const struct cdns_dphy_info tx_ref_info = {
> +	.phy_ops = &tx_ref_phy_ops,
> +	.common_ops = &tx_ref_common_ops,
> +	.tx_ops = &tx_ref_dphy_ops,
>  };
>  
>  static int cdns_dphy_probe(struct platform_device *pdev)
>  {
>  	struct phy_provider *phy_provider;
> +	const struct cdns_dphy_info *info;
>  	struct cdns_dphy *dphy;
>  	int ret;
>  
> @@ -320,34 +371,29 @@ static int cdns_dphy_probe(struct platform_device *pdev)
>  	if (!dphy)
>  		return -ENOMEM;
>  	dev_set_drvdata(&pdev->dev, dphy);
> +	dphy->dev = &pdev->dev;
>  
> -	dphy->ops = of_device_get_match_data(&pdev->dev);
> -	if (!dphy->ops)
> +	info = of_device_get_match_data(&pdev->dev);
> +	if (!info)
>  		return -EINVAL;
>  
> +	dphy->info = info;
> +
>  	dphy->regs = devm_platform_ioremap_resource(pdev, 0);
>  	if (IS_ERR(dphy->regs))
>  		return PTR_ERR(dphy->regs);
>  
> -	dphy->psm_clk = devm_clk_get(&pdev->dev, "psm");
> -	if (IS_ERR(dphy->psm_clk))
> -		return PTR_ERR(dphy->psm_clk);
> -
> -	dphy->pll_ref_clk = devm_clk_get(&pdev->dev, "pll_ref");
> -	if (IS_ERR(dphy->pll_ref_clk))
> -		return PTR_ERR(dphy->pll_ref_clk);
> -
> -	if (dphy->ops->probe) {
> -		ret = dphy->ops->probe(dphy);
> +	if (info->common_ops && info->common_ops->probe) {
> +		ret = info->common_ops->probe(dphy);
>  		if (ret)
>  			return ret;
>  	}
>  
> -	dphy->phy = devm_phy_create(&pdev->dev, NULL, &cdns_dphy_ops);
> +	dphy->phy = devm_phy_create(&pdev->dev, NULL, info->phy_ops);
>  	if (IS_ERR(dphy->phy)) {
>  		dev_err(&pdev->dev, "failed to create PHY\n");
> -		if (dphy->ops->remove)
> -			dphy->ops->remove(dphy);
> +		if (info->common_ops && info->common_ops->remove)
> +			info->common_ops->remove(dphy);
>  		return PTR_ERR(dphy->phy);
>  	}
>  
> @@ -361,15 +407,16 @@ static int cdns_dphy_probe(struct platform_device *pdev)
>  static int cdns_dphy_remove(struct platform_device *pdev)
>  {
>  	struct cdns_dphy *dphy = dev_get_drvdata(&pdev->dev);
> +	const struct cdns_dphy_info *info = dphy->info;
>  
> -	if (dphy->ops->remove)
> -		dphy->ops->remove(dphy);
> +	if (info->common_ops && info->common_ops->remove)
> +		info->common_ops->remove(dphy);
>  
>  	return 0;
>  }
>  
>  static const struct of_device_id cdns_dphy_of_match[] = {
> -	{ .compatible = "cdns,dphy", .data = &ref_dphy_ops },
> +	{ .compatible = "cdns,dphy", .data = &tx_ref_info },
>  	{ /* sentinel */ },
>  };
>  MODULE_DEVICE_TABLE(of, cdns_dphy_of_match);

-- 
Regards,

Laurent Pinchart

Re: [PATCH v5 1/6] phy: cdns-dphy: Prepare for Rx support

[Laurent Pinchart]

Hi Pratyush,

Thank you for the patch.

On Fri, Sep 03, 2021 at 12:25:38AM +0530, Pratyush Yadav wrote:
> The Rx programming sequence differs from the Tx programming sequence.
> Currently only Tx mode is supported. For example, the power on and off,
> validation, and configuration procedures are all different between Rx
> and Tx DPHYs. Currently they are only written from a Tx point of view
> and they won't work with an Rx DPHY.
> 
> Set the PHY ops from driver data, which makes it possible to use
> different PHY callbacks for Rx and Tx modes. Rename cdns_dphy_ops to
> cdns_dphy_tx_ops since they are only used by the Tx path. Also move
> probe() and remove() to a new struct called cdns_dphy_common_ops. These
> can be used by both Rx and Tx paths. cdns_dphy_rx_ops is not added since
> it is not needed by the reference Rx mode implementation as of now. It
> can be added later if needed.
> 
> The clocks "psm" and "pll_ref" are not used by the Rx path so check for
> them in the Tx path's probe() callback.
> 
> Signed-off-by: Pratyush Yadav <p.yadav@ti.com>

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

> 
> ---
> 
> Changes in v5:
> - Based on Laurent's suggestion, add cdns_dphy_info which contains the
>   phy_ops and cdns_dphy_tx_ops (renamed from cdns_dphy_ops). This lets us
>   get rid of the phy ops wrappers.
> - Move probe() and remove() into cdns_dphy_common_ops() since they can
>   be used by both modes. Drop the check in power_on().
> - Get the clocks in the tx ops probe to make sure they are mandatory for
>   Tx mode but not for Rx mode.
> 
> Changes in v4:
> - Instead of having both Rx and Tx modes in the same driver data, keep
>   them separate since the op selection is based on compatible now. For
>   that reason, the cdns_dphy_driver_data struct is no longer needed.
> - Rename ref_dphy_ops to tx_ref_dphy_ops to clarify their purpose.
> - Drop submode checks in validate() hook.
> 
>  drivers/phy/cadence/cdns-dphy.c | 169 ++++++++++++++++++++------------
>  1 file changed, 108 insertions(+), 61 deletions(-)
> 
> diff --git a/drivers/phy/cadence/cdns-dphy.c b/drivers/phy/cadence/cdns-dphy.c
> index ba042e39cfaf..e2c2b27c6539 100644
> --- a/drivers/phy/cadence/cdns-dphy.c
> +++ b/drivers/phy/cadence/cdns-dphy.c
> @@ -72,9 +72,13 @@ enum cdns_dphy_clk_lane_cfg {
>  };
>  
>  struct cdns_dphy;
> -struct cdns_dphy_ops {
> +
> +struct cdns_dphy_common_ops {
>  	int (*probe)(struct cdns_dphy *dphy);
>  	void (*remove)(struct cdns_dphy *dphy);
> +};
> +
> +struct cdns_dphy_tx_ops {
>  	void (*set_psm_div)(struct cdns_dphy *dphy, u8 div);
>  	void (*set_clk_lane_cfg)(struct cdns_dphy *dphy,
>  				 enum cdns_dphy_clk_lane_cfg cfg);
> @@ -83,12 +87,21 @@ struct cdns_dphy_ops {
>  	unsigned long (*get_wakeup_time_ns)(struct cdns_dphy *dphy);
>  };
>  
> +struct cdns_dphy_info {
> +	const struct phy_ops *phy_ops;
> +	const struct cdns_dphy_common_ops *common_ops;
> +
> +	/* Only set when DPHY is to be used in Tx mode. */
> +	const struct cdns_dphy_tx_ops *tx_ops;
> +};
> +
>  struct cdns_dphy {
>  	struct cdns_dphy_cfg cfg;
>  	void __iomem *regs;
> +	struct device *dev;
>  	struct clk *psm_clk;
>  	struct clk *pll_ref_clk;
> -	const struct cdns_dphy_ops *ops;
> +	const struct cdns_dphy_info *info;
>  	struct phy *phy;
>  };
>  
> @@ -135,6 +148,7 @@ static int cdns_dsi_get_dphy_pll_cfg(struct cdns_dphy *dphy,
>  
>  static int cdns_dphy_setup_psm(struct cdns_dphy *dphy)
>  {
> +	const struct cdns_dphy_tx_ops *ops = dphy->info->tx_ops;
>  	unsigned long psm_clk_hz = clk_get_rate(dphy->psm_clk);
>  	unsigned long psm_div;
>  
> @@ -142,8 +156,8 @@ static int cdns_dphy_setup_psm(struct cdns_dphy *dphy)
>  		return -EINVAL;
>  
>  	psm_div = DIV_ROUND_CLOSEST(psm_clk_hz, 1000000);
> -	if (dphy->ops->set_psm_div)
> -		dphy->ops->set_psm_div(dphy, psm_div);
> +	if (ops && ops->set_psm_div)
> +		ops->set_psm_div(dphy, psm_div);
>  
>  	return 0;
>  }
> @@ -151,20 +165,31 @@ static int cdns_dphy_setup_psm(struct cdns_dphy *dphy)
>  static void cdns_dphy_set_clk_lane_cfg(struct cdns_dphy *dphy,
>  				       enum cdns_dphy_clk_lane_cfg cfg)
>  {
> -	if (dphy->ops->set_clk_lane_cfg)
> -		dphy->ops->set_clk_lane_cfg(dphy, cfg);
> +	const struct cdns_dphy_tx_ops *ops = dphy->info->tx_ops;
> +
> +	if (ops && ops->set_clk_lane_cfg)
> +		ops->set_clk_lane_cfg(dphy, cfg);
>  }
>  
>  static void cdns_dphy_set_pll_cfg(struct cdns_dphy *dphy,
>  				  const struct cdns_dphy_cfg *cfg)
>  {
> -	if (dphy->ops->set_pll_cfg)
> -		dphy->ops->set_pll_cfg(dphy, cfg);
> +	const struct cdns_dphy_tx_ops *ops = dphy->info->tx_ops;
> +
> +	if (ops && ops->set_pll_cfg)
> +		ops->set_pll_cfg(dphy, cfg);
>  }
>  
>  static unsigned long cdns_dphy_get_wakeup_time_ns(struct cdns_dphy *dphy)
>  {
> -	return dphy->ops->get_wakeup_time_ns(dphy);
> +	const struct cdns_dphy_tx_ops *ops = dphy->info->tx_ops;
> +
> +	if (!ops || !ops->get_wakeup_time_ns) {
> +		dev_err(dphy->dev, "get_wakeup_time_ns() is required\n");
> +		return 0;
> +	}
> +
> +	return ops->get_wakeup_time_ns(dphy);
>  }
>  
>  static unsigned long cdns_dphy_ref_get_wakeup_time_ns(struct cdns_dphy *dphy)
> @@ -199,20 +224,9 @@ static void cdns_dphy_ref_set_psm_div(struct cdns_dphy *dphy, u8 div)
>  	       dphy->regs + DPHY_PSM_CFG);
>  }
>  
> -/*
> - * This is the reference implementation of DPHY hooks. Specific integration of
> - * this IP may have to re-implement some of them depending on how they decided
> - * to wire things in the SoC.
> - */
> -static const struct cdns_dphy_ops ref_dphy_ops = {
> -	.get_wakeup_time_ns = cdns_dphy_ref_get_wakeup_time_ns,
> -	.set_pll_cfg = cdns_dphy_ref_set_pll_cfg,
> -	.set_psm_div = cdns_dphy_ref_set_psm_div,
> -};
> -
> -static int cdns_dphy_config_from_opts(struct phy *phy,
> -				      struct phy_configure_opts_mipi_dphy *opts,
> -				      struct cdns_dphy_cfg *cfg)
> +static int cdns_dphy_tx_config_from_opts(struct phy *phy,
> +					 struct phy_configure_opts_mipi_dphy *opts,
> +					 struct cdns_dphy_cfg *cfg)
>  {
>  	struct cdns_dphy *dphy = phy_get_drvdata(phy);
>  	unsigned int dsi_hfp_ext = 0;
> @@ -232,24 +246,14 @@ static int cdns_dphy_config_from_opts(struct phy *phy,
>  	return 0;
>  }
>  
> -static int cdns_dphy_validate(struct phy *phy, enum phy_mode mode, int submode,
> -			      union phy_configure_opts *opts)
> -{
> -	struct cdns_dphy_cfg cfg = { 0 };
> -
> -	if (mode != PHY_MODE_MIPI_DPHY)
> -		return -EINVAL;
> -
> -	return cdns_dphy_config_from_opts(phy, &opts->mipi_dphy, &cfg);
> -}
> -
> -static int cdns_dphy_configure(struct phy *phy, union phy_configure_opts *opts)
> +static int cdns_dphy_tx_configure(struct phy *phy,
> +				  union phy_configure_opts *opts)
>  {
>  	struct cdns_dphy *dphy = phy_get_drvdata(phy);
>  	struct cdns_dphy_cfg cfg = { 0 };
>  	int ret;
>  
> -	ret = cdns_dphy_config_from_opts(phy, &opts->mipi_dphy, &cfg);
> +	ret = cdns_dphy_tx_config_from_opts(dphy->phy, &opts->mipi_dphy, &cfg);
>  	if (ret)
>  		return ret;
>  
> @@ -279,7 +283,19 @@ static int cdns_dphy_configure(struct phy *phy, union phy_configure_opts *opts)
>  	return 0;
>  }
>  
> -static int cdns_dphy_power_on(struct phy *phy)
> +static int cdns_dphy_tx_validate(struct phy *phy, enum phy_mode mode,
> +				 int submode, union phy_configure_opts *opts)
> +{
> +	struct cdns_dphy *dphy = phy_get_drvdata(phy);
> +	struct cdns_dphy_cfg cfg = { 0 };
> +
> +	if (mode != PHY_MODE_MIPI_DPHY)
> +		return -EINVAL;
> +
> +	return cdns_dphy_tx_config_from_opts(dphy->phy, &opts->mipi_dphy, &cfg);
> +}
> +
> +static int cdns_dphy_tx_power_on(struct phy *phy)
>  {
>  	struct cdns_dphy *dphy = phy_get_drvdata(phy);
>  
> @@ -293,7 +309,7 @@ static int cdns_dphy_power_on(struct phy *phy)
>  	return 0;
>  }
>  
> -static int cdns_dphy_power_off(struct phy *phy)
> +static int cdns_dphy_tx_power_off(struct phy *phy)
>  {
>  	struct cdns_dphy *dphy = phy_get_drvdata(phy);
>  
> @@ -303,16 +319,51 @@ static int cdns_dphy_power_off(struct phy *phy)
>  	return 0;
>  }
>  
> -static const struct phy_ops cdns_dphy_ops = {
> -	.configure	= cdns_dphy_configure,
> -	.validate	= cdns_dphy_validate,
> -	.power_on	= cdns_dphy_power_on,
> -	.power_off	= cdns_dphy_power_off,
> +static int cdns_dphy_tx_probe(struct cdns_dphy *dphy)
> +{
> +	dphy->psm_clk = devm_clk_get(dphy->dev, "psm");
> +	if (IS_ERR(dphy->psm_clk))
> +		return PTR_ERR(dphy->psm_clk);
> +
> +	dphy->pll_ref_clk = devm_clk_get(dphy->dev, "pll_ref");
> +	if (IS_ERR(dphy->pll_ref_clk))
> +		return PTR_ERR(dphy->pll_ref_clk);
> +
> +	return 0;
> +}
> +
> +/*
> + * This is the reference implementation of DPHY hooks. Specific integration of
> + * this IP may have to re-implement some of them depending on how they decided
> + * to wire things in the SoC.
> + */
> +static const struct cdns_dphy_tx_ops tx_ref_dphy_ops = {
> +	.get_wakeup_time_ns = cdns_dphy_ref_get_wakeup_time_ns,
> +	.set_pll_cfg = cdns_dphy_ref_set_pll_cfg,
> +	.set_psm_div = cdns_dphy_ref_set_psm_div,
> +};
> +
> +static const struct cdns_dphy_common_ops tx_ref_common_ops = {
> +	.probe = cdns_dphy_tx_probe,
> +};
> +
> +static const struct phy_ops tx_ref_phy_ops = {
> +	.power_on = cdns_dphy_tx_power_on,
> +	.power_off = cdns_dphy_tx_power_off,
> +	.validate = cdns_dphy_tx_validate,
> +	.configure = cdns_dphy_tx_configure,
> +};
> +
> +static const struct cdns_dphy_info tx_ref_info = {
> +	.phy_ops = &tx_ref_phy_ops,
> +	.common_ops = &tx_ref_common_ops,
> +	.tx_ops = &tx_ref_dphy_ops,
>  };
>  
>  static int cdns_dphy_probe(struct platform_device *pdev)
>  {
>  	struct phy_provider *phy_provider;
> +	const struct cdns_dphy_info *info;
>  	struct cdns_dphy *dphy;
>  	int ret;
>  
> @@ -320,34 +371,29 @@ static int cdns_dphy_probe(struct platform_device *pdev)
>  	if (!dphy)
>  		return -ENOMEM;
>  	dev_set_drvdata(&pdev->dev, dphy);
> +	dphy->dev = &pdev->dev;
>  
> -	dphy->ops = of_device_get_match_data(&pdev->dev);
> -	if (!dphy->ops)
> +	info = of_device_get_match_data(&pdev->dev);
> +	if (!info)
>  		return -EINVAL;
>  
> +	dphy->info = info;
> +
>  	dphy->regs = devm_platform_ioremap_resource(pdev, 0);
>  	if (IS_ERR(dphy->regs))
>  		return PTR_ERR(dphy->regs);
>  
> -	dphy->psm_clk = devm_clk_get(&pdev->dev, "psm");
> -	if (IS_ERR(dphy->psm_clk))
> -		return PTR_ERR(dphy->psm_clk);
> -
> -	dphy->pll_ref_clk = devm_clk_get(&pdev->dev, "pll_ref");
> -	if (IS_ERR(dphy->pll_ref_clk))
> -		return PTR_ERR(dphy->pll_ref_clk);
> -
> -	if (dphy->ops->probe) {
> -		ret = dphy->ops->probe(dphy);
> +	if (info->common_ops && info->common_ops->probe) {
> +		ret = info->common_ops->probe(dphy);
>  		if (ret)
>  			return ret;
>  	}
>  
> -	dphy->phy = devm_phy_create(&pdev->dev, NULL, &cdns_dphy_ops);
> +	dphy->phy = devm_phy_create(&pdev->dev, NULL, info->phy_ops);
>  	if (IS_ERR(dphy->phy)) {
>  		dev_err(&pdev->dev, "failed to create PHY\n");
> -		if (dphy->ops->remove)
> -			dphy->ops->remove(dphy);
> +		if (info->common_ops && info->common_ops->remove)
> +			info->common_ops->remove(dphy);
>  		return PTR_ERR(dphy->phy);
>  	}
>  
> @@ -361,15 +407,16 @@ static int cdns_dphy_probe(struct platform_device *pdev)
>  static int cdns_dphy_remove(struct platform_device *pdev)
>  {
>  	struct cdns_dphy *dphy = dev_get_drvdata(&pdev->dev);
> +	const struct cdns_dphy_info *info = dphy->info;
>  
> -	if (dphy->ops->remove)
> -		dphy->ops->remove(dphy);
> +	if (info->common_ops && info->common_ops->remove)
> +		info->common_ops->remove(dphy);
>  
>  	return 0;
>  }
>  
>  static const struct of_device_id cdns_dphy_of_match[] = {
> -	{ .compatible = "cdns,dphy", .data = &ref_dphy_ops },
> +	{ .compatible = "cdns,dphy", .data = &tx_ref_info },
>  	{ /* sentinel */ },
>  };
>  MODULE_DEVICE_TABLE(of, cdns_dphy_of_match);

-- 
Regards,

Laurent Pinchart

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v5 2/6] phy: cdns-dphy: Add Rx support

[Laurent Pinchart]

Hi Vinod,

On Fri, Oct 01, 2021 at 11:53:16AM +0530, Vinod Koul wrote:
> On 17-09-21, 22:58, Pratyush Yadav wrote:
> > On 16/09/21 12:22PM, Paul Kocialkowski wrote:
> > > On Fri 03 Sep 21, 00:25, Pratyush Yadav wrote:
> > > > The Cadence DPHY can be used to receive image data over the CSI-2
> > > > protocol. Add support for Rx mode. The programming sequence differs from
> > > > the Tx mode so it is added as a separate set of hooks to isolate the two
> > > > paths. The mode in which the DPHY has to be used is selected based on
> > > > the compatible.
> > > 
> > > I just realized that I didn't follow-up on a previous revision on the debate
> > > about using the phy sub-mode to distinguish between rx/tx.
> > > 
> > > I see that you've been using a dedicated compatible, but I'm not sure this is a
> > > good fit either. My understanding is that the compatible should describe a group
> > > of register-compatible revisions of a hardware component, not how the hardware
> > > is used specifically. I guess the distinction between rx/tx falls under
> > > the latter rather than the former.
> > 
> > I am not sure if that is the case. For example, we use "ti,am654-ospi" 
> > for Cadence Quadspi controller. The default compatible, "cdns,qspi-nor", 
> > only supports Quad SPI (4 lines). The "ti,am654-ospi" compatible also 
> > supports Octal SPI (8 lines).
> 
> Those are hardware defaults right?
> 
> > In addition, I feel like the Rx DPHY is almost a different type of 
> > device from a Tx DPHY. The programming sequence is completely different, 
> 
> Is that due to direction or something else..?
> 
> > the clocks required are different, etc. So I think using a different 
> > compatible for Rx mode makes sense.
> 
> Is the underlaying IP not capable of both TX and RX and in the specific
> situations you are using it as TX and RX.
> 
> I am okay that default being TX but you can use Paul's approach of
> direction with this to make it better proposal


Given that the RX and TX implementations are very different (it's not a
matter of selecting a mode at runtime), I'm actually tempted to
recommend having two drivers, one for the RX PHY and one for the TX PHY.
This can only be done with two different compatible strings, which I
think would be a better approach.

It's unfortunate that the original compatible string didn't contain
"tx". We could rename it and keep the old one in the driver for backward
compatibility, making things cleaner going forward.

-- 
Regards,

Laurent Pinchart

Re: [PATCH v5 2/6] phy: cdns-dphy: Add Rx support

[Laurent Pinchart]

Hi Vinod,

On Fri, Oct 01, 2021 at 11:53:16AM +0530, Vinod Koul wrote:
> On 17-09-21, 22:58, Pratyush Yadav wrote:
> > On 16/09/21 12:22PM, Paul Kocialkowski wrote:
> > > On Fri 03 Sep 21, 00:25, Pratyush Yadav wrote:
> > > > The Cadence DPHY can be used to receive image data over the CSI-2
> > > > protocol. Add support for Rx mode. The programming sequence differs from
> > > > the Tx mode so it is added as a separate set of hooks to isolate the two
> > > > paths. The mode in which the DPHY has to be used is selected based on
> > > > the compatible.
> > > 
> > > I just realized that I didn't follow-up on a previous revision on the debate
> > > about using the phy sub-mode to distinguish between rx/tx.
> > > 
> > > I see that you've been using a dedicated compatible, but I'm not sure this is a
> > > good fit either. My understanding is that the compatible should describe a group
> > > of register-compatible revisions of a hardware component, not how the hardware
> > > is used specifically. I guess the distinction between rx/tx falls under
> > > the latter rather than the former.
> > 
> > I am not sure if that is the case. For example, we use "ti,am654-ospi" 
> > for Cadence Quadspi controller. The default compatible, "cdns,qspi-nor", 
> > only supports Quad SPI (4 lines). The "ti,am654-ospi" compatible also 
> > supports Octal SPI (8 lines).
> 
> Those are hardware defaults right?
> 
> > In addition, I feel like the Rx DPHY is almost a different type of 
> > device from a Tx DPHY. The programming sequence is completely different, 
> 
> Is that due to direction or something else..?
> 
> > the clocks required are different, etc. So I think using a different 
> > compatible for Rx mode makes sense.
> 
> Is the underlaying IP not capable of both TX and RX and in the specific
> situations you are using it as TX and RX.
> 
> I am okay that default being TX but you can use Paul's approach of
> direction with this to make it better proposal


Given that the RX and TX implementations are very different (it's not a
matter of selecting a mode at runtime), I'm actually tempted to
recommend having two drivers, one for the RX PHY and one for the TX PHY.
This can only be done with two different compatible strings, which I
think would be a better approach.

It's unfortunate that the original compatible string didn't contain
"tx". We could rename it and keep the old one in the driver for backward
compatibility, making things cleaner going forward.

-- 
Regards,

Laurent Pinchart

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v5 2/6] phy: cdns-dphy: Add Rx support

[Pratyush Yadav]

On 07/10/21 03:10AM, Laurent Pinchart wrote:
> Hi Vinod,
> 
> On Fri, Oct 01, 2021 at 11:53:16AM +0530, Vinod Koul wrote:
> > On 17-09-21, 22:58, Pratyush Yadav wrote:
> > > On 16/09/21 12:22PM, Paul Kocialkowski wrote:
> > > > On Fri 03 Sep 21, 00:25, Pratyush Yadav wrote:
> > > > > The Cadence DPHY can be used to receive image data over the CSI-2
> > > > > protocol. Add support for Rx mode. The programming sequence differs from
> > > > > the Tx mode so it is added as a separate set of hooks to isolate the two
> > > > > paths. The mode in which the DPHY has to be used is selected based on
> > > > > the compatible.
> > > > 
> > > > I just realized that I didn't follow-up on a previous revision on the debate
> > > > about using the phy sub-mode to distinguish between rx/tx.
> > > > 
> > > > I see that you've been using a dedicated compatible, but I'm not sure this is a
> > > > good fit either. My understanding is that the compatible should describe a group
> > > > of register-compatible revisions of a hardware component, not how the hardware
> > > > is used specifically. I guess the distinction between rx/tx falls under
> > > > the latter rather than the former.
> > > 
> > > I am not sure if that is the case. For example, we use "ti,am654-ospi" 
> > > for Cadence Quadspi controller. The default compatible, "cdns,qspi-nor", 
> > > only supports Quad SPI (4 lines). The "ti,am654-ospi" compatible also 
> > > supports Octal SPI (8 lines).
> > 
> > Those are hardware defaults right?
> > 
> > > In addition, I feel like the Rx DPHY is almost a different type of 
> > > device from a Tx DPHY. The programming sequence is completely different, 
> > 
> > Is that due to direction or something else..?
> > 
> > > the clocks required are different, etc. So I think using a different 
> > > compatible for Rx mode makes sense.
> > 
> > Is the underlaying IP not capable of both TX and RX and in the specific
> > situations you are using it as TX and RX.
> > 
> > I am okay that default being TX but you can use Paul's approach of
> > direction with this to make it better proposal
> 
> 
> Given that the RX and TX implementations are very different (it's not a
> matter of selecting a mode at runtime), I'm actually tempted to
> recommend having two drivers, one for the RX PHY and one for the TX PHY.
> This can only be done with two different compatible strings, which I
> think would be a better approach.

FWIW, I think having different drivers would certainly make things 
easier to maintain.

> 
> It's unfortunate that the original compatible string didn't contain
> "tx". We could rename it and keep the old one in the driver for backward
> compatibility, making things cleaner going forward.
> 
> -- 
> Regards,
> 
> Laurent Pinchart

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.

Re: [PATCH v5 2/6] phy: cdns-dphy: Add Rx support

[Pratyush Yadav]

On 07/10/21 03:10AM, Laurent Pinchart wrote:
> Hi Vinod,
> 
> On Fri, Oct 01, 2021 at 11:53:16AM +0530, Vinod Koul wrote:
> > On 17-09-21, 22:58, Pratyush Yadav wrote:
> > > On 16/09/21 12:22PM, Paul Kocialkowski wrote:
> > > > On Fri 03 Sep 21, 00:25, Pratyush Yadav wrote:
> > > > > The Cadence DPHY can be used to receive image data over the CSI-2
> > > > > protocol. Add support for Rx mode. The programming sequence differs from
> > > > > the Tx mode so it is added as a separate set of hooks to isolate the two
> > > > > paths. The mode in which the DPHY has to be used is selected based on
> > > > > the compatible.
> > > > 
> > > > I just realized that I didn't follow-up on a previous revision on the debate
> > > > about using the phy sub-mode to distinguish between rx/tx.
> > > > 
> > > > I see that you've been using a dedicated compatible, but I'm not sure this is a
> > > > good fit either. My understanding is that the compatible should describe a group
> > > > of register-compatible revisions of a hardware component, not how the hardware
> > > > is used specifically. I guess the distinction between rx/tx falls under
> > > > the latter rather than the former.
> > > 
> > > I am not sure if that is the case. For example, we use "ti,am654-ospi" 
> > > for Cadence Quadspi controller. The default compatible, "cdns,qspi-nor", 
> > > only supports Quad SPI (4 lines). The "ti,am654-ospi" compatible also 
> > > supports Octal SPI (8 lines).
> > 
> > Those are hardware defaults right?
> > 
> > > In addition, I feel like the Rx DPHY is almost a different type of 
> > > device from a Tx DPHY. The programming sequence is completely different, 
> > 
> > Is that due to direction or something else..?
> > 
> > > the clocks required are different, etc. So I think using a different 
> > > compatible for Rx mode makes sense.
> > 
> > Is the underlaying IP not capable of both TX and RX and in the specific
> > situations you are using it as TX and RX.
> > 
> > I am okay that default being TX but you can use Paul's approach of
> > direction with this to make it better proposal
> 
> 
> Given that the RX and TX implementations are very different (it's not a
> matter of selecting a mode at runtime), I'm actually tempted to
> recommend having two drivers, one for the RX PHY and one for the TX PHY.
> This can only be done with two different compatible strings, which I
> think would be a better approach.

FWIW, I think having different drivers would certainly make things 
easier to maintain.

> 
> It's unfortunate that the original compatible string didn't contain
> "tx". We could rename it and keep the old one in the driver for backward
> compatibility, making things cleaner going forward.
> 
> -- 
> Regards,
> 
> Laurent Pinchart

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v5 2/6] phy: cdns-dphy: Add Rx support

[Laurent Pinchart]

Hi Pratyush,

On Thu, Oct 07, 2021 at 05:44:38PM +0530, Pratyush Yadav wrote:
> On 07/10/21 03:10AM, Laurent Pinchart wrote:
> > On Fri, Oct 01, 2021 at 11:53:16AM +0530, Vinod Koul wrote:
> > > On 17-09-21, 22:58, Pratyush Yadav wrote:
> > > > On 16/09/21 12:22PM, Paul Kocialkowski wrote:
> > > > > On Fri 03 Sep 21, 00:25, Pratyush Yadav wrote:
> > > > > > The Cadence DPHY can be used to receive image data over the CSI-2
> > > > > > protocol. Add support for Rx mode. The programming sequence differs from
> > > > > > the Tx mode so it is added as a separate set of hooks to isolate the two
> > > > > > paths. The mode in which the DPHY has to be used is selected based on
> > > > > > the compatible.
> > > > > 
> > > > > I just realized that I didn't follow-up on a previous revision on the debate
> > > > > about using the phy sub-mode to distinguish between rx/tx.
> > > > > 
> > > > > I see that you've been using a dedicated compatible, but I'm not sure this is a
> > > > > good fit either. My understanding is that the compatible should describe a group
> > > > > of register-compatible revisions of a hardware component, not how the hardware
> > > > > is used specifically. I guess the distinction between rx/tx falls under
> > > > > the latter rather than the former.
> > > > 
> > > > I am not sure if that is the case. For example, we use "ti,am654-ospi" 
> > > > for Cadence Quadspi controller. The default compatible, "cdns,qspi-nor", 
> > > > only supports Quad SPI (4 lines). The "ti,am654-ospi" compatible also 
> > > > supports Octal SPI (8 lines).
> > > 
> > > Those are hardware defaults right?
> > > 
> > > > In addition, I feel like the Rx DPHY is almost a different type of 
> > > > device from a Tx DPHY. The programming sequence is completely different, 
> > > 
> > > Is that due to direction or something else..?
> > > 
> > > > the clocks required are different, etc. So I think using a different 
> > > > compatible for Rx mode makes sense.
> > > 
> > > Is the underlaying IP not capable of both TX and RX and in the specific
> > > situations you are using it as TX and RX.
> > > 
> > > I am okay that default being TX but you can use Paul's approach of
> > > direction with this to make it better proposal
> > 
> > 
> > Given that the RX and TX implementations are very different (it's not a
> > matter of selecting a mode at runtime), I'm actually tempted to
> > recommend having two drivers, one for the RX PHY and one for the TX PHY.
> > This can only be done with two different compatible strings, which I
> > think would be a better approach.
> 
> FWIW, I think having different drivers would certainly make things 
> easier to maintain.

I'm sorry for not having recommended this in the first place.

Any objection from anyone against going in this direction ?

> > It's unfortunate that the original compatible string didn't contain
> > "tx". We could rename it and keep the old one in the driver for backward
> > compatibility, making things cleaner going forward.

-- 
Regards,

Laurent Pinchart

Re: [PATCH v5 2/6] phy: cdns-dphy: Add Rx support

[Laurent Pinchart]

Hi Pratyush,

On Thu, Oct 07, 2021 at 05:44:38PM +0530, Pratyush Yadav wrote:
> On 07/10/21 03:10AM, Laurent Pinchart wrote:
> > On Fri, Oct 01, 2021 at 11:53:16AM +0530, Vinod Koul wrote:
> > > On 17-09-21, 22:58, Pratyush Yadav wrote:
> > > > On 16/09/21 12:22PM, Paul Kocialkowski wrote:
> > > > > On Fri 03 Sep 21, 00:25, Pratyush Yadav wrote:
> > > > > > The Cadence DPHY can be used to receive image data over the CSI-2
> > > > > > protocol. Add support for Rx mode. The programming sequence differs from
> > > > > > the Tx mode so it is added as a separate set of hooks to isolate the two
> > > > > > paths. The mode in which the DPHY has to be used is selected based on
> > > > > > the compatible.
> > > > > 
> > > > > I just realized that I didn't follow-up on a previous revision on the debate
> > > > > about using the phy sub-mode to distinguish between rx/tx.
> > > > > 
> > > > > I see that you've been using a dedicated compatible, but I'm not sure this is a
> > > > > good fit either. My understanding is that the compatible should describe a group
> > > > > of register-compatible revisions of a hardware component, not how the hardware
> > > > > is used specifically. I guess the distinction between rx/tx falls under
> > > > > the latter rather than the former.
> > > > 
> > > > I am not sure if that is the case. For example, we use "ti,am654-ospi" 
> > > > for Cadence Quadspi controller. The default compatible, "cdns,qspi-nor", 
> > > > only supports Quad SPI (4 lines). The "ti,am654-ospi" compatible also 
> > > > supports Octal SPI (8 lines).
> > > 
> > > Those are hardware defaults right?
> > > 
> > > > In addition, I feel like the Rx DPHY is almost a different type of 
> > > > device from a Tx DPHY. The programming sequence is completely different, 
> > > 
> > > Is that due to direction or something else..?
> > > 
> > > > the clocks required are different, etc. So I think using a different 
> > > > compatible for Rx mode makes sense.
> > > 
> > > Is the underlaying IP not capable of both TX and RX and in the specific
> > > situations you are using it as TX and RX.
> > > 
> > > I am okay that default being TX but you can use Paul's approach of
> > > direction with this to make it better proposal
> > 
> > 
> > Given that the RX and TX implementations are very different (it's not a
> > matter of selecting a mode at runtime), I'm actually tempted to
> > recommend having two drivers, one for the RX PHY and one for the TX PHY.
> > This can only be done with two different compatible strings, which I
> > think would be a better approach.
> 
> FWIW, I think having different drivers would certainly make things 
> easier to maintain.

I'm sorry for not having recommended this in the first place.

Any objection from anyone against going in this direction ?

> > It's unfortunate that the original compatible string didn't contain
> > "tx". We could rename it and keep the old one in the driver for backward
> > compatibility, making things cleaner going forward.

-- 
Regards,

Laurent Pinchart

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v5 2/6] phy: cdns-dphy: Add Rx support

[Paul Kocialkowski]

[-- Attachment #1: Type: text/plain, Size: 3641 bytes --]

Hi,

On Fri 08 Oct 21, 13:27, Laurent Pinchart wrote:
> Hi Pratyush,
> 
> On Thu, Oct 07, 2021 at 05:44:38PM +0530, Pratyush Yadav wrote:
> > On 07/10/21 03:10AM, Laurent Pinchart wrote:
> > > On Fri, Oct 01, 2021 at 11:53:16AM +0530, Vinod Koul wrote:
> > > > On 17-09-21, 22:58, Pratyush Yadav wrote:
> > > > > On 16/09/21 12:22PM, Paul Kocialkowski wrote:
> > > > > > On Fri 03 Sep 21, 00:25, Pratyush Yadav wrote:
> > > > > > > The Cadence DPHY can be used to receive image data over the CSI-2
> > > > > > > protocol. Add support for Rx mode. The programming sequence differs from
> > > > > > > the Tx mode so it is added as a separate set of hooks to isolate the two
> > > > > > > paths. The mode in which the DPHY has to be used is selected based on
> > > > > > > the compatible.
> > > > > > 
> > > > > > I just realized that I didn't follow-up on a previous revision on the debate
> > > > > > about using the phy sub-mode to distinguish between rx/tx.
> > > > > > 
> > > > > > I see that you've been using a dedicated compatible, but I'm not sure this is a
> > > > > > good fit either. My understanding is that the compatible should describe a group
> > > > > > of register-compatible revisions of a hardware component, not how the hardware
> > > > > > is used specifically. I guess the distinction between rx/tx falls under
> > > > > > the latter rather than the former.
> > > > > 
> > > > > I am not sure if that is the case. For example, we use "ti,am654-ospi" 
> > > > > for Cadence Quadspi controller. The default compatible, "cdns,qspi-nor", 
> > > > > only supports Quad SPI (4 lines). The "ti,am654-ospi" compatible also 
> > > > > supports Octal SPI (8 lines).
> > > > 
> > > > Those are hardware defaults right?
> > > > 
> > > > > In addition, I feel like the Rx DPHY is almost a different type of 
> > > > > device from a Tx DPHY. The programming sequence is completely different, 
> > > > 
> > > > Is that due to direction or something else..?
> > > > 
> > > > > the clocks required are different, etc. So I think using a different 
> > > > > compatible for Rx mode makes sense.
> > > > 
> > > > Is the underlaying IP not capable of both TX and RX and in the specific
> > > > situations you are using it as TX and RX.
> > > > 
> > > > I am okay that default being TX but you can use Paul's approach of
> > > > direction with this to make it better proposal
> > > 
> > > 
> > > Given that the RX and TX implementations are very different (it's not a
> > > matter of selecting a mode at runtime), I'm actually tempted to
> > > recommend having two drivers, one for the RX PHY and one for the TX PHY.
> > > This can only be done with two different compatible strings, which I
> > > think would be a better approach.
> > 
> > FWIW, I think having different drivers would certainly make things 
> > easier to maintain.
> 
> I'm sorry for not having recommended this in the first place.
> 
> Any objection from anyone against going in this direction ?

So apparently there is not a single register that is shared between rx and tx
and clocks are not the same either so it feels to me like a separate driver
would be legit. This looks like two distinct IPs sharing the same base address.

Cheers,

Paul

> > > It's unfortunate that the original compatible string didn't contain
> > > "tx". We could rename it and keep the old one in the driver for backward
> > > compatibility, making things cleaner going forward.
> 
> -- 
> Regards,
> 
> Laurent Pinchart

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v5 2/6] phy: cdns-dphy: Add Rx support

[Paul Kocialkowski]

[-- Attachment #1.1: Type: text/plain, Size: 3641 bytes --]

Hi,

On Fri 08 Oct 21, 13:27, Laurent Pinchart wrote:
> Hi Pratyush,
> 
> On Thu, Oct 07, 2021 at 05:44:38PM +0530, Pratyush Yadav wrote:
> > On 07/10/21 03:10AM, Laurent Pinchart wrote:
> > > On Fri, Oct 01, 2021 at 11:53:16AM +0530, Vinod Koul wrote:
> > > > On 17-09-21, 22:58, Pratyush Yadav wrote:
> > > > > On 16/09/21 12:22PM, Paul Kocialkowski wrote:
> > > > > > On Fri 03 Sep 21, 00:25, Pratyush Yadav wrote:
> > > > > > > The Cadence DPHY can be used to receive image data over the CSI-2
> > > > > > > protocol. Add support for Rx mode. The programming sequence differs from
> > > > > > > the Tx mode so it is added as a separate set of hooks to isolate the two
> > > > > > > paths. The mode in which the DPHY has to be used is selected based on
> > > > > > > the compatible.
> > > > > > 
> > > > > > I just realized that I didn't follow-up on a previous revision on the debate
> > > > > > about using the phy sub-mode to distinguish between rx/tx.
> > > > > > 
> > > > > > I see that you've been using a dedicated compatible, but I'm not sure this is a
> > > > > > good fit either. My understanding is that the compatible should describe a group
> > > > > > of register-compatible revisions of a hardware component, not how the hardware
> > > > > > is used specifically. I guess the distinction between rx/tx falls under
> > > > > > the latter rather than the former.
> > > > > 
> > > > > I am not sure if that is the case. For example, we use "ti,am654-ospi" 
> > > > > for Cadence Quadspi controller. The default compatible, "cdns,qspi-nor", 
> > > > > only supports Quad SPI (4 lines). The "ti,am654-ospi" compatible also 
> > > > > supports Octal SPI (8 lines).
> > > > 
> > > > Those are hardware defaults right?
> > > > 
> > > > > In addition, I feel like the Rx DPHY is almost a different type of 
> > > > > device from a Tx DPHY. The programming sequence is completely different, 
> > > > 
> > > > Is that due to direction or something else..?
> > > > 
> > > > > the clocks required are different, etc. So I think using a different 
> > > > > compatible for Rx mode makes sense.
> > > > 
> > > > Is the underlaying IP not capable of both TX and RX and in the specific
> > > > situations you are using it as TX and RX.
> > > > 
> > > > I am okay that default being TX but you can use Paul's approach of
> > > > direction with this to make it better proposal
> > > 
> > > 
> > > Given that the RX and TX implementations are very different (it's not a
> > > matter of selecting a mode at runtime), I'm actually tempted to
> > > recommend having two drivers, one for the RX PHY and one for the TX PHY.
> > > This can only be done with two different compatible strings, which I
> > > think would be a better approach.
> > 
> > FWIW, I think having different drivers would certainly make things 
> > easier to maintain.
> 
> I'm sorry for not having recommended this in the first place.
> 
> Any objection from anyone against going in this direction ?

So apparently there is not a single register that is shared between rx and tx
and clocks are not the same either so it feels to me like a separate driver
would be legit. This looks like two distinct IPs sharing the same base address.

Cheers,

Paul

> > > It's unfortunate that the original compatible string didn't contain
> > > "tx". We could rename it and keep the old one in the driver for backward
> > > compatibility, making things cleaner going forward.
> 
> -- 
> Regards,
> 
> Laurent Pinchart

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 112 bytes --]

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v5 2/6] phy: cdns-dphy: Add Rx support

[Vinod Koul]

On 08-10-21, 14:55, Paul Kocialkowski wrote:
> Hi,
> 
> On Fri 08 Oct 21, 13:27, Laurent Pinchart wrote:
> > Hi Pratyush,
> > 
> > On Thu, Oct 07, 2021 at 05:44:38PM +0530, Pratyush Yadav wrote:
> > > On 07/10/21 03:10AM, Laurent Pinchart wrote:
> > > > On Fri, Oct 01, 2021 at 11:53:16AM +0530, Vinod Koul wrote:
> > > > > On 17-09-21, 22:58, Pratyush Yadav wrote:
> > > > > > On 16/09/21 12:22PM, Paul Kocialkowski wrote:
> > > > > > > On Fri 03 Sep 21, 00:25, Pratyush Yadav wrote:
> > > > > > > > The Cadence DPHY can be used to receive image data over the CSI-2
> > > > > > > > protocol. Add support for Rx mode. The programming sequence differs from
> > > > > > > > the Tx mode so it is added as a separate set of hooks to isolate the two
> > > > > > > > paths. The mode in which the DPHY has to be used is selected based on
> > > > > > > > the compatible.
> > > > > > > 
> > > > > > > I just realized that I didn't follow-up on a previous revision on the debate
> > > > > > > about using the phy sub-mode to distinguish between rx/tx.
> > > > > > > 
> > > > > > > I see that you've been using a dedicated compatible, but I'm not sure this is a
> > > > > > > good fit either. My understanding is that the compatible should describe a group
> > > > > > > of register-compatible revisions of a hardware component, not how the hardware
> > > > > > > is used specifically. I guess the distinction between rx/tx falls under
> > > > > > > the latter rather than the former.
> > > > > > 
> > > > > > I am not sure if that is the case. For example, we use "ti,am654-ospi" 
> > > > > > for Cadence Quadspi controller. The default compatible, "cdns,qspi-nor", 
> > > > > > only supports Quad SPI (4 lines). The "ti,am654-ospi" compatible also 
> > > > > > supports Octal SPI (8 lines).
> > > > > 
> > > > > Those are hardware defaults right?
> > > > > 
> > > > > > In addition, I feel like the Rx DPHY is almost a different type of 
> > > > > > device from a Tx DPHY. The programming sequence is completely different, 
> > > > > 
> > > > > Is that due to direction or something else..?
> > > > > 
> > > > > > the clocks required are different, etc. So I think using a different 
> > > > > > compatible for Rx mode makes sense.
> > > > > 
> > > > > Is the underlaying IP not capable of both TX and RX and in the specific
> > > > > situations you are using it as TX and RX.
> > > > > 
> > > > > I am okay that default being TX but you can use Paul's approach of
> > > > > direction with this to make it better proposal
> > > > 
> > > > 
> > > > Given that the RX and TX implementations are very different (it's not a
> > > > matter of selecting a mode at runtime), I'm actually tempted to
> > > > recommend having two drivers, one for the RX PHY and one for the TX PHY.
> > > > This can only be done with two different compatible strings, which I
> > > > think would be a better approach.
> > > 
> > > FWIW, I think having different drivers would certainly make things 
> > > easier to maintain.
> > 
> > I'm sorry for not having recommended this in the first place.
> > 
> > Any objection from anyone against going in this direction ?
> 
> So apparently there is not a single register that is shared between rx and tx
> and clocks are not the same either so it feels to me like a separate driver
> would be legit. This looks like two distinct IPs sharing the same base address.

Sorry for delay in getting back..

Okay lets have a different compatible and driver for this

-- 
~Vinod

Re: [PATCH v5 2/6] phy: cdns-dphy: Add Rx support

[Vinod Koul]

On 08-10-21, 14:55, Paul Kocialkowski wrote:
> Hi,
> 
> On Fri 08 Oct 21, 13:27, Laurent Pinchart wrote:
> > Hi Pratyush,
> > 
> > On Thu, Oct 07, 2021 at 05:44:38PM +0530, Pratyush Yadav wrote:
> > > On 07/10/21 03:10AM, Laurent Pinchart wrote:
> > > > On Fri, Oct 01, 2021 at 11:53:16AM +0530, Vinod Koul wrote:
> > > > > On 17-09-21, 22:58, Pratyush Yadav wrote:
> > > > > > On 16/09/21 12:22PM, Paul Kocialkowski wrote:
> > > > > > > On Fri 03 Sep 21, 00:25, Pratyush Yadav wrote:
> > > > > > > > The Cadence DPHY can be used to receive image data over the CSI-2
> > > > > > > > protocol. Add support for Rx mode. The programming sequence differs from
> > > > > > > > the Tx mode so it is added as a separate set of hooks to isolate the two
> > > > > > > > paths. The mode in which the DPHY has to be used is selected based on
> > > > > > > > the compatible.
> > > > > > > 
> > > > > > > I just realized that I didn't follow-up on a previous revision on the debate
> > > > > > > about using the phy sub-mode to distinguish between rx/tx.
> > > > > > > 
> > > > > > > I see that you've been using a dedicated compatible, but I'm not sure this is a
> > > > > > > good fit either. My understanding is that the compatible should describe a group
> > > > > > > of register-compatible revisions of a hardware component, not how the hardware
> > > > > > > is used specifically. I guess the distinction between rx/tx falls under
> > > > > > > the latter rather than the former.
> > > > > > 
> > > > > > I am not sure if that is the case. For example, we use "ti,am654-ospi" 
> > > > > > for Cadence Quadspi controller. The default compatible, "cdns,qspi-nor", 
> > > > > > only supports Quad SPI (4 lines). The "ti,am654-ospi" compatible also 
> > > > > > supports Octal SPI (8 lines).
> > > > > 
> > > > > Those are hardware defaults right?
> > > > > 
> > > > > > In addition, I feel like the Rx DPHY is almost a different type of 
> > > > > > device from a Tx DPHY. The programming sequence is completely different, 
> > > > > 
> > > > > Is that due to direction or something else..?
> > > > > 
> > > > > > the clocks required are different, etc. So I think using a different 
> > > > > > compatible for Rx mode makes sense.
> > > > > 
> > > > > Is the underlaying IP not capable of both TX and RX and in the specific
> > > > > situations you are using it as TX and RX.
> > > > > 
> > > > > I am okay that default being TX but you can use Paul's approach of
> > > > > direction with this to make it better proposal
> > > > 
> > > > 
> > > > Given that the RX and TX implementations are very different (it's not a
> > > > matter of selecting a mode at runtime), I'm actually tempted to
> > > > recommend having two drivers, one for the RX PHY and one for the TX PHY.
> > > > This can only be done with two different compatible strings, which I
> > > > think would be a better approach.
> > > 
> > > FWIW, I think having different drivers would certainly make things 
> > > easier to maintain.
> > 
> > I'm sorry for not having recommended this in the first place.
> > 
> > Any objection from anyone against going in this direction ?
> 
> So apparently there is not a single register that is shared between rx and tx
> and clocks are not the same either so it feels to me like a separate driver
> would be legit. This looks like two distinct IPs sharing the same base address.

Sorry for delay in getting back..

Okay lets have a different compatible and driver for this

-- 
~Vinod

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy