[PATCH v1 0/4] Fine tune USB 3.0 PHY on exynos5420

[PATCH v1 0/4] Fine tune USB 3.0 PHY on exynos5420

[Vivek Gautam]

The RFC version of this series was posted long time back, around December
last year [1].
This series is based on Heikki's patches for simpliefied phy lookup table:
[PATCHv2 0/6] phy: simplified phy lookup [2], applied against 'usb-next'
branch of Greg's usb tree.
Tested on peach-pit boards with SuperSpeed devices and confirmed that now
the devices are detected as SupedSpeed, not as HighSpeed.

Explanation for the need of this patch-series:
"The DWC3-exynos eXtensible host controller present on Exynos5420
SoC is quirky. The PHY serving this controller operates at High-Speed
by default, so it detects even Super-speed devices as high-speed ones.
Certain PHY parameters like Tx LOS levels and Boost levels need to be
calibrated further post initialization of xHCI controller, to get
SuperSpeed operations working."

[1] https://lkml.org/lkml/2013/12/10/365
[2] https://lkml.org/lkml/2014/6/5/358

Vivek Gautam (4):
  phy: Add provision for calibrating phy.
  usb: host: xhci-plat: Add support to get PHYs
  usb: host: xhci-plat: Caibrate PHY post host reset
  phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

 drivers/phy/phy-core.c           |   36 ++++++++
 drivers/phy/phy-exynos5-usbdrd.c |  168 ++++++++++++++++++++++++++++++++++++++
 drivers/usb/host/xhci-plat.c     |   74 ++++++++++++++++-
 drivers/usb/host/xhci.h          |    3 +
 include/linux/phy/phy.h          |    7 ++
 5 files changed, 286 insertions(+), 2 deletions(-)

-- 
1.7.10.4

[PATCH v1 0/4] Fine tune USB 3.0 PHY on exynos5420

[Vivek Gautam]

The RFC version of this series was posted long time back, around December
last year [1].
This series is based on Heikki's patches for simpliefied phy lookup table:
[PATCHv2 0/6] phy: simplified phy lookup [2], applied against 'usb-next'
branch of Greg's usb tree.
Tested on peach-pit boards with SuperSpeed devices and confirmed that now
the devices are detected as SupedSpeed, not as HighSpeed.

Explanation for the need of this patch-series:
"The DWC3-exynos eXtensible host controller present on Exynos5420
SoC is quirky. The PHY serving this controller operates at High-Speed
by default, so it detects even Super-speed devices as high-speed ones.
Certain PHY parameters like Tx LOS levels and Boost levels need to be
calibrated further post initialization of xHCI controller, to get
SuperSpeed operations working."

[1] https://lkml.org/lkml/2013/12/10/365
[2] https://lkml.org/lkml/2014/6/5/358

Vivek Gautam (4):
  phy: Add provision for calibrating phy.
  usb: host: xhci-plat: Add support to get PHYs
  usb: host: xhci-plat: Caibrate PHY post host reset
  phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

 drivers/phy/phy-core.c           |   36 ++++++++
 drivers/phy/phy-exynos5-usbdrd.c |  168 ++++++++++++++++++++++++++++++++++++++
 drivers/usb/host/xhci-plat.c     |   74 ++++++++++++++++-
 drivers/usb/host/xhci.h          |    3 +
 include/linux/phy/phy.h          |    7 ++
 5 files changed, 286 insertions(+), 2 deletions(-)

-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v1 0/4] Fine tune USB 3.0 PHY on exynos5420

[Vivek Gautam]

The RFC version of this series was posted long time back, around December
last year [1].
This series is based on Heikki's patches for simpliefied phy lookup table:
[PATCHv2 0/6] phy: simplified phy lookup [2], applied against 'usb-next'
branch of Greg's usb tree.
Tested on peach-pit boards with SuperSpeed devices and confirmed that now
the devices are detected as SupedSpeed, not as HighSpeed.

Explanation for the need of this patch-series:
"The DWC3-exynos eXtensible host controller present on Exynos5420
SoC is quirky. The PHY serving this controller operates at High-Speed
by default, so it detects even Super-speed devices as high-speed ones.
Certain PHY parameters like Tx LOS levels and Boost levels need to be
calibrated further post initialization of xHCI controller, to get
SuperSpeed operations working."

[1] https://lkml.org/lkml/2013/12/10/365
[2] https://lkml.org/lkml/2014/6/5/358

Vivek Gautam (4):
  phy: Add provision for calibrating phy.
  usb: host: xhci-plat: Add support to get PHYs
  usb: host: xhci-plat: Caibrate PHY post host reset
  phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

 drivers/phy/phy-core.c           |   36 ++++++++
 drivers/phy/phy-exynos5-usbdrd.c |  168 ++++++++++++++++++++++++++++++++++++++
 drivers/usb/host/xhci-plat.c     |   74 ++++++++++++++++-
 drivers/usb/host/xhci.h          |    3 +
 include/linux/phy/phy.h          |    7 ++
 5 files changed, 286 insertions(+), 2 deletions(-)

-- 
1.7.10.4

[PATCH 1/4] phy: Add provision for calibrating phy.

[Vivek Gautam]

Some PHY controllers may need to calibrate certain
PHY settings after initialization of the controller and
sometimes even after initializing the PHY-consumer too.
Add support for the same in order to let consumers do so in need.

Signed-off-by: vivek Gautam <gautam.vivek@samsung.com>
---
 drivers/phy/phy-core.c  |   36 ++++++++++++++++++++++++++++++++++++
 include/linux/phy/phy.h |    7 +++++++
 2 files changed, 43 insertions(+)

diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 74d4346..92d31a3 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -376,6 +376,42 @@ int phy_power_off(struct phy *phy)
 EXPORT_SYMBOL_GPL(phy_power_off);
 
 /**
+ * phy_calibrate - calibrate a phy post initialization
+ * @phy: Pointer to 'phy' from consumer
+ *
+ * For certain PHYs, it may be needed to calibrate few phy parameters
+ * post initialization. The need to calibrate may arise after the
+ * initialization of consumer itself, in order to prevent further any
+ * loss of phy settings post consumer-initialization.
+ *	example: USB 3.0 DRD PHY on Exynos5420/5800 systems is one such
+ *	phy which needs calibration after the host controller reset
+ *	has happened.
+ */
+int phy_calibrate(struct phy *phy)
+{
+	int ret = -ENOTSUPP;
+
+	if (!phy)
+		return 0;
+
+	mutex_lock(&phy->mutex);
+	if (phy->ops->calibrate) {
+		ret =  phy->ops->calibrate(phy);
+		if (ret < 0) {
+			dev_err(&phy->dev,
+				"phy calibration failed --> %d\n", ret);
+			goto out;
+		}
+	}
+
+out:
+	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
  * @index: the index of the phy
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 5a537a5..1de6c0a 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -34,6 +34,7 @@ struct phy_ops {
 	int	(*exit)(struct phy *phy);
 	int	(*power_on)(struct phy *phy);
 	int	(*power_off)(struct phy *phy);
+	int	(*calibrate)(struct phy *phy);
 	struct module *owner;
 };
 
@@ -124,6 +125,7 @@ int phy_init(struct phy *phy);
 int phy_exit(struct phy *phy);
 int phy_power_on(struct phy *phy);
 int phy_power_off(struct phy *phy);
+int phy_calibrate(struct phy *phy);
 static inline int phy_get_bus_width(struct phy *phy)
 {
 	return phy->attrs.bus_width;
@@ -227,6 +229,11 @@ static inline int phy_power_off(struct phy *phy)
 	return -ENOSYS;
 }
 
+static inline int phy_calibrate(struct phy *phy)
+{
+	return -ENOSYS;
+}
+
 static inline int phy_get_bus_width(struct phy *phy)
 {
 	return -ENOSYS;
-- 
1.7.10.4

[PATCH 1/4] phy: Add provision for calibrating phy.

[Vivek Gautam]

Some PHY controllers may need to calibrate certain
PHY settings after initialization of the controller and
sometimes even after initializing the PHY-consumer too.
Add support for the same in order to let consumers do so in need.

Signed-off-by: vivek Gautam <gautam.vivek@samsung.com>
---
 drivers/phy/phy-core.c  |   36 ++++++++++++++++++++++++++++++++++++
 include/linux/phy/phy.h |    7 +++++++
 2 files changed, 43 insertions(+)

diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 74d4346..92d31a3 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -376,6 +376,42 @@ int phy_power_off(struct phy *phy)
 EXPORT_SYMBOL_GPL(phy_power_off);
 
 /**
+ * phy_calibrate - calibrate a phy post initialization
+ * @phy: Pointer to 'phy' from consumer
+ *
+ * For certain PHYs, it may be needed to calibrate few phy parameters
+ * post initialization. The need to calibrate may arise after the
+ * initialization of consumer itself, in order to prevent further any
+ * loss of phy settings post consumer-initialization.
+ *	example: USB 3.0 DRD PHY on Exynos5420/5800 systems is one such
+ *	phy which needs calibration after the host controller reset
+ *	has happened.
+ */
+int phy_calibrate(struct phy *phy)
+{
+	int ret = -ENOTSUPP;
+
+	if (!phy)
+		return 0;
+
+	mutex_lock(&phy->mutex);
+	if (phy->ops->calibrate) {
+		ret =  phy->ops->calibrate(phy);
+		if (ret < 0) {
+			dev_err(&phy->dev,
+				"phy calibration failed --> %d\n", ret);
+			goto out;
+		}
+	}
+
+out:
+	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
  * @index: the index of the phy
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 5a537a5..1de6c0a 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -34,6 +34,7 @@ struct phy_ops {
 	int	(*exit)(struct phy *phy);
 	int	(*power_on)(struct phy *phy);
 	int	(*power_off)(struct phy *phy);
+	int	(*calibrate)(struct phy *phy);
 	struct module *owner;
 };
 
@@ -124,6 +125,7 @@ int phy_init(struct phy *phy);
 int phy_exit(struct phy *phy);
 int phy_power_on(struct phy *phy);
 int phy_power_off(struct phy *phy);
+int phy_calibrate(struct phy *phy);
 static inline int phy_get_bus_width(struct phy *phy)
 {
 	return phy->attrs.bus_width;
@@ -227,6 +229,11 @@ static inline int phy_power_off(struct phy *phy)
 	return -ENOSYS;
 }
 
+static inline int phy_calibrate(struct phy *phy)
+{
+	return -ENOSYS;
+}
+
 static inline int phy_get_bus_width(struct phy *phy)
 {
 	return -ENOSYS;
-- 
1.7.10.4

[PATCH 2/4] usb: host: xhci-plat: Add support to get PHYs

[Vivek Gautam]

The host controller by itself may sometimes need to handle PHY
and/or calibrate some of the PHY settings to get full support out
of the PHY controller.
The PHY core provides a calibration funtionality now to do so.
Therefore, facilitate getting the two possible PHY types for
xhci controller, viz. USB 2.0 type (UTMI+) and USB 3.0 type (PIPE3)
from its parent.

Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
---
 drivers/usb/host/xhci-plat.c |   24 ++++++++++++++++++++++++
 drivers/usb/host/xhci.h      |    3 +++
 2 files changed, 27 insertions(+)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 29d8adb..e7145b5 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -17,6 +17,7 @@
 #include <linux/of.h>
 #include <linux/platform_device.h>
 #include <linux/slab.h>
+#include <linux/phy/phy.h>
 
 #include "xhci.h"
 #include "xhci-mvebu.h"
@@ -183,6 +184,29 @@ static int xhci_plat_probe(struct platform_device *pdev)
 	}
 
 	/*
+	 * Get possile USB 2.0 type PHY (UTMI+), as well as
+	 * USB 3.0 type PHY (PIPE3).
+	 * The host controller may need to handle PHYs by itself too
+	 * sometimes, so as to calibrate it based on the need.
+	 */
+	xhci->phy2_gen = devm_phy_get(&pdev->dev, "usb2-phy");
+	if (IS_ERR(xhci->phy2_gen)) {
+		ret = PTR_ERR(xhci->phy2_gen);
+		if (ret != -ENOSYS && ret != -ENODEV) {
+			dev_err(&pdev->dev, "no usb2 phy configured\n");
+			return ret;
+		}
+	}
+	xhci->phy3_gen = devm_phy_get(&pdev->dev, "usb3-phy");
+	if (IS_ERR(xhci->phy3_gen)) {
+		ret = PTR_ERR(xhci->phy3_gen);
+		if (ret != -ENOSYS && ret != -ENODEV) {
+			dev_err(&pdev->dev, "no usb3 phy configured\n");
+			return ret;
+		}
+	}
+
+	/*
 	 * Set the xHCI pointer before xhci_plat_setup() (aka hcd_driver.reset)
 	 * is called by usb_add_hcd().
 	 */
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 9ffecd5..453d89e 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1582,6 +1582,9 @@ struct xhci_hcd {
 	u32			port_status_u0;
 /* Compliance Mode Timer Triggered every 2 seconds */
 #define COMP_MODE_RCVRY_MSECS 2000
+	/* phys for the controller */
+	struct phy		*phy2_gen;
+	struct phy		*phy3_gen;
 };
 
 /* convert between an HCD pointer and the corresponding EHCI_HCD */
-- 
1.7.10.4

[PATCH 2/4] usb: host: xhci-plat: Add support to get PHYs

[Vivek Gautam]

The host controller by itself may sometimes need to handle PHY
and/or calibrate some of the PHY settings to get full support out
of the PHY controller.
The PHY core provides a calibration funtionality now to do so.
Therefore, facilitate getting the two possible PHY types for
xhci controller, viz. USB 2.0 type (UTMI+) and USB 3.0 type (PIPE3)
from its parent.

Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
---
 drivers/usb/host/xhci-plat.c |   24 ++++++++++++++++++++++++
 drivers/usb/host/xhci.h      |    3 +++
 2 files changed, 27 insertions(+)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 29d8adb..e7145b5 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -17,6 +17,7 @@
 #include <linux/of.h>
 #include <linux/platform_device.h>
 #include <linux/slab.h>
+#include <linux/phy/phy.h>
 
 #include "xhci.h"
 #include "xhci-mvebu.h"
@@ -183,6 +184,29 @@ static int xhci_plat_probe(struct platform_device *pdev)
 	}
 
 	/*
+	 * Get possile USB 2.0 type PHY (UTMI+), as well as
+	 * USB 3.0 type PHY (PIPE3).
+	 * The host controller may need to handle PHYs by itself too
+	 * sometimes, so as to calibrate it based on the need.
+	 */
+	xhci->phy2_gen = devm_phy_get(&pdev->dev, "usb2-phy");
+	if (IS_ERR(xhci->phy2_gen)) {
+		ret = PTR_ERR(xhci->phy2_gen);
+		if (ret != -ENOSYS && ret != -ENODEV) {
+			dev_err(&pdev->dev, "no usb2 phy configured\n");
+			return ret;
+		}
+	}
+	xhci->phy3_gen = devm_phy_get(&pdev->dev, "usb3-phy");
+	if (IS_ERR(xhci->phy3_gen)) {
+		ret = PTR_ERR(xhci->phy3_gen);
+		if (ret != -ENOSYS && ret != -ENODEV) {
+			dev_err(&pdev->dev, "no usb3 phy configured\n");
+			return ret;
+		}
+	}
+
+	/*
 	 * Set the xHCI pointer before xhci_plat_setup() (aka hcd_driver.reset)
 	 * is called by usb_add_hcd().
 	 */
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 9ffecd5..453d89e 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1582,6 +1582,9 @@ struct xhci_hcd {
 	u32			port_status_u0;
 /* Compliance Mode Timer Triggered every 2 seconds */
 #define COMP_MODE_RCVRY_MSECS 2000
+	/* phys for the controller */
+	struct phy		*phy2_gen;
+	struct phy		*phy3_gen;
 };
 
 /* convert between an HCD pointer and the corresponding EHCI_HCD */
-- 
1.7.10.4

[PATCH 3/4] usb: host: xhci-plat: Caibrate PHY post host reset

[Vivek Gautam]

Some quirky PHYs may require to be calibrated post the host
controller initialization.
The USB 3.0 DRD PHY on Exynos5420/5800 systems is one such PHY
which needs to calibrated post xhci's reset at initialization
time and at resume time, to get the controller work at SuperSpeed.

Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
---
 drivers/usb/host/xhci-plat.c |   50 ++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 48 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index e7145b5..7be03df 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -32,10 +32,51 @@ static void xhci_plat_quirks(struct device *dev, struct xhci_hcd *xhci)
 	xhci->quirks |= XHCI_PLAT;
 }
 
+static int xhci_plat_calibrate_phy(struct xhci_hcd *xhci)
+{
+	int ret = 0;
+	struct usb_hcd *hcd = xhci_to_hcd(xhci);
+
+	/* calibrate phy if available */
+	if (!IS_ERR(xhci->phy2_gen)) {
+		ret = phy_calibrate(xhci->phy2_gen);
+		if (ret < 0 && ret != -ENOTSUPP) {
+			dev_err(hcd->self.controller,
+				"failed to calibrate USB 2.0 type PHY\n");
+			return ret;
+		}
+	}
+
+	if (!IS_ERR(xhci->phy3_gen)) {
+		ret = phy_calibrate(xhci->phy3_gen);
+		if (ret < 0 && ret != -ENOTSUPP)
+			dev_err(hcd->self.controller,
+				"failed to calibrate USB 3.0 type PHY\n");
+	}
+
+	return ret;
+}
+
 /* called during probe() after chip reset completes */
 static int xhci_plat_setup(struct usb_hcd *hcd)
 {
-	return xhci_gen_setup(hcd, xhci_plat_quirks);
+	struct xhci_hcd	*xhci;
+	int ret;
+
+	ret = xhci_gen_setup(hcd, xhci_plat_quirks);
+	if (ret) {
+		dev_err(hcd->self.controller, "xhci setup failed\n");
+		return ret;
+	}
+
+	if (!usb_hcd_is_primary_hcd(hcd)) {
+		xhci = hcd_to_xhci(hcd);
+		ret = xhci_plat_calibrate_phy(xhci);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
 }
 
 static int xhci_plat_start(struct usb_hcd *hcd)
@@ -276,8 +317,13 @@ static int xhci_plat_resume(struct device *dev)
 {
 	struct usb_hcd	*hcd = dev_get_drvdata(dev);
 	struct xhci_hcd	*xhci = hcd_to_xhci(hcd);
+	int ret;
+
+	ret = xhci_resume(xhci, 0);
+	if (ret)
+		return ret;
 
-	return xhci_resume(xhci, 0);
+	return xhci_plat_calibrate_phy(xhci);
 }
 
 static const struct dev_pm_ops xhci_plat_pm_ops = {
-- 
1.7.10.4

[PATCH 3/4] usb: host: xhci-plat: Caibrate PHY post host reset

[Vivek Gautam]

Some quirky PHYs may require to be calibrated post the host
controller initialization.
The USB 3.0 DRD PHY on Exynos5420/5800 systems is one such PHY
which needs to calibrated post xhci's reset at initialization
time and at resume time, to get the controller work at SuperSpeed.

Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
---
 drivers/usb/host/xhci-plat.c |   50 ++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 48 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index e7145b5..7be03df 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -32,10 +32,51 @@ static void xhci_plat_quirks(struct device *dev, struct xhci_hcd *xhci)
 	xhci->quirks |= XHCI_PLAT;
 }
 
+static int xhci_plat_calibrate_phy(struct xhci_hcd *xhci)
+{
+	int ret = 0;
+	struct usb_hcd *hcd = xhci_to_hcd(xhci);
+
+	/* calibrate phy if available */
+	if (!IS_ERR(xhci->phy2_gen)) {
+		ret = phy_calibrate(xhci->phy2_gen);
+		if (ret < 0 && ret != -ENOTSUPP) {
+			dev_err(hcd->self.controller,
+				"failed to calibrate USB 2.0 type PHY\n");
+			return ret;
+		}
+	}
+
+	if (!IS_ERR(xhci->phy3_gen)) {
+		ret = phy_calibrate(xhci->phy3_gen);
+		if (ret < 0 && ret != -ENOTSUPP)
+			dev_err(hcd->self.controller,
+				"failed to calibrate USB 3.0 type PHY\n");
+	}
+
+	return ret;
+}
+
 /* called during probe() after chip reset completes */
 static int xhci_plat_setup(struct usb_hcd *hcd)
 {
-	return xhci_gen_setup(hcd, xhci_plat_quirks);
+	struct xhci_hcd	*xhci;
+	int ret;
+
+	ret = xhci_gen_setup(hcd, xhci_plat_quirks);
+	if (ret) {
+		dev_err(hcd->self.controller, "xhci setup failed\n");
+		return ret;
+	}
+
+	if (!usb_hcd_is_primary_hcd(hcd)) {
+		xhci = hcd_to_xhci(hcd);
+		ret = xhci_plat_calibrate_phy(xhci);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
 }
 
 static int xhci_plat_start(struct usb_hcd *hcd)
@@ -276,8 +317,13 @@ static int xhci_plat_resume(struct device *dev)
 {
 	struct usb_hcd	*hcd = dev_get_drvdata(dev);
 	struct xhci_hcd	*xhci = hcd_to_xhci(hcd);
+	int ret;
+
+	ret = xhci_resume(xhci, 0);
+	if (ret)
+		return ret;
 
-	return xhci_resume(xhci, 0);
+	return xhci_plat_calibrate_phy(xhci);
 }
 
 static const struct dev_pm_ops xhci_plat_pm_ops = {
-- 
1.7.10.4

[PATCH 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

[Vivek Gautam]

Adding phy calibrate callback, which facilitates setting certain
PHY settings post initialization of the PHY controller.
Exynos5420 and Exynos5800 have 28nm USB 3.0 DRD PHY for which
the Loss-of-Signal (LOS) Detector Threshold Level as well as
Tx-Vboost-Level should be controlled for Super-Speed operations.

Additionally 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

Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
---
 drivers/phy/phy-exynos5-usbdrd.c |  168 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 168 insertions(+)

diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index 56285af..73689d5 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -89,8 +89,20 @@
 #define PHYCLKRST_COMMONONN			BIT(0)
 
 #define EXYNOS5_DRD_PHYREG0			0x14
+
+#define EXYNOS5_DRD_PHYREG0_SSC_REF_CLK_SEL	BIT(21)
+#define EXYNOS5_DRD_PHYREG0_SSC_RANGE		BIT(20)
+#define EXYNOS5_DRD_PHYREG0_CR_WRITE		BIT(19)
+#define EXYNOS5_DRD_PHYREG0_CR_READ		BIT(18)
+#define EXYNOS5_DRD_PHYREG0_CR_DATA_IN(_x)	((_x) << 2)
+#define EXYNOS5_DRD_PHYREG0_CR_CAP_DATA		BIT(1)
+#define EXYNOS5_DRD_PHYREG0_CR_CAP_ADDR		BIT(0)
+
 #define EXYNOS5_DRD_PHYREG1			0x18
 
+#define EXYNOS5_DRD_PHYREG1_CR_DATA_OUT(_x)	((_x) << 1)
+#define EXYNOS5_DRD_PHYREG1_CR_ACK		BIT(0)
+
 #define EXYNOS5_DRD_PHYPARAM0			0x1c
 
 #define PHYPARAM0_REF_USE_PAD			BIT(31)
@@ -118,6 +130,26 @@
 #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)
 
@@ -135,12 +167,14 @@ struct exynos5_usbdrd_phy_config {
 	void (*phy_isol)(struct phy_usb_instance *inst, u32 on);
 	void (*phy_init)(struct exynos5_usbdrd_phy *phy_drd);
 	unsigned int (*set_refclk)(struct phy_usb_instance *inst);
+	int (*phy_calibrate)(struct phy_usb_instance *inst);
 };
 
 struct exynos5_usbdrd_phy_drvdata {
 	const struct exynos5_usbdrd_phy_config *phy_cfg;
 	u32 pmu_offset_usbdrd0_phy;
 	u32 pmu_offset_usbdrd1_phy;
+	void (*phy_calibrate)(struct exynos5_usbdrd_phy *phy_drd);
 };
 
 /**
@@ -487,6 +521,137 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
 	return 0;
 }
 
+static void crport_handshake(struct exynos5_usbdrd_phy *phy_drd,
+						u32 val, u32 cmd)
+{
+	u32 usec = 100;
+	u32 result;
+
+	writel(val | cmd, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
+
+	do {
+		result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
+		if (result & EXYNOS5_DRD_PHYREG1_CR_ACK)
+			break;
+
+		udelay(1);
+	} while (usec-- > 0);
+
+	if (!usec)
+		dev_err(phy_drd->dev,
+			"CRPORT handshake timeout1 (0x%08x)\n", val);
+
+	usec = 100;
+
+	writel(val, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
+
+	do {
+		result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
+		if (!(result & EXYNOS5_DRD_PHYREG1_CR_ACK))
+			break;
+
+		udelay(1);
+	} while (usec-- > 0);
+
+	if (!usec)
+		dev_err(phy_drd->dev,
+			"CRPORT handshake timeout2 (0x%08x)\n", val);
+}
+
+static void crport_ctrl_write(struct exynos5_usbdrd_phy *phy_drd,
+						u32 addr, u32 data)
+{
+	/* Write Address */
+	crport_handshake(phy_drd, EXYNOS5_DRD_PHYREG0_CR_DATA_IN(addr),
+			 EXYNOS5_DRD_PHYREG0_CR_CAP_ADDR);
+
+	/* Write Data */
+	crport_handshake(phy_drd, EXYNOS5_DRD_PHYREG0_CR_DATA_IN(data),
+			 EXYNOS5_DRD_PHYREG0_CR_CAP_DATA);
+	crport_handshake(phy_drd, EXYNOS5_DRD_PHYREG0_CR_DATA_IN(data),
+			 EXYNOS5_DRD_PHYREG0_CR_WRITE);
+}
+
+/*
+ * Override PHY paramaeters using CR_PORT register to calibrate settings
+ * to meet meet SuperSpeed requirements, on Exynos5420 and Exynos5800 systems,
+ * which have 28nm USB 3.0 DRD PHY.
+ */
+static void exynos5420_usbdrd_phy_calibrate(struct exynos5_usbdrd_phy *phy_drd)
+{
+	u32 temp;
+
+	/*
+	 * 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;
+	crport_ctrl_write(phy_drd,
+			  EXYNOS5_DRD_PHYSS_LOSLEVEL_OVRD_IN,
+			  temp);
+
+	/*
+	 * 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;
+	crport_ctrl_write(phy_drd,
+			  EXYNOS5_DRD_PHYSS_TX_VBOOSTLEVEL_OVRD_IN,
+			  temp);
+
+	/*
+	 * Set proper time to wait for RxDetect measurement, for
+	 * desired reference clock of PHY, by tuning the CRPORT
+	 * 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;
+	}
+
+	crport_ctrl_write(phy_drd,
+			  EXYNOS5_DRD_PHYSS_LANE0_TX_DEBUG,
+			  temp);
+}
+
+/* Calibrate PIPE3 PHY settings, if any */
+static int exynos5_usbdrd_pipe3_phy_calibrate(struct phy_usb_instance *inst)
+{
+	struct exynos5_usbdrd_phy *phy_drd = to_usbdrd_phy(inst);
+
+	if (phy_drd->drv_data->phy_calibrate)
+		phy_drd->drv_data->phy_calibrate(phy_drd);
+
+	return 0;
+}
+
+static int exynos5_usbdrd_phy_calibrate(struct phy *phy)
+{
+	struct phy_usb_instance *inst = phy_get_drvdata(phy);
+
+	if (inst->phy_cfg->phy_calibrate)
+		inst->phy_cfg->phy_calibrate(inst);
+
+	return 0;
+}
+
 static struct phy *exynos5_usbdrd_phy_xlate(struct device *dev,
 					struct of_phandle_args *args)
 {
@@ -503,6 +668,7 @@ static struct phy_ops exynos5_usbdrd_phy_ops = {
 	.exit		= exynos5_usbdrd_phy_exit,
 	.power_on	= exynos5_usbdrd_phy_power_on,
 	.power_off	= exynos5_usbdrd_phy_power_off,
+	.calibrate	= exynos5_usbdrd_phy_calibrate,
 	.owner		= THIS_MODULE,
 };
 
@@ -518,6 +684,7 @@ const struct exynos5_usbdrd_phy_config phy_cfg_exynos5[] = {
 		.phy_isol	= exynos5_usbdrd_phy_isol,
 		.phy_init	= exynos5_usbdrd_pipe3_init,
 		.set_refclk	= exynos5_usbdrd_pipe3_set_refclk,
+		.phy_calibrate	= exynos5_usbdrd_pipe3_phy_calibrate,
 	},
 };
 
@@ -525,6 +692,7 @@ const struct exynos5_usbdrd_phy_drvdata exynos5420_usbdrd_phy = {
 	.phy_cfg		= phy_cfg_exynos5,
 	.pmu_offset_usbdrd0_phy	= EXYNOS5_USBDRD_PHY_CONTROL,
 	.pmu_offset_usbdrd1_phy	= EXYNOS5420_USBDRD1_PHY_CONTROL,
+	.phy_calibrate		= exynos5420_usbdrd_phy_calibrate,
 };
 
 const struct exynos5_usbdrd_phy_drvdata exynos5250_usbdrd_phy = {
-- 
1.7.10.4

[PATCH 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

[Vivek Gautam]

Adding phy calibrate callback, which facilitates setting certain
PHY settings post initialization of the PHY controller.
Exynos5420 and Exynos5800 have 28nm USB 3.0 DRD PHY for which
the Loss-of-Signal (LOS) Detector Threshold Level as well as
Tx-Vboost-Level should be controlled for Super-Speed operations.

Additionally 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

Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
---
 drivers/phy/phy-exynos5-usbdrd.c |  168 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 168 insertions(+)

diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index 56285af..73689d5 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -89,8 +89,20 @@
 #define PHYCLKRST_COMMONONN			BIT(0)
 
 #define EXYNOS5_DRD_PHYREG0			0x14
+
+#define EXYNOS5_DRD_PHYREG0_SSC_REF_CLK_SEL	BIT(21)
+#define EXYNOS5_DRD_PHYREG0_SSC_RANGE		BIT(20)
+#define EXYNOS5_DRD_PHYREG0_CR_WRITE		BIT(19)
+#define EXYNOS5_DRD_PHYREG0_CR_READ		BIT(18)
+#define EXYNOS5_DRD_PHYREG0_CR_DATA_IN(_x)	((_x) << 2)
+#define EXYNOS5_DRD_PHYREG0_CR_CAP_DATA		BIT(1)
+#define EXYNOS5_DRD_PHYREG0_CR_CAP_ADDR		BIT(0)
+
 #define EXYNOS5_DRD_PHYREG1			0x18
 
+#define EXYNOS5_DRD_PHYREG1_CR_DATA_OUT(_x)	((_x) << 1)
+#define EXYNOS5_DRD_PHYREG1_CR_ACK		BIT(0)
+
 #define EXYNOS5_DRD_PHYPARAM0			0x1c
 
 #define PHYPARAM0_REF_USE_PAD			BIT(31)
@@ -118,6 +130,26 @@
 #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)
 
@@ -135,12 +167,14 @@ struct exynos5_usbdrd_phy_config {
 	void (*phy_isol)(struct phy_usb_instance *inst, u32 on);
 	void (*phy_init)(struct exynos5_usbdrd_phy *phy_drd);
 	unsigned int (*set_refclk)(struct phy_usb_instance *inst);
+	int (*phy_calibrate)(struct phy_usb_instance *inst);
 };
 
 struct exynos5_usbdrd_phy_drvdata {
 	const struct exynos5_usbdrd_phy_config *phy_cfg;
 	u32 pmu_offset_usbdrd0_phy;
 	u32 pmu_offset_usbdrd1_phy;
+	void (*phy_calibrate)(struct exynos5_usbdrd_phy *phy_drd);
 };
 
 /**
@@ -487,6 +521,137 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
 	return 0;
 }
 
+static void crport_handshake(struct exynos5_usbdrd_phy *phy_drd,
+						u32 val, u32 cmd)
+{
+	u32 usec = 100;
+	u32 result;
+
+	writel(val | cmd, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
+
+	do {
+		result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
+		if (result & EXYNOS5_DRD_PHYREG1_CR_ACK)
+			break;
+
+		udelay(1);
+	} while (usec-- > 0);
+
+	if (!usec)
+		dev_err(phy_drd->dev,
+			"CRPORT handshake timeout1 (0x%08x)\n", val);
+
+	usec = 100;
+
+	writel(val, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
+
+	do {
+		result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
+		if (!(result & EXYNOS5_DRD_PHYREG1_CR_ACK))
+			break;
+
+		udelay(1);
+	} while (usec-- > 0);
+
+	if (!usec)
+		dev_err(phy_drd->dev,
+			"CRPORT handshake timeout2 (0x%08x)\n", val);
+}
+
+static void crport_ctrl_write(struct exynos5_usbdrd_phy *phy_drd,
+						u32 addr, u32 data)
+{
+	/* Write Address */
+	crport_handshake(phy_drd, EXYNOS5_DRD_PHYREG0_CR_DATA_IN(addr),
+			 EXYNOS5_DRD_PHYREG0_CR_CAP_ADDR);
+
+	/* Write Data */
+	crport_handshake(phy_drd, EXYNOS5_DRD_PHYREG0_CR_DATA_IN(data),
+			 EXYNOS5_DRD_PHYREG0_CR_CAP_DATA);
+	crport_handshake(phy_drd, EXYNOS5_DRD_PHYREG0_CR_DATA_IN(data),
+			 EXYNOS5_DRD_PHYREG0_CR_WRITE);
+}
+
+/*
+ * Override PHY paramaeters using CR_PORT register to calibrate settings
+ * to meet meet SuperSpeed requirements, on Exynos5420 and Exynos5800 systems,
+ * which have 28nm USB 3.0 DRD PHY.
+ */
+static void exynos5420_usbdrd_phy_calibrate(struct exynos5_usbdrd_phy *phy_drd)
+{
+	u32 temp;
+
+	/*
+	 * 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;
+	crport_ctrl_write(phy_drd,
+			  EXYNOS5_DRD_PHYSS_LOSLEVEL_OVRD_IN,
+			  temp);
+
+	/*
+	 * 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;
+	crport_ctrl_write(phy_drd,
+			  EXYNOS5_DRD_PHYSS_TX_VBOOSTLEVEL_OVRD_IN,
+			  temp);
+
+	/*
+	 * Set proper time to wait for RxDetect measurement, for
+	 * desired reference clock of PHY, by tuning the CRPORT
+	 * 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;
+	}
+
+	crport_ctrl_write(phy_drd,
+			  EXYNOS5_DRD_PHYSS_LANE0_TX_DEBUG,
+			  temp);
+}
+
+/* Calibrate PIPE3 PHY settings, if any */
+static int exynos5_usbdrd_pipe3_phy_calibrate(struct phy_usb_instance *inst)
+{
+	struct exynos5_usbdrd_phy *phy_drd = to_usbdrd_phy(inst);
+
+	if (phy_drd->drv_data->phy_calibrate)
+		phy_drd->drv_data->phy_calibrate(phy_drd);
+
+	return 0;
+}
+
+static int exynos5_usbdrd_phy_calibrate(struct phy *phy)
+{
+	struct phy_usb_instance *inst = phy_get_drvdata(phy);
+
+	if (inst->phy_cfg->phy_calibrate)
+		inst->phy_cfg->phy_calibrate(inst);
+
+	return 0;
+}
+
 static struct phy *exynos5_usbdrd_phy_xlate(struct device *dev,
 					struct of_phandle_args *args)
 {
@@ -503,6 +668,7 @@ static struct phy_ops exynos5_usbdrd_phy_ops = {
 	.exit		= exynos5_usbdrd_phy_exit,
 	.power_on	= exynos5_usbdrd_phy_power_on,
 	.power_off	= exynos5_usbdrd_phy_power_off,
+	.calibrate	= exynos5_usbdrd_phy_calibrate,
 	.owner		= THIS_MODULE,
 };
 
@@ -518,6 +684,7 @@ const struct exynos5_usbdrd_phy_config phy_cfg_exynos5[] = {
 		.phy_isol	= exynos5_usbdrd_phy_isol,
 		.phy_init	= exynos5_usbdrd_pipe3_init,
 		.set_refclk	= exynos5_usbdrd_pipe3_set_refclk,
+		.phy_calibrate	= exynos5_usbdrd_pipe3_phy_calibrate,
 	},
 };
 
@@ -525,6 +692,7 @@ const struct exynos5_usbdrd_phy_drvdata exynos5420_usbdrd_phy = {
 	.phy_cfg		= phy_cfg_exynos5,
 	.pmu_offset_usbdrd0_phy	= EXYNOS5_USBDRD_PHY_CONTROL,
 	.pmu_offset_usbdrd1_phy	= EXYNOS5420_USBDRD1_PHY_CONTROL,
+	.phy_calibrate		= exynos5420_usbdrd_phy_calibrate,
 };
 
 const struct exynos5_usbdrd_phy_drvdata exynos5250_usbdrd_phy = {
-- 
1.7.10.4

Re: [PATCH 1/4] phy: Add provision for calibrating phy.

[Pratyush Anand]

On Fri, Jun 06, 2014 at 08:12:12PM +0800, Vivek Gautam wrote:
> Some PHY controllers may need to calibrate certain
> PHY settings after initialization of the controller and
> sometimes even after initializing the PHY-consumer too.
> Add support for the same in order to let consumers do so in need.
> 
> Signed-off-by: vivek Gautam <gautam.vivek@samsung.com>
> ---
>  drivers/phy/phy-core.c  |   36 ++++++++++++++++++++++++++++++++++++
>  include/linux/phy/phy.h |    7 +++++++
>  2 files changed, 43 insertions(+)
> 
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index 74d4346..92d31a3 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -376,6 +376,42 @@ int phy_power_off(struct phy *phy)
>  EXPORT_SYMBOL_GPL(phy_power_off);
>  
>  /**
> + * phy_calibrate - calibrate a phy post initialization
> + * @phy: Pointer to 'phy' from consumer
> + *
> + * For certain PHYs, it may be needed to calibrate few phy parameters
> + * post initialization. The need to calibrate may arise after the

For USB you may need to calibrate phy after each new connection. If
so, why not to use already existing struct usb_phy's notify_connect.

        pratyush

Re: [PATCH 1/4] phy: Add provision for calibrating phy.

[Pratyush Anand]

On Fri, Jun 06, 2014 at 08:12:12PM +0800, Vivek Gautam wrote:
> Some PHY controllers may need to calibrate certain
> PHY settings after initialization of the controller and
> sometimes even after initializing the PHY-consumer too.
> Add support for the same in order to let consumers do so in need.
> 
> Signed-off-by: vivek Gautam <gautam.vivek-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> ---
>  drivers/phy/phy-core.c  |   36 ++++++++++++++++++++++++++++++++++++
>  include/linux/phy/phy.h |    7 +++++++
>  2 files changed, 43 insertions(+)
> 
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index 74d4346..92d31a3 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -376,6 +376,42 @@ int phy_power_off(struct phy *phy)
>  EXPORT_SYMBOL_GPL(phy_power_off);
>  
>  /**
> + * phy_calibrate - calibrate a phy post initialization
> + * @phy: Pointer to 'phy' from consumer
> + *
> + * For certain PHYs, it may be needed to calibrate few phy parameters
> + * post initialization. The need to calibrate may arise after the

For USB you may need to calibrate phy after each new connection. If
so, why not to use already existing struct usb_phy's notify_connect.

        pratyush

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/4] phy: Add provision for calibrating phy.

[Pratyush Anand]

On Fri, Jun 06, 2014 at 08:12:12PM +0800, Vivek Gautam wrote:
> Some PHY controllers may need to calibrate certain
> PHY settings after initialization of the controller and
> sometimes even after initializing the PHY-consumer too.
> Add support for the same in order to let consumers do so in need.
> 
> Signed-off-by: vivek Gautam <gautam.vivek@samsung.com>
> ---
>  drivers/phy/phy-core.c  |   36 ++++++++++++++++++++++++++++++++++++
>  include/linux/phy/phy.h |    7 +++++++
>  2 files changed, 43 insertions(+)
> 
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index 74d4346..92d31a3 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -376,6 +376,42 @@ int phy_power_off(struct phy *phy)
>  EXPORT_SYMBOL_GPL(phy_power_off);
>  
>  /**
> + * phy_calibrate - calibrate a phy post initialization
> + * @phy: Pointer to 'phy' from consumer
> + *
> + * For certain PHYs, it may be needed to calibrate few phy parameters
> + * post initialization. The need to calibrate may arise after the

For USB you may need to calibrate phy after each new connection. If
so, why not to use already existing struct usb_phy's notify_connect.

        pratyush

Re: [PATCH 2/4] usb: host: xhci-plat: Add support to get PHYs

[Julius Werner]

> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
> index 9ffecd5..453d89e 100644
> --- a/drivers/usb/host/xhci.h
> +++ b/drivers/usb/host/xhci.h
> @@ -1582,6 +1582,9 @@ struct xhci_hcd {
>         u32                     port_status_u0;
>  /* Compliance Mode Timer Triggered every 2 seconds */
>  #define COMP_MODE_RCVRY_MSECS 2000
> +       /* phys for the controller */
> +       struct phy              *phy2_gen;
> +       struct phy              *phy3_gen;
>  };

I don't think adding new variables here and restricting most of this
logic to xhci-plat.c (in the next patch) is the best way to do it.
There's no conceptual reason why other host controllers (e.g. xhci-pci
or even EHCI) could not have a similar need to tune their PHY after
reset. PHYs are universal to all host controllers.

There is already a 'phy' member in struct usb_hcd which I think is
mostly unused right now. I think it would be much less
confusing/redundant to reuse that member for this purpose (you could
still set it up from xhci_plat_probe(), and then call it from
hcd_bus_resume() or something like that). Since XHCI host controllers
already conveniently have two struct usb_hcd (one for 2.0 and one for
3.0), you can cleanly store references to your two PHYs in there.

Re: [PATCH 2/4] usb: host: xhci-plat: Add support to get PHYs

[Julius Werner]

> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
> index 9ffecd5..453d89e 100644
> --- a/drivers/usb/host/xhci.h
> +++ b/drivers/usb/host/xhci.h
> @@ -1582,6 +1582,9 @@ struct xhci_hcd {
>         u32                     port_status_u0;
>  /* Compliance Mode Timer Triggered every 2 seconds */
>  #define COMP_MODE_RCVRY_MSECS 2000
> +       /* phys for the controller */
> +       struct phy              *phy2_gen;
> +       struct phy              *phy3_gen;
>  };

I don't think adding new variables here and restricting most of this
logic to xhci-plat.c (in the next patch) is the best way to do it.
There's no conceptual reason why other host controllers (e.g. xhci-pci
or even EHCI) could not have a similar need to tune their PHY after
reset. PHYs are universal to all host controllers.

There is already a 'phy' member in struct usb_hcd which I think is
mostly unused right now. I think it would be much less
confusing/redundant to reuse that member for this purpose (you could
still set it up from xhci_plat_probe(), and then call it from
hcd_bus_resume() or something like that). Since XHCI host controllers
already conveniently have two struct usb_hcd (one for 2.0 and one for
3.0), you can cleanly store references to your two PHYs in there.

[PATCH 2/4] usb: host: xhci-plat: Add support to get PHYs

[Julius Werner]

> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
> index 9ffecd5..453d89e 100644
> --- a/drivers/usb/host/xhci.h
> +++ b/drivers/usb/host/xhci.h
> @@ -1582,6 +1582,9 @@ struct xhci_hcd {
>         u32                     port_status_u0;
>  /* Compliance Mode Timer Triggered every 2 seconds */
>  #define COMP_MODE_RCVRY_MSECS 2000
> +       /* phys for the controller */
> +       struct phy              *phy2_gen;
> +       struct phy              *phy3_gen;
>  };

I don't think adding new variables here and restricting most of this
logic to xhci-plat.c (in the next patch) is the best way to do it.
There's no conceptual reason why other host controllers (e.g. xhci-pci
or even EHCI) could not have a similar need to tune their PHY after
reset. PHYs are universal to all host controllers.

There is already a 'phy' member in struct usb_hcd which I think is
mostly unused right now. I think it would be much less
confusing/redundant to reuse that member for this purpose (you could
still set it up from xhci_plat_probe(), and then call it from
hcd_bus_resume() or something like that). Since XHCI host controllers
already conveniently have two struct usb_hcd (one for 2.0 and one for
3.0), you can cleanly store references to your two PHYs in there.

Re: [PATCH 2/4] usb: host: xhci-plat: Add support to get PHYs

[Vivek Gautam]

Hi,


On Tue, Jun 10, 2014 at 1:52 AM, Julius Werner <jwerner@chromium.org> wrote:
>> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
>> index 9ffecd5..453d89e 100644
>> --- a/drivers/usb/host/xhci.h
>> +++ b/drivers/usb/host/xhci.h
>> @@ -1582,6 +1582,9 @@ struct xhci_hcd {
>>         u32                     port_status_u0;
>>  /* Compliance Mode Timer Triggered every 2 seconds */
>>  #define COMP_MODE_RCVRY_MSECS 2000
>> +       /* phys for the controller */
>> +       struct phy              *phy2_gen;
>> +       struct phy              *phy3_gen;
>>  };
>
> I don't think adding new variables here and restricting most of this
> logic to xhci-plat.c (in the next patch) is the best way to do it.
> There's no conceptual reason why other host controllers (e.g. xhci-pci
> or even EHCI) could not have a similar need to tune their PHY after
> reset. PHYs are universal to all host controllers.
>
> There is already a 'phy' member in struct usb_hcd which I think is
> mostly unused right now. I think it would be much less
> confusing/redundant to reuse that member for this purpose (you could
> still set it up from xhci_plat_probe(), and then call it from
> hcd_bus_resume() or something like that). Since XHCI host controllers
> already conveniently have two struct usb_hcd (one for 2.0 and one for
> 3.0), you can cleanly store references to your two PHYs in there.

Ok, i will look into the suggested approach, and raise flag in case i
have doubts.



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India

Re: [PATCH 2/4] usb: host: xhci-plat: Add support to get PHYs

[Vivek Gautam]

Hi,


On Tue, Jun 10, 2014 at 1:52 AM, Julius Werner <jwerner@chromium.org> wrote:
>> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
>> index 9ffecd5..453d89e 100644
>> --- a/drivers/usb/host/xhci.h
>> +++ b/drivers/usb/host/xhci.h
>> @@ -1582,6 +1582,9 @@ struct xhci_hcd {
>>         u32                     port_status_u0;
>>  /* Compliance Mode Timer Triggered every 2 seconds */
>>  #define COMP_MODE_RCVRY_MSECS 2000
>> +       /* phys for the controller */
>> +       struct phy              *phy2_gen;
>> +       struct phy              *phy3_gen;
>>  };
>
> I don't think adding new variables here and restricting most of this
> logic to xhci-plat.c (in the next patch) is the best way to do it.
> There's no conceptual reason why other host controllers (e.g. xhci-pci
> or even EHCI) could not have a similar need to tune their PHY after
> reset. PHYs are universal to all host controllers.
>
> There is already a 'phy' member in struct usb_hcd which I think is
> mostly unused right now. I think it would be much less
> confusing/redundant to reuse that member for this purpose (you could
> still set it up from xhci_plat_probe(), and then call it from
> hcd_bus_resume() or something like that). Since XHCI host controllers
> already conveniently have two struct usb_hcd (one for 2.0 and one for
> 3.0), you can cleanly store references to your two PHYs in there.

Ok, i will look into the suggested approach, and raise flag in case i
have doubts.



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India

[PATCH 2/4] usb: host: xhci-plat: Add support to get PHYs

[Vivek Gautam]

Hi,


On Tue, Jun 10, 2014 at 1:52 AM, Julius Werner <jwerner@chromium.org> wrote:
>> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
>> index 9ffecd5..453d89e 100644
>> --- a/drivers/usb/host/xhci.h
>> +++ b/drivers/usb/host/xhci.h
>> @@ -1582,6 +1582,9 @@ struct xhci_hcd {
>>         u32                     port_status_u0;
>>  /* Compliance Mode Timer Triggered every 2 seconds */
>>  #define COMP_MODE_RCVRY_MSECS 2000
>> +       /* phys for the controller */
>> +       struct phy              *phy2_gen;
>> +       struct phy              *phy3_gen;
>>  };
>
> I don't think adding new variables here and restricting most of this
> logic to xhci-plat.c (in the next patch) is the best way to do it.
> There's no conceptual reason why other host controllers (e.g. xhci-pci
> or even EHCI) could not have a similar need to tune their PHY after
> reset. PHYs are universal to all host controllers.
>
> There is already a 'phy' member in struct usb_hcd which I think is
> mostly unused right now. I think it would be much less
> confusing/redundant to reuse that member for this purpose (you could
> still set it up from xhci_plat_probe(), and then call it from
> hcd_bus_resume() or something like that). Since XHCI host controllers
> already conveniently have two struct usb_hcd (one for 2.0 and one for
> 3.0), you can cleanly store references to your two PHYs in there.

Ok, i will look into the suggested approach, and raise flag in case i
have doubts.



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India

Re: [PATCH 2/4] usb: host: xhci-plat: Add support to get PHYs

[Sergei Shtylyov]

Hello.

On 06/10/2014 12:22 AM, Julius Werner wrote:

>> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
>> index 9ffecd5..453d89e 100644
>> --- a/drivers/usb/host/xhci.h
>> +++ b/drivers/usb/host/xhci.h
>> @@ -1582,6 +1582,9 @@ struct xhci_hcd {
>>          u32                     port_status_u0;
>>   /* Compliance Mode Timer Triggered every 2 seconds */
>>   #define COMP_MODE_RCVRY_MSECS 2000
>> +       /* phys for the controller */
>> +       struct phy              *phy2_gen;
>> +       struct phy              *phy3_gen;
>>   };

> I don't think adding new variables here and restricting most of this
> logic to xhci-plat.c (in the next patch) is the best way to do it.

    Indeed.

> There's no conceptual reason why other host controllers (e.g. xhci-pci
> or even EHCI) could not have a similar need to tune their PHY after
> reset. PHYs are universal to all host controllers.

> There is already a 'phy' member in struct usb_hcd which I think is
> mostly unused right now. I think it would be much less
> confusing/redundant to reuse that member for this purpose (you could
> still set it up from xhci_plat_probe(), and then call it from
> hcd_bus_resume() or something like that).

    That member has type 'struct usb_phy *' while here we have 'struct phy *' 
-- feel the difference.
    I have already tried adding 'struct phy *gen_phy' to 'struct usb_hcd', 
however Greg wasn't eager to pick that up so far. Here's the last posting of 
my patch:

http://marc.info/?l=linux-usb&m=140145917506582

WBR, Sergei

Re: [PATCH 2/4] usb: host: xhci-plat: Add support to get PHYs

[Sergei Shtylyov]

Hello.

On 06/10/2014 12:22 AM, Julius Werner wrote:

>> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
>> index 9ffecd5..453d89e 100644
>> --- a/drivers/usb/host/xhci.h
>> +++ b/drivers/usb/host/xhci.h
>> @@ -1582,6 +1582,9 @@ struct xhci_hcd {
>>          u32                     port_status_u0;
>>   /* Compliance Mode Timer Triggered every 2 seconds */
>>   #define COMP_MODE_RCVRY_MSECS 2000
>> +       /* phys for the controller */
>> +       struct phy              *phy2_gen;
>> +       struct phy              *phy3_gen;
>>   };

> I don't think adding new variables here and restricting most of this
> logic to xhci-plat.c (in the next patch) is the best way to do it.

    Indeed.

> There's no conceptual reason why other host controllers (e.g. xhci-pci
> or even EHCI) could not have a similar need to tune their PHY after
> reset. PHYs are universal to all host controllers.

> There is already a 'phy' member in struct usb_hcd which I think is
> mostly unused right now. I think it would be much less
> confusing/redundant to reuse that member for this purpose (you could
> still set it up from xhci_plat_probe(), and then call it from
> hcd_bus_resume() or something like that).

    That member has type 'struct usb_phy *' while here we have 'struct phy *' 
-- feel the difference.
    I have already tried adding 'struct phy *gen_phy' to 'struct usb_hcd', 
however Greg wasn't eager to pick that up so far. Here's the last posting of 
my patch:

http://marc.info/?l=linux-usb&m=140145917506582

WBR, Sergei

[PATCH 2/4] usb: host: xhci-plat: Add support to get PHYs

[Sergei Shtylyov]

Hello.

On 06/10/2014 12:22 AM, Julius Werner wrote:

>> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
>> index 9ffecd5..453d89e 100644
>> --- a/drivers/usb/host/xhci.h
>> +++ b/drivers/usb/host/xhci.h
>> @@ -1582,6 +1582,9 @@ struct xhci_hcd {
>>          u32                     port_status_u0;
>>   /* Compliance Mode Timer Triggered every 2 seconds */
>>   #define COMP_MODE_RCVRY_MSECS 2000
>> +       /* phys for the controller */
>> +       struct phy              *phy2_gen;
>> +       struct phy              *phy3_gen;
>>   };

> I don't think adding new variables here and restricting most of this
> logic to xhci-plat.c (in the next patch) is the best way to do it.

    Indeed.

> There's no conceptual reason why other host controllers (e.g. xhci-pci
> or even EHCI) could not have a similar need to tune their PHY after
> reset. PHYs are universal to all host controllers.

> There is already a 'phy' member in struct usb_hcd which I think is
> mostly unused right now. I think it would be much less
> confusing/redundant to reuse that member for this purpose (you could
> still set it up from xhci_plat_probe(), and then call it from
> hcd_bus_resume() or something like that).

    That member has type 'struct usb_phy *' while here we have 'struct phy *' 
-- feel the difference.
    I have already tried adding 'struct phy *gen_phy' to 'struct usb_hcd', 
however Greg wasn't eager to pick that up so far. Here's the last posting of 
my patch:

http://marc.info/?l=linux-usb&m=140145917506582

WBR, Sergei

Re: [PATCH 2/4] usb: host: xhci-plat: Add support to get PHYs

[Vivek Gautam]

HI Sergei,


On Wed, Jun 25, 2014 at 4:04 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Hello.
>
>
> On 06/10/2014 12:22 AM, Julius Werner wrote:
>
>>> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
>>> index 9ffecd5..453d89e 100644
>>> --- a/drivers/usb/host/xhci.h
>>> +++ b/drivers/usb/host/xhci.h
>>> @@ -1582,6 +1582,9 @@ struct xhci_hcd {
>>>          u32                     port_status_u0;
>>>   /* Compliance Mode Timer Triggered every 2 seconds */
>>>   #define COMP_MODE_RCVRY_MSECS 2000
>>> +       /* phys for the controller */
>>> +       struct phy              *phy2_gen;
>>> +       struct phy              *phy3_gen;
>>>   };
>
>
>> I don't think adding new variables here and restricting most of this
>> logic to xhci-plat.c (in the next patch) is the best way to do it.
>
>
>    Indeed.
>
>
>> There's no conceptual reason why other host controllers (e.g. xhci-pci
>> or even EHCI) could not have a similar need to tune their PHY after
>> reset. PHYs are universal to all host controllers.
>
>
>> There is already a 'phy' member in struct usb_hcd which I think is
>> mostly unused right now. I think it would be much less
>> confusing/redundant to reuse that member for this purpose (you could
>> still set it up from xhci_plat_probe(), and then call it from
>> hcd_bus_resume() or something like that).
>
>
>    That member has type 'struct usb_phy *' while here we have 'struct phy *'
> -- feel the difference.
>    I have already tried adding 'struct phy *gen_phy' to 'struct usb_hcd',
> however Greg wasn't eager to pick that up so far. Here's the last posting of
> my patch:
>
> http://marc.info/?l=linux-usb&m=140145917506582

Thanks for pointing to the patch, i have also been tracking this patch.
I will try to rework using this patch and post the relevant patches.



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India

Re: [PATCH 2/4] usb: host: xhci-plat: Add support to get PHYs

[Vivek Gautam]

HI Sergei,


On Wed, Jun 25, 2014 at 4:04 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Hello.
>
>
> On 06/10/2014 12:22 AM, Julius Werner wrote:
>
>>> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
>>> index 9ffecd5..453d89e 100644
>>> --- a/drivers/usb/host/xhci.h
>>> +++ b/drivers/usb/host/xhci.h
>>> @@ -1582,6 +1582,9 @@ struct xhci_hcd {
>>>          u32                     port_status_u0;
>>>   /* Compliance Mode Timer Triggered every 2 seconds */
>>>   #define COMP_MODE_RCVRY_MSECS 2000
>>> +       /* phys for the controller */
>>> +       struct phy              *phy2_gen;
>>> +       struct phy              *phy3_gen;
>>>   };
>
>
>> I don't think adding new variables here and restricting most of this
>> logic to xhci-plat.c (in the next patch) is the best way to do it.
>
>
>    Indeed.
>
>
>> There's no conceptual reason why other host controllers (e.g. xhci-pci
>> or even EHCI) could not have a similar need to tune their PHY after
>> reset. PHYs are universal to all host controllers.
>
>
>> There is already a 'phy' member in struct usb_hcd which I think is
>> mostly unused right now. I think it would be much less
>> confusing/redundant to reuse that member for this purpose (you could
>> still set it up from xhci_plat_probe(), and then call it from
>> hcd_bus_resume() or something like that).
>
>
>    That member has type 'struct usb_phy *' while here we have 'struct phy *'
> -- feel the difference.
>    I have already tried adding 'struct phy *gen_phy' to 'struct usb_hcd',
> however Greg wasn't eager to pick that up so far. Here's the last posting of
> my patch:
>
> http://marc.info/?l=linux-usb&m=140145917506582

Thanks for pointing to the patch, i have also been tracking this patch.
I will try to rework using this patch and post the relevant patches.



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India

[PATCH 2/4] usb: host: xhci-plat: Add support to get PHYs

[Vivek Gautam]

HI Sergei,


On Wed, Jun 25, 2014 at 4:04 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Hello.
>
>
> On 06/10/2014 12:22 AM, Julius Werner wrote:
>
>>> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
>>> index 9ffecd5..453d89e 100644
>>> --- a/drivers/usb/host/xhci.h
>>> +++ b/drivers/usb/host/xhci.h
>>> @@ -1582,6 +1582,9 @@ struct xhci_hcd {
>>>          u32                     port_status_u0;
>>>   /* Compliance Mode Timer Triggered every 2 seconds */
>>>   #define COMP_MODE_RCVRY_MSECS 2000
>>> +       /* phys for the controller */
>>> +       struct phy              *phy2_gen;
>>> +       struct phy              *phy3_gen;
>>>   };
>
>
>> I don't think adding new variables here and restricting most of this
>> logic to xhci-plat.c (in the next patch) is the best way to do it.
>
>
>    Indeed.
>
>
>> There's no conceptual reason why other host controllers (e.g. xhci-pci
>> or even EHCI) could not have a similar need to tune their PHY after
>> reset. PHYs are universal to all host controllers.
>
>
>> There is already a 'phy' member in struct usb_hcd which I think is
>> mostly unused right now. I think it would be much less
>> confusing/redundant to reuse that member for this purpose (you could
>> still set it up from xhci_plat_probe(), and then call it from
>> hcd_bus_resume() or something like that).
>
>
>    That member has type 'struct usb_phy *' while here we have 'struct phy *'
> -- feel the difference.
>    I have already tried adding 'struct phy *gen_phy' to 'struct usb_hcd',
> however Greg wasn't eager to pick that up so far. Here's the last posting of
> my patch:
>
> http://marc.info/?l=linux-usb&m=140145917506582

Thanks for pointing to the patch, i have also been tracking this patch.
I will try to rework using this patch and post the relevant patches.



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India

Re: [PATCH 2/4] usb: host: xhci-plat: Add support to get PHYs

[Vivek Gautam]

Hi,


On Wed, Jun 25, 2014 at 4:04 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Hello.
>
>
> On 06/10/2014 12:22 AM, Julius Werner wrote:
>
>>> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
>>> index 9ffecd5..453d89e 100644
>>> --- a/drivers/usb/host/xhci.h
>>> +++ b/drivers/usb/host/xhci.h
>>> @@ -1582,6 +1582,9 @@ struct xhci_hcd {
>>>          u32                     port_status_u0;
>>>   /* Compliance Mode Timer Triggered every 2 seconds */
>>>   #define COMP_MODE_RCVRY_MSECS 2000
>>> +       /* phys for the controller */
>>> +       struct phy              *phy2_gen;
>>> +       struct phy              *phy3_gen;
>>>   };
>
>
>> I don't think adding new variables here and restricting most of this
>> logic to xhci-plat.c (in the next patch) is the best way to do it.
>
>
>    Indeed.
>
>
>> There's no conceptual reason why other host controllers (e.g. xhci-pci
>> or even EHCI) could not have a similar need to tune their PHY after
>> reset. PHYs are universal to all host controllers.
>
>
>> There is already a 'phy' member in struct usb_hcd which I think is
>> mostly unused right now. I think it would be much less
>> confusing/redundant to reuse that member for this purpose (you could
>> still set it up from xhci_plat_probe(), and then call it from
>> hcd_bus_resume() or something like that).
>
>
>    That member has type 'struct usb_phy *' while here we have 'struct phy *'
> -- feel the difference.
>    I have already tried adding 'struct phy *gen_phy' to 'struct usb_hcd',

So the 'struct phy *' available in the usb_hcd is requested in usb_add_hcd().
This is requested with the constant string 'usb' :
           struct phy *phy = phy_get(hcd->self.controller, "usb");

This can get the phy with string 'usb' only if, either the host
controller has a device node wherein the phys are given.
Even in this case one can't give same constant string for two
different phys, UTMI+ and PIPE3 phy, isn't it ?

Or, the other way can be when host gets a lookup table to look into to
find the relevant phys, something like
Heikki has suggested:
usb: dwc3: host: convey the PHYs to xhci
(https://lkml.org/lkml/2014/6/5/585) and related patch series.

So if we use this second approach, we would need to override the
'phy_get()' that has been done in usb_add_hcd()
in xhci_plat_probe(), and then use them in later operations.

am i getting the things correctly ?



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India

Re: [PATCH 2/4] usb: host: xhci-plat: Add support to get PHYs

[Vivek Gautam]

Hi,


On Wed, Jun 25, 2014 at 4:04 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Hello.
>
>
> On 06/10/2014 12:22 AM, Julius Werner wrote:
>
>>> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
>>> index 9ffecd5..453d89e 100644
>>> --- a/drivers/usb/host/xhci.h
>>> +++ b/drivers/usb/host/xhci.h
>>> @@ -1582,6 +1582,9 @@ struct xhci_hcd {
>>>          u32                     port_status_u0;
>>>   /* Compliance Mode Timer Triggered every 2 seconds */
>>>   #define COMP_MODE_RCVRY_MSECS 2000
>>> +       /* phys for the controller */
>>> +       struct phy              *phy2_gen;
>>> +       struct phy              *phy3_gen;
>>>   };
>
>
>> I don't think adding new variables here and restricting most of this
>> logic to xhci-plat.c (in the next patch) is the best way to do it.
>
>
>    Indeed.
>
>
>> There's no conceptual reason why other host controllers (e.g. xhci-pci
>> or even EHCI) could not have a similar need to tune their PHY after
>> reset. PHYs are universal to all host controllers.
>
>
>> There is already a 'phy' member in struct usb_hcd which I think is
>> mostly unused right now. I think it would be much less
>> confusing/redundant to reuse that member for this purpose (you could
>> still set it up from xhci_plat_probe(), and then call it from
>> hcd_bus_resume() or something like that).
>
>
>    That member has type 'struct usb_phy *' while here we have 'struct phy *'
> -- feel the difference.
>    I have already tried adding 'struct phy *gen_phy' to 'struct usb_hcd',

So the 'struct phy *' available in the usb_hcd is requested in usb_add_hcd().
This is requested with the constant string 'usb' :
           struct phy *phy = phy_get(hcd->self.controller, "usb");

This can get the phy with string 'usb' only if, either the host
controller has a device node wherein the phys are given.
Even in this case one can't give same constant string for two
different phys, UTMI+ and PIPE3 phy, isn't it ?

Or, the other way can be when host gets a lookup table to look into to
find the relevant phys, something like
Heikki has suggested:
usb: dwc3: host: convey the PHYs to xhci
(https://lkml.org/lkml/2014/6/5/585) and related patch series.

So if we use this second approach, we would need to override the
'phy_get()' that has been done in usb_add_hcd()
in xhci_plat_probe(), and then use them in later operations.

am i getting the things correctly ?



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India

[PATCH 2/4] usb: host: xhci-plat: Add support to get PHYs

[Vivek Gautam]

Hi,


On Wed, Jun 25, 2014 at 4:04 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Hello.
>
>
> On 06/10/2014 12:22 AM, Julius Werner wrote:
>
>>> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
>>> index 9ffecd5..453d89e 100644
>>> --- a/drivers/usb/host/xhci.h
>>> +++ b/drivers/usb/host/xhci.h
>>> @@ -1582,6 +1582,9 @@ struct xhci_hcd {
>>>          u32                     port_status_u0;
>>>   /* Compliance Mode Timer Triggered every 2 seconds */
>>>   #define COMP_MODE_RCVRY_MSECS 2000
>>> +       /* phys for the controller */
>>> +       struct phy              *phy2_gen;
>>> +       struct phy              *phy3_gen;
>>>   };
>
>
>> I don't think adding new variables here and restricting most of this
>> logic to xhci-plat.c (in the next patch) is the best way to do it.
>
>
>    Indeed.
>
>
>> There's no conceptual reason why other host controllers (e.g. xhci-pci
>> or even EHCI) could not have a similar need to tune their PHY after
>> reset. PHYs are universal to all host controllers.
>
>
>> There is already a 'phy' member in struct usb_hcd which I think is
>> mostly unused right now. I think it would be much less
>> confusing/redundant to reuse that member for this purpose (you could
>> still set it up from xhci_plat_probe(), and then call it from
>> hcd_bus_resume() or something like that).
>
>
>    That member has type 'struct usb_phy *' while here we have 'struct phy *'
> -- feel the difference.
>    I have already tried adding 'struct phy *gen_phy' to 'struct usb_hcd',

So the 'struct phy *' available in the usb_hcd is requested in usb_add_hcd().
This is requested with the constant string 'usb' :
           struct phy *phy = phy_get(hcd->self.controller, "usb");

This can get the phy with string 'usb' only if, either the host
controller has a device node wherein the phys are given.
Even in this case one can't give same constant string for two
different phys, UTMI+ and PIPE3 phy, isn't it ?

Or, the other way can be when host gets a lookup table to look into to
find the relevant phys, something like
Heikki has suggested:
usb: dwc3: host: convey the PHYs to xhci
(https://lkml.org/lkml/2014/6/5/585) and related patch series.

So if we use this second approach, we would need to override the
'phy_get()' that has been done in usb_add_hcd()
in xhci_plat_probe(), and then use them in later operations.

am i getting the things correctly ?



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India

Re: [PATCH 2/4] usb: host: xhci-plat: Add support to get PHYs

[Sergei Shtylyov]

Hello.

On 06/25/2014 12:44 PM, Vivek Gautam wrote:

>>>> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
>>>> index 9ffecd5..453d89e 100644
>>>> --- a/drivers/usb/host/xhci.h
>>>> +++ b/drivers/usb/host/xhci.h
>>>> @@ -1582,6 +1582,9 @@ struct xhci_hcd {
>>>>           u32                     port_status_u0;
>>>>    /* Compliance Mode Timer Triggered every 2 seconds */
>>>>    #define COMP_MODE_RCVRY_MSECS 2000
>>>> +       /* phys for the controller */
>>>> +       struct phy              *phy2_gen;
>>>> +       struct phy              *phy3_gen;
>>>>    };

>>> I don't think adding new variables here and restricting most of this
>>> logic to xhci-plat.c (in the next patch) is the best way to do it.

>>     Indeed.

    Actually, I haven't given enough thought to this...

>>> There's no conceptual reason why other host controllers (e.g. xhci-pci
>>> or even EHCI) could not have a similar need to tune their PHY after
>>> reset. PHYs are universal to all host controllers.

>>> There is already a 'phy' member in struct usb_hcd which I think is
>>> mostly unused right now. I think it would be much less
>>> confusing/redundant to reuse that member for this purpose (you could
>>> still set it up from xhci_plat_probe(), and then call it from
>>> hcd_bus_resume() or something like that).

>>     That member has type 'struct usb_phy *' while here we have 'struct phy *'
>> -- feel the difference.
>>     I have already tried adding 'struct phy *gen_phy' to 'struct usb_hcd',

> So the 'struct phy *' available in the usb_hcd is requested in usb_add_hcd().
> This is requested with the constant string 'usb' :
>             struct phy *phy = phy_get(hcd->self.controller, "usb");

> This can get the phy with string 'usb' only if, either the host
> controller has a device node wherein the phys are given.

    Yes, that was the plan. Currently, the PHY driver for which this was 
written can be probed from the device tree only.

> Even in this case one can't give same constant string for two
> different phys, UTMI+ and PIPE3 phy, isn't it ?

    Yes, you're right. I didn't really consider the case of some host needing 
2 distinct PHY.

> Or, the other way can be when host gets a lookup table to look into to
> find the relevant phys, something like
> Heikki has suggested:
> usb: dwc3: host: convey the PHYs to xhci
> (https://lkml.org/lkml/2014/6/5/585) and related patch series.

    Well, AFAIK the look-up table method is already provided by the current 
PHY core for non-DT use cases; this doesn't seem to have changed with that 
patch set, does it?

> So if we use this second approach, we would need to override the
> 'phy_get()' that has been done in usb_add_hcd()
> in xhci_plat_probe(), and then use them in later operations.

    I guess it'd probably be simpler to ignore the 'gen_phy' member of 'struct 
usb_hcd' in your case (if it gets eventually added).

WBR, Sergei

Re: [PATCH 2/4] usb: host: xhci-plat: Add support to get PHYs

[Sergei Shtylyov]

Hello.

On 06/25/2014 12:44 PM, Vivek Gautam wrote:

>>>> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
>>>> index 9ffecd5..453d89e 100644
>>>> --- a/drivers/usb/host/xhci.h
>>>> +++ b/drivers/usb/host/xhci.h
>>>> @@ -1582,6 +1582,9 @@ struct xhci_hcd {
>>>>           u32                     port_status_u0;
>>>>    /* Compliance Mode Timer Triggered every 2 seconds */
>>>>    #define COMP_MODE_RCVRY_MSECS 2000
>>>> +       /* phys for the controller */
>>>> +       struct phy              *phy2_gen;
>>>> +       struct phy              *phy3_gen;
>>>>    };

>>> I don't think adding new variables here and restricting most of this
>>> logic to xhci-plat.c (in the next patch) is the best way to do it.

>>     Indeed.

    Actually, I haven't given enough thought to this...

>>> There's no conceptual reason why other host controllers (e.g. xhci-pci
>>> or even EHCI) could not have a similar need to tune their PHY after
>>> reset. PHYs are universal to all host controllers.

>>> There is already a 'phy' member in struct usb_hcd which I think is
>>> mostly unused right now. I think it would be much less
>>> confusing/redundant to reuse that member for this purpose (you could
>>> still set it up from xhci_plat_probe(), and then call it from
>>> hcd_bus_resume() or something like that).

>>     That member has type 'struct usb_phy *' while here we have 'struct phy *'
>> -- feel the difference.
>>     I have already tried adding 'struct phy *gen_phy' to 'struct usb_hcd',

> So the 'struct phy *' available in the usb_hcd is requested in usb_add_hcd().
> This is requested with the constant string 'usb' :
>             struct phy *phy = phy_get(hcd->self.controller, "usb");

> This can get the phy with string 'usb' only if, either the host
> controller has a device node wherein the phys are given.

    Yes, that was the plan. Currently, the PHY driver for which this was 
written can be probed from the device tree only.

> Even in this case one can't give same constant string for two
> different phys, UTMI+ and PIPE3 phy, isn't it ?

    Yes, you're right. I didn't really consider the case of some host needing 
2 distinct PHY.

> Or, the other way can be when host gets a lookup table to look into to
> find the relevant phys, something like
> Heikki has suggested:
> usb: dwc3: host: convey the PHYs to xhci
> (https://lkml.org/lkml/2014/6/5/585) and related patch series.

    Well, AFAIK the look-up table method is already provided by the current 
PHY core for non-DT use cases; this doesn't seem to have changed with that 
patch set, does it?

> So if we use this second approach, we would need to override the
> 'phy_get()' that has been done in usb_add_hcd()
> in xhci_plat_probe(), and then use them in later operations.

    I guess it'd probably be simpler to ignore the 'gen_phy' member of 'struct 
usb_hcd' in your case (if it gets eventually added).

WBR, Sergei

[PATCH 2/4] usb: host: xhci-plat: Add support to get PHYs

[Sergei Shtylyov]

Hello.

On 06/25/2014 12:44 PM, Vivek Gautam wrote:

>>>> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
>>>> index 9ffecd5..453d89e 100644
>>>> --- a/drivers/usb/host/xhci.h
>>>> +++ b/drivers/usb/host/xhci.h
>>>> @@ -1582,6 +1582,9 @@ struct xhci_hcd {
>>>>           u32                     port_status_u0;
>>>>    /* Compliance Mode Timer Triggered every 2 seconds */
>>>>    #define COMP_MODE_RCVRY_MSECS 2000
>>>> +       /* phys for the controller */
>>>> +       struct phy              *phy2_gen;
>>>> +       struct phy              *phy3_gen;
>>>>    };

>>> I don't think adding new variables here and restricting most of this
>>> logic to xhci-plat.c (in the next patch) is the best way to do it.

>>     Indeed.

    Actually, I haven't given enough thought to this...

>>> There's no conceptual reason why other host controllers (e.g. xhci-pci
>>> or even EHCI) could not have a similar need to tune their PHY after
>>> reset. PHYs are universal to all host controllers.

>>> There is already a 'phy' member in struct usb_hcd which I think is
>>> mostly unused right now. I think it would be much less
>>> confusing/redundant to reuse that member for this purpose (you could
>>> still set it up from xhci_plat_probe(), and then call it from
>>> hcd_bus_resume() or something like that).

>>     That member has type 'struct usb_phy *' while here we have 'struct phy *'
>> -- feel the difference.
>>     I have already tried adding 'struct phy *gen_phy' to 'struct usb_hcd',

> So the 'struct phy *' available in the usb_hcd is requested in usb_add_hcd().
> This is requested with the constant string 'usb' :
>             struct phy *phy = phy_get(hcd->self.controller, "usb");

> This can get the phy with string 'usb' only if, either the host
> controller has a device node wherein the phys are given.

    Yes, that was the plan. Currently, the PHY driver for which this was 
written can be probed from the device tree only.

> Even in this case one can't give same constant string for two
> different phys, UTMI+ and PIPE3 phy, isn't it ?

    Yes, you're right. I didn't really consider the case of some host needing 
2 distinct PHY.

> Or, the other way can be when host gets a lookup table to look into to
> find the relevant phys, something like
> Heikki has suggested:
> usb: dwc3: host: convey the PHYs to xhci
> (https://lkml.org/lkml/2014/6/5/585) and related patch series.

    Well, AFAIK the look-up table method is already provided by the current 
PHY core for non-DT use cases; this doesn't seem to have changed with that 
patch set, does it?

> So if we use this second approach, we would need to override the
> 'phy_get()' that has been done in usb_add_hcd()
> in xhci_plat_probe(), and then use them in later operations.

    I guess it'd probably be simpler to ignore the 'gen_phy' member of 'struct 
usb_hcd' in your case (if it gets eventually added).

WBR, Sergei

Re: [PATCH 1/4] phy: Add provision for calibrating phy.

[Vivek Gautam]

Hi,


On Mon, Jun 9, 2014 at 9:19 AM, Pratyush Anand <pratyush.anand@st.com> wrote:
> On Fri, Jun 06, 2014 at 08:12:12PM +0800, Vivek Gautam wrote:
>> Some PHY controllers may need to calibrate certain
>> PHY settings after initialization of the controller and
>> sometimes even after initializing the PHY-consumer too.
>> Add support for the same in order to let consumers do so in need.
>>
>> Signed-off-by: vivek Gautam <gautam.vivek@samsung.com>
>> ---
>>  drivers/phy/phy-core.c  |   36 ++++++++++++++++++++++++++++++++++++
>>  include/linux/phy/phy.h |    7 +++++++
>>  2 files changed, 43 insertions(+)
>>
>> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
>> index 74d4346..92d31a3 100644
>> --- a/drivers/phy/phy-core.c
>> +++ b/drivers/phy/phy-core.c
>> @@ -376,6 +376,42 @@ int phy_power_off(struct phy *phy)
>>  EXPORT_SYMBOL_GPL(phy_power_off);
>>
>>  /**
>> + * phy_calibrate - calibrate a phy post initialization
>> + * @phy: Pointer to 'phy' from consumer
>> + *
>> + * For certain PHYs, it may be needed to calibrate few phy parameters
>> + * post initialization. The need to calibrate may arise after the
>
> For USB you may need to calibrate phy after each new connection. If
> so, why not to use already existing struct usb_phy's notify_connect.

The phy_calibrate will rather be a one time phenomenon.
On exynos atleast the case is : the phy settings for PIPE3 phy on DWC3
controller need to be
configured post hcd reset. so that we don't need to re-configure these
phy settings on every connect.

Moreover *there are certain devices* which need these PHY settings
even to show a connect-status-change.
So, it would rather be not useful to create a 'phy_notify_connect' API
in drivers/phy/ and use the same for this purpose.



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India

Re: [PATCH 1/4] phy: Add provision for calibrating phy.

[Vivek Gautam]

Hi,


On Mon, Jun 9, 2014 at 9:19 AM, Pratyush Anand <pratyush.anand@st.com> wrote:
> On Fri, Jun 06, 2014 at 08:12:12PM +0800, Vivek Gautam wrote:
>> Some PHY controllers may need to calibrate certain
>> PHY settings after initialization of the controller and
>> sometimes even after initializing the PHY-consumer too.
>> Add support for the same in order to let consumers do so in need.
>>
>> Signed-off-by: vivek Gautam <gautam.vivek@samsung.com>
>> ---
>>  drivers/phy/phy-core.c  |   36 ++++++++++++++++++++++++++++++++++++
>>  include/linux/phy/phy.h |    7 +++++++
>>  2 files changed, 43 insertions(+)
>>
>> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
>> index 74d4346..92d31a3 100644
>> --- a/drivers/phy/phy-core.c
>> +++ b/drivers/phy/phy-core.c
>> @@ -376,6 +376,42 @@ int phy_power_off(struct phy *phy)
>>  EXPORT_SYMBOL_GPL(phy_power_off);
>>
>>  /**
>> + * phy_calibrate - calibrate a phy post initialization
>> + * @phy: Pointer to 'phy' from consumer
>> + *
>> + * For certain PHYs, it may be needed to calibrate few phy parameters
>> + * post initialization. The need to calibrate may arise after the
>
> For USB you may need to calibrate phy after each new connection. If
> so, why not to use already existing struct usb_phy's notify_connect.

The phy_calibrate will rather be a one time phenomenon.
On exynos atleast the case is : the phy settings for PIPE3 phy on DWC3
controller need to be
configured post hcd reset. so that we don't need to re-configure these
phy settings on every connect.

Moreover *there are certain devices* which need these PHY settings
even to show a connect-status-change.
So, it would rather be not useful to create a 'phy_notify_connect' API
in drivers/phy/ and use the same for this purpose.



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India

[PATCH 1/4] phy: Add provision for calibrating phy.

[Vivek Gautam]

Hi,


On Mon, Jun 9, 2014 at 9:19 AM, Pratyush Anand <pratyush.anand@st.com> wrote:
> On Fri, Jun 06, 2014 at 08:12:12PM +0800, Vivek Gautam wrote:
>> Some PHY controllers may need to calibrate certain
>> PHY settings after initialization of the controller and
>> sometimes even after initializing the PHY-consumer too.
>> Add support for the same in order to let consumers do so in need.
>>
>> Signed-off-by: vivek Gautam <gautam.vivek@samsung.com>
>> ---
>>  drivers/phy/phy-core.c  |   36 ++++++++++++++++++++++++++++++++++++
>>  include/linux/phy/phy.h |    7 +++++++
>>  2 files changed, 43 insertions(+)
>>
>> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
>> index 74d4346..92d31a3 100644
>> --- a/drivers/phy/phy-core.c
>> +++ b/drivers/phy/phy-core.c
>> @@ -376,6 +376,42 @@ int phy_power_off(struct phy *phy)
>>  EXPORT_SYMBOL_GPL(phy_power_off);
>>
>>  /**
>> + * phy_calibrate - calibrate a phy post initialization
>> + * @phy: Pointer to 'phy' from consumer
>> + *
>> + * For certain PHYs, it may be needed to calibrate few phy parameters
>> + * post initialization. The need to calibrate may arise after the
>
> For USB you may need to calibrate phy after each new connection. If
> so, why not to use already existing struct usb_phy's notify_connect.

The phy_calibrate will rather be a one time phenomenon.
On exynos atleast the case is : the phy settings for PIPE3 phy on DWC3
controller need to be
configured post hcd reset. so that we don't need to re-configure these
phy settings on every connect.

Moreover *there are certain devices* which need these PHY settings
even to show a connect-status-change.
So, it would rather be not useful to create a 'phy_notify_connect' API
in drivers/phy/ and use the same for this purpose.



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India