dwc3 on XU3 and XU4

Odroid XU4 board does not enumerate SuperSpeed devices. This patch makes exynos5 series chips use USB SUSPHY quirk, which solves the problem.

Signed-off-by Andrzej Pietrasiewicz <[email protected]>

---
 arch/arm/boot/dts/exynos54xx.dtsi | 2 ++
 1 file changed, 2 insertions(+)

arch/arm/boot/dts/exynos54xx.dtsi +2 -0

index 0389e8a..8ca4fef 100644
@@ -134,6 +134,7 @@
 				interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
 				phys = <&usbdrd_phy0 0>, <&usbdrd_phy0 1>;
 				phy-names = "usb2-phy", "usb3-phy";
+				snps,dis_u3_susphy_quirk;
 			};
 		};
 

@@ -154,6 +155,7 @@
 				reg = <0x12400000 0x10000>;
 				phys = <&usbdrd_phy1 0>, <&usbdrd_phy1 1>;
 				phy-names = "usb2-phy", "usb3-phy";
+				snps,dis_u3_susphy_quirk;
 			};
 		};
 

Signature · 1 line

1.9.1

Quoted 8 lines · Andrzej Pietrasiewicz

Odroid XU4 board does not enumerate SuperSpeed devices. This patch makes exynos5 series chips use USB SUSPHY quirk, which solves the problem.

Signed-off-by Andrzej Pietrasiewicz <[email protected]>

---
 arch/arm/boot/dts/exynos54xx.dtsi | 2 ++
 1 file changed, 2 insertions(+)

Makes sense to me... was it tested also on XU3 and XU?

Best regards,
Krzysztof

Quoted 24 lines

arch/arm/boot/dts/exynos54xx.dtsi +2 -0

index 0389e8a..8ca4fef 100644
@@ -134,6 +134,7 @@
 				interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
 				phys = <&usbdrd_phy0 0>, <&usbdrd_phy0 1>;
 				phy-names = "usb2-phy", "usb3-phy";
+				snps,dis_u3_susphy_quirk;
 			};
 		};
 

@@ -154,6 +155,7 @@
 				reg = <0x12400000 0x10000>;
 				phys = <&usbdrd_phy1 0>, <&usbdrd_phy1 1>;
 				phy-names = "usb2-phy", "usb3-phy";
+				snps,dis_u3_susphy_quirk;
 			};
 		};
 

Signature · 1 line

1.9.1

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Quoted 10 lines · Andrzej Pietrasiewicz

Quoted 8 lines

Odroid XU4 board does not enumerate SuperSpeed devices. This patch makes exynos5 series chips use USB SUSPHY quirk, which solves the problem.

Signed-off-by Andrzej Pietrasiewicz <[email protected]>

---
  arch/arm/boot/dts/exynos54xx.dtsi | 2 ++
  1 file changed, 2 insertions(+)

Quoted 1 line

Makes sense to me... was it tested also on XU3 and XU?

Well, it at least doesn't make USB3 on my XU any more or less broken than it was before ;) (both ports still report an over-current condition even with nothing plugged in - I suspect there's probably still some pinctrl/regulator stuff missing)

Robin.

Hi,

W dniu 19.09.2017 o?20:10, Robin Murphy pisze:

Quoted 18 lines · Krzysztof Kozlowski

Quoted 11 lines · Andrzej Pietrasiewicz

Quoted 8 lines

Odroid XU4 board does not enumerate SuperSpeed devices. This patch makes exynos5 series chips use USB SUSPHY quirk, which solves the problem.

Signed-off-by Andrzej Pietrasiewicz <[email protected]>

---
  arch/arm/boot/dts/exynos54xx.dtsi | 2 ++
  1 file changed, 2 insertions(+)

Makes sense to me... was it tested also on XU3 and XU?

Well, it at least doesn't make USB3 on my XU any more or less broken than it was before ;) (both ports still report an over-current condition even with nothing plugged in - I suspect there's probably still some pinctrl/regulator stuff missing)

Quoted 2 lines

Robin.

Similar with XU3: nothing is any more or less broken with this patch compared to the situation without the patch.

From: Vivek Gautam <[email protected]>

Adding phy calibration sequence for USB 3.0 DRD PHY present on Exynos5420/5800 systems.
This calibration facilitates setting certain PHY parameters viz. the Loss-of-Signal (LOS) Detector Threshold Level, as well as Tx-Vboost-Level for Super-Speed operations.
Additionally we also set proper time to wait for RxDetect measurement, for desired PHY reference clock, so as to solve issue with enumeration of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive on the controller.

We are using CR_port for this purpose to send required data to override the LOS values.

On testing with USB 3.0 devices on USB 3.0 port present on SMDK5420, and peach-pit boards should see following message:
usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd

and without this patch, should see below shown message:
usb 1-1: new high-speed USB device number 2 using xhci-hcd

[Also removed unnecessary extra lines in the register macro definitions]

Signed-off-by Vivek Gautam <[email protected]>

[adapted to use phy_reset as entry point]

Signed-off-by Andrzej Pietrasiewicz <[email protected]>

---
 drivers/phy/samsung/phy-exynos5-usbdrd.c | 183 +++++++++++++++++++++++++++++++
 drivers/usb/dwc3/core.c                  |   8 +-
 2 files changed, 189 insertions(+), 2 deletions(-)

drivers/phy/samsung/phy-exynos5-usbdrd.c +183 -0

index 7c41daa..f7de067 100644
@@ -89,7 +89,17 @@
 #define PHYCLKRST_COMMONONN			BIT(0)
 
 #define EXYNOS5_DRD_PHYREG0			0x14
+#define PHYREG0_SSC_REF_CLK_SEL			BIT(21)
+#define PHYREG0_SSC_RANGE			BIT(20)
+#define PHYREG0_CR_WRITE			BIT(19)
+#define PHYREG0_CR_READ				BIT(18)
+#define PHYREG0_CR_DATA_IN(_x)			((_x) << 2)
+#define PHYREG0_CR_CAP_DATA			BIT(1)
+#define PHYREG0_CR_CAP_ADDR			BIT(0)
+
 #define EXYNOS5_DRD_PHYREG1			0x18
+#define PHYREG1_CR_DATA_OUT(_x)			((_x) << 1)
+#define PHYREG1_CR_ACK				BIT(0)
 
 #define EXYNOS5_DRD_PHYPARAM0			0x1c
 

@@ -118,6 +128,25 @@
 #define EXYNOS5_DRD_PHYRESUME			0x34
 #define EXYNOS5_DRD_LINKPORT			0x44
 
+/* USB 3.0 DRD PHY SS Function Control Reg; accessed by CR_PORT */
+#define EXYNOS5_DRD_PHYSS_LOSLEVEL_OVRD_IN		(0x15)
+#define LOSLEVEL_OVRD_IN_LOS_BIAS_5420			(0x5 << 13)
+#define LOSLEVEL_OVRD_IN_LOS_BIAS_DEFAULT		(0x0 << 13)
+#define LOSLEVEL_OVRD_IN_EN				(0x1 << 10)
+#define LOSLEVEL_OVRD_IN_LOS_LEVEL_DEFAULT		(0x9 << 0)
+
+#define EXYNOS5_DRD_PHYSS_TX_VBOOSTLEVEL_OVRD_IN	(0x12)
+#define TX_VBOOSTLEVEL_OVRD_IN_VBOOST_5420		(0x5 << 13)
+#define TX_VBOOSTLEVEL_OVRD_IN_VBOOST_DEFAULT		(0x4 << 13)
+
+#define EXYNOS5_DRD_PHYSS_LANE0_TX_DEBUG		(0x1010)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_19M2_20M		(0x4 << 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_24M		(0x8 << 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_25M_26M		(0x8 << 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_48M_50M_52M	(0x20 << 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_62M5		(0x20 << 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_96M_100M		(0x40 << 4)
+
 #define KHZ	1000
 #define MHZ	(KHZ * KHZ)
 

@@ -526,6 +555,151 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
 	return 0;
 }
 
+static int crport_handshake(struct exynos5_usbdrd_phy *phy_drd,
+						u32 val, u32 cmd)
+{
+	u32 usec = 100;
+	unsigned int result;
+
+	writel(val | cmd, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
+
+	do {
+		result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
+		if (result & PHYREG1_CR_ACK)
+			break;
+
+		udelay(1);
+	} while (usec-- > 0);
+
+	if (!usec) {
+		dev_err(phy_drd->dev,
+			"CRPORT handshake timeout1 (0x%08x)\n", val);
+		return -ETIME;
+	}
+
+	usec = 100;
+
+	writel(val, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
+
+	do {
+		result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
+		if (!(result & PHYREG1_CR_ACK))
+			break;
+
+		udelay(1);
+	} while (usec-- > 0);
+
+	if (!usec) {
+		dev_err(phy_drd->dev,
+			"CRPORT handshake timeout2 (0x%08x)\n", val);
+		return -ETIME;
+	}
+
+	return 0;
+}
+
+static int crport_ctrl_write(struct exynos5_usbdrd_phy *phy_drd,
+						u32 addr, u32 data)
+{
+	int ret;
+
+	/* Write Address */
+	writel(PHYREG0_CR_DATA_IN(addr),
+		phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
+	ret = crport_handshake(phy_drd, PHYREG0_CR_DATA_IN(addr),
+				PHYREG0_CR_CAP_ADDR);
+	if (ret)
+		return ret;
+
+	/* Write Data */
+	writel(PHYREG0_CR_DATA_IN(data),
+		phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
+	ret = crport_handshake(phy_drd, PHYREG0_CR_DATA_IN(data),
+				PHYREG0_CR_CAP_DATA);
+	if (ret)
+		return ret;
+
+	ret = crport_handshake(phy_drd, PHYREG0_CR_DATA_IN(data),
+				PHYREG0_CR_WRITE);
+
+	return ret;
+}
+
+/*
+ * Calibrate few PHY parameters using CR_PORT register to meet
+ * SuperSpeed requirements on Exynos5420 and Exynos5800 systems,
+ * which have 28nm USB 3.0 DRD PHY.
+ */
+static int exynos5420_usbdrd_phy_calibrate(struct exynos5_usbdrd_phy *phy_drd)
+{
+	unsigned int temp;
+	int ret = 0;
+
+	/*
+	 * Change los_bias to (0x5) for 28nm PHY from a
+	 * default value (0x0); los_level is set as default
+	 * (0x9) as also reflected in los_level[30:26] bits
+	 * of PHYPARAM0 register.
+	 */
+	temp = LOSLEVEL_OVRD_IN_LOS_BIAS_5420 |
+		LOSLEVEL_OVRD_IN_EN |
+		LOSLEVEL_OVRD_IN_LOS_LEVEL_DEFAULT;
+	ret = crport_ctrl_write(phy_drd,
+				EXYNOS5_DRD_PHYSS_LOSLEVEL_OVRD_IN,
+				temp);
+	if (ret) {
+		dev_err(phy_drd->dev,
+		 "Failed setting Loss-of-Signal level for SuperSpeed\n");
+		return ret;
+	}
+
+	/*
+	 * Set tx_vboost_lvl to (0x5) for 28nm PHY Tuning,
+	 * to raise Tx signal level from its default value of (0x4)
+	 */
+	temp = TX_VBOOSTLEVEL_OVRD_IN_VBOOST_5420;
+	ret = crport_ctrl_write(phy_drd,
+				EXYNOS5_DRD_PHYSS_TX_VBOOSTLEVEL_OVRD_IN,
+				temp);
+	if (ret) {
+		dev_err(phy_drd->dev,
+		 "Failed setting Tx-Vboost-Level for SuperSpeed\n");
+		return ret;
+	}
+
+	/*
+	 * Set proper time to wait for RxDetect measurement, for
+	 * desired reference clock of PHY, by tuning the CR_PORT
+	 * register LANE0.TX_DEBUG which is internal to PHY.
+	 * This fixes issue with few USB 3.0 devices, which are
+	 * not detected (not even generate interrupts on the bus
+	 * on insertion) without this change.
+	 * e.g. Samsung SUM-TSB16S 3.0 USB drive.
+	 */
+	switch (phy_drd->extrefclk) {
+	case EXYNOS5_FSEL_50MHZ:
+		temp = LANE0_TX_DEBUG_RXDET_MEAS_TIME_48M_50M_52M;
+		break;
+	case EXYNOS5_FSEL_20MHZ:
+	case EXYNOS5_FSEL_19MHZ2:
+		temp = LANE0_TX_DEBUG_RXDET_MEAS_TIME_19M2_20M;
+		break;
+	case EXYNOS5_FSEL_24MHZ:
+	default:
+		temp = LANE0_TX_DEBUG_RXDET_MEAS_TIME_24M;
+		break;
+	}
+
+	ret = crport_ctrl_write(phy_drd,
+				EXYNOS5_DRD_PHYSS_LANE0_TX_DEBUG,
+				temp);
+	if (ret)
+		dev_err(phy_drd->dev,
+		 "Failed setting RxDetect measurement time for SuperSpeed\n");
+
+	return ret;
+}
+
 static struct phy *exynos5_usbdrd_phy_xlate(struct device *dev,
 					struct of_phandle_args *args)
 {

@@ -537,11 +711,20 @@ static struct phy *exynos5_usbdrd_phy_xlate(struct device *dev,
 	return phy_drd->phys[args->args[0]].phy;
 }
 
+static int exynos5_usbdrd_phy_reset(struct phy *phy)
+{
+	struct phy_usb_instance *inst = phy_get_drvdata(phy);
+	struct exynos5_usbdrd_phy *phy_drd = to_usbdrd_phy(inst);
+
+	return exynos5420_usbdrd_phy_calibrate(phy_drd);
+}
+
 static const struct phy_ops exynos5_usbdrd_phy_ops = {
 	.init		= exynos5_usbdrd_phy_init,
 	.exit		= exynos5_usbdrd_phy_exit,
 	.power_on	= exynos5_usbdrd_phy_power_on,
 	.power_off	= exynos5_usbdrd_phy_power_off,
+	.reset		= exynos5_usbdrd_phy_reset,
 	.owner		= THIS_MODULE,
 };
 

drivers/usb/dwc3/core.c +0 -0

index 03474d3..1d5836e 100644

Hi,

Quoted 253 lines · Andrzej Pietrasiewicz

From: Vivek Gautam <[email protected]>

Adding phy calibration sequence for USB 3.0 DRD PHY present on Exynos5420/5800 systems.
This calibration facilitates setting certain PHY parameters viz. the Loss-of-Signal (LOS) Detector Threshold Level, as well as Tx-Vboost-Level for Super-Speed operations.
Additionally we also set proper time to wait for RxDetect measurement, for desired PHY reference clock, so as to solve issue with enumeration of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive on the controller.

We are using CR_port for this purpose to send required data to override the LOS values.

On testing with USB 3.0 devices on USB 3.0 port present on SMDK5420, and peach-pit boards should see following message:
usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd

and without this patch, should see below shown message:
usb 1-1: new high-speed USB device number 2 using xhci-hcd

[Also removed unnecessary extra lines in the register macro definitions]

Signed-off-by Vivek Gautam <[email protected]>

[adapted to use phy_reset as entry point]

Signed-off-by Andrzej Pietrasiewicz <[email protected]>

---
 drivers/phy/samsung/phy-exynos5-usbdrd.c | 183 +++++++++++++++++++++++++++++++
 drivers/usb/dwc3/core.c                  |   8 +-
 2 files changed, 189 insertions(+), 2 deletions(-)

drivers/phy/samsung/phy-exynos5-usbdrd.c +183 -0

index 7c41daa..f7de067 100644
@@ -89,7 +89,17 @@
 #define PHYCLKRST_COMMONONN			BIT(0)
 
 #define EXYNOS5_DRD_PHYREG0			0x14
+#define PHYREG0_SSC_REF_CLK_SEL			BIT(21)
+#define PHYREG0_SSC_RANGE			BIT(20)
+#define PHYREG0_CR_WRITE			BIT(19)
+#define PHYREG0_CR_READ				BIT(18)
+#define PHYREG0_CR_DATA_IN(_x)			((_x) << 2)
+#define PHYREG0_CR_CAP_DATA			BIT(1)
+#define PHYREG0_CR_CAP_ADDR			BIT(0)
+
 #define EXYNOS5_DRD_PHYREG1			0x18
+#define PHYREG1_CR_DATA_OUT(_x)			((_x) << 1)
+#define PHYREG1_CR_ACK				BIT(0)
 
 #define EXYNOS5_DRD_PHYPARAM0			0x1c
 

@@ -118,6 +128,25 @@
 #define EXYNOS5_DRD_PHYRESUME			0x34
 #define EXYNOS5_DRD_LINKPORT			0x44
 
+/* USB 3.0 DRD PHY SS Function Control Reg; accessed by CR_PORT */
+#define EXYNOS5_DRD_PHYSS_LOSLEVEL_OVRD_IN		(0x15)
+#define LOSLEVEL_OVRD_IN_LOS_BIAS_5420			(0x5 << 13)
+#define LOSLEVEL_OVRD_IN_LOS_BIAS_DEFAULT		(0x0 << 13)
+#define LOSLEVEL_OVRD_IN_EN				(0x1 << 10)
+#define LOSLEVEL_OVRD_IN_LOS_LEVEL_DEFAULT		(0x9 << 0)
+
+#define EXYNOS5_DRD_PHYSS_TX_VBOOSTLEVEL_OVRD_IN	(0x12)
+#define TX_VBOOSTLEVEL_OVRD_IN_VBOOST_5420		(0x5 << 13)
+#define TX_VBOOSTLEVEL_OVRD_IN_VBOOST_DEFAULT		(0x4 << 13)
+
+#define EXYNOS5_DRD_PHYSS_LANE0_TX_DEBUG		(0x1010)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_19M2_20M		(0x4 << 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_24M		(0x8 << 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_25M_26M		(0x8 << 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_48M_50M_52M	(0x20 << 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_62M5		(0x20 << 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_96M_100M		(0x40 << 4)
+
 #define KHZ	1000
 #define MHZ	(KHZ * KHZ)
 

@@ -526,6 +555,151 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
 	return 0;
 }
 
+static int crport_handshake(struct exynos5_usbdrd_phy *phy_drd,
+						u32 val, u32 cmd)
+{
+	u32 usec = 100;
+	unsigned int result;
+
+	writel(val | cmd, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
+
+	do {
+		result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
+		if (result & PHYREG1_CR_ACK)
+			break;
+
+		udelay(1);
+	} while (usec-- > 0);
+
+	if (!usec) {
+		dev_err(phy_drd->dev,
+			"CRPORT handshake timeout1 (0x%08x)\n", val);
+		return -ETIME;
+	}
+
+	usec = 100;
+
+	writel(val, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
+
+	do {
+		result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
+		if (!(result & PHYREG1_CR_ACK))
+			break;
+
+		udelay(1);
+	} while (usec-- > 0);
+
+	if (!usec) {
+		dev_err(phy_drd->dev,
+			"CRPORT handshake timeout2 (0x%08x)\n", val);
+		return -ETIME;
+	}
+
+	return 0;
+}
+
+static int crport_ctrl_write(struct exynos5_usbdrd_phy *phy_drd,
+						u32 addr, u32 data)
+{
+	int ret;
+
+	/* Write Address */
+	writel(PHYREG0_CR_DATA_IN(addr),
+		phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
+	ret = crport_handshake(phy_drd, PHYREG0_CR_DATA_IN(addr),
+				PHYREG0_CR_CAP_ADDR);
+	if (ret)
+		return ret;
+
+	/* Write Data */
+	writel(PHYREG0_CR_DATA_IN(data),
+		phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
+	ret = crport_handshake(phy_drd, PHYREG0_CR_DATA_IN(data),
+				PHYREG0_CR_CAP_DATA);
+	if (ret)
+		return ret;
+
+	ret = crport_handshake(phy_drd, PHYREG0_CR_DATA_IN(data),
+				PHYREG0_CR_WRITE);
+
+	return ret;
+}
+
+/*
+ * Calibrate few PHY parameters using CR_PORT register to meet
+ * SuperSpeed requirements on Exynos5420 and Exynos5800 systems,
+ * which have 28nm USB 3.0 DRD PHY.
+ */
+static int exynos5420_usbdrd_phy_calibrate(struct exynos5_usbdrd_phy *phy_drd)
+{
+	unsigned int temp;
+	int ret = 0;
+
+	/*
+	 * Change los_bias to (0x5) for 28nm PHY from a
+	 * default value (0x0); los_level is set as default
+	 * (0x9) as also reflected in los_level[30:26] bits
+	 * of PHYPARAM0 register.
+	 */
+	temp = LOSLEVEL_OVRD_IN_LOS_BIAS_5420 |
+		LOSLEVEL_OVRD_IN_EN |
+		LOSLEVEL_OVRD_IN_LOS_LEVEL_DEFAULT;
+	ret = crport_ctrl_write(phy_drd,
+				EXYNOS5_DRD_PHYSS_LOSLEVEL_OVRD_IN,
+				temp);
+	if (ret) {
+		dev_err(phy_drd->dev,
+		 "Failed setting Loss-of-Signal level for SuperSpeed\n");
+		return ret;
+	}
+
+	/*
+	 * Set tx_vboost_lvl to (0x5) for 28nm PHY Tuning,
+	 * to raise Tx signal level from its default value of (0x4)
+	 */
+	temp = TX_VBOOSTLEVEL_OVRD_IN_VBOOST_5420;
+	ret = crport_ctrl_write(phy_drd,
+				EXYNOS5_DRD_PHYSS_TX_VBOOSTLEVEL_OVRD_IN,
+				temp);
+	if (ret) {
+		dev_err(phy_drd->dev,
+		 "Failed setting Tx-Vboost-Level for SuperSpeed\n");
+		return ret;
+	}
+
+	/*
+	 * Set proper time to wait for RxDetect measurement, for
+	 * desired reference clock of PHY, by tuning the CR_PORT
+	 * register LANE0.TX_DEBUG which is internal to PHY.
+	 * This fixes issue with few USB 3.0 devices, which are
+	 * not detected (not even generate interrupts on the bus
+	 * on insertion) without this change.
+	 * e.g. Samsung SUM-TSB16S 3.0 USB drive.
+	 */
+	switch (phy_drd->extrefclk) {
+	case EXYNOS5_FSEL_50MHZ:
+		temp = LANE0_TX_DEBUG_RXDET_MEAS_TIME_48M_50M_52M;
+		break;
+	case EXYNOS5_FSEL_20MHZ:
+	case EXYNOS5_FSEL_19MHZ2:
+		temp = LANE0_TX_DEBUG_RXDET_MEAS_TIME_19M2_20M;
+		break;
+	case EXYNOS5_FSEL_24MHZ:
+	default:
+		temp = LANE0_TX_DEBUG_RXDET_MEAS_TIME_24M;
+		break;
+	}
+
+	ret = crport_ctrl_write(phy_drd,
+				EXYNOS5_DRD_PHYSS_LANE0_TX_DEBUG,
+				temp);
+	if (ret)
+		dev_err(phy_drd->dev,
+		 "Failed setting RxDetect measurement time for SuperSpeed\n");
+
+	return ret;
+}
+
 static struct phy *exynos5_usbdrd_phy_xlate(struct device *dev,
 					struct of_phandle_args *args)
 {

@@ -537,11 +711,20 @@ static struct phy *exynos5_usbdrd_phy_xlate(struct device *dev,
 	return phy_drd->phys[args->args[0]].phy;
 }
 
+static int exynos5_usbdrd_phy_reset(struct phy *phy)
+{
+	struct phy_usb_instance *inst = phy_get_drvdata(phy);
+	struct exynos5_usbdrd_phy *phy_drd = to_usbdrd_phy(inst);
+
+	return exynos5420_usbdrd_phy_calibrate(phy_drd);
+}
+
 static const struct phy_ops exynos5_usbdrd_phy_ops = {
 	.init		= exynos5_usbdrd_phy_init,
 	.exit		= exynos5_usbdrd_phy_exit,
 	.power_on	= exynos5_usbdrd_phy_power_on,
 	.power_off	= exynos5_usbdrd_phy_power_off,
+	.reset		= exynos5_usbdrd_phy_reset,
 	.owner		= THIS_MODULE,
 };
 

drivers/usb/dwc3/core.c static void __dwc3_set_mode(struct work_struct *work) · line 161

Quoted 13 lines

drivers/usb/dwc3/core.c +2 -2

index 03474d3..1d5836e 100644
@@ -156,9 +156,10 @@ static void __dwc3_set_mode(struct work_struct *work)
 		} else {
 			if (dwc->usb2_phy)
 				otg_set_vbus(dwc->usb2_phy->otg, true);
-			if (dwc->usb2_generic_phy)
+			if (dwc->usb2_generic_phy) {
 				phy_set_mode(dwc->usb2_generic_phy, PHY_MODE_USB_HOST);
-
+				phy_reset(dwc->usb2_generic_phy);

it doesn't look like this is the best place to reset the phy. Also,

->reset() doesn't seem to match correctly with a calibration. That seems to be more fitting to a ->power_on() or ->init() implementation.

Hi,

Quoted 8 lines · Felipe Balbi

Hi,

Quoted 4 lines · Andrzej Pietrasiewicz

From: Vivek Gautam <[email protected]>

Adding phy calibration sequence for USB 3.0 DRD PHY present on Exynos5420/5800 systems.

Quoted 18 lines

Quoted 18 lines

drivers/phy/samsung/phy-exynos5-usbdrd.c +9 -0

+static int exynos5_usbdrd_phy_reset(struct phy *phy)
+{
+	struct phy_usb_instance *inst = phy_get_drvdata(phy);
+	struct exynos5_usbdrd_phy *phy_drd = to_usbdrd_phy(inst);
+
+	return exynos5420_usbdrd_phy_calibrate(phy_drd);
+}
+
  static const struct phy_ops exynos5_usbdrd_phy_ops = {
  	.init		= exynos5_usbdrd_phy_init,
  	.exit		= exynos5_usbdrd_phy_exit,
  	.power_on	= exynos5_usbdrd_phy_power_on,
  	.power_off	= exynos5_usbdrd_phy_power_off,
+	.reset		= exynos5_usbdrd_phy_reset,
  	.owner		= THIS_MODULE,
  };

Quoted 15 lines

drivers/usb/dwc3/core.c static void __dwc3_set_mode(struct work_struct *work) · line 161

Quoted 13 lines

drivers/usb/dwc3/core.c +2 -2

index 03474d3..1d5836e 100644
@@ -156,9 +156,10 @@ static void __dwc3_set_mode(struct work_struct *work)
  		} else {
  			if (dwc->usb2_phy)
  				otg_set_vbus(dwc->usb2_phy->otg, true);
-			if (dwc->usb2_generic_phy)
+			if (dwc->usb2_generic_phy) {
  				phy_set_mode(dwc->usb2_generic_phy, PHY_MODE_USB_HOST);
-
+				phy_reset(dwc->usb2_generic_phy);

it doesn't look like this is the best place to reset the phy. Also,

right, phy_reset is done during initialization before phy_power_on/phy_init or in error cases.

Quoted 2 lines

->reset() doesn't seem to match correctly with a calibration. That seems to be more fitting to a ->power_on() or ->init() implementation.

yeah, the initial patch seems to calibrate in phy_init(). Not sure why it's modified.

W dniu 18.09.2017 o?13:06, Kishon Vijay Abraham I pisze:

Quoted 11 lines

Hi,

Quoted 8 lines · Felipe Balbi

Hi,

Quoted 4 lines · Andrzej Pietrasiewicz

From: Vivek Gautam <[email protected]>

Adding phy calibration sequence for USB 3.0 DRD PHY present on Exynos5420/5800 systems.

<snip>

Quoted 34 lines

Quoted 18 lines

Quoted 18 lines

drivers/phy/samsung/phy-exynos5-usbdrd.c +9 -0

+static int exynos5_usbdrd_phy_reset(struct phy *phy)
+{
+	struct phy_usb_instance *inst = phy_get_drvdata(phy);
+	struct exynos5_usbdrd_phy *phy_drd = to_usbdrd_phy(inst);
+
+	return exynos5420_usbdrd_phy_calibrate(phy_drd);
+}
+
   static const struct phy_ops exynos5_usbdrd_phy_ops = {
   	.init		= exynos5_usbdrd_phy_init,
   	.exit		= exynos5_usbdrd_phy_exit,
   	.power_on	= exynos5_usbdrd_phy_power_on,
   	.power_off	= exynos5_usbdrd_phy_power_off,
+	.reset		= exynos5_usbdrd_phy_reset,
   	.owner		= THIS_MODULE,
   };

Quoted 15 lines

drivers/usb/dwc3/core.c static void __dwc3_set_mode(struct work_struct *work) · line 161

Quoted 13 lines

drivers/usb/dwc3/core.c +2 -2

index 03474d3..1d5836e 100644
@@ -156,9 +156,10 @@ static void __dwc3_set_mode(struct work_struct *work)
   		} else {
   			if (dwc->usb2_phy)
   				otg_set_vbus(dwc->usb2_phy->otg, true);
-			if (dwc->usb2_generic_phy)
+			if (dwc->usb2_generic_phy) {
   				phy_set_mode(dwc->usb2_generic_phy, PHY_MODE_USB_HOST);
-
+				phy_reset(dwc->usb2_generic_phy);

it doesn't look like this is the best place to reset the phy. Also,

Quoted 8 lines

right, phy_reset is done during initialization before phy_power_on/phy_init or in error cases.

Quoted 2 lines

->reset() doesn't seem to match correctly with a calibration. That seems to be more fitting to a ->power_on() or ->init() implementation.

yeah, the initial patch seems to calibrate in phy_init(). Not sure why it's modified.

The original patch used a hack like below, in xhci_plat_probe():

(quoted diff) +13 -0

+       /* Initialize and power-on USB 3.0 PHY */
+       xhci->shared_hcd->phy->init_count = 0;
+       ret = phy_init(xhci->shared_hcd->phy);
+       if (ret)
+               goto dealloc_usb3_hcd;
+
+       xhci->shared_hcd->phy->power_count = 0;
+       ret = phy_power_on(xhci->shared_hcd->phy);
+       if (ret) {
+               phy_exit(xhci->shared_hcd->phy);
+               goto dealloc_usb3_hcd;
+       }
+

Manually setting init_count to 0 in order for the subsequent phy_init() to happen probably does not look good.

The calibration is clearly needed. However, I don't have any strong opinions on from which place exactly to trigger the calibration process. The original patch did not make it upstream, but if that patch is ok, it is perfectly fine with me to drop my version and take that one instead.

Quoted 61 lines

Quoted 33 lines

Quoted 17 lines

Quoted 17 lines

drivers/phy/samsung/phy-exynos5-usbdrd.c +9 -0

+static int exynos5_usbdrd_phy_reset(struct phy *phy)
+{
+	struct phy_usb_instance *inst = phy_get_drvdata(phy);
+	struct exynos5_usbdrd_phy *phy_drd = to_usbdrd_phy(inst);
+
+	return exynos5420_usbdrd_phy_calibrate(phy_drd);
+}
+
   static const struct phy_ops exynos5_usbdrd_phy_ops = {
   	.init		= exynos5_usbdrd_phy_init,
   	.exit		= exynos5_usbdrd_phy_exit,
   	.power_on	= exynos5_usbdrd_phy_power_on,
   	.power_off	= exynos5_usbdrd_phy_power_off,
+	.reset		= exynos5_usbdrd_phy_reset,
   	.owner		= THIS_MODULE,
   };

Quoted 15 lines

drivers/usb/dwc3/core.c static void __dwc3_set_mode(struct work_struct *work) · line 161

Quoted 13 lines

drivers/usb/dwc3/core.c +2 -2

index 03474d3..1d5836e 100644
@@ -156,9 +156,10 @@ static void __dwc3_set_mode(struct work_struct *work)
   		} else {
   			if (dwc->usb2_phy)
   				otg_set_vbus(dwc->usb2_phy->otg, true);
-			if (dwc->usb2_generic_phy)
+			if (dwc->usb2_generic_phy) {
   				phy_set_mode(dwc->usb2_generic_phy, PHY_MODE_USB_HOST);
-
+				phy_reset(dwc->usb2_generic_phy);

it doesn't look like this is the best place to reset the phy. Also,

Quoted 8 lines

right, phy_reset is done during initialization before phy_power_on/phy_init or in error cases.

Quoted 2 lines

->reset() doesn't seem to match correctly with a calibration. That seems to be more fitting to a ->power_on() or ->init() implementation.

yeah, the initial patch seems to calibrate in phy_init(). Not sure why it's modified.

The original patch used a hack like below, in xhci_plat_probe():

(quoted diff) +13 -0

+       /* Initialize and power-on USB 3.0 PHY */
+       xhci->shared_hcd->phy->init_count = 0;
+       ret = phy_init(xhci->shared_hcd->phy);
+       if (ret)
+               goto dealloc_usb3_hcd;
+
+       xhci->shared_hcd->phy->power_count = 0;
+       ret = phy_power_on(xhci->shared_hcd->phy);
+       if (ret) {
+               phy_exit(xhci->shared_hcd->phy);
+               goto dealloc_usb3_hcd;
+       }
+

Manually setting init_count to 0 in order for the subsequent phy_init() to happen probably does not look good.

Quoted 4 lines

The calibration is clearly needed. However, I don't have any strong opinions on from which place exactly to trigger the calibration process. The original patch did not make it upstream, but if that patch is ok, it is perfectly fine with me to drop my version and take that one instead.

Me bad, I did not write about an important issue.
The calibration must happen after usb_add_hcd(), otherwise usb_add_hcd() indirectly triggers overwriting the effects of calibration.

Hi,

Quoted 61 lines · Andrzej Pietrasiewicz

Quoted 61 lines

Quoted 33 lines

Quoted 17 lines

Quoted 17 lines

drivers/phy/samsung/phy-exynos5-usbdrd.c +9 -0

+static int exynos5_usbdrd_phy_reset(struct phy *phy)
+{
+	struct phy_usb_instance *inst = phy_get_drvdata(phy);
+	struct exynos5_usbdrd_phy *phy_drd = to_usbdrd_phy(inst);
+
+	return exynos5420_usbdrd_phy_calibrate(phy_drd);
+}
+
    static const struct phy_ops exynos5_usbdrd_phy_ops = {
    	.init		= exynos5_usbdrd_phy_init,
    	.exit		= exynos5_usbdrd_phy_exit,
    	.power_on	= exynos5_usbdrd_phy_power_on,
    	.power_off	= exynos5_usbdrd_phy_power_off,
+	.reset		= exynos5_usbdrd_phy_reset,
    	.owner		= THIS_MODULE,
    };

Quoted 15 lines

drivers/usb/dwc3/core.c static void __dwc3_set_mode(struct work_struct *work) · line 161

Quoted 13 lines

drivers/usb/dwc3/core.c +2 -2

index 03474d3..1d5836e 100644
@@ -156,9 +156,10 @@ static void __dwc3_set_mode(struct work_struct *work)
    		} else {
    			if (dwc->usb2_phy)
    				otg_set_vbus(dwc->usb2_phy->otg, true);
-			if (dwc->usb2_generic_phy)
+			if (dwc->usb2_generic_phy) {
    				phy_set_mode(dwc->usb2_generic_phy, PHY_MODE_USB_HOST);
-
+				phy_reset(dwc->usb2_generic_phy);

it doesn't look like this is the best place to reset the phy. Also,

Quoted 8 lines

right, phy_reset is done during initialization before phy_power_on/phy_init or in error cases.

Quoted 2 lines

->reset() doesn't seem to match correctly with a calibration. That seems to be more fitting to a ->power_on() or ->init() implementation.

yeah, the initial patch seems to calibrate in phy_init(). Not sure why it's modified.

The original patch used a hack like below, in xhci_plat_probe():

(quoted diff) +13 -0

+       /* Initialize and power-on USB 3.0 PHY */
+       xhci->shared_hcd->phy->init_count = 0;
+       ret = phy_init(xhci->shared_hcd->phy);
+       if (ret)
+               goto dealloc_usb3_hcd;
+
+       xhci->shared_hcd->phy->power_count = 0;
+       ret = phy_power_on(xhci->shared_hcd->phy);
+       if (ret) {
+               phy_exit(xhci->shared_hcd->phy);
+               goto dealloc_usb3_hcd;
+       }
+

Manually setting init_count to 0 in order for the subsequent phy_init() to happen probably does not look good.

Quoted 8 lines

Quoted 4 lines

The calibration is clearly needed. However, I don't have any strong opinions on from which place exactly to trigger the calibration process. The original patch did not make it upstream, but if that patch is ok, it is perfectly fine with me to drop my version and take that one instead.

Me bad, I did not write about an important issue.
The calibration must happen after usb_add_hcd(), otherwise usb_add_hcd() indirectly triggers overwriting the effects of calibration.

in that case, you should do that from xhci-plat indeed. I think the whole idea with init_count is just to make sure you don't initialize it twice.

One thing's for sure, ->reset() doesn't seem to be the matching callback for you to use and, given your explanation above, dwc3 doesn't seem to be the right place to fiddle with that.

Seems like we need an extension of the generic PHY framework to cope with your requirement.

Hi,

W dniu 18.09.2017 o 14:43, Felipe Balbi pisze:

Quoted 74 lines

Hi,

Quoted 61 lines · Andrzej Pietrasiewicz

Quoted 61 lines

Quoted 36 lines

Quoted 23 lines

Quoted 23 lines

(quoted diff) +9 -0

+static int exynos5_usbdrd_phy_reset(struct phy *phy)
+{
+    struct phy_usb_instance *inst = phy_get_drvdata(phy);
+    struct exynos5_usbdrd_phy *phy_drd = to_usbdrd_phy(inst);
+
+    return exynos5420_usbdrd_phy_calibrate(phy_drd);
+}
+
    static const struct phy_ops exynos5_usbdrd_phy_ops = {
        .init        = exynos5_usbdrd_phy_init,
        .exit        = exynos5_usbdrd_phy_exit,
        .power_on    = exynos5_usbdrd_phy_power_on,
        .power_off    = exynos5_usbdrd_phy_power_off,
+    .reset        = exynos5_usbdrd_phy_reset,
        .owner        = THIS_MODULE,
    };
    diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c

index 03474d3..1d5836e 100644

drivers/usb/dwc3/core.c +0 -0

@@ -156,9 +156,10 @@ static void __dwc3_set_mode(struct work_struct *work)
            } else {
                if (dwc->usb2_phy)

Quoted 8 lines

drivers/usb/dwc3/core.c static void __dwc3_set_mode(struct work_struct *work) · line 161

Quoted 6 lines

drivers/usb/dwc3/core.c +2 -2

                    otg_set_vbus(dwc->usb2_phy->otg, true);
-            if (dwc->usb2_generic_phy)
+            if (dwc->usb2_generic_phy) {
                    phy_set_mode(dwc->usb2_generic_phy, PHY_MODE_USB_HOST);
-
+                phy_reset(dwc->usb2_generic_phy);

it doesn't look like this is the best place to reset the phy. Also,

right, phy_reset is done during initialization before phy_power_on/phy_init or
in error cases.

Quoted 5 lines

Quoted 2 lines

->reset() doesn't seem to match correctly with a calibration. That seems to be more fitting to a ->power_on() or ->init() implementation.

yeah, the initial patch seems to calibrate in phy_init(). Not sure why it's modified.

The original patch used a hack like below, in xhci_plat_probe():

(quoted diff) +13 -0

+       /* Initialize and power-on USB 3.0 PHY */
+       xhci->shared_hcd->phy->init_count = 0;
+       ret = phy_init(xhci->shared_hcd->phy);
+       if (ret)
+               goto dealloc_usb3_hcd;
+
+       xhci->shared_hcd->phy->power_count = 0;
+       ret = phy_power_on(xhci->shared_hcd->phy);
+       if (ret) {
+               phy_exit(xhci->shared_hcd->phy);
+               goto dealloc_usb3_hcd;
+       }
+

Manually setting init_count to 0 in order for the subsequent phy_init() to happen probably does not look good.

Quoted 8 lines

Quoted 4 lines

The calibration is clearly needed. However, I don't have any strong opinions on from which place exactly to trigger the calibration process. The original patch did not make it upstream, but if that patch is ok, it is perfectly fine with me to drop my version and take that one instead.

Me bad, I did not write about an important issue.
The calibration must happen after usb_add_hcd(), otherwise usb_add_hcd() indirectly triggers overwriting the effects of calibration.

Quoted 3 lines

in that case, you should do that from xhci-plat indeed. I think the whole idea with init_count is just to make sure you don't initialize it twice.

As far as I understand the code in question the desired result is exactly the opposite:
to make sure it _does_ initialize twice, otherwise after the first initialization the
calibration results were lost. In other words, in the code snippet above, in xhci_plat_probe() the phy_init() was creatively (ab)used in order to force the calibration at a desired moment, while in the original invocation of phy_init()
the calibration result was merely a short-term side effect discarded soon afterwards.

Quoted 8 lines

One thing's for sure, ->reset() doesn't seem to be the matching callback for you to use and, given your explanation above, dwc3 doesn't seem to be the right place to fiddle with that.

Seems like we need an extension of the generic PHY framework to cope with your requirement.

Here are old patches from Vivek:

https://lkml.org/lkml/2014/9/2/166

In particular:

https://lkml.org/lkml/2014/9/2/170

Please see the discussion that follows the latter.

All in all, is adding the calibrate() method to phy_ops the way to go or not?

Hi all,

This is the second version of patches in this thread.

Hi all,

This is the second version of patches in this thread.

The series fixes problems with enumerating of SuperSpeed devices on an Odroid XU3. There was a patch series from Vivek Gautam in circulation, but it got lost somehow. Please see:

https://lkml.org/lkml/2014/9/2/166
https://lkml.org/lkml/2015/2/2/257

I adapted his patch so that it does not use a hacky solution to force additional initialization in order for calibration to happen. With this patch enumeration happens correctly and a super speed device is recognized as such.

@Kishon:

As far as I understand what you suggest is to move phy_init() and phy_power_on() invocations from dwc3/core.c to xhci-plat, but, to the best of my knowledge, they are needed in device mode, too.

Hi,

Quoted 6 lines

@Kishon:

As far as I understand what you suggest is to move phy_init() and phy_power_on() invocations from dwc3/core.c to xhci-plat, but, to the best of my knowledge, they are needed in device mode, too.

What I meant is perform phy initializations for host mode in xhci and keep only device mode phy initialization in dwc3.

Some quirky UDCs (like dwc3 on exynos) need to have heir phys calibrated

e.g. for using super speed.

Signed-off-by Andrzej Pietrasiewicz <[email protected]>

---
 drivers/phy/phy-core.c  | 15 +++++++++++++++
 include/linux/phy/phy.h | 10 ++++++++++
 2 files changed, 25 insertions(+)

drivers/phy/phy-core.c +15 -0

index a268f4d..b4964b0 100644
@@ -372,6 +372,21 @@ int phy_reset(struct phy *phy)
 }
 EXPORT_SYMBOL_GPL(phy_reset);
 
+int phy_calibrate(struct phy *phy)
+{
+	int ret;
+
+	if (!phy || !phy->ops->calibrate)
+		return 0;
+
+	mutex_lock(&phy->mutex);
+	ret = phy->ops->calibrate(phy);
+	mutex_unlock(&phy->mutex);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(phy_calibrate);
+
 /**
  * _of_phy_get() - lookup and obtain a reference to a phy by phandle
  * @np: device_node for which to get the phy

include/linux/phy/phy.h +10 -0

index e694d40..87580c8 100644
@@ -39,6 +39,7 @@ enum phy_mode {
  * @power_off: powering off the phy
  * @set_mode: set the mode of the phy
  * @reset: resetting the phy
+ * @calibrate: calibrate the phy
  * @owner: the module owner containing the ops
  */
 struct phy_ops {

@@ -48,6 +49,7 @@ struct phy_ops {
 	int	(*power_off)(struct phy *phy);
 	int	(*set_mode)(struct phy *phy, enum phy_mode mode);
 	int	(*reset)(struct phy *phy);
+	int	(*calibrate)(struct phy *phy);
 	struct module *owner;
 };
 

@@ -141,6 +143,7 @@ static inline void *phy_get_drvdata(struct phy *phy)
 int phy_power_off(struct phy *phy);
 int phy_set_mode(struct phy *phy, enum phy_mode mode);
 int phy_reset(struct phy *phy);
+int phy_calibrate(struct phy *phy);
 static inline int phy_get_bus_width(struct phy *phy)
 {
 	return phy->attrs.bus_width;

@@ -262,6 +265,13 @@ static inline int phy_reset(struct phy *phy)
 	return -ENOSYS;
 }
 
+static inline int phy_calibrate(struct phy *phy)
+{
+	if (!phy)
+		return 0;
+	return -ENOSYS;
+}
+
 static inline int phy_get_bus_width(struct phy *phy)
 {
 	return -ENOSYS;

From: Vivek Gautam <[email protected]>

Adding phy calibration sequence for USB 3.0 DRD PHY present on Exynos5420/5800 systems.
This calibration facilitates setting certain PHY parameters viz. the Loss-of-Signal (LOS) Detector Threshold Level, as well as Tx-Vboost-Level for Super-Speed operations.
Additionally we also set proper time to wait for RxDetect measurement, for desired PHY reference clock, so as to solve issue with enumeration of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive on the controller.

We are using CR_port for this purpose to send required data to override the LOS values.

On testing with USB 3.0 devices on USB 3.0 port present on SMDK5420, and peach-pit boards should see following message:
usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd

and without this patch, should see below shown message:
usb 1-1: new high-speed USB device number 2 using xhci-hcd

[Also removed unnecessary extra lines in the register macro definitions]

Signed-off-by Vivek Gautam <[email protected]>

[adapted to use phy_calibrate as entry point]

Signed-off-by Andrzej Pietrasiewicz <[email protected]>

---
 drivers/phy/samsung/phy-exynos5-usbdrd.c | 183 +++++++++++++++++++++++++++++++
 drivers/usb/dwc3/core.c                  |   7 +-

Felipe,

Quoted 24 lines · Andrzej Pietrasiewicz

From: Vivek Gautam <[email protected]>

Adding phy calibration sequence for USB 3.0 DRD PHY present on Exynos5420/5800 systems.
This calibration facilitates setting certain PHY parameters viz. the Loss-of-Signal (LOS) Detector Threshold Level, as well as Tx-Vboost-Level for Super-Speed operations.
Additionally we also set proper time to wait for RxDetect measurement, for desired PHY reference clock, so as to solve issue with enumeration of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive on the controller.

We are using CR_port for this purpose to send required data to override the LOS values.

On testing with USB 3.0 devices on USB 3.0 port present on SMDK5420, and peach-pit boards should see following message:
usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd

and without this patch, should see below shown message:
usb 1-1: new high-speed USB device number 2 using xhci-hcd

[Also removed unnecessary extra lines in the register macro definitions]

Quoted 6 lines

Signed-off-by Vivek Gautam <[email protected]>

[adapted to use phy_calibrate as entry point]

Signed-off-by Andrzej Pietrasiewicz <[email protected]>

---
 drivers/phy/samsung/phy-exynos5-usbdrd.c | 183 +++++++++++++++++++++++++++++++
 drivers/usb/dwc3/core.c                  |   7 +-

are you okay with this patch?

Hi all,

This is the fourth version of patches in this thread.

The series fixes problems with enumerating of SuperSpeed devices on an Odroid XU3. There was a patch series from Vivek Gautam in circulation, but it got lost somehow. Please see:

https://lkml.org/lkml/2014/9/2/166
https://lkml.org/lkml/2015/2/2/257

I adapted his patch so that it does not use a hacky solution to force additional initialization in order for calibration to happen. With this patch enumeration happens correctly and a super speed device is recognized as such.

Changes since v3:

- improved the commit message in phy_calibrate() commit (as suggested by Kishon)
- rebased onto v4.14-rc4

Changes since v2:

- exported the "calibrate_phy" symbol

Changes since v1:

- added calibrate() callback to phy
- used calibrate() instead of reset() to trigger the calibration

Andrzej Pietrasiewicz (1):
drivers: phy: add calibrate method

Vivek Gautam (1):
phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

 drivers/phy/phy-core.c                   |  15 +++
 drivers/phy/samsung/phy-exynos5-usbdrd.c | 183 +++++++++++++++++++++++++++++++
 drivers/usb/dwc3/core.c                  |   7 +-
 include/linux/phy/phy.h                  |  10 ++
 4 files changed, 213 insertions(+), 2 deletions(-)

drivers/phy/samsung/phy-exynos5-usbdrd.c +5 -0

+static int crport_handshake(struct exynos5_usbdrd_phy *phy_drd,
+						u32 val, u32 cmd)
+{
+	u32 usec = 100;
+	unsigned int result;

Hi all,

this short series addresses two issues.

The first issue is devices not enumerating when connected to an Odroid XU4, to its 3.0 root hub. The interplay between refactoring certain parts of dwc3's code and handling the SUSPHY quirk results in the said problem. Please see: https://patchwork.kernel.org/patch/9535235/
Actually using the quirk solves it.

The second issue is devices not enumerating and/or wrongly enumerating as high speed instead of super speed on an Odroid XU3. There was a patch series from Vivek Gautam in circulation, but it got lost somehow. Please see:

https://lkml.org/lkml/2014/9/2/166
https://lkml.org/lkml/2015/2/2/257

I adapted his patch so that it does not use a hacky solution to force additional initialization in order for calibration to happen. Instead I used the .reset() in phy_ops. I could have used the .set_mode(), but the calibration must happen only after dwc3_host_init() but phy_set_mode() is called either after of before it. With this patch enumeration happens correctly and a super speed device is recognized as such.

Rebased onto v4.13. It also applies cleanly to Felipe's testing/next.

Andrzej Pietrasiewicz (1):
ARM: dts: exynos: Add dwc3 SUSPHY quirk

Vivek Gautam (1):
phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

 arch/arm/boot/dts/exynos54xx.dtsi        |   2 +
 drivers/phy/samsung/phy-exynos5-usbdrd.c | 183 +++++++++++++++++++++++++++++++
 drivers/usb/dwc3/core.c                  |   8 +-
 3 files changed, 191 insertions(+), 2 deletions(-)