[PATCH v4 00/22] Support qcom's HSIC USB and rewrite USB2 HS support

[PATCH v4 00/22] Support qcom's HSIC USB and rewrite USB2 HS support

[Stephen Boyd]

The state of USB ChipIdea support on Qualcomm's platforms is not great.
The DT description of these devices requires up to three different nodes
for what amounts to be the same hardware block, when there should really
only be one. Furthermore, the "phy" driver that is in mainline (phy-msm-usb.c)
duplicates the OTG state machine and touches the ci controller wrapper
registers when it should really be focused on the phy and the ULPI accesses
needed to get the phy working. There's also a slimmed down phy driver for
the msm8916 platform, but really the phy hardware is the same as other MSMs,
so we have two drivers doing pretty much the same thing. This leads to a
situtaion where we have the chipidea core driver, the "phy" driver, and
sometimes the ehci-msm.c driver operating the same device all at the same
time with very little coordination. This just isn't very safe and is
confusing from a driver perspective when trying to figure out who does what.
Finally, there isn't any HSIC support on platforms like apq8074 so we
should add that.

This patch series updates the ChipIdea driver and the MSM wrapper
(ci_hdrc_msm.c) to properly handle the PHY and wrapper bits at the right
times in the right places. To get there, we update the ChipIdea core to
have support for the ULPI phy bus introduced by Heikki. Along the way
we fix bugs with the extcon handling for peripheral and OTG mode controllers
and move the parts of phy-usb-msm.c that are touching the CI controller
wrapper into the wrapper driver (ci_hdrc_msm.c). Finally we add support
for the HSIC phy based on the ULPI bus and rewrite the HS phy driver
(phy-usb-msm.c) as a standard ULPI phy driver.

Once this series is accepted, we should be able to delete the phy-usb-msm.c,
phy-qcom-8x16-usb.c, and ehci-msm.c drivers from the tree and use the ULPI
based phy driver (which also lives in drivers/phy/ instead of drivers/usb/phy/)
and the chipidea host core instead.

I've also sent separate patches for other minor pieces to make this
all work. The full tree can be found here[3], hacks and all to get
things working. I've tested this on the db410c, apq8074 dragonboard,
and ifc6410 with configfs gadgets and otg cables.

Patches based on v4.8-rc1

Changes from v3:

 * Picked up Acks from Peter

 * Updated extcon consolidation patch per Peter's comments

 * Folded in simplification from Heikki for ULPI DT matching

Changes from v2:

 * Added SoC specific compatibles in phy bindings

 * Dropped AVVIS patch for OTG statemachine

 * New patch to consolidate extcon handlers

 * Picked up Acks from Peter

 * Rebased onto v4.8-rc1

 * Reworked ULPI OF code to look at vid == 0 instead of pid == 0
 
 * Dropped ULPI bindings for vid and pid overrides

Changes from v1:

 * Reworked ULPI device probing to keep using vendor/product ids that
   come from DT if needed and falls back to OF style match when product id
   is 0

 * PHY init later patch was rejected so that moved to a quirk flag and
   the msm wrapper started managing the phy on/off

 * Updated clk requirements for HSIC phy in binding doc

 * Added optional clk in wrapper for "housekeeping" found on older qcom
   platforms
 
 * Bug fix to OTGSC polling function

 * Changed runtime PM patch to set as active instead of get/put

TODO:
 * DMA fails on arm64 so we need something like [1] to make it work.

 * The db410c needs a driver to toggle the onboard switch to connect
   the usb hub instead of micro port when the usb cable is disconnected

 * apq8064 platforms need a vbus regulator to really use otg and I haven't
   tried out the RPM based regulators yet

 * The HSIC phy on the apq8074 dragonboard is connected to a usb4604
   device which requires the i2c driver to probe and send an i2c
   sequence before the HSIC controller enumerates or HSIC doesn't work.
   Right now I have a hack to force the controller to probe defer
   once so that usb4604 probes first. This needs a more proper solution
   like having the DT describe a linkage between the controller and
   the usb device so we can enforce probe ordering.
 
 * OTG support requires a working VBUS supply on apq8074 dragonboard
   and that requires changes to the smbb_charger driver to support
   the OTG OVP switch as a regulator[2]. This series needs revival
   on the list so that OTG works properly on that board.

[1] https://lkml.org/lkml/2016/2/22/7
[2] http://lkml.kernel.org/g/1449621618-11900-1-git-send-email-tim.bird@sonymobile.com
[3] https://git.linaro.org/people/stephen.boyd/linux.git/shortlog/refs/heads/usb-hsic-8074


Stephen Boyd (22):
  of: device: Support loading a module with OF based modalias
  of: device: Export of_device_{get_modalias,uvent_modalias} to modules
  usb: ulpi: Support device discovery via DT
  usb: chipidea: Only read/write OTGSC from one place
  usb: chipidea: Handle extcon events properly
  usb: chipidea: Add platform flag for wrapper phy management
  usb: chipidea: Notify events when switching host mode
  usb: chipidea: Remove locking in ci_udc_start()
  usb: chipidea: Add support for ULPI PHY bus
  usb: chipidea: Consolidate extcon notifiers
  usb: chipidea: msm: Mark device as runtime pm active
  usb: chipidea: msm: Rely on core to override AHBBURST
  usb: chipidea: msm: Use hw_write_id_reg() instead of writel
  usb: chipidea: msm: Add proper clk and reset support
  usb: chipidea: msm: Mux over secondary phy at the right time
  usb: chipidea: msm: Restore wrapper settings after reset
  usb: chipidea: msm: Make platform data driver local instead of global
  usb: chipidea: msm: Add reset controller for PHY POR bit
  usb: chipidea: msm: Handle phy power states
  usb: chipidea: msm: Be silent on probe defer errors
  phy: Add support for Qualcomm's USB HSIC phy
  phy: Add support for Qualcomm's USB HS phy

 .../devicetree/bindings/phy/qcom,usb-hs-phy.txt    |  83 ++++++
 .../devicetree/bindings/phy/qcom,usb-hsic-phy.txt  |  65 +++++
 Documentation/devicetree/bindings/usb/ulpi.txt     |  20 ++
 drivers/of/device.c                                |  25 ++
 drivers/phy/Kconfig                                |  15 ++
 drivers/phy/Makefile                               |   2 +
 drivers/phy/phy-qcom-usb-hs.c                      | 289 +++++++++++++++++++++
 drivers/phy/phy-qcom-usb-hsic.c                    | 160 ++++++++++++
 drivers/usb/chipidea/Kconfig                       |   8 +
 drivers/usb/chipidea/Makefile                      |   1 +
 drivers/usb/chipidea/ci.h                          |  22 +-
 drivers/usb/chipidea/ci_hdrc_msm.c                 | 280 +++++++++++++++++---
 drivers/usb/chipidea/core.c                        | 122 ++++-----
 drivers/usb/chipidea/host.c                        |  10 +
 drivers/usb/chipidea/otg.c                         |  86 +++++-
 drivers/usb/chipidea/udc.c                         |   3 -
 drivers/usb/chipidea/ulpi.c                        | 113 ++++++++
 drivers/usb/common/ulpi.c                          |  77 +++++-
 include/linux/of_device.h                          |   6 +
 include/linux/usb/chipidea.h                       |   9 +-
 20 files changed, 1259 insertions(+), 137 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
 create mode 100644 Documentation/devicetree/bindings/phy/qcom,usb-hsic-phy.txt
 create mode 100644 Documentation/devicetree/bindings/usb/ulpi.txt
 create mode 100644 drivers/phy/phy-qcom-usb-hs.c
 create mode 100644 drivers/phy/phy-qcom-usb-hsic.c
 create mode 100644 drivers/usb/chipidea/ulpi.c

-- 
2.9.0.rc2.8.ga28705d

[PATCH v4 01/22] of: device: Support loading a module with OF based modalias

[Stephen Boyd]

In the case of ULPI devices, we want to be able to load the
driver before registering the device so that we don't get stuck
in a loop waiting for the phy module to appear and failing usb
controller probe. Currently we request the ulpi module via the
ulpi ids, but in the DT case we might need to request it with the
OF based modalias instead. Add a common function that allows
anyone to request a module with the OF based modalias.

Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Signed-off-by: Stephen Boyd <stephen.boyd-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 drivers/of/device.c       | 23 +++++++++++++++++++++++
 include/linux/of_device.h |  6 ++++++
 2 files changed, 29 insertions(+)

diff --git a/drivers/of/device.c b/drivers/of/device.c
index fd5cfad7c403..8a22a253a830 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -226,6 +226,29 @@ ssize_t of_device_get_modalias(struct device *dev, char *str, ssize_t len)
 	return tsize;
 }
 
+int of_device_request_module(struct device *dev)
+{
+	char *str;
+	ssize_t size;
+	int ret;
+
+	size = of_device_get_modalias(dev, NULL, 0);
+	if (size < 0)
+		return size;
+
+	str = kmalloc(size + 1, GFP_KERNEL);
+	if (!str)
+		return -ENOMEM;
+
+	of_device_get_modalias(dev, str, size);
+	str[size] = '\0';
+	ret = request_module(str);
+	kfree(str);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(of_device_request_module);
+
 /**
  * of_device_uevent - Display OF related uevent information
  */
diff --git a/include/linux/of_device.h b/include/linux/of_device.h
index cc7dd687a89d..e9afbcc8de12 100644
--- a/include/linux/of_device.h
+++ b/include/linux/of_device.h
@@ -37,6 +37,7 @@ extern const void *of_device_get_match_data(const struct device *dev);
 
 extern ssize_t of_device_get_modalias(struct device *dev,
 					char *str, ssize_t len);
+extern int of_device_request_module(struct device *dev);
 
 extern void of_device_uevent(struct device *dev, struct kobj_uevent_env *env);
 extern int of_device_uevent_modalias(struct device *dev, struct kobj_uevent_env *env);
@@ -78,6 +79,11 @@ static inline int of_device_get_modalias(struct device *dev,
 	return -ENODEV;
 }
 
+static inline int of_device_request_module(struct device *dev)
+{
+	return -ENODEV;
+}
+
 static inline int of_device_uevent_modalias(struct device *dev,
 				   struct kobj_uevent_env *env)
 {
-- 
2.9.0.rc2.8.ga28705d

--
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 v4 02/22] of: device: Export of_device_{get_modalias, uvent_modalias} to modules

[Stephen Boyd]

The ULPI bus can be built as a module, and it will soon be
calling these functions when it supports probing devices from DT.
Export them so they can be used by the ULPI module.

Cc: Rob Herring <robh+dt@kernel.org>
Cc: <devicetree@vger.kernel.org>
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
---
 drivers/of/device.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/of/device.c b/drivers/of/device.c
index 8a22a253a830..6719ab35b62e 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -225,6 +225,7 @@ ssize_t of_device_get_modalias(struct device *dev, char *str, ssize_t len)
 
 	return tsize;
 }
+EXPORT_SYMBOL_GPL(of_device_get_modalias);
 
 int of_device_request_module(struct device *dev)
 {
@@ -290,6 +291,7 @@ void of_device_uevent(struct device *dev, struct kobj_uevent_env *env)
 	}
 	mutex_unlock(&of_mutex);
 }
+EXPORT_SYMBOL_GPL(of_device_uevent_modalias);
 
 int of_device_uevent_modalias(struct device *dev, struct kobj_uevent_env *env)
 {
-- 
2.9.0.rc2.8.ga28705d

[PATCH v4 03/22] usb: ulpi: Support device discovery via DT

[Stephen Boyd]

The qcom HSIC ULPI phy doesn't have any bits set in the vendor or
product ID registers. This makes it impossible to make a ULPI
driver match against the ID registers. Add support to discover
the ULPI phys via DT help alleviate this problem. In the DT case,
we'll look for a ULPI bus node underneath the device registering
the ULPI viewport (or the parent of that device to support
chipidea's device layout) and then match up the phy node
underneath that with the ULPI device that's created.

The side benefit of this is that we can use standard properties
in the phy node like clks, regulators, gpios, etc. because we
don't have firmware like ACPI to turn these things on for us. And
we can use the DT phy binding to point our phy consumer to the
phy provider.

The ULPI bus code supports native enumeration by reading the
vendor ID and product ID registers at device creation time, but
we can't be certain that those register reads will succeed if the
phy is not powered up. To avoid any problems with reading the ID
registers before the phy is powered we fallback to DT matching
when the ID reads fail.

If the ULPI spec had some generic power sequencing for these
registers we could put that into the ULPI bus layer and power up
the device before reading the ID registers. Unfortunately this
doesn't exist and the power sequence is usually device specific.
By having the device matched up with DT we can avoid this
problem.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: <devicetree@vger.kernel.org>
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
---
 Documentation/devicetree/bindings/usb/ulpi.txt | 20 +++++++
 drivers/usb/common/ulpi.c                      | 77 ++++++++++++++++++++++++--
 2 files changed, 92 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/ulpi.txt

diff --git a/Documentation/devicetree/bindings/usb/ulpi.txt b/Documentation/devicetree/bindings/usb/ulpi.txt
new file mode 100644
index 000000000000..ca179dc4bd50
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ulpi.txt
@@ -0,0 +1,20 @@
+ULPI bus binding
+----------------
+
+Phys that are behind a ULPI connection can be described with the following
+binding. The host controller shall have a "ulpi" named node as a child, and
+that node shall have one enabled node underneath it representing the ulpi
+device on the bus.
+
+EXAMPLE
+-------
+
+usb {
+	compatible = "vendor,usb-controller";
+
+	ulpi {
+		phy {
+			compatible = "vendor,phy";
+		};
+	};
+};
diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
index 01c0c0477a9e..24689e05a3df 100644
--- a/drivers/usb/common/ulpi.c
+++ b/drivers/usb/common/ulpi.c
@@ -16,6 +16,9 @@
 #include <linux/module.h>
 #include <linux/slab.h>
 #include <linux/acpi.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/clk/clk-conf.h>
 
 /* -------------------------------------------------------------------------- */
 
@@ -39,6 +42,10 @@ static int ulpi_match(struct device *dev, struct device_driver *driver)
 	struct ulpi *ulpi = to_ulpi_dev(dev);
 	const struct ulpi_device_id *id;
 
+	/* Some ULPI devices don't have a vendor id so rely on OF match */
+	if (ulpi->id.vendor == 0)
+		return of_driver_match_device(dev, driver);
+
 	for (id = drv->id_table; id->vendor; id++)
 		if (id->vendor == ulpi->id.vendor &&
 		    id->product == ulpi->id.product)
@@ -50,6 +57,11 @@ static int ulpi_match(struct device *dev, struct device_driver *driver)
 static int ulpi_uevent(struct device *dev, struct kobj_uevent_env *env)
 {
 	struct ulpi *ulpi = to_ulpi_dev(dev);
+	int ret;
+
+	ret = of_device_uevent_modalias(dev, env);
+	if (ret != -ENODEV)
+		return ret;
 
 	if (add_uevent_var(env, "MODALIAS=ulpi:v%04xp%04x",
 			   ulpi->id.vendor, ulpi->id.product))
@@ -60,6 +72,11 @@ static int ulpi_uevent(struct device *dev, struct kobj_uevent_env *env)
 static int ulpi_probe(struct device *dev)
 {
 	struct ulpi_driver *drv = to_ulpi_driver(dev->driver);
+	int ret;
+
+	ret = of_clk_set_defaults(dev->of_node, false);
+	if (ret < 0)
+		return ret;
 
 	return drv->probe(to_ulpi_dev(dev));
 }
@@ -87,8 +104,13 @@ static struct bus_type ulpi_bus = {
 static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
 			     char *buf)
 {
+	int len;
 	struct ulpi *ulpi = to_ulpi_dev(dev);
 
+	len = of_device_get_modalias(dev, buf, PAGE_SIZE - 1);
+	if (len != -ENODEV)
+		return len;
+
 	return sprintf(buf, "ulpi:v%04xp%04x\n",
 		       ulpi->id.vendor, ulpi->id.product);
 }
@@ -152,21 +174,44 @@ EXPORT_SYMBOL_GPL(ulpi_unregister_driver);
 
 /* -------------------------------------------------------------------------- */
 
-static int ulpi_register(struct device *dev, struct ulpi *ulpi)
+static int ulpi_of_register(struct ulpi *ulpi)
+{
+	struct device_node *np = NULL, *child;
+
+	/* Find a ulpi bus underneath the parent or the parent of the parent */
+	if (ulpi->dev.parent->of_node)
+		np = of_find_node_by_name(ulpi->dev.parent->of_node, "ulpi");
+	else if (ulpi->dev.parent->parent && ulpi->dev.parent->parent->of_node)
+		np = of_find_node_by_name(ulpi->dev.parent->parent->of_node,
+					  "ulpi");
+	if (!np)
+		return 0;
+
+	child = of_get_next_available_child(np, NULL);
+	of_node_put(np);
+	if (!child)
+		return -EINVAL;
+
+	ulpi->dev.of_node = child;
+
+	return 0;
+}
+
+static int ulpi_read_id(struct ulpi *ulpi)
 {
 	int ret;
 
 	/* Test the interface */
 	ret = ulpi_write(ulpi, ULPI_SCRATCH, 0xaa);
 	if (ret < 0)
-		return ret;
+		goto err;
 
 	ret = ulpi_read(ulpi, ULPI_SCRATCH);
 	if (ret < 0)
-		return ret;
+		goto err;
 
 	if (ret != 0xaa)
-		return -ENODEV;
+		goto err;
 
 	ulpi->id.vendor = ulpi_read(ulpi, ULPI_VENDOR_ID_LOW);
 	ulpi->id.vendor |= ulpi_read(ulpi, ULPI_VENDOR_ID_HIGH) << 8;
@@ -174,6 +219,21 @@ static int ulpi_register(struct device *dev, struct ulpi *ulpi)
 	ulpi->id.product = ulpi_read(ulpi, ULPI_PRODUCT_ID_LOW);
 	ulpi->id.product |= ulpi_read(ulpi, ULPI_PRODUCT_ID_HIGH) << 8;
 
+	/* Some ULPI devices don't have a vendor id so rely on OF match */
+	if (ulpi->id.vendor == 0)
+		goto err;
+
+	request_module("ulpi:v%04xp%04x", ulpi->id.vendor, ulpi->id.product);
+
+	return 0;
+err:
+	return of_device_request_module(&ulpi->dev);
+}
+
+static int ulpi_register(struct device *dev, struct ulpi *ulpi)
+{
+	int ret;
+
 	ulpi->dev.parent = dev;
 	ulpi->dev.bus = &ulpi_bus;
 	ulpi->dev.type = &ulpi_dev_type;
@@ -181,7 +241,13 @@ static int ulpi_register(struct device *dev, struct ulpi *ulpi)
 
 	ACPI_COMPANION_SET(&ulpi->dev, ACPI_COMPANION(dev));
 
-	request_module("ulpi:v%04xp%04x", ulpi->id.vendor, ulpi->id.product);
+	ret = ulpi_of_register(ulpi);
+	if (ret)
+		return ret;
+
+	ret = ulpi_read_id(ulpi);
+	if (ret)
+		return ret;
 
 	ret = device_register(&ulpi->dev);
 	if (ret)
@@ -232,6 +298,7 @@ EXPORT_SYMBOL_GPL(ulpi_register_interface);
  */
 void ulpi_unregister_interface(struct ulpi *ulpi)
 {
+	of_node_put(ulpi->dev.of_node);
 	device_unregister(&ulpi->dev);
 }
 EXPORT_SYMBOL_GPL(ulpi_unregister_interface);
-- 
2.9.0.rc2.8.ga28705d

[PATCH v4 21/22] phy: Add support for Qualcomm's USB HSIC phy

[Stephen Boyd]

The HSIC USB controller on qcom SoCs has an integrated all
digital phy controlled via the ULPI viewport.

Cc: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
Cc: <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Signed-off-by: Stephen Boyd <stephen.boyd-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 .../devicetree/bindings/phy/qcom,usb-hsic-phy.txt  |  65 +++++++++
 drivers/phy/Kconfig                                |   7 +
 drivers/phy/Makefile                               |   1 +
 drivers/phy/phy-qcom-usb-hsic.c                    | 160 +++++++++++++++++++++
 4 files changed, 233 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom,usb-hsic-phy.txt
 create mode 100644 drivers/phy/phy-qcom-usb-hsic.c

diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hsic-phy.txt b/Documentation/devicetree/bindings/phy/qcom,usb-hsic-phy.txt
new file mode 100644
index 000000000000..3c7cb2be4b12
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,usb-hsic-phy.txt
@@ -0,0 +1,65 @@
+Qualcomm's USB HSIC PHY
+
+PROPERTIES
+
+- compatible:
+    Usage: required
+    Value type: <string>
+    Definition: Should contain "qcom,usb-hsic-phy" and more specifically one of the
+		following:
+
+			"qcom,usb-hsic-phy-mdm9615"
+			"qcom,usb-hsic-phy-msm8974"
+
+- #phy-cells:
+    Usage: required
+    Value type: <u32>
+    Definition: Should contain 0
+
+- clocks:
+    Usage: required
+    Value type: <prop-encoded-array>
+    Definition: Should contain clock specifier for phy, calibration and
+                a calibration sleep clock
+
+- clock-names:
+    Usage: required
+    Value type: <stringlist>
+    Definition: Should contain "phy, "cal" and "cal_sleep"
+
+- pinctrl-names:
+    Usage: required
+    Value type: <stringlist>
+    Definition: Should contain "init" and "default" in that order
+
+- pinctrl-0:
+    Usage: required
+    Value type: <prop-encoded-array>
+    Definition: List of pinctrl settings to apply to keep HSIC pins in a glitch
+                free state
+
+- pinctrl-1:
+    Usage: required
+    Value type: <prop-encoded-array>
+    Definition: List of pinctrl settings to apply to mux out the HSIC pins
+
+EXAMPLE
+
+usb-controller {
+	ulpi {
+		phy {
+			compatible = "qcom,usb-hsic-phy-msm8974",
+				     "qcom,usb-hsic-phy";
+			#phy-cells = <0>;
+			pinctrl-names = "init", "default";
+			pinctrl-0 = <&hsic_sleep>;
+			pinctrl-1 = <&hsic_default>;
+			clocks = <&gcc GCC_USB_HSIC_CLK>,
+				 <&gcc GCC_USB_HSIC_IO_CAL_CLK>,
+				 <&gcc GCC_USB_HSIC_IO_CAL_SLEEP_CLK>;
+			clock-names = "phy", "cal", "cal_sleep";
+			assigned-clocks = <&gcc GCC_USB_HSIC_IO_CAL_CLK>;
+			assigned-clock-rates = <960000>;
+		};
+	};
+};
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 19bff3a10f69..830c443eeabf 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -417,6 +417,13 @@ config PHY_QCOM_UFS
 	help
 	  Support for UFS PHY on QCOM chipsets.
 
+config PHY_QCOM_USB_HSIC
+	tristate "Qualcomm USB HSIC ULPI PHY module"
+	depends on USB_ULPI_BUS
+	select GENERIC_PHY
+	help
+	  Support for the USB HSIC ULPI compliant PHY on QCOM chipsets.
+
 config PHY_TUSB1210
 	tristate "TI TUSB1210 ULPI PHY module"
 	depends on USB_ULPI_BUS
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 90ae19879b0a..5422f543d17d 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_PHY_STIH41X_USB)		+= phy-stih41x-usb.o
 obj-$(CONFIG_PHY_QCOM_UFS) 	+= phy-qcom-ufs.o
 obj-$(CONFIG_PHY_QCOM_UFS) 	+= phy-qcom-ufs-qmp-20nm.o
 obj-$(CONFIG_PHY_QCOM_UFS) 	+= phy-qcom-ufs-qmp-14nm.o
+obj-$(CONFIG_PHY_QCOM_USB_HSIC) 	+= phy-qcom-usb-hsic.o
 obj-$(CONFIG_PHY_TUSB1210)		+= phy-tusb1210.o
 obj-$(CONFIG_PHY_BRCM_SATA)		+= phy-brcm-sata.o
 obj-$(CONFIG_PHY_PISTACHIO_USB)		+= phy-pistachio-usb.o
diff --git a/drivers/phy/phy-qcom-usb-hsic.c b/drivers/phy/phy-qcom-usb-hsic.c
new file mode 100644
index 000000000000..47690f9945b9
--- /dev/null
+++ b/drivers/phy/phy-qcom-usb-hsic.c
@@ -0,0 +1,160 @@
+/**
+ * Copyright (C) 2016 Linaro Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <linux/module.h>
+#include <linux/ulpi/driver.h>
+#include <linux/ulpi/regs.h>
+#include <linux/pinctrl/consumer.h>
+#include <linux/pinctrl/pinctrl-state.h>
+#include <linux/delay.h>
+#include <linux/clk.h>
+
+#include "ulpi_phy.h"
+
+#define ULPI_HSIC_CFG		0x30
+#define ULPI_HSIC_IO_CAL	0x33
+
+struct qcom_usb_hsic_phy {
+	struct ulpi *ulpi;
+	struct phy *phy;
+	struct pinctrl *pctl;
+	struct clk *phy_clk;
+	struct clk *cal_clk;
+	struct clk *cal_sleep_clk;
+};
+
+static int qcom_usb_hsic_phy_power_on(struct phy *phy)
+{
+	struct qcom_usb_hsic_phy *uphy = phy_get_drvdata(phy);
+	struct ulpi *ulpi = uphy->ulpi;
+	struct pinctrl_state *pins_default;
+	int ret;
+
+	ret = clk_prepare_enable(uphy->phy_clk);
+	if (ret)
+		return ret;
+
+	ret = clk_prepare_enable(uphy->cal_clk);
+	if (ret)
+		goto err_cal;
+
+	ret = clk_prepare_enable(uphy->cal_sleep_clk);
+	if (ret)
+		goto err_sleep;
+
+	/* Set periodic calibration interval to ~2.048sec in HSIC_IO_CAL_REG */
+	ret = ulpi_write(ulpi, ULPI_HSIC_IO_CAL, 0xff);
+	if (ret)
+		goto err_ulpi;
+
+	/* Enable periodic IO calibration in HSIC_CFG register */
+	ret = ulpi_write(ulpi, ULPI_HSIC_CFG, 0xa8);
+	if (ret)
+		goto err_ulpi;
+
+	/* Configure pins for HSIC functionality */
+	pins_default = pinctrl_lookup_state(uphy->pctl, PINCTRL_STATE_DEFAULT);
+	if (IS_ERR(pins_default))
+		return PTR_ERR(pins_default);
+
+	ret = pinctrl_select_state(uphy->pctl, pins_default);
+	if (ret)
+		goto err_ulpi;
+
+	 /* Enable HSIC mode in HSIC_CFG register */
+	ret = ulpi_write(ulpi, ULPI_SET(ULPI_HSIC_CFG), 0x01);
+	if (ret)
+		goto err_ulpi;
+
+	/* Disable auto-resume */
+	ret = ulpi_write(ulpi, ULPI_CLR(ULPI_IFC_CTRL),
+			 ULPI_IFC_CTRL_AUTORESUME);
+	if (ret)
+		goto err_ulpi;
+
+	return ret;
+err_ulpi:
+	clk_disable_unprepare(uphy->cal_sleep_clk);
+err_sleep:
+	clk_disable_unprepare(uphy->cal_clk);
+err_cal:
+	clk_disable_unprepare(uphy->phy_clk);
+	return ret;
+}
+
+static int qcom_usb_hsic_phy_power_off(struct phy *phy)
+{
+	struct qcom_usb_hsic_phy *uphy = phy_get_drvdata(phy);
+
+	clk_disable_unprepare(uphy->cal_sleep_clk);
+	clk_disable_unprepare(uphy->cal_clk);
+	clk_disable_unprepare(uphy->phy_clk);
+
+	return 0;
+}
+
+static const struct phy_ops qcom_usb_hsic_phy_ops = {
+	.power_on = qcom_usb_hsic_phy_power_on,
+	.power_off = qcom_usb_hsic_phy_power_off,
+	.owner = THIS_MODULE,
+};
+
+static int qcom_usb_hsic_phy_probe(struct ulpi *ulpi)
+{
+	struct qcom_usb_hsic_phy *uphy;
+	struct phy_provider *p;
+	struct clk *clk;
+
+	uphy = devm_kzalloc(&ulpi->dev, sizeof(*uphy), GFP_KERNEL);
+	if (!uphy)
+		return -ENOMEM;
+	ulpi_set_drvdata(ulpi, uphy);
+
+	uphy->ulpi = ulpi;
+	uphy->pctl = devm_pinctrl_get(&ulpi->dev);
+	if (IS_ERR(uphy->pctl))
+		return PTR_ERR(uphy->pctl);
+
+	uphy->phy_clk = clk = devm_clk_get(&ulpi->dev, "phy");
+	if (IS_ERR(clk))
+		return PTR_ERR(clk);
+
+	uphy->cal_clk = clk = devm_clk_get(&ulpi->dev, "cal");
+	if (IS_ERR(clk))
+		return PTR_ERR(clk);
+
+	uphy->cal_sleep_clk = clk = devm_clk_get(&ulpi->dev, "cal_sleep");
+	if (IS_ERR(clk))
+		return PTR_ERR(clk);
+
+	uphy->phy = devm_phy_create(&ulpi->dev, ulpi->dev.of_node,
+				    &qcom_usb_hsic_phy_ops);
+	if (IS_ERR(uphy->phy))
+		return PTR_ERR(uphy->phy);
+	phy_set_drvdata(uphy->phy, uphy);
+
+	p = devm_of_phy_provider_register(&ulpi->dev, of_phy_simple_xlate);
+	return PTR_ERR_OR_ZERO(p);
+}
+
+static const struct of_device_id qcom_usb_hsic_phy_match[] = {
+	{ .compatible = "qcom,usb-hsic-phy", },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, qcom_usb_hsic_phy_match);
+
+static struct ulpi_driver qcom_usb_hsic_phy_driver = {
+	.probe = qcom_usb_hsic_phy_probe,
+	.driver = {
+		.name = "qcom_usb_hsic_phy",
+		.of_match_table = qcom_usb_hsic_phy_match,
+	},
+};
+module_ulpi_driver(qcom_usb_hsic_phy_driver);
+
+MODULE_DESCRIPTION("Qualcomm USB HSIC phy");
+MODULE_LICENSE("GPL v2");
-- 
2.9.0.rc2.8.ga28705d

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

[PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy

[Stephen Boyd]

The high-speed phy on qcom SoCs is controlled via the ULPI
viewport.

Cc: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
Cc: <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Signed-off-by: Stephen Boyd <stephen.boyd-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 .../devicetree/bindings/phy/qcom,usb-hs-phy.txt    |  83 ++++++
 drivers/phy/Kconfig                                |   8 +
 drivers/phy/Makefile                               |   1 +
 drivers/phy/phy-qcom-usb-hs.c                      | 289 +++++++++++++++++++++
 4 files changed, 381 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
 create mode 100644 drivers/phy/phy-qcom-usb-hs.c

diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
new file mode 100644
index 000000000000..d7eacd63d06b
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
@@ -0,0 +1,83 @@
+Qualcomm's USB HS PHY
+
+PROPERTIES
+
+- compatible:
+    Usage: required
+    Value type: <string>
+    Definition: Should contain "qcom,usb-hs-phy" and more specifically one of the
+                following:
+
+                        "qcom,usb-hs-phy-apq8064"
+                        "qcom,usb-hs-phy-msm8916"
+                        "qcom,usb-hs-phy-msm8974"
+
+- #phy-cells:
+    Usage: required
+    Value type: <u32>
+    Definition: Should contain 0
+
+- clocks:
+    Usage: required
+    Value type: <prop-encoded-array>
+    Definition: Should contain clock specifier for the reference and sleep
+                clocks
+
+- clock-names:
+    Usage: required
+    Value type: <stringlist>
+    Definition: Should contain "ref" and "sleep" for the reference and sleep
+                clocks respectively
+
+- resets:
+    Usage: required
+    Value type: <prop-encoded-array>
+    Definition: Should contain the phy and POR resets
+
+- reset-names:
+    Usage: required
+    Value type: <stringlist>
+    Definition: Should contain "phy" and "por" for the phy and POR resets
+                respectively
+
+- v3p3-supply:
+    Usage: required
+    Value type: <phandle>
+    Definition: Should contain a reference to the 3.3V supply
+
+- v1p8-supply:
+    Usage: required
+    Value type: <phandle>
+    Definition: Should contain a reference to the 1.8V supply
+
+- extcon:
+    Usage: optional
+    Value type: <prop-encoded-array>
+    Definition: Should contain the vbus and ID extcons in the first and second
+                cells respectively
+
+- qcom,init-seq:
+    Usage: optional
+    Value type: <u8 array>
+    Definition: Should contain a sequence of ULPI register and address pairs to
+                program into the ULPI_EXT_VENDOR_SPECIFIC area. This is related
+                to Device Mode Eye Diagram test.
+
+EXAMPLE
+
+otg: usb-controller {
+	ulpi {
+		phy {
+			compatible = "qcom,usb-hs-phy-msm8974", "qcom,usb-hs-phy";
+			#phy-cells = <0>;
+			clocks = <&xo_board>, <&gcc GCC_USB2A_PHY_SLEEP_CLK>;
+			clock-names = "ref", "sleep";
+			resets = <&gcc GCC_USB2A_PHY_BCR>, <&otg 0>;
+			reset-names = "phy", "por";
+			v3p3-supply = <&pm8941_l24>;
+			v1p8-supply = <&pm8941_l6>;
+			extcon = <&smbb>, <&usb_id>;
+			qcom,init-seq = /bits/ 8 <0x81 0x63>;
+		};
+	};
+};
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 830c443eeabf..ee0ec021a98c 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -417,6 +417,14 @@ config PHY_QCOM_UFS
 	help
 	  Support for UFS PHY on QCOM chipsets.
 
+config PHY_QCOM_USB_HS
+	tristate "Qualcomm USB HS PHY module"
+	depends on USB_ULPI_BUS
+	select GENERIC_PHY
+	help
+	  Support for the USB high-speed ULPI compliant phy on Qualcomm
+	  chipsets.
+
 config PHY_QCOM_USB_HSIC
 	tristate "Qualcomm USB HSIC ULPI PHY module"
 	depends on USB_ULPI_BUS
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 5422f543d17d..31c84faa07fa 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_PHY_STIH41X_USB)		+= phy-stih41x-usb.o
 obj-$(CONFIG_PHY_QCOM_UFS) 	+= phy-qcom-ufs.o
 obj-$(CONFIG_PHY_QCOM_UFS) 	+= phy-qcom-ufs-qmp-20nm.o
 obj-$(CONFIG_PHY_QCOM_UFS) 	+= phy-qcom-ufs-qmp-14nm.o
+obj-$(CONFIG_PHY_QCOM_USB_HS) 		+= phy-qcom-usb-hs.o
 obj-$(CONFIG_PHY_QCOM_USB_HSIC) 	+= phy-qcom-usb-hsic.o
 obj-$(CONFIG_PHY_TUSB1210)		+= phy-tusb1210.o
 obj-$(CONFIG_PHY_BRCM_SATA)		+= phy-brcm-sata.o
diff --git a/drivers/phy/phy-qcom-usb-hs.c b/drivers/phy/phy-qcom-usb-hs.c
new file mode 100644
index 000000000000..73fb4b49a8e1
--- /dev/null
+++ b/drivers/phy/phy-qcom-usb-hs.c
@@ -0,0 +1,289 @@
+/**
+ * Copyright (C) 2016 Linaro Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <linux/module.h>
+#include <linux/ulpi/driver.h>
+#include <linux/ulpi/regs.h>
+#include <linux/clk.h>
+#include <linux/regulator/consumer.h>
+#include <linux/of_device.h>
+#include <linux/reset.h>
+#include <linux/extcon.h>
+#include <linux/notifier.h>
+#include <linux/usb/of.h>
+
+#include "ulpi_phy.h"
+
+#define ULPI_PWR_CLK_MNG_REG		0x88
+# define ULPI_PWR_OTG_COMP_DISABLE	BIT(0)
+
+#define ULPI_MISC_A			0x96
+# define ULPI_MISC_A_VBUSVLDEXTSEL	BIT(1)
+# define ULPI_MISC_A_VBUSVLDEXT		BIT(0)
+
+
+struct ulpi_seq {
+	u8 addr;
+	u8 val;
+};
+
+struct qcom_usb_hs_phy {
+	struct ulpi *ulpi;
+	struct phy *phy;
+	struct clk *ref_clk;
+	struct clk *sleep_clk;
+	struct regulator *v1p8;
+	struct regulator *v3p3;
+	struct reset_control *reset;
+	struct ulpi_seq *init_seq;
+	struct notifier_block vbus_notify;
+	struct extcon_dev *vbus_edev;
+	struct extcon_dev *id_edev;
+	enum usb_dr_mode dr_mode;
+};
+
+static int
+qcom_usb_hs_phy_vbus_notifier(struct notifier_block *nb, unsigned long event,
+			      void *ptr)
+{
+	struct qcom_usb_hs_phy *uphy;
+	int is_host;
+	u8 addr;
+
+	uphy = container_of(nb, struct qcom_usb_hs_phy, vbus_notify);
+	is_host = extcon_get_cable_state_(uphy->id_edev, EXTCON_USB_HOST);
+	if (is_host < 0)
+		is_host = 0; /* No id event means always a peripheral */
+
+	if (event && !is_host)
+		addr = ULPI_SET(ULPI_MISC_A);
+	else
+		addr = ULPI_CLR(ULPI_MISC_A);
+
+	return ulpi_write(uphy->ulpi, addr,
+			  ULPI_MISC_A_VBUSVLDEXTSEL | ULPI_MISC_A_VBUSVLDEXT);
+}
+
+static int qcom_usb_hs_phy_power_on(struct phy *phy)
+{
+	struct qcom_usb_hs_phy *uphy = phy_get_drvdata(phy);
+	struct ulpi *ulpi = uphy->ulpi;
+	const struct ulpi_seq *seq;
+	int ret, state;
+
+	ret = clk_prepare_enable(uphy->ref_clk);
+	if (ret)
+		return ret;
+
+	ret = clk_prepare_enable(uphy->sleep_clk);
+	if (ret)
+		goto err_sleep;
+
+	ret = regulator_set_voltage(uphy->v1p8, 1800000, 1800000);
+	if (ret)
+		goto err_1p8;
+
+	ret = regulator_set_load(uphy->v1p8, 50000);
+	if (ret < 0)
+		goto err_1p8;
+
+	ret = regulator_enable(uphy->v1p8);
+	if (ret)
+		goto err_1p8;
+
+	ret = regulator_set_voltage_triplet(uphy->v3p3, 3050000, 3300000,
+					    3300000);
+	if (ret)
+		goto err_3p3;
+
+	ret = regulator_set_load(uphy->v3p3, 50000);
+	if (ret < 0)
+		goto err_3p3;
+
+	ret = regulator_enable(uphy->v3p3);
+	if (ret)
+		goto err_3p3;
+
+	for (seq = uphy->init_seq; seq->addr; seq++) {
+		ret = ulpi_write(ulpi, seq->addr, seq->val);
+		if (ret)
+			goto err_ulpi;
+	}
+
+	if (uphy->reset) {
+		ret = reset_control_reset(uphy->reset);
+		if (ret)
+			goto err_ulpi;
+	}
+
+	if (uphy->vbus_edev) {
+		ulpi_write(ulpi, ULPI_SET(ULPI_PWR_CLK_MNG_REG),
+			   ULPI_PWR_OTG_COMP_DISABLE);
+		state = extcon_get_cable_state_(uphy->vbus_edev, EXTCON_USB);
+		/* setup initial state */
+		qcom_usb_hs_phy_vbus_notifier(&uphy->vbus_notify, state,
+					      uphy->vbus_edev);
+		ret = extcon_register_notifier(uphy->vbus_edev, EXTCON_USB,
+						&uphy->vbus_notify);
+		if (ret)
+			return ret;
+	} else {
+		u8 val;
+
+		switch (uphy->dr_mode) {
+		case USB_DR_MODE_OTG:
+			val = ULPI_INT_IDGRD;
+		case USB_DR_MODE_PERIPHERAL:
+			val |= ULPI_INT_SESS_VALID;
+			break;
+		default:
+			val = 0;
+		}
+
+		ret = ulpi_write(ulpi, ULPI_USB_INT_EN_RISE, val);
+		if (ret)
+			goto err_ulpi;
+		ret = ulpi_write(ulpi, ULPI_USB_INT_EN_FALL, val);
+		if (ret)
+			goto err_ulpi;
+	}
+
+	return 0;
+err_ulpi:
+	regulator_disable(uphy->v3p3);
+err_3p3:
+	regulator_disable(uphy->v1p8);
+err_1p8:
+	clk_disable_unprepare(uphy->sleep_clk);
+err_sleep:
+	clk_disable_unprepare(uphy->ref_clk);
+	return ret;
+}
+
+static int qcom_usb_hs_phy_power_off(struct phy *phy)
+{
+	int ret;
+	struct qcom_usb_hs_phy *uphy = phy_get_drvdata(phy);
+
+	if (uphy->vbus_edev) {
+		ret = extcon_unregister_notifier(uphy->vbus_edev, EXTCON_USB,
+						 &uphy->vbus_notify);
+		if (ret)
+			return ret;
+	}
+
+	regulator_disable(uphy->v3p3);
+	regulator_disable(uphy->v1p8);
+	clk_disable_unprepare(uphy->sleep_clk);
+	clk_disable_unprepare(uphy->ref_clk);
+
+	return 0;
+}
+
+static const struct phy_ops qcom_usb_hs_phy_ops = {
+	.power_on = qcom_usb_hs_phy_power_on,
+	.power_off = qcom_usb_hs_phy_power_off,
+	.owner = THIS_MODULE,
+};
+
+static int qcom_usb_hs_phy_probe(struct ulpi *ulpi)
+{
+	struct qcom_usb_hs_phy *uphy;
+	struct phy_provider *p;
+	struct clk *clk;
+	struct regulator *reg;
+	struct reset_control *reset;
+	int size;
+	int ret;
+
+	uphy = devm_kzalloc(&ulpi->dev, sizeof(*uphy), GFP_KERNEL);
+	if (!uphy)
+		return -ENOMEM;
+	ulpi_set_drvdata(ulpi, uphy);
+	uphy->ulpi = ulpi;
+	uphy->dr_mode = of_usb_get_dr_mode_by_phy(ulpi->dev.of_node, -1);
+
+	size = of_property_count_u8_elems(ulpi->dev.of_node, "qcom,init-seq");
+	if (size < 0)
+		size = 0;
+	uphy->init_seq = devm_kmalloc_array(&ulpi->dev, (size / 2) + 1,
+					   sizeof(*uphy->init_seq), GFP_KERNEL);
+	if (!uphy->init_seq)
+		return -ENOMEM;
+	ret = of_property_read_u8_array(ulpi->dev.of_node, "qcom,init-seq",
+					(u8 *)uphy->init_seq, size);
+	if (ret && size)
+		return ret;
+	/* NUL terminate */
+	uphy->init_seq[size / 2].addr = uphy->init_seq[size / 2].val = 0;
+
+	uphy->ref_clk = clk = devm_clk_get(&ulpi->dev, "ref");
+	if (IS_ERR(clk))
+		return PTR_ERR(clk);
+
+	uphy->sleep_clk = clk = devm_clk_get(&ulpi->dev, "sleep");
+	if (IS_ERR(clk))
+		return PTR_ERR(clk);
+
+	uphy->v1p8 = reg = devm_regulator_get(&ulpi->dev, "v1p8");
+	if (IS_ERR(reg))
+		return PTR_ERR(reg);
+
+	uphy->v3p3 = reg = devm_regulator_get(&ulpi->dev, "v3p3");
+	if (IS_ERR(reg))
+		return PTR_ERR(reg);
+
+	uphy->reset = reset = devm_reset_control_get(&ulpi->dev, "por");
+	if (IS_ERR(reset)) {
+		if (PTR_ERR(reset) == -EPROBE_DEFER)
+			return PTR_ERR(reset);
+		uphy->reset = NULL;
+	}
+
+	uphy->phy = devm_phy_create(&ulpi->dev, ulpi->dev.of_node,
+				    &qcom_usb_hs_phy_ops);
+	if (IS_ERR(uphy->phy))
+		return PTR_ERR(uphy->phy);
+
+	uphy->vbus_edev = extcon_get_edev_by_phandle(&ulpi->dev, 0);
+	if (IS_ERR(uphy->vbus_edev)) {
+		if (PTR_ERR(uphy->vbus_edev) != -ENODEV)
+			return PTR_ERR(uphy->vbus_edev);
+		uphy->vbus_edev = NULL;
+	}
+
+	uphy->id_edev = extcon_get_edev_by_phandle(&ulpi->dev, 1);
+	if (IS_ERR(uphy->id_edev)) {
+		if (PTR_ERR(uphy->id_edev) != -ENODEV)
+			return PTR_ERR(uphy->id_edev);
+		uphy->id_edev = NULL;
+	}
+
+	uphy->vbus_notify.notifier_call = qcom_usb_hs_phy_vbus_notifier;
+	phy_set_drvdata(uphy->phy, uphy);
+
+	p = devm_of_phy_provider_register(&ulpi->dev, of_phy_simple_xlate);
+	return PTR_ERR_OR_ZERO(p);
+}
+
+static const struct of_device_id qcom_usb_hs_phy_match[] = {
+	{ .compatible = "qcom,usb-hs-phy", },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, qcom_usb_hs_phy_match);
+
+static struct ulpi_driver qcom_usb_hs_phy_driver = {
+	.probe = qcom_usb_hs_phy_probe,
+	.driver = {
+		.name = "qcom_usb_hs_phy",
+		.of_match_table = qcom_usb_hs_phy_match,
+	},
+};
+module_ulpi_driver(qcom_usb_hs_phy_driver);
+
+MODULE_DESCRIPTION("Qualcomm USB HS phy");
+MODULE_LICENSE("GPL v2");
-- 
2.9.0.rc2.8.ga28705d

--
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

Re: [PATCH v4 01/22] of: device: Support loading a module with OF based modalias

[Rob Herring]

On Wed, Sep 7, 2016 at 4:34 PM, Stephen Boyd <stephen.boyd@linaro.org> wrote:
> In the case of ULPI devices, we want to be able to load the
> driver before registering the device so that we don't get stuck
> in a loop waiting for the phy module to appear and failing usb
> controller probe. Currently we request the ulpi module via the
> ulpi ids, but in the DT case we might need to request it with the
> OF based modalias instead. Add a common function that allows
> anyone to request a module with the OF based modalias.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: <devicetree@vger.kernel.org>
> Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> ---
>  drivers/of/device.c       | 23 +++++++++++++++++++++++
>  include/linux/of_device.h |  6 ++++++
>  2 files changed, 29 insertions(+)

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

Re: [PATCH v4 02/22] of: device: Export of_device_{get_modalias,uvent_modalias} to modules

[Rob Herring]

On Wed, Sep 7, 2016 at 4:34 PM, Stephen Boyd <stephen.boyd@linaro.org> wrote:
> The ULPI bus can be built as a module, and it will soon be
> calling these functions when it supports probing devices from DT.
> Export them so they can be used by the ULPI module.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: <devicetree@vger.kernel.org>
> Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> ---
>  drivers/of/device.c | 2 ++
>  1 file changed, 2 insertions(+)

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

Re: [PATCH v4 03/22] usb: ulpi: Support device discovery via DT

[Rob Herring]

On Wed, Sep 7, 2016 at 4:35 PM, Stephen Boyd <stephen.boyd-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> The qcom HSIC ULPI phy doesn't have any bits set in the vendor or
> product ID registers. This makes it impossible to make a ULPI
> driver match against the ID registers. Add support to discover
> the ULPI phys via DT help alleviate this problem. In the DT case,
> we'll look for a ULPI bus node underneath the device registering
> the ULPI viewport (or the parent of that device to support
> chipidea's device layout) and then match up the phy node
> underneath that with the ULPI device that's created.
>
> The side benefit of this is that we can use standard properties
> in the phy node like clks, regulators, gpios, etc. because we
> don't have firmware like ACPI to turn these things on for us. And
> we can use the DT phy binding to point our phy consumer to the
> phy provider.
>
> The ULPI bus code supports native enumeration by reading the
> vendor ID and product ID registers at device creation time, but
> we can't be certain that those register reads will succeed if the
> phy is not powered up. To avoid any problems with reading the ID
> registers before the phy is powered we fallback to DT matching
> when the ID reads fail.
>
> If the ULPI spec had some generic power sequencing for these
> registers we could put that into the ULPI bus layer and power up
> the device before reading the ID registers. Unfortunately this
> doesn't exist and the power sequence is usually device specific.
> By having the device matched up with DT we can avoid this
> problem.
>
> Cc: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
> Cc: Heikki Krogerus <heikki.krogerus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> Cc: <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Stephen Boyd <stephen.boyd-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/usb/ulpi.txt | 20 +++++++
>  drivers/usb/common/ulpi.c                      | 77 ++++++++++++++++++++++++--
>  2 files changed, 92 insertions(+), 5 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/usb/ulpi.txt

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

But one concern below.

> -static int ulpi_register(struct device *dev, struct ulpi *ulpi)
> +static int ulpi_of_register(struct ulpi *ulpi)
> +{
> +       struct device_node *np = NULL, *child;
> +
> +       /* Find a ulpi bus underneath the parent or the parent of the parent */

parent of the parent is called the grandparent.

> +       if (ulpi->dev.parent->of_node)
> +               np = of_find_node_by_name(ulpi->dev.parent->of_node, "ulpi");
> +       else if (ulpi->dev.parent->parent && ulpi->dev.parent->parent->of_node)
> +               np = of_find_node_by_name(ulpi->dev.parent->parent->of_node,

First setting "parent = ulpi->dev.parent" would make this a bit easier
on the eyes.

When is it valid to be the grandparent? The binding doesn't mention that.

Rob
--
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

Re: [PATCH v4 03/22] usb: ulpi: Support device discovery via DT

[Stephen Boyd]

Quoting Rob Herring (2016-09-07 18:12:32)
> On Wed, Sep 7, 2016 at 4:35 PM, Stephen Boyd <stephen.boyd@linaro.org> wrote:
> > ---
> >  Documentation/devicetree/bindings/usb/ulpi.txt | 20 +++++++
> >  drivers/usb/common/ulpi.c                      | 77 ++++++++++++++++++++++++--
> >  2 files changed, 92 insertions(+), 5 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/usb/ulpi.txt
> 
> Acked-by: Rob Herring <robh@kernel.org>
> 
> But one concern below.
> 
> > -static int ulpi_register(struct device *dev, struct ulpi *ulpi)
> > +static int ulpi_of_register(struct ulpi *ulpi)
> > +{
> > +       struct device_node *np = NULL, *child;
> > +
> > +       /* Find a ulpi bus underneath the parent or the parent of the parent */
> 
> parent of the parent is called the grandparent.

Heh, I can reword it.

> 
> > +       if (ulpi->dev.parent->of_node)
> > +               np = of_find_node_by_name(ulpi->dev.parent->of_node, "ulpi");
> > +       else if (ulpi->dev.parent->parent && ulpi->dev.parent->parent->of_node)
> > +               np = of_find_node_by_name(ulpi->dev.parent->parent->of_node,
> 
> First setting "parent = ulpi->dev.parent" would make this a bit easier
> on the eyes.

Ok.

> 
> When is it valid to be the grandparent? The binding doesn't mention that.

This case arises when we're registering the ulpi device as a child of
the device created by chipidea usb glue drivers (the "core" chipidea
device called something like ci_hdrc.N). In that case we have DT like
this:

	usb-controller {
		ulpi {
			phy {
			};
		};
	};

where the usb-controller node corresponds to a device that's probed by
the glue driver. That glue driver creates a child platform device,
ci_hdrc.0, that doesn't have any DT node associated with it, and then
that device driver probes and creates the ulpi device that is associated
with the phy node.

The grandparent scenario will fall away once Peter's patch is merged to
set the of_node of ci_hdrc.0 to be the same of_node as the glue
device[1]. I can rebase on that patch, but it looked like the power
sequence stuff was getting held up.

Honestly, having the child device registered by the glue driver seems to
cause some difficulties and I've been thinking about how we could get
rid of it, but Peter seems fairly adamant about keeping this design.
Also, I think dwc3 is done in a similar way, but in that case the child
device is in DT and I think we could put the ulpi node inside of it. I
haven't looked in too much detail though.

[1] http://lkml.kernel.org/r/1471252398-957-6-git-send-email-peter.chen@nxp.com

Re: [PATCH v4 00/22] Support qcom's HSIC USB and rewrite USB2 HS support

[Peter Chen]

On Thu, Sep 8, 2016 at 5:34 AM, Stephen Boyd <stephen.boyd-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> The state of USB ChipIdea support on Qualcomm's platforms is not great.
> The DT description of these devices requires up to three different nodes
> for what amounts to be the same hardware block, when there should really
> only be one. Furthermore, the "phy" driver that is in mainline (phy-msm-usb.c)
> duplicates the OTG state machine and touches the ci controller wrapper
> registers when it should really be focused on the phy and the ULPI accesses
> needed to get the phy working. There's also a slimmed down phy driver for
> the msm8916 platform, but really the phy hardware is the same as other MSMs,
> so we have two drivers doing pretty much the same thing. This leads to a
> situtaion where we have the chipidea core driver, the "phy" driver, and
> sometimes the ehci-msm.c driver operating the same device all at the same
> time with very little coordination. This just isn't very safe and is
> confusing from a driver perspective when trying to figure out who does what.
> Finally, there isn't any HSIC support on platforms like apq8074 so we
> should add that.
>
> This patch series updates the ChipIdea driver and the MSM wrapper
> (ci_hdrc_msm.c) to properly handle the PHY and wrapper bits at the right
> times in the right places. To get there, we update the ChipIdea core to
> have support for the ULPI phy bus introduced by Heikki. Along the way
> we fix bugs with the extcon handling for peripheral and OTG mode controllers
> and move the parts of phy-usb-msm.c that are touching the CI controller
> wrapper into the wrapper driver (ci_hdrc_msm.c). Finally we add support
> for the HSIC phy based on the ULPI bus and rewrite the HS phy driver
> (phy-usb-msm.c) as a standard ULPI phy driver.
>
> Once this series is accepted, we should be able to delete the phy-usb-msm.c,
> phy-qcom-8x16-usb.c, and ehci-msm.c drivers from the tree and use the ULPI
> based phy driver (which also lives in drivers/phy/ instead of drivers/usb/phy/)
> and the chipidea host core instead.
>
> I've also sent separate patches for other minor pieces to make this
> all work. The full tree can be found here[3], hacks and all to get
> things working. I've tested this on the db410c, apq8074 dragonboard,
> and ifc6410 with configfs gadgets and otg cables.
>
> Patches based on v4.8-rc1
>
> Changes from v3:
>
>  * Picked up Acks from Peter
>
>  * Updated extcon consolidation patch per Peter's comments
>
>  * Folded in simplification from Heikki for ULPI DT matching
>

I find the kbuild dependency error when compile your series, I remembered
someone met it before, would you have a solution:

  GEN     ./Makefile
scripts/kconfig/conf  --silentoldconfig Kconfig
drivers/usb/Kconfig:39:error: recursive dependency detected!
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/usb/Kconfig:39: symbol USB is selected by MOUSE_APPLETOUCH
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/input/mouse/Kconfig:187: symbol MOUSE_APPLETOUCH depends on INPUT
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/input/Kconfig:8: symbol INPUT is selected by VT
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/tty/Kconfig:12: symbol VT is selected by FB_STI
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:674: symbol FB_STI depends on FB
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/Kconfig:42: symbol DRM_KMS_FB_HELPER is selected by
DRM_KMS_CMA_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/Kconfig:98: symbol DRM_KMS_CMA_HELPER is selected by DRM_IMX
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/imx/Kconfig:1: symbol DRM_IMX depends on IMX_IPUV3_CORE
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/ipu-v3/Kconfig:1: symbol IMX_IPUV3_CORE depends on RESET_CONTROLLER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/reset/Kconfig:4: symbol RESET_CONTROLLER is selected by USB_CHIPIDEA
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/usb/chipidea/Kconfig:1: symbol USB_CHIPIDEA depends on USB_EHCI_HCD
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/usb/host/Kconfig:84: symbol USB_EHCI_HCD depends on USB
#

Peter

> Changes from v2:
>
>  * Added SoC specific compatibles in phy bindings
>
>  * Dropped AVVIS patch for OTG statemachine
>
>  * New patch to consolidate extcon handlers
>
>  * Picked up Acks from Peter
>
>  * Rebased onto v4.8-rc1
>
>  * Reworked ULPI OF code to look at vid == 0 instead of pid == 0
>
>  * Dropped ULPI bindings for vid and pid overrides
>
> Changes from v1:
>
>  * Reworked ULPI device probing to keep using vendor/product ids that
>    come from DT if needed and falls back to OF style match when product id
>    is 0
>
>  * PHY init later patch was rejected so that moved to a quirk flag and
>    the msm wrapper started managing the phy on/off
>
>  * Updated clk requirements for HSIC phy in binding doc
>
>  * Added optional clk in wrapper for "housekeeping" found on older qcom
>    platforms
>
>  * Bug fix to OTGSC polling function
>
>  * Changed runtime PM patch to set as active instead of get/put
>
> TODO:
>  * DMA fails on arm64 so we need something like [1] to make it work.
>
>  * The db410c needs a driver to toggle the onboard switch to connect
>    the usb hub instead of micro port when the usb cable is disconnected
>
>  * apq8064 platforms need a vbus regulator to really use otg and I haven't
>    tried out the RPM based regulators yet
>
>  * The HSIC phy on the apq8074 dragonboard is connected to a usb4604
>    device which requires the i2c driver to probe and send an i2c
>    sequence before the HSIC controller enumerates or HSIC doesn't work.
>    Right now I have a hack to force the controller to probe defer
>    once so that usb4604 probes first. This needs a more proper solution
>    like having the DT describe a linkage between the controller and
>    the usb device so we can enforce probe ordering.
>
>  * OTG support requires a working VBUS supply on apq8074 dragonboard
>    and that requires changes to the smbb_charger driver to support
>    the OTG OVP switch as a regulator[2]. This series needs revival
>    on the list so that OTG works properly on that board.
>
> [1] https://lkml.org/lkml/2016/2/22/7
> [2] http://lkml.kernel.org/g/1449621618-11900-1-git-send-email-tim.bird-/MT0OVThwyLZJqsBc5GL+g@public.gmane.org
> [3] https://git.linaro.org/people/stephen.boyd/linux.git/shortlog/refs/heads/usb-hsic-8074
>
>
> Stephen Boyd (22):
>   of: device: Support loading a module with OF based modalias
>   of: device: Export of_device_{get_modalias,uvent_modalias} to modules
>   usb: ulpi: Support device discovery via DT
>   usb: chipidea: Only read/write OTGSC from one place
>   usb: chipidea: Handle extcon events properly
>   usb: chipidea: Add platform flag for wrapper phy management
>   usb: chipidea: Notify events when switching host mode
>   usb: chipidea: Remove locking in ci_udc_start()
>   usb: chipidea: Add support for ULPI PHY bus
>   usb: chipidea: Consolidate extcon notifiers
>   usb: chipidea: msm: Mark device as runtime pm active
>   usb: chipidea: msm: Rely on core to override AHBBURST
>   usb: chipidea: msm: Use hw_write_id_reg() instead of writel
>   usb: chipidea: msm: Add proper clk and reset support
>   usb: chipidea: msm: Mux over secondary phy at the right time
>   usb: chipidea: msm: Restore wrapper settings after reset
>   usb: chipidea: msm: Make platform data driver local instead of global
>   usb: chipidea: msm: Add reset controller for PHY POR bit
>   usb: chipidea: msm: Handle phy power states
>   usb: chipidea: msm: Be silent on probe defer errors
>   phy: Add support for Qualcomm's USB HSIC phy
>   phy: Add support for Qualcomm's USB HS phy
>
>  .../devicetree/bindings/phy/qcom,usb-hs-phy.txt    |  83 ++++++
>  .../devicetree/bindings/phy/qcom,usb-hsic-phy.txt  |  65 +++++
>  Documentation/devicetree/bindings/usb/ulpi.txt     |  20 ++
>  drivers/of/device.c                                |  25 ++
>  drivers/phy/Kconfig                                |  15 ++
>  drivers/phy/Makefile                               |   2 +
>  drivers/phy/phy-qcom-usb-hs.c                      | 289 +++++++++++++++++++++
>  drivers/phy/phy-qcom-usb-hsic.c                    | 160 ++++++++++++
>  drivers/usb/chipidea/Kconfig                       |   8 +
>  drivers/usb/chipidea/Makefile                      |   1 +
>  drivers/usb/chipidea/ci.h                          |  22 +-
>  drivers/usb/chipidea/ci_hdrc_msm.c                 | 280 +++++++++++++++++---
>  drivers/usb/chipidea/core.c                        | 122 ++++-----
>  drivers/usb/chipidea/host.c                        |  10 +
>  drivers/usb/chipidea/otg.c                         |  86 +++++-
>  drivers/usb/chipidea/udc.c                         |   3 -
>  drivers/usb/chipidea/ulpi.c                        | 113 ++++++++
>  drivers/usb/common/ulpi.c                          |  77 +++++-
>  include/linux/of_device.h                          |   6 +
>  include/linux/usb/chipidea.h                       |   9 +-
>  20 files changed, 1259 insertions(+), 137 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
>  create mode 100644 Documentation/devicetree/bindings/phy/qcom,usb-hsic-phy.txt
>  create mode 100644 Documentation/devicetree/bindings/usb/ulpi.txt
>  create mode 100644 drivers/phy/phy-qcom-usb-hs.c
>  create mode 100644 drivers/phy/phy-qcom-usb-hsic.c
>  create mode 100644 drivers/usb/chipidea/ulpi.c
>
> --
> 2.9.0.rc2.8.ga28705d
>
> --
> 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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 00/22] Support qcom's HSIC USB and rewrite USB2 HS support

[Stephen Boyd]

Quoting Peter Chen (2016-09-07 19:06:45)
> On Thu, Sep 8, 2016 at 5:34 AM, Stephen Boyd <stephen.boyd@linaro.org> wrote:
> > The state of USB ChipIdea support on Qualcomm's platforms is not great.
> > The DT description of these devices requires up to three different nodes
> > for what amounts to be the same hardware block, when there should really
> > only be one. Furthermore, the "phy" driver that is in mainline (phy-msm-usb.c)
> > duplicates the OTG state machine and touches the ci controller wrapper
> > registers when it should really be focused on the phy and the ULPI accesses
> > needed to get the phy working. There's also a slimmed down phy driver for
> > the msm8916 platform, but really the phy hardware is the same as other MSMs,
> > so we have two drivers doing pretty much the same thing. This leads to a
> > situtaion where we have the chipidea core driver, the "phy" driver, and
> > sometimes the ehci-msm.c driver operating the same device all at the same
> > time with very little coordination. This just isn't very safe and is
> > confusing from a driver perspective when trying to figure out who does what.
> > Finally, there isn't any HSIC support on platforms like apq8074 so we
> > should add that.
> >
> > This patch series updates the ChipIdea driver and the MSM wrapper
> > (ci_hdrc_msm.c) to properly handle the PHY and wrapper bits at the right
> > times in the right places. To get there, we update the ChipIdea core to
> > have support for the ULPI phy bus introduced by Heikki. Along the way
> > we fix bugs with the extcon handling for peripheral and OTG mode controllers
> > and move the parts of phy-usb-msm.c that are touching the CI controller
> > wrapper into the wrapper driver (ci_hdrc_msm.c). Finally we add support
> > for the HSIC phy based on the ULPI bus and rewrite the HS phy driver
> > (phy-usb-msm.c) as a standard ULPI phy driver.
> >
> > Once this series is accepted, we should be able to delete the phy-usb-msm.c,
> > phy-qcom-8x16-usb.c, and ehci-msm.c drivers from the tree and use the ULPI
> > based phy driver (which also lives in drivers/phy/ instead of drivers/usb/phy/)
> > and the chipidea host core instead.
> >
> > I've also sent separate patches for other minor pieces to make this
> > all work. The full tree can be found here[3], hacks and all to get
> > things working. I've tested this on the db410c, apq8074 dragonboard,
> > and ifc6410 with configfs gadgets and otg cables.
> >
> > Patches based on v4.8-rc1
> >
> > Changes from v3:
> >
> >  * Picked up Acks from Peter
> >
> >  * Updated extcon consolidation patch per Peter's comments
> >
> >  * Folded in simplification from Heikki for ULPI DT matching
> >
> 
> I find the kbuild dependency error when compile your series, I remembered
> someone met it before, would you have a solution:

Yes. Should I send it through the drm maintainers?

---8<---
From: Stephen Boyd <stephen.boyd@linaro.org>
Subject: [PATCH] gpu: Remove depends on RESET_CONTROLLER when not a provider

These GPU drivers only depend on the RESET_CONTROLLER config
option to fix build issues that existed when there weren't stub
reset APIs for reset controller consumers. Given that these
drivers aren't providing any reset controllers themselves, they
don't actually depend on the API to build (just to function) so
they don't need to depend on it. Remove the dependency to fix
recursive build errors like the following:

drivers/usb/Kconfig:39:error: recursive dependency detected!
drivers/usb/Kconfig:39: symbol USB is selected by MOUSE_APPLETOUCH
drivers/input/mouse/Kconfig:187:        symbol MOUSE_APPLETOUCH depends on INPUT
drivers/input/Kconfig:8:        symbol INPUT is selected by VT
drivers/tty/Kconfig:12: symbol VT is selected by FB_STI
drivers/video/fbdev/Kconfig:674:        symbol FB_STI depends on FB
drivers/video/fbdev/Kconfig:5:  symbol FB is selected by DRM_KMS_FB_HELPER
drivers/gpu/drm/Kconfig:42:     symbol DRM_KMS_FB_HELPER is selected by DRM_KMS_CMA_HELPER
drivers/gpu/drm/Kconfig:98:     symbol DRM_KMS_CMA_HELPER is selected by DRM_IMX
drivers/gpu/drm/imx/Kconfig:1:  symbol DRM_IMX depends on IMX_IPUV3_CORE
drivers/gpu/ipu-v3/Kconfig:1:   symbol IMX_IPUV3_CORE depends on RESET_CONTROLLER
drivers/reset/Kconfig:4:        symbol RESET_CONTROLLER is selected by USB_CHIPIDEA
drivers/usb/chipidea/Kconfig:1: symbol USB_CHIPIDEA depends on USB_EHCI_HCD
drivers/usb/host/Kconfig:84:    symbol USB_EHCI_HCD depends on USB

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: David Airlie <airlied@linux.ie>
Cc: <dri-devel@lists.freedesktop.org>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Mark Yao <mark.yao@rock-chips.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
---
 drivers/gpu/drm/rockchip/Kconfig | 1 -
 drivers/gpu/drm/tegra/Kconfig    | 1 -
 drivers/gpu/ipu-v3/Kconfig       | 1 -
 3 files changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 3c58669a06ce..6f7f9c59f05b 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -1,7 +1,6 @@
 config DRM_ROCKCHIP
 	tristate "DRM Support for Rockchip"
 	depends on DRM && ROCKCHIP_IOMMU
-	depends on RESET_CONTROLLER
 	select DRM_GEM_CMA_HELPER
 	select DRM_KMS_HELPER
 	select DRM_PANEL
diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
index 63ebb154b9b5..bbf5a4b7e0b6 100644
--- a/drivers/gpu/drm/tegra/Kconfig
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -3,7 +3,6 @@ config DRM_TEGRA
 	depends on ARCH_TEGRA || (ARM && COMPILE_TEST)
 	depends on COMMON_CLK
 	depends on DRM
-	depends on RESET_CONTROLLER
 	select DRM_KMS_HELPER
 	select DRM_MIPI_DSI
 	select DRM_PANEL
diff --git a/drivers/gpu/ipu-v3/Kconfig b/drivers/gpu/ipu-v3/Kconfig
index aefdff95356d..08766c6e7856 100644
--- a/drivers/gpu/ipu-v3/Kconfig
+++ b/drivers/gpu/ipu-v3/Kconfig
@@ -1,7 +1,6 @@
 config IMX_IPUV3_CORE
 	tristate "IPUv3 core support"
 	depends on SOC_IMX5 || SOC_IMX6Q || ARCH_MULTIPLATFORM
-	depends on RESET_CONTROLLER
 	select GENERIC_IRQ_CHIP
 	help
 	  Choose this if you have a i.MX5/6 system and want to use the Image
-- 
2.9.0.rc2.8.ga28705d

Re: [PATCH v4 00/22] Support qcom's HSIC USB and rewrite USB2 HS support

[Peter Chen]

On Thu, Sep 08, 2016 at 02:13:28PM -0700, Stephen Boyd wrote:
> Quoting Peter Chen (2016-09-07 19:06:45)
> > On Thu, Sep 8, 2016 at 5:34 AM, Stephen Boyd <stephen.boyd@linaro.org> wrote:
> > > The state of USB ChipIdea support on Qualcomm's platforms is not great.
> > > The DT description of these devices requires up to three different nodes
> > > for what amounts to be the same hardware block, when there should really
> > > only be one. Furthermore, the "phy" driver that is in mainline (phy-msm-usb.c)
> > > duplicates the OTG state machine and touches the ci controller wrapper
> > > registers when it should really be focused on the phy and the ULPI accesses
> > > needed to get the phy working. There's also a slimmed down phy driver for
> > > the msm8916 platform, but really the phy hardware is the same as other MSMs,
> > > so we have two drivers doing pretty much the same thing. This leads to a
> > > situtaion where we have the chipidea core driver, the "phy" driver, and
> > > sometimes the ehci-msm.c driver operating the same device all at the same
> > > time with very little coordination. This just isn't very safe and is
> > > confusing from a driver perspective when trying to figure out who does what.
> > > Finally, there isn't any HSIC support on platforms like apq8074 so we
> > > should add that.
> > >
> > > This patch series updates the ChipIdea driver and the MSM wrapper
> > > (ci_hdrc_msm.c) to properly handle the PHY and wrapper bits at the right
> > > times in the right places. To get there, we update the ChipIdea core to
> > > have support for the ULPI phy bus introduced by Heikki. Along the way
> > > we fix bugs with the extcon handling for peripheral and OTG mode controllers
> > > and move the parts of phy-usb-msm.c that are touching the CI controller
> > > wrapper into the wrapper driver (ci_hdrc_msm.c). Finally we add support
> > > for the HSIC phy based on the ULPI bus and rewrite the HS phy driver
> > > (phy-usb-msm.c) as a standard ULPI phy driver.
> > >
> > > Once this series is accepted, we should be able to delete the phy-usb-msm.c,
> > > phy-qcom-8x16-usb.c, and ehci-msm.c drivers from the tree and use the ULPI
> > > based phy driver (which also lives in drivers/phy/ instead of drivers/usb/phy/)
> > > and the chipidea host core instead.
> > >
> > > I've also sent separate patches for other minor pieces to make this
> > > all work. The full tree can be found here[3], hacks and all to get
> > > things working. I've tested this on the db410c, apq8074 dragonboard,
> > > and ifc6410 with configfs gadgets and otg cables.
> > >
> > > Patches based on v4.8-rc1
> > >
> > > Changes from v3:
> > >
> > >  * Picked up Acks from Peter
> > >
> > >  * Updated extcon consolidation patch per Peter's comments
> > >
> > >  * Folded in simplification from Heikki for ULPI DT matching
> > >
> > 
> > I find the kbuild dependency error when compile your series, I remembered
> > someone met it before, would you have a solution:
> 
> Yes. Should I send it through the drm maintainers?
> 

Yes, please add me at cc list, thanks.

Peter
> ---8<---
> From: Stephen Boyd <stephen.boyd@linaro.org>
> Subject: [PATCH] gpu: Remove depends on RESET_CONTROLLER when not a provider
> 
> These GPU drivers only depend on the RESET_CONTROLLER config
> option to fix build issues that existed when there weren't stub
> reset APIs for reset controller consumers. Given that these
> drivers aren't providing any reset controllers themselves, they
> don't actually depend on the API to build (just to function) so
> they don't need to depend on it. Remove the dependency to fix
> recursive build errors like the following:
> 
> drivers/usb/Kconfig:39:error: recursive dependency detected!
> drivers/usb/Kconfig:39: symbol USB is selected by MOUSE_APPLETOUCH
> drivers/input/mouse/Kconfig:187:        symbol MOUSE_APPLETOUCH depends on INPUT
> drivers/input/Kconfig:8:        symbol INPUT is selected by VT
> drivers/tty/Kconfig:12: symbol VT is selected by FB_STI
> drivers/video/fbdev/Kconfig:674:        symbol FB_STI depends on FB
> drivers/video/fbdev/Kconfig:5:  symbol FB is selected by DRM_KMS_FB_HELPER
> drivers/gpu/drm/Kconfig:42:     symbol DRM_KMS_FB_HELPER is selected by DRM_KMS_CMA_HELPER
> drivers/gpu/drm/Kconfig:98:     symbol DRM_KMS_CMA_HELPER is selected by DRM_IMX
> drivers/gpu/drm/imx/Kconfig:1:  symbol DRM_IMX depends on IMX_IPUV3_CORE
> drivers/gpu/ipu-v3/Kconfig:1:   symbol IMX_IPUV3_CORE depends on RESET_CONTROLLER
> drivers/reset/Kconfig:4:        symbol RESET_CONTROLLER is selected by USB_CHIPIDEA
> drivers/usb/chipidea/Kconfig:1: symbol USB_CHIPIDEA depends on USB_EHCI_HCD
> drivers/usb/host/Kconfig:84:    symbol USB_EHCI_HCD depends on USB
> 
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: David Airlie <airlied@linux.ie>
> Cc: <dri-devel@lists.freedesktop.org>
> Cc: Heiko Stuebner <heiko@sntech.de>
> Cc: Mark Yao <mark.yao@rock-chips.com>
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> ---
>  drivers/gpu/drm/rockchip/Kconfig | 1 -
>  drivers/gpu/drm/tegra/Kconfig    | 1 -
>  drivers/gpu/ipu-v3/Kconfig       | 1 -
>  3 files changed, 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
> index 3c58669a06ce..6f7f9c59f05b 100644
> --- a/drivers/gpu/drm/rockchip/Kconfig
> +++ b/drivers/gpu/drm/rockchip/Kconfig
> @@ -1,7 +1,6 @@
>  config DRM_ROCKCHIP
>  	tristate "DRM Support for Rockchip"
>  	depends on DRM && ROCKCHIP_IOMMU
> -	depends on RESET_CONTROLLER
>  	select DRM_GEM_CMA_HELPER
>  	select DRM_KMS_HELPER
>  	select DRM_PANEL
> diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
> index 63ebb154b9b5..bbf5a4b7e0b6 100644
> --- a/drivers/gpu/drm/tegra/Kconfig
> +++ b/drivers/gpu/drm/tegra/Kconfig
> @@ -3,7 +3,6 @@ config DRM_TEGRA
>  	depends on ARCH_TEGRA || (ARM && COMPILE_TEST)
>  	depends on COMMON_CLK
>  	depends on DRM
> -	depends on RESET_CONTROLLER
>  	select DRM_KMS_HELPER
>  	select DRM_MIPI_DSI
>  	select DRM_PANEL
> diff --git a/drivers/gpu/ipu-v3/Kconfig b/drivers/gpu/ipu-v3/Kconfig
> index aefdff95356d..08766c6e7856 100644
> --- a/drivers/gpu/ipu-v3/Kconfig
> +++ b/drivers/gpu/ipu-v3/Kconfig
> @@ -1,7 +1,6 @@
>  config IMX_IPUV3_CORE
>  	tristate "IPUv3 core support"
>  	depends on SOC_IMX5 || SOC_IMX6Q || ARCH_MULTIPLATFORM
> -	depends on RESET_CONTROLLER
>  	select GENERIC_IRQ_CHIP
>  	help
>  	  Choose this if you have a i.MX5/6 system and want to use the Image
> -- 
> 2.9.0.rc2.8.ga28705d

-- 

Best Regards,
Peter Chen

Re: [PATCH v4 03/22] usb: ulpi: Support device discovery via DT

[Stephen Boyd]

Quoting Stephen Boyd (2016-09-07 14:35:00)
> @@ -174,6 +219,21 @@ static int ulpi_register(struct device *dev, struct ulpi *ulpi)
>         ulpi->id.product = ulpi_read(ulpi, ULPI_PRODUCT_ID_LOW);
>         ulpi->id.product |= ulpi_read(ulpi, ULPI_PRODUCT_ID_HIGH) << 8;
>  
> +       /* Some ULPI devices don't have a vendor id so rely on OF match */
> +       if (ulpi->id.vendor == 0)
> +               goto err;
> +
> +       request_module("ulpi:v%04xp%04x", ulpi->id.vendor, ulpi->id.product);
> +
> +       return 0;
> +err:
> +       return of_device_request_module(&ulpi->dev);

This can't return the value of of_device_request_module() because that
returns an error if the module is builtin or if module loading is
disabled. I'll have to ignore the error here and just return success all
the time.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy

[Peter Chen]

On Wed, Sep 07, 2016 at 02:35:19PM -0700, Stephen Boyd wrote:
> The high-speed phy on qcom SoCs is controlled via the ULPI
> viewport.
> 

Hi Stephen, I am a little puzzled how this driver co-work with chipidea
driver. According to nxp IC guys, the ULPI PHY's clock needs to be enabled
before access portsc.pts (calling hw_phymode_configure), otherwise,
the system will hang. But I find you call hw_phymode_configure before
phy->power_on, doesn't your design have this requirement?
       
Besides, you read ulpi id before phy->power_on, how can read work before
phy power on?

Peter

> Cc: Kishon Vijay Abraham I <kishon@ti.com>
> Cc: <devicetree@vger.kernel.org>
> Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> ---
>  .../devicetree/bindings/phy/qcom,usb-hs-phy.txt    |  83 ++++++
>  drivers/phy/Kconfig                                |   8 +
>  drivers/phy/Makefile                               |   1 +
>  drivers/phy/phy-qcom-usb-hs.c                      | 289 +++++++++++++++++++++
>  4 files changed, 381 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
>  create mode 100644 drivers/phy/phy-qcom-usb-hs.c
> 
> diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
> new file mode 100644
> index 000000000000..d7eacd63d06b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
> @@ -0,0 +1,83 @@
> +Qualcomm's USB HS PHY
> +
> +PROPERTIES
> +
> +- compatible:
> +    Usage: required
> +    Value type: <string>
> +    Definition: Should contain "qcom,usb-hs-phy" and more specifically one of the
> +                following:
> +
> +                        "qcom,usb-hs-phy-apq8064"
> +                        "qcom,usb-hs-phy-msm8916"
> +                        "qcom,usb-hs-phy-msm8974"
> +
> +- #phy-cells:
> +    Usage: required
> +    Value type: <u32>
> +    Definition: Should contain 0
> +
> +- clocks:
> +    Usage: required
> +    Value type: <prop-encoded-array>
> +    Definition: Should contain clock specifier for the reference and sleep
> +                clocks
> +
> +- clock-names:
> +    Usage: required
> +    Value type: <stringlist>
> +    Definition: Should contain "ref" and "sleep" for the reference and sleep
> +                clocks respectively
> +
> +- resets:
> +    Usage: required
> +    Value type: <prop-encoded-array>
> +    Definition: Should contain the phy and POR resets
> +
> +- reset-names:
> +    Usage: required
> +    Value type: <stringlist>
> +    Definition: Should contain "phy" and "por" for the phy and POR resets
> +                respectively
> +
> +- v3p3-supply:
> +    Usage: required
> +    Value type: <phandle>
> +    Definition: Should contain a reference to the 3.3V supply
> +
> +- v1p8-supply:
> +    Usage: required
> +    Value type: <phandle>
> +    Definition: Should contain a reference to the 1.8V supply
> +
> +- extcon:
> +    Usage: optional
> +    Value type: <prop-encoded-array>
> +    Definition: Should contain the vbus and ID extcons in the first and second
> +                cells respectively
> +
> +- qcom,init-seq:
> +    Usage: optional
> +    Value type: <u8 array>
> +    Definition: Should contain a sequence of ULPI register and address pairs to
> +                program into the ULPI_EXT_VENDOR_SPECIFIC area. This is related
> +                to Device Mode Eye Diagram test.
> +
> +EXAMPLE
> +
> +otg: usb-controller {
> +	ulpi {
> +		phy {
> +			compatible = "qcom,usb-hs-phy-msm8974", "qcom,usb-hs-phy";
> +			#phy-cells = <0>;
> +			clocks = <&xo_board>, <&gcc GCC_USB2A_PHY_SLEEP_CLK>;
> +			clock-names = "ref", "sleep";
> +			resets = <&gcc GCC_USB2A_PHY_BCR>, <&otg 0>;
> +			reset-names = "phy", "por";
> +			v3p3-supply = <&pm8941_l24>;
> +			v1p8-supply = <&pm8941_l6>;
> +			extcon = <&smbb>, <&usb_id>;
> +			qcom,init-seq = /bits/ 8 <0x81 0x63>;
> +		};
> +	};
> +};
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 830c443eeabf..ee0ec021a98c 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -417,6 +417,14 @@ config PHY_QCOM_UFS
>  	help
>  	  Support for UFS PHY on QCOM chipsets.
>  
> +config PHY_QCOM_USB_HS
> +	tristate "Qualcomm USB HS PHY module"
> +	depends on USB_ULPI_BUS
> +	select GENERIC_PHY
> +	help
> +	  Support for the USB high-speed ULPI compliant phy on Qualcomm
> +	  chipsets.
> +
>  config PHY_QCOM_USB_HSIC
>  	tristate "Qualcomm USB HSIC ULPI PHY module"
>  	depends on USB_ULPI_BUS
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 5422f543d17d..31c84faa07fa 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -50,6 +50,7 @@ obj-$(CONFIG_PHY_STIH41X_USB)		+= phy-stih41x-usb.o
>  obj-$(CONFIG_PHY_QCOM_UFS) 	+= phy-qcom-ufs.o
>  obj-$(CONFIG_PHY_QCOM_UFS) 	+= phy-qcom-ufs-qmp-20nm.o
>  obj-$(CONFIG_PHY_QCOM_UFS) 	+= phy-qcom-ufs-qmp-14nm.o
> +obj-$(CONFIG_PHY_QCOM_USB_HS) 		+= phy-qcom-usb-hs.o
>  obj-$(CONFIG_PHY_QCOM_USB_HSIC) 	+= phy-qcom-usb-hsic.o
>  obj-$(CONFIG_PHY_TUSB1210)		+= phy-tusb1210.o
>  obj-$(CONFIG_PHY_BRCM_SATA)		+= phy-brcm-sata.o
> diff --git a/drivers/phy/phy-qcom-usb-hs.c b/drivers/phy/phy-qcom-usb-hs.c
> new file mode 100644
> index 000000000000..73fb4b49a8e1
> --- /dev/null
> +++ b/drivers/phy/phy-qcom-usb-hs.c
> @@ -0,0 +1,289 @@
> +/**
> + * Copyright (C) 2016 Linaro Ltd
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#include <linux/module.h>
> +#include <linux/ulpi/driver.h>
> +#include <linux/ulpi/regs.h>
> +#include <linux/clk.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/of_device.h>
> +#include <linux/reset.h>
> +#include <linux/extcon.h>
> +#include <linux/notifier.h>
> +#include <linux/usb/of.h>
> +
> +#include "ulpi_phy.h"
> +
> +#define ULPI_PWR_CLK_MNG_REG		0x88
> +# define ULPI_PWR_OTG_COMP_DISABLE	BIT(0)
> +
> +#define ULPI_MISC_A			0x96
> +# define ULPI_MISC_A_VBUSVLDEXTSEL	BIT(1)
> +# define ULPI_MISC_A_VBUSVLDEXT		BIT(0)
> +
> +
> +struct ulpi_seq {
> +	u8 addr;
> +	u8 val;
> +};
> +
> +struct qcom_usb_hs_phy {
> +	struct ulpi *ulpi;
> +	struct phy *phy;
> +	struct clk *ref_clk;
> +	struct clk *sleep_clk;
> +	struct regulator *v1p8;
> +	struct regulator *v3p3;
> +	struct reset_control *reset;
> +	struct ulpi_seq *init_seq;
> +	struct notifier_block vbus_notify;
> +	struct extcon_dev *vbus_edev;
> +	struct extcon_dev *id_edev;
> +	enum usb_dr_mode dr_mode;
> +};
> +
> +static int
> +qcom_usb_hs_phy_vbus_notifier(struct notifier_block *nb, unsigned long event,
> +			      void *ptr)
> +{
> +	struct qcom_usb_hs_phy *uphy;
> +	int is_host;
> +	u8 addr;
> +
> +	uphy = container_of(nb, struct qcom_usb_hs_phy, vbus_notify);
> +	is_host = extcon_get_cable_state_(uphy->id_edev, EXTCON_USB_HOST);
> +	if (is_host < 0)
> +		is_host = 0; /* No id event means always a peripheral */
> +
> +	if (event && !is_host)
> +		addr = ULPI_SET(ULPI_MISC_A);
> +	else
> +		addr = ULPI_CLR(ULPI_MISC_A);
> +
> +	return ulpi_write(uphy->ulpi, addr,
> +			  ULPI_MISC_A_VBUSVLDEXTSEL | ULPI_MISC_A_VBUSVLDEXT);
> +}
> +
> +static int qcom_usb_hs_phy_power_on(struct phy *phy)
> +{
> +	struct qcom_usb_hs_phy *uphy = phy_get_drvdata(phy);
> +	struct ulpi *ulpi = uphy->ulpi;
> +	const struct ulpi_seq *seq;
> +	int ret, state;
> +
> +	ret = clk_prepare_enable(uphy->ref_clk);
> +	if (ret)
> +		return ret;
> +
> +	ret = clk_prepare_enable(uphy->sleep_clk);
> +	if (ret)
> +		goto err_sleep;
> +
> +	ret = regulator_set_voltage(uphy->v1p8, 1800000, 1800000);
> +	if (ret)
> +		goto err_1p8;
> +
> +	ret = regulator_set_load(uphy->v1p8, 50000);
> +	if (ret < 0)
> +		goto err_1p8;
> +
> +	ret = regulator_enable(uphy->v1p8);
> +	if (ret)
> +		goto err_1p8;
> +
> +	ret = regulator_set_voltage_triplet(uphy->v3p3, 3050000, 3300000,
> +					    3300000);
> +	if (ret)
> +		goto err_3p3;
> +
> +	ret = regulator_set_load(uphy->v3p3, 50000);
> +	if (ret < 0)
> +		goto err_3p3;
> +
> +	ret = regulator_enable(uphy->v3p3);
> +	if (ret)
> +		goto err_3p3;
> +
> +	for (seq = uphy->init_seq; seq->addr; seq++) {
> +		ret = ulpi_write(ulpi, seq->addr, seq->val);
> +		if (ret)
> +			goto err_ulpi;
> +	}
> +
> +	if (uphy->reset) {
> +		ret = reset_control_reset(uphy->reset);
> +		if (ret)
> +			goto err_ulpi;
> +	}
> +
> +	if (uphy->vbus_edev) {
> +		ulpi_write(ulpi, ULPI_SET(ULPI_PWR_CLK_MNG_REG),
> +			   ULPI_PWR_OTG_COMP_DISABLE);
> +		state = extcon_get_cable_state_(uphy->vbus_edev, EXTCON_USB);
> +		/* setup initial state */
> +		qcom_usb_hs_phy_vbus_notifier(&uphy->vbus_notify, state,
> +					      uphy->vbus_edev);
> +		ret = extcon_register_notifier(uphy->vbus_edev, EXTCON_USB,
> +						&uphy->vbus_notify);
> +		if (ret)
> +			return ret;
> +	} else {
> +		u8 val;
> +
> +		switch (uphy->dr_mode) {
> +		case USB_DR_MODE_OTG:
> +			val = ULPI_INT_IDGRD;
> +		case USB_DR_MODE_PERIPHERAL:
> +			val |= ULPI_INT_SESS_VALID;
> +			break;
> +		default:
> +			val = 0;
> +		}
> +
> +		ret = ulpi_write(ulpi, ULPI_USB_INT_EN_RISE, val);
> +		if (ret)
> +			goto err_ulpi;
> +		ret = ulpi_write(ulpi, ULPI_USB_INT_EN_FALL, val);
> +		if (ret)
> +			goto err_ulpi;
> +	}
> +
> +	return 0;
> +err_ulpi:
> +	regulator_disable(uphy->v3p3);
> +err_3p3:
> +	regulator_disable(uphy->v1p8);
> +err_1p8:
> +	clk_disable_unprepare(uphy->sleep_clk);
> +err_sleep:
> +	clk_disable_unprepare(uphy->ref_clk);
> +	return ret;
> +}
> +
> +static int qcom_usb_hs_phy_power_off(struct phy *phy)
> +{
> +	int ret;
> +	struct qcom_usb_hs_phy *uphy = phy_get_drvdata(phy);
> +
> +	if (uphy->vbus_edev) {
> +		ret = extcon_unregister_notifier(uphy->vbus_edev, EXTCON_USB,
> +						 &uphy->vbus_notify);
> +		if (ret)
> +			return ret;
> +	}
> +
> +	regulator_disable(uphy->v3p3);
> +	regulator_disable(uphy->v1p8);
> +	clk_disable_unprepare(uphy->sleep_clk);
> +	clk_disable_unprepare(uphy->ref_clk);
> +
> +	return 0;
> +}
> +
> +static const struct phy_ops qcom_usb_hs_phy_ops = {
> +	.power_on = qcom_usb_hs_phy_power_on,
> +	.power_off = qcom_usb_hs_phy_power_off,
> +	.owner = THIS_MODULE,
> +};
> +
> +static int qcom_usb_hs_phy_probe(struct ulpi *ulpi)
> +{
> +	struct qcom_usb_hs_phy *uphy;
> +	struct phy_provider *p;
> +	struct clk *clk;
> +	struct regulator *reg;
> +	struct reset_control *reset;
> +	int size;
> +	int ret;
> +
> +	uphy = devm_kzalloc(&ulpi->dev, sizeof(*uphy), GFP_KERNEL);
> +	if (!uphy)
> +		return -ENOMEM;
> +	ulpi_set_drvdata(ulpi, uphy);
> +	uphy->ulpi = ulpi;
> +	uphy->dr_mode = of_usb_get_dr_mode_by_phy(ulpi->dev.of_node, -1);
> +
> +	size = of_property_count_u8_elems(ulpi->dev.of_node, "qcom,init-seq");
> +	if (size < 0)
> +		size = 0;
> +	uphy->init_seq = devm_kmalloc_array(&ulpi->dev, (size / 2) + 1,
> +					   sizeof(*uphy->init_seq), GFP_KERNEL);
> +	if (!uphy->init_seq)
> +		return -ENOMEM;
> +	ret = of_property_read_u8_array(ulpi->dev.of_node, "qcom,init-seq",
> +					(u8 *)uphy->init_seq, size);
> +	if (ret && size)
> +		return ret;
> +	/* NUL terminate */
> +	uphy->init_seq[size / 2].addr = uphy->init_seq[size / 2].val = 0;
> +
> +	uphy->ref_clk = clk = devm_clk_get(&ulpi->dev, "ref");
> +	if (IS_ERR(clk))
> +		return PTR_ERR(clk);
> +
> +	uphy->sleep_clk = clk = devm_clk_get(&ulpi->dev, "sleep");
> +	if (IS_ERR(clk))
> +		return PTR_ERR(clk);
> +
> +	uphy->v1p8 = reg = devm_regulator_get(&ulpi->dev, "v1p8");
> +	if (IS_ERR(reg))
> +		return PTR_ERR(reg);
> +
> +	uphy->v3p3 = reg = devm_regulator_get(&ulpi->dev, "v3p3");
> +	if (IS_ERR(reg))
> +		return PTR_ERR(reg);
> +
> +	uphy->reset = reset = devm_reset_control_get(&ulpi->dev, "por");
> +	if (IS_ERR(reset)) {
> +		if (PTR_ERR(reset) == -EPROBE_DEFER)
> +			return PTR_ERR(reset);
> +		uphy->reset = NULL;
> +	}
> +
> +	uphy->phy = devm_phy_create(&ulpi->dev, ulpi->dev.of_node,
> +				    &qcom_usb_hs_phy_ops);
> +	if (IS_ERR(uphy->phy))
> +		return PTR_ERR(uphy->phy);
> +
> +	uphy->vbus_edev = extcon_get_edev_by_phandle(&ulpi->dev, 0);
> +	if (IS_ERR(uphy->vbus_edev)) {
> +		if (PTR_ERR(uphy->vbus_edev) != -ENODEV)
> +			return PTR_ERR(uphy->vbus_edev);
> +		uphy->vbus_edev = NULL;
> +	}
> +
> +	uphy->id_edev = extcon_get_edev_by_phandle(&ulpi->dev, 1);
> +	if (IS_ERR(uphy->id_edev)) {
> +		if (PTR_ERR(uphy->id_edev) != -ENODEV)
> +			return PTR_ERR(uphy->id_edev);
> +		uphy->id_edev = NULL;
> +	}
> +
> +	uphy->vbus_notify.notifier_call = qcom_usb_hs_phy_vbus_notifier;
> +	phy_set_drvdata(uphy->phy, uphy);
> +
> +	p = devm_of_phy_provider_register(&ulpi->dev, of_phy_simple_xlate);
> +	return PTR_ERR_OR_ZERO(p);
> +}
> +
> +static const struct of_device_id qcom_usb_hs_phy_match[] = {
> +	{ .compatible = "qcom,usb-hs-phy", },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(of, qcom_usb_hs_phy_match);
> +
> +static struct ulpi_driver qcom_usb_hs_phy_driver = {
> +	.probe = qcom_usb_hs_phy_probe,
> +	.driver = {
> +		.name = "qcom_usb_hs_phy",
> +		.of_match_table = qcom_usb_hs_phy_match,
> +	},
> +};
> +module_ulpi_driver(qcom_usb_hs_phy_driver);
> +
> +MODULE_DESCRIPTION("Qualcomm USB HS phy");
> +MODULE_LICENSE("GPL v2");
> -- 
> 2.9.0.rc2.8.ga28705d
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

Best Regards,
Peter Chen

Re: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy

[Stephen Boyd]

Quoting Peter Chen (2016-09-13 00:03:58)
> On Wed, Sep 07, 2016 at 02:35:19PM -0700, Stephen Boyd wrote:
> > The high-speed phy on qcom SoCs is controlled via the ULPI
> > viewport.
> > 
> 
> Hi Stephen, I am a little puzzled how this driver co-work with chipidea
> driver. According to nxp IC guys, the ULPI PHY's clock needs to be enabled
> before access portsc.pts (calling hw_phymode_configure), otherwise,
> the system will hang. But I find you call hw_phymode_configure before
> phy->power_on, doesn't your design have this requirement?

Which clk needs to be enabled? The xcvr_clk? I believe that clk
corresponds to the "core" clk that we enable in the msm glue driver
layer. When that clk is enabled, the ULPI phy is able to respond to
register read/writes via the ULPI viewport.

>        
> Besides, you read ulpi id before phy->power_on, how can read work before
> phy power on?
> 

I've found that even having the link clk enabled before phy->power_on
doesn't mean it's possible to read the id registers though. That's
because there can be other power supplies, like regulators, which need
to be on for the phy to operate properly.

Either way, the system does not hang.

Re: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy

[Peter Chen]

On Tue, Sep 13, 2016 at 01:41:44PM -0700, Stephen Boyd wrote:
> Quoting Peter Chen (2016-09-13 00:03:58)
> > On Wed, Sep 07, 2016 at 02:35:19PM -0700, Stephen Boyd wrote:
> > > The high-speed phy on qcom SoCs is controlled via the ULPI
> > > viewport.
> > > 
> > 
> > Hi Stephen, I am a little puzzled how this driver co-work with chipidea
> > driver. According to nxp IC guys, the ULPI PHY's clock needs to be enabled
> > before access portsc.pts (calling hw_phymode_configure), otherwise,
> > the system will hang. But I find you call hw_phymode_configure before
> > phy->power_on, doesn't your design have this requirement?
> 
> Which clk needs to be enabled? The xcvr_clk? I believe that clk
> corresponds to the "core" clk that we enable in the msm glue driver
> layer. When that clk is enabled, the ULPI phy is able to respond to
> register read/writes via the ULPI viewport.
> 

The input clock for ULPI PHY, maybe it is ref_clk at this PHY driver, 
so in your platform, even PHY clock is gated, you can still access
portsc.pts to configure PHY mode at controller register?

> >        
> > Besides, you read ulpi id before phy->power_on, how can read work before
> > phy power on?
> > 
> 
> I've found that even having the link clk enabled before phy->power_on
> doesn't mean it's possible to read the id registers though. That's
> because there can be other power supplies, like regulators, which need
> to be on for the phy to operate properly.
> 

Then I am puzzled the current initialization for your case, in my mind,
it should like below:

qcom_usb_hs_phy_probe->qcom_usb_hs_phy_power_on->ci_ulpi_init

Like other PHYs, it should get PHY first, then power on it, after that,
you can access its register.

-- 

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

Re: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy

[Kishon Vijay Abraham I]

On Saturday 10 September 2016 05:48 PM, Kishon Vijay Abraham I wrote:
> 
> On Wed, Sep 07, 2016 at 02:35:19PM -0700, Stephen Boyd wrote:
>> The high-speed phy on qcom SoCs is controlled via the ULPI
>> viewport.
>>
>> Cc: Kishon Vijay Abraham I <kishon@ti.com>
>> Cc: <devicetree@vger.kernel.org>
>> Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> 
> merged this and the previous patch to linux-phy.

since there are pending discussions, I'll drop this patch for now.

Thanks
Kishon
> 
> Thanks
> Kishon
> 
>> ---
>>  .../devicetree/bindings/phy/qcom,usb-hs-phy.txt    |  83 ++++++
>>  drivers/phy/Kconfig                                |   8 +
>>  drivers/phy/Makefile                               |   1 +
>>  drivers/phy/phy-qcom-usb-hs.c                      | 289 +++++++++++++++++++++
>>  4 files changed, 381 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
>>  create mode 100644 drivers/phy/phy-qcom-usb-hs.c
>>
>> diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
>> new file mode 100644
>> index 000000000000..d7eacd63d06b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
>> @@ -0,0 +1,83 @@
>> +Qualcomm's USB HS PHY
>> +
>> +PROPERTIES
>> +
>> +- compatible:
>> +    Usage: required
>> +    Value type: <string>
>> +    Definition: Should contain "qcom,usb-hs-phy" and more specifically one of the
>> +                following:
>> +
>> +                        "qcom,usb-hs-phy-apq8064"
>> +                        "qcom,usb-hs-phy-msm8916"
>> +                        "qcom,usb-hs-phy-msm8974"
>> +
>> +- #phy-cells:
>> +    Usage: required
>> +    Value type: <u32>
>> +    Definition: Should contain 0
>> +
>> +- clocks:
>> +    Usage: required
>> +    Value type: <prop-encoded-array>
>> +    Definition: Should contain clock specifier for the reference and sleep
>> +                clocks
>> +
>> +- clock-names:
>> +    Usage: required
>> +    Value type: <stringlist>
>> +    Definition: Should contain "ref" and "sleep" for the reference and sleep
>> +                clocks respectively
>> +
>> +- resets:
>> +    Usage: required
>> +    Value type: <prop-encoded-array>
>> +    Definition: Should contain the phy and POR resets
>> +
>> +- reset-names:
>> +    Usage: required
>> +    Value type: <stringlist>
>> +    Definition: Should contain "phy" and "por" for the phy and POR resets
>> +                respectively
>> +
>> +- v3p3-supply:
>> +    Usage: required
>> +    Value type: <phandle>
>> +    Definition: Should contain a reference to the 3.3V supply
>> +
>> +- v1p8-supply:
>> +    Usage: required
>> +    Value type: <phandle>
>> +    Definition: Should contain a reference to the 1.8V supply
>> +
>> +- extcon:
>> +    Usage: optional
>> +    Value type: <prop-encoded-array>
>> +    Definition: Should contain the vbus and ID extcons in the first and second
>> +                cells respectively
>> +
>> +- qcom,init-seq:
>> +    Usage: optional
>> +    Value type: <u8 array>
>> +    Definition: Should contain a sequence of ULPI register and address pairs to
>> +                program into the ULPI_EXT_VENDOR_SPECIFIC area. This is related
>> +                to Device Mode Eye Diagram test.
>> +
>> +EXAMPLE
>> +
>> +otg: usb-controller {
>> +	ulpi {
>> +		phy {
>> +			compatible = "qcom,usb-hs-phy-msm8974", "qcom,usb-hs-phy";
>> +			#phy-cells = <0>;
>> +			clocks = <&xo_board>, <&gcc GCC_USB2A_PHY_SLEEP_CLK>;
>> +			clock-names = "ref", "sleep";
>> +			resets = <&gcc GCC_USB2A_PHY_BCR>, <&otg 0>;
>> +			reset-names = "phy", "por";
>> +			v3p3-supply = <&pm8941_l24>;
>> +			v1p8-supply = <&pm8941_l6>;
>> +			extcon = <&smbb>, <&usb_id>;
>> +			qcom,init-seq = /bits/ 8 <0x81 0x63>;
>> +		};
>> +	};
>> +};
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index 830c443eeabf..ee0ec021a98c 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -417,6 +417,14 @@ config PHY_QCOM_UFS
>>  	help
>>  	  Support for UFS PHY on QCOM chipsets.
>>  
>> +config PHY_QCOM_USB_HS
>> +	tristate "Qualcomm USB HS PHY module"
>> +	depends on USB_ULPI_BUS
>> +	select GENERIC_PHY
>> +	help
>> +	  Support for the USB high-speed ULPI compliant phy on Qualcomm
>> +	  chipsets.
>> +
>>  config PHY_QCOM_USB_HSIC
>>  	tristate "Qualcomm USB HSIC ULPI PHY module"
>>  	depends on USB_ULPI_BUS
>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>> index 5422f543d17d..31c84faa07fa 100644
>> --- a/drivers/phy/Makefile
>> +++ b/drivers/phy/Makefile
>> @@ -50,6 +50,7 @@ obj-$(CONFIG_PHY_STIH41X_USB)		+= phy-stih41x-usb.o
>>  obj-$(CONFIG_PHY_QCOM_UFS) 	+= phy-qcom-ufs.o
>>  obj-$(CONFIG_PHY_QCOM_UFS) 	+= phy-qcom-ufs-qmp-20nm.o
>>  obj-$(CONFIG_PHY_QCOM_UFS) 	+= phy-qcom-ufs-qmp-14nm.o
>> +obj-$(CONFIG_PHY_QCOM_USB_HS) 		+= phy-qcom-usb-hs.o
>>  obj-$(CONFIG_PHY_QCOM_USB_HSIC) 	+= phy-qcom-usb-hsic.o
>>  obj-$(CONFIG_PHY_TUSB1210)		+= phy-tusb1210.o
>>  obj-$(CONFIG_PHY_BRCM_SATA)		+= phy-brcm-sata.o
>> diff --git a/drivers/phy/phy-qcom-usb-hs.c b/drivers/phy/phy-qcom-usb-hs.c
>> new file mode 100644
>> index 000000000000..73fb4b49a8e1
>> --- /dev/null
>> +++ b/drivers/phy/phy-qcom-usb-hs.c
>> @@ -0,0 +1,289 @@
>> +/**
>> + * Copyright (C) 2016 Linaro Ltd
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +#include <linux/module.h>
>> +#include <linux/ulpi/driver.h>
>> +#include <linux/ulpi/regs.h>
>> +#include <linux/clk.h>
>> +#include <linux/regulator/consumer.h>
>> +#include <linux/of_device.h>
>> +#include <linux/reset.h>
>> +#include <linux/extcon.h>
>> +#include <linux/notifier.h>
>> +#include <linux/usb/of.h>
>> +
>> +#include "ulpi_phy.h"
>> +
>> +#define ULPI_PWR_CLK_MNG_REG		0x88
>> +# define ULPI_PWR_OTG_COMP_DISABLE	BIT(0)
>> +
>> +#define ULPI_MISC_A			0x96
>> +# define ULPI_MISC_A_VBUSVLDEXTSEL	BIT(1)
>> +# define ULPI_MISC_A_VBUSVLDEXT		BIT(0)
>> +
>> +
>> +struct ulpi_seq {
>> +	u8 addr;
>> +	u8 val;
>> +};
>> +
>> +struct qcom_usb_hs_phy {
>> +	struct ulpi *ulpi;
>> +	struct phy *phy;
>> +	struct clk *ref_clk;
>> +	struct clk *sleep_clk;
>> +	struct regulator *v1p8;
>> +	struct regulator *v3p3;
>> +	struct reset_control *reset;
>> +	struct ulpi_seq *init_seq;
>> +	struct notifier_block vbus_notify;
>> +	struct extcon_dev *vbus_edev;
>> +	struct extcon_dev *id_edev;
>> +	enum usb_dr_mode dr_mode;
>> +};
>> +
>> +static int
>> +qcom_usb_hs_phy_vbus_notifier(struct notifier_block *nb, unsigned long event,
>> +			      void *ptr)
>> +{
>> +	struct qcom_usb_hs_phy *uphy;
>> +	int is_host;
>> +	u8 addr;
>> +
>> +	uphy = container_of(nb, struct qcom_usb_hs_phy, vbus_notify);
>> +	is_host = extcon_get_cable_state_(uphy->id_edev, EXTCON_USB_HOST);
>> +	if (is_host < 0)
>> +		is_host = 0; /* No id event means always a peripheral */
>> +
>> +	if (event && !is_host)
>> +		addr = ULPI_SET(ULPI_MISC_A);
>> +	else
>> +		addr = ULPI_CLR(ULPI_MISC_A);
>> +
>> +	return ulpi_write(uphy->ulpi, addr,
>> +			  ULPI_MISC_A_VBUSVLDEXTSEL | ULPI_MISC_A_VBUSVLDEXT);
>> +}
>> +
>> +static int qcom_usb_hs_phy_power_on(struct phy *phy)
>> +{
>> +	struct qcom_usb_hs_phy *uphy = phy_get_drvdata(phy);
>> +	struct ulpi *ulpi = uphy->ulpi;
>> +	const struct ulpi_seq *seq;
>> +	int ret, state;
>> +
>> +	ret = clk_prepare_enable(uphy->ref_clk);
>> +	if (ret)
>> +		return ret;
>> +
>> +	ret = clk_prepare_enable(uphy->sleep_clk);
>> +	if (ret)
>> +		goto err_sleep;
>> +
>> +	ret = regulator_set_voltage(uphy->v1p8, 1800000, 1800000);
>> +	if (ret)
>> +		goto err_1p8;
>> +
>> +	ret = regulator_set_load(uphy->v1p8, 50000);
>> +	if (ret < 0)
>> +		goto err_1p8;
>> +
>> +	ret = regulator_enable(uphy->v1p8);
>> +	if (ret)
>> +		goto err_1p8;
>> +
>> +	ret = regulator_set_voltage_triplet(uphy->v3p3, 3050000, 3300000,
>> +					    3300000);
>> +	if (ret)
>> +		goto err_3p3;
>> +
>> +	ret = regulator_set_load(uphy->v3p3, 50000);
>> +	if (ret < 0)
>> +		goto err_3p3;
>> +
>> +	ret = regulator_enable(uphy->v3p3);
>> +	if (ret)
>> +		goto err_3p3;
>> +
>> +	for (seq = uphy->init_seq; seq->addr; seq++) {
>> +		ret = ulpi_write(ulpi, seq->addr, seq->val);
>> +		if (ret)
>> +			goto err_ulpi;
>> +	}
>> +
>> +	if (uphy->reset) {
>> +		ret = reset_control_reset(uphy->reset);
>> +		if (ret)
>> +			goto err_ulpi;
>> +	}
>> +
>> +	if (uphy->vbus_edev) {
>> +		ulpi_write(ulpi, ULPI_SET(ULPI_PWR_CLK_MNG_REG),
>> +			   ULPI_PWR_OTG_COMP_DISABLE);
>> +		state = extcon_get_cable_state_(uphy->vbus_edev, EXTCON_USB);
>> +		/* setup initial state */
>> +		qcom_usb_hs_phy_vbus_notifier(&uphy->vbus_notify, state,
>> +					      uphy->vbus_edev);
>> +		ret = extcon_register_notifier(uphy->vbus_edev, EXTCON_USB,
>> +						&uphy->vbus_notify);
>> +		if (ret)
>> +			return ret;
>> +	} else {
>> +		u8 val;
>> +
>> +		switch (uphy->dr_mode) {
>> +		case USB_DR_MODE_OTG:
>> +			val = ULPI_INT_IDGRD;
>> +		case USB_DR_MODE_PERIPHERAL:
>> +			val |= ULPI_INT_SESS_VALID;
>> +			break;
>> +		default:
>> +			val = 0;
>> +		}
>> +
>> +		ret = ulpi_write(ulpi, ULPI_USB_INT_EN_RISE, val);
>> +		if (ret)
>> +			goto err_ulpi;
>> +		ret = ulpi_write(ulpi, ULPI_USB_INT_EN_FALL, val);
>> +		if (ret)
>> +			goto err_ulpi;
>> +	}
>> +
>> +	return 0;
>> +err_ulpi:
>> +	regulator_disable(uphy->v3p3);
>> +err_3p3:
>> +	regulator_disable(uphy->v1p8);
>> +err_1p8:
>> +	clk_disable_unprepare(uphy->sleep_clk);
>> +err_sleep:
>> +	clk_disable_unprepare(uphy->ref_clk);
>> +	return ret;
>> +}
>> +
>> +static int qcom_usb_hs_phy_power_off(struct phy *phy)
>> +{
>> +	int ret;
>> +	struct qcom_usb_hs_phy *uphy = phy_get_drvdata(phy);
>> +
>> +	if (uphy->vbus_edev) {
>> +		ret = extcon_unregister_notifier(uphy->vbus_edev, EXTCON_USB,
>> +						 &uphy->vbus_notify);
>> +		if (ret)
>> +			return ret;
>> +	}
>> +
>> +	regulator_disable(uphy->v3p3);
>> +	regulator_disable(uphy->v1p8);
>> +	clk_disable_unprepare(uphy->sleep_clk);
>> +	clk_disable_unprepare(uphy->ref_clk);
>> +
>> +	return 0;
>> +}
>> +
>> +static const struct phy_ops qcom_usb_hs_phy_ops = {
>> +	.power_on = qcom_usb_hs_phy_power_on,
>> +	.power_off = qcom_usb_hs_phy_power_off,
>> +	.owner = THIS_MODULE,
>> +};
>> +
>> +static int qcom_usb_hs_phy_probe(struct ulpi *ulpi)
>> +{
>> +	struct qcom_usb_hs_phy *uphy;
>> +	struct phy_provider *p;
>> +	struct clk *clk;
>> +	struct regulator *reg;
>> +	struct reset_control *reset;
>> +	int size;
>> +	int ret;
>> +
>> +	uphy = devm_kzalloc(&ulpi->dev, sizeof(*uphy), GFP_KERNEL);
>> +	if (!uphy)
>> +		return -ENOMEM;
>> +	ulpi_set_drvdata(ulpi, uphy);
>> +	uphy->ulpi = ulpi;
>> +	uphy->dr_mode = of_usb_get_dr_mode_by_phy(ulpi->dev.of_node, -1);
>> +
>> +	size = of_property_count_u8_elems(ulpi->dev.of_node, "qcom,init-seq");
>> +	if (size < 0)
>> +		size = 0;
>> +	uphy->init_seq = devm_kmalloc_array(&ulpi->dev, (size / 2) + 1,
>> +					   sizeof(*uphy->init_seq), GFP_KERNEL);
>> +	if (!uphy->init_seq)
>> +		return -ENOMEM;
>> +	ret = of_property_read_u8_array(ulpi->dev.of_node, "qcom,init-seq",
>> +					(u8 *)uphy->init_seq, size);
>> +	if (ret && size)
>> +		return ret;
>> +	/* NUL terminate */
>> +	uphy->init_seq[size / 2].addr = uphy->init_seq[size / 2].val = 0;
>> +
>> +	uphy->ref_clk = clk = devm_clk_get(&ulpi->dev, "ref");
>> +	if (IS_ERR(clk))
>> +		return PTR_ERR(clk);
>> +
>> +	uphy->sleep_clk = clk = devm_clk_get(&ulpi->dev, "sleep");
>> +	if (IS_ERR(clk))
>> +		return PTR_ERR(clk);
>> +
>> +	uphy->v1p8 = reg = devm_regulator_get(&ulpi->dev, "v1p8");
>> +	if (IS_ERR(reg))
>> +		return PTR_ERR(reg);
>> +
>> +	uphy->v3p3 = reg = devm_regulator_get(&ulpi->dev, "v3p3");
>> +	if (IS_ERR(reg))
>> +		return PTR_ERR(reg);
>> +
>> +	uphy->reset = reset = devm_reset_control_get(&ulpi->dev, "por");
>> +	if (IS_ERR(reset)) {
>> +		if (PTR_ERR(reset) == -EPROBE_DEFER)
>> +			return PTR_ERR(reset);
>> +		uphy->reset = NULL;
>> +	}
>> +
>> +	uphy->phy = devm_phy_create(&ulpi->dev, ulpi->dev.of_node,
>> +				    &qcom_usb_hs_phy_ops);
>> +	if (IS_ERR(uphy->phy))
>> +		return PTR_ERR(uphy->phy);
>> +
>> +	uphy->vbus_edev = extcon_get_edev_by_phandle(&ulpi->dev, 0);
>> +	if (IS_ERR(uphy->vbus_edev)) {
>> +		if (PTR_ERR(uphy->vbus_edev) != -ENODEV)
>> +			return PTR_ERR(uphy->vbus_edev);
>> +		uphy->vbus_edev = NULL;
>> +	}
>> +
>> +	uphy->id_edev = extcon_get_edev_by_phandle(&ulpi->dev, 1);
>> +	if (IS_ERR(uphy->id_edev)) {
>> +		if (PTR_ERR(uphy->id_edev) != -ENODEV)
>> +			return PTR_ERR(uphy->id_edev);
>> +		uphy->id_edev = NULL;
>> +	}
>> +
>> +	uphy->vbus_notify.notifier_call = qcom_usb_hs_phy_vbus_notifier;
>> +	phy_set_drvdata(uphy->phy, uphy);
>> +
>> +	p = devm_of_phy_provider_register(&ulpi->dev, of_phy_simple_xlate);
>> +	return PTR_ERR_OR_ZERO(p);
>> +}
>> +
>> +static const struct of_device_id qcom_usb_hs_phy_match[] = {
>> +	{ .compatible = "qcom,usb-hs-phy", },
>> +	{ }
>> +};
>> +MODULE_DEVICE_TABLE(of, qcom_usb_hs_phy_match);
>> +
>> +static struct ulpi_driver qcom_usb_hs_phy_driver = {
>> +	.probe = qcom_usb_hs_phy_probe,
>> +	.driver = {
>> +		.name = "qcom_usb_hs_phy",
>> +		.of_match_table = qcom_usb_hs_phy_match,
>> +	},
>> +};
>> +module_ulpi_driver(qcom_usb_hs_phy_driver);
>> +
>> +MODULE_DESCRIPTION("Qualcomm USB HS phy");
>> +MODULE_LICENSE("GPL v2");
>> -- 
>> 2.9.0.rc2.8.ga28705d
>>

Re: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy

[Stephen Boyd]

Quoting Peter Chen (2016-09-13 19:11:33)
> On Tue, Sep 13, 2016 at 01:41:44PM -0700, Stephen Boyd wrote:
> > Quoting Peter Chen (2016-09-13 00:03:58)
> > > On Wed, Sep 07, 2016 at 02:35:19PM -0700, Stephen Boyd wrote:
> > > > The high-speed phy on qcom SoCs is controlled via the ULPI
> > > > viewport.
> > > > 
> > > 
> > > Hi Stephen, I am a little puzzled how this driver co-work with chipidea
> > > driver. According to nxp IC guys, the ULPI PHY's clock needs to be enabled
> > > before access portsc.pts (calling hw_phymode_configure), otherwise,
> > > the system will hang. But I find you call hw_phymode_configure before
> > > phy->power_on, doesn't your design have this requirement?
> > 
> > Which clk needs to be enabled? The xcvr_clk? I believe that clk
> > corresponds to the "core" clk that we enable in the msm glue driver
> > layer. When that clk is enabled, the ULPI phy is able to respond to
> > register read/writes via the ULPI viewport.
> > 
> 
> The input clock for ULPI PHY, maybe it is ref_clk at this PHY driver, 
> so in your platform, even PHY clock is gated, you can still access
> portsc.pts to configure PHY mode at controller register?

There are a couple input clocks for this phy. I'm not sure which one the
nxp IC guys think needs to be enabled. Typically, the ref_clk is always
on so it's hard for me to test a scenario where it isn't enabled. But
I'm not sure that the ref_clk is what we're talking about anyway. Would
you know the frequency perhaps? The ref_clk is usually 19.2MHz on these
SoCs. That would match up with the "crystal input" pin in the ULPI
spec[1].

Do you know if this is documented anywhere in the chipidea manual?
I'll have to look again and see if there's something in there, but I
didn't see anything like this.

I would guess that we're talking about the xcvr clock though, because
from what I see in the manual, this is used to clock the interface
between the ULPI phy and the controller. In the ULPI spec, this matches
up with the "clock" signal for the ULPI phy and that usually runs at
something >= 60MHz. 

> 
> > >        
> > > Besides, you read ulpi id before phy->power_on, how can read work before
> > > phy power on?
> > > 
> > 
> > I've found that even having the link clk enabled before phy->power_on
> > doesn't mean it's possible to read the id registers though. That's
> > because there can be other power supplies, like regulators, which need
> > to be on for the phy to operate properly.
> > 
> 
> Then I am puzzled the current initialization for your case, in my mind,
> it should like below:
> 
> qcom_usb_hs_phy_probe->qcom_usb_hs_phy_power_on->ci_ulpi_init
> 
> Like other PHYs, it should get PHY first, then power on it, after that,
> you can access its register.
> 

Hmm.. maybe the confusion is in which registers we should be able to
access? Are we talking about the ULPI viewport MMIO register space or
the ULPI registers that we access through the viewport? I have a
hw_phymode_configure() inside of of ci_ulpi_init() so that the
identification registers through the ULPI viewport read properly
(assuming there aren't other power requirements like regulators). If we
don't set the portsc.pts before using the viewport, the viewport doesn't
work and reads timeout. So we really don't touch the ULPI registers
except for the scratch space and the id registers until after the phy is
properly powered on with clks and regulators, because the only place we
touch them after doing the id checking is in this phy driver in
qcom_usb_hs_phy_power_on(). We've "solved" the chicken-egg problem where
we don't know which device driver to probe because the phy needs to be
powered on to read the id registers to know which device driver to use
by using DT to match up device drivers instead.

[1] https://www.sparkfun.com/datasheets/Components/SMD/ULPI_v1_1.pdf

Re: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy

[Peter Chen]

On Tue, Sep 13, 2016 at 11:29:12PM -0700, Stephen Boyd wrote:
> Quoting Peter Chen (2016-09-13 19:11:33)
> > On Tue, Sep 13, 2016 at 01:41:44PM -0700, Stephen Boyd wrote:
> > > Quoting Peter Chen (2016-09-13 00:03:58)
> > > > On Wed, Sep 07, 2016 at 02:35:19PM -0700, Stephen Boyd wrote:
> > > > > The high-speed phy on qcom SoCs is controlled via the ULPI
> > > > > viewport.
> > > > > 
> > > > 
> > > > Hi Stephen, I am a little puzzled how this driver co-work with chipidea
> > > > driver. According to nxp IC guys, the ULPI PHY's clock needs to be enabled
> > > > before access portsc.pts (calling hw_phymode_configure), otherwise,
> > > > the system will hang. But I find you call hw_phymode_configure before
> > > > phy->power_on, doesn't your design have this requirement?
> > > 
> > > Which clk needs to be enabled? The xcvr_clk? I believe that clk
> > > corresponds to the "core" clk that we enable in the msm glue driver
> > > layer. When that clk is enabled, the ULPI phy is able to respond to
> > > register read/writes via the ULPI viewport.
> > > 
> > 
> > The input clock for ULPI PHY, maybe it is ref_clk at this PHY driver, 
> > so in your platform, even PHY clock is gated, you can still access
> > portsc.pts to configure PHY mode at controller register?
> 
> There are a couple input clocks for this phy. I'm not sure which one the
> nxp IC guys think needs to be enabled. Typically, the ref_clk is always
> on so it's hard for me to test a scenario where it isn't enabled. But
> I'm not sure that the ref_clk is what we're talking about anyway. Would
> you know the frequency perhaps?

I think this ref_clk is ULPI PHY vendor specific, at USB3317, it is
26Mhz.

> The ref_clk is usually 19.2MHz on these
> SoCs. That would match up with the "crystal input" pin in the ULPI
> spec[1].
> 
> Do you know if this is documented anywhere in the chipidea manual?
> I'll have to look again and see if there's something in there, but I
> didn't see anything like this.
> 
> I would guess that we're talking about the xcvr clock though, because
> from what I see in the manual, this is used to clock the interface
> between the ULPI phy and the controller. In the ULPI spec, this matches
> up with the "clock" signal for the ULPI phy and that usually runs at
> something >= 60MHz. 

I think you are right, since controller only concerns the output clock.
So, if you have not enabled xcvr, you may meet hang when set portsc.pts too?

At some designs, ULPI input clock (ref_clk) may from Soc internal,
without enabling it, the controller will not get PHY clock (60Mhz).
When visiting portsc.pts, may meet hang.

> 
> > 
> > > >        
> > > > Besides, you read ulpi id before phy->power_on, how can read work before
> > > > phy power on?
> > > > 
> > > 
> > > I've found that even having the link clk enabled before phy->power_on
> > > doesn't mean it's possible to read the id registers though. That's
> > > because there can be other power supplies, like regulators, which need
> > > to be on for the phy to operate properly.
> > > 
> > 
> > Then I am puzzled the current initialization for your case, in my mind,
> > it should like below:
> > 
> > qcom_usb_hs_phy_probe->qcom_usb_hs_phy_power_on->ci_ulpi_init
> > 
> > Like other PHYs, it should get PHY first, then power on it, after that,
> > you can access its register.
> > 
> 
> Hmm.. maybe the confusion is in which registers we should be able to
> access? Are we talking about the ULPI viewport MMIO register space or
> the ULPI registers that we access through the viewport? I have a
> hw_phymode_configure() inside of of ci_ulpi_init() so that the
> identification registers through the ULPI viewport read properly
> (assuming there aren't other power requirements like regulators). If we
> don't set the portsc.pts before using the viewport, the viewport doesn't
> work and reads timeout. So we really don't touch the ULPI registers
> except for the scratch space and the id registers until after the phy is
> properly powered on with clks and regulators, because the only place we
> touch them after doing the id checking is in this phy driver in
> qcom_usb_hs_phy_power_on(). We've "solved" the chicken-egg problem where
> we don't know which device driver to probe because the phy needs to be
> powered on to read the id registers to know which device driver to use
> by using DT to match up device drivers instead.
> 
> [1] https://www.sparkfun.com/datasheets/Components/SMD/ULPI_v1_1.pdf

Ok, ulpi phy works like USB device on USB bus which create device at
runtime. So, like some hard-wired USB devices, it may needs power
sequence too, otherwise, how it knows which driver can loads.

-- 

Best Regards,
Peter Chen

Re: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy

[Stephen Boyd]

Quoting Peter Chen (2016-09-14 02:33:07)
> On Tue, Sep 13, 2016 at 11:29:12PM -0700, Stephen Boyd wrote:
> > Quoting Peter Chen (2016-09-13 19:11:33)
> > > On Tue, Sep 13, 2016 at 01:41:44PM -0700, Stephen Boyd wrote:
> > > > Quoting Peter Chen (2016-09-13 00:03:58)
> > > > > On Wed, Sep 07, 2016 at 02:35:19PM -0700, Stephen Boyd wrote:
> > > > > > The high-speed phy on qcom SoCs is controlled via the ULPI
> > > > > > viewport.
> > > > > > 
> > > > > 
> > > > > Hi Stephen, I am a little puzzled how this driver co-work with chipidea
> > > > > driver. According to nxp IC guys, the ULPI PHY's clock needs to be enabled
> > > > > before access portsc.pts (calling hw_phymode_configure), otherwise,
> > > > > the system will hang. But I find you call hw_phymode_configure before
> > > > > phy->power_on, doesn't your design have this requirement?
> > > > 
> > > > Which clk needs to be enabled? The xcvr_clk? I believe that clk
> > > > corresponds to the "core" clk that we enable in the msm glue driver
> > > > layer. When that clk is enabled, the ULPI phy is able to respond to
> > > > register read/writes via the ULPI viewport.
> > > > 
> > > 
> > > The input clock for ULPI PHY, maybe it is ref_clk at this PHY driver, 
> > > so in your platform, even PHY clock is gated, you can still access
> > > portsc.pts to configure PHY mode at controller register?
> > 
> > There are a couple input clocks for this phy. I'm not sure which one the
> > nxp IC guys think needs to be enabled. Typically, the ref_clk is always
> > on so it's hard for me to test a scenario where it isn't enabled. But
> > I'm not sure that the ref_clk is what we're talking about anyway. Would
> > you know the frequency perhaps?
> 
> I think this ref_clk is ULPI PHY vendor specific, at USB3317, it is
> 26Mhz.

Ok. Makes sense.

> 
> > The ref_clk is usually 19.2MHz on these
> > SoCs. That would match up with the "crystal input" pin in the ULPI
> > spec[1].
> > 
> > Do you know if this is documented anywhere in the chipidea manual?
> > I'll have to look again and see if there's something in there, but I
> > didn't see anything like this.
> > 
> > I would guess that we're talking about the xcvr clock though, because
> > from what I see in the manual, this is used to clock the interface
> > between the ULPI phy and the controller. In the ULPI spec, this matches
> > up with the "clock" signal for the ULPI phy and that usually runs at
> > something >= 60MHz. 
> 
> I think you are right, since controller only concerns the output clock.
> So, if you have not enabled xcvr, you may meet hang when set portsc.pts too?

Yes. In the qcom designs the xcvr clk is necessary to read/write any of
the registers in the controller. So we wouldn't be able to touch
portsc.pts or any other controller registers without a hang.

> 
> At some designs, ULPI input clock (ref_clk) may from Soc internal,
> without enabling it, the controller will not get PHY clock (60Mhz).
> When visiting portsc.pts, may meet hang.
> 
> > 
> > > 
> > > > >        
> > > > > Besides, you read ulpi id before phy->power_on, how can read work before
> > > > > phy power on?
> > > > > 
> > > > 
> > > > I've found that even having the link clk enabled before phy->power_on
> > > > doesn't mean it's possible to read the id registers though. That's
> > > > because there can be other power supplies, like regulators, which need
> > > > to be on for the phy to operate properly.
> > > > 
> > > 
> > > Then I am puzzled the current initialization for your case, in my mind,
> > > it should like below:
> > > 
> > > qcom_usb_hs_phy_probe->qcom_usb_hs_phy_power_on->ci_ulpi_init
> > > 
> > > Like other PHYs, it should get PHY first, then power on it, after that,
> > > you can access its register.
> > > 
> > 
> > Hmm.. maybe the confusion is in which registers we should be able to
> > access? Are we talking about the ULPI viewport MMIO register space or
> > the ULPI registers that we access through the viewport? I have a
> > hw_phymode_configure() inside of of ci_ulpi_init() so that the
> > identification registers through the ULPI viewport read properly
> > (assuming there aren't other power requirements like regulators). If we
> > don't set the portsc.pts before using the viewport, the viewport doesn't
> > work and reads timeout. So we really don't touch the ULPI registers
> > except for the scratch space and the id registers until after the phy is
> > properly powered on with clks and regulators, because the only place we
> > touch them after doing the id checking is in this phy driver in
> > qcom_usb_hs_phy_power_on(). We've "solved" the chicken-egg problem where
> > we don't know which device driver to probe because the phy needs to be
> > powered on to read the id registers to know which device driver to use
> > by using DT to match up device drivers instead.
> > 
> > [1] https://www.sparkfun.com/datasheets/Components/SMD/ULPI_v1_1.pdf
> 
> Ok, ulpi phy works like USB device on USB bus which create device at
> runtime. So, like some hard-wired USB devices, it may needs power
> sequence too, otherwise, how it knows which driver can loads.
> 

Yes. We use the DT compatible string to ignore any issues with reading
the device ids when the device is powered off. Unlike USB though, we
have device drivers for the ULPI PHYs that do the power sequencing along
with other initializations, so using a common pwrseq layer seems like
overkill just so we can read the id registers.

Are there any concerns with this patch? Or can they be reapplied?

Re: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy

[Peter Chen]

On Wed, Sep 14, 2016 at 10:42:50AM -0700, Stephen Boyd wrote:
> > > 
> > > Hmm.. maybe the confusion is in which registers we should be able to
> > > access? Are we talking about the ULPI viewport MMIO register space or
> > > the ULPI registers that we access through the viewport? I have a
> > > hw_phymode_configure() inside of of ci_ulpi_init() so that the
> > > identification registers through the ULPI viewport read properly
> > > (assuming there aren't other power requirements like regulators). If we
> > > don't set the portsc.pts before using the viewport, the viewport doesn't
> > > work and reads timeout. So we really don't touch the ULPI registers
> > > except for the scratch space and the id registers until after the phy is
> > > properly powered on with clks and regulators, because the only place we
> > > touch them after doing the id checking is in this phy driver in
> > > qcom_usb_hs_phy_power_on(). We've "solved" the chicken-egg problem where
> > > we don't know which device driver to probe because the phy needs to be
> > > powered on to read the id registers to know which device driver to use
> > > by using DT to match up device drivers instead.
> > > 
> > > [1] https://www.sparkfun.com/datasheets/Components/SMD/ULPI_v1_1.pdf
> > 
> > Ok, ulpi phy works like USB device on USB bus which create device at
> > runtime. So, like some hard-wired USB devices, it may needs power
> > sequence too, otherwise, how it knows which driver can loads.
> > 
> 
> Yes. We use the DT compatible string to ignore any issues with reading
> the device ids when the device is powered off. Unlike USB though, we
> have device drivers for the ULPI PHYs that do the power sequencing along
> with other initializations, so using a common pwrseq layer seems like
> overkill just so we can read the id registers.

If the attempt to read id registers will not hang the system, it can
work. Like the case [1], without PHY ref_clk, it will hang when
configure PHY mode (visit portsc.pts), it has no chance to read id
registers. So, I still think the ULPI bus driver needs to do power
sequence for its children, unless you have some place to open the
ref_clk.

> 
> Are there any concerns with this patch? Or can they be reapplied?

For this patch, it is ok for me.


[1] http://www.spinics.net/lists/linux-usb/msg146336.html
-- 

Best Regards,
Peter Chen

Re: [PATCH v4 21/22] phy: Add support for Qualcomm's USB HSIC phy

[Rob Herring]

On Wed, Sep 07, 2016 at 02:35:18PM -0700, Stephen Boyd wrote:
> The HSIC USB controller on qcom SoCs has an integrated all
> digital phy controlled via the ULPI viewport.
> 
> Cc: Kishon Vijay Abraham I <kishon@ti.com>
> Cc: <devicetree@vger.kernel.org>
> Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> ---
>  .../devicetree/bindings/phy/qcom,usb-hsic-phy.txt  |  65 +++++++++

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

>  drivers/phy/Kconfig                                |   7 +
>  drivers/phy/Makefile                               |   1 +
>  drivers/phy/phy-qcom-usb-hsic.c                    | 160 +++++++++++++++++++++
>  4 files changed, 233 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/qcom,usb-hsic-phy.txt
>  create mode 100644 drivers/phy/phy-qcom-usb-hsic.c

Re: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy

[Rob Herring]

On Wed, Sep 07, 2016 at 02:35:19PM -0700, Stephen Boyd wrote:
> The high-speed phy on qcom SoCs is controlled via the ULPI
> viewport.
> 
> Cc: Kishon Vijay Abraham I <kishon@ti.com>
> Cc: <devicetree@vger.kernel.org>
> Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> ---
>  .../devicetree/bindings/phy/qcom,usb-hs-phy.txt    |  83 ++++++
>  drivers/phy/Kconfig                                |   8 +
>  drivers/phy/Makefile                               |   1 +
>  drivers/phy/phy-qcom-usb-hs.c                      | 289 +++++++++++++++++++++
>  4 files changed, 381 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
>  create mode 100644 drivers/phy/phy-qcom-usb-hs.c
> 
> diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
> new file mode 100644
> index 000000000000..d7eacd63d06b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
> @@ -0,0 +1,83 @@
> +Qualcomm's USB HS PHY
> +
> +PROPERTIES
> +
> +- compatible:
> +    Usage: required
> +    Value type: <string>
> +    Definition: Should contain "qcom,usb-hs-phy" and more specifically one of the
> +                following:
> +
> +                        "qcom,usb-hs-phy-apq8064"
> +                        "qcom,usb-hs-phy-msm8916"
> +                        "qcom,usb-hs-phy-msm8974"

This is fine, but things are usually named <soc>-<ipblock>.

> +
> +- #phy-cells:
> +    Usage: required
> +    Value type: <u32>
> +    Definition: Should contain 0
> +
> +- clocks:
> +    Usage: required
> +    Value type: <prop-encoded-array>
> +    Definition: Should contain clock specifier for the reference and sleep
> +                clocks
> +
> +- clock-names:
> +    Usage: required
> +    Value type: <stringlist>
> +    Definition: Should contain "ref" and "sleep" for the reference and sleep
> +                clocks respectively
> +
> +- resets:
> +    Usage: required
> +    Value type: <prop-encoded-array>
> +    Definition: Should contain the phy and POR resets
> +
> +- reset-names:
> +    Usage: required
> +    Value type: <stringlist>
> +    Definition: Should contain "phy" and "por" for the phy and POR resets
> +                respectively
> +
> +- v3p3-supply:
> +    Usage: required
> +    Value type: <phandle>
> +    Definition: Should contain a reference to the 3.3V supply
> +
> +- v1p8-supply:
> +    Usage: required
> +    Value type: <phandle>
> +    Definition: Should contain a reference to the 1.8V supply
> +
> +- extcon:

I don't recommend using extcon binding. It needs some work to put it 
nicely.

> +    Usage: optional
> +    Value type: <prop-encoded-array>
> +    Definition: Should contain the vbus and ID extcons in the first and second
> +                cells respectively
> +
> +- qcom,init-seq:
> +    Usage: optional
> +    Value type: <u8 array>
> +    Definition: Should contain a sequence of ULPI register and address pairs to
> +                program into the ULPI_EXT_VENDOR_SPECIFIC area. This is related
> +                to Device Mode Eye Diagram test.

We generally nak this type of property. For 1 register I don't care so 
much. For 100, that would be another story.

Is this value per unit, per board, per SoC? Can you limit it to certain 
registers?

> +
> +EXAMPLE
> +
> +otg: usb-controller {
> +	ulpi {
> +		phy {
> +			compatible = "qcom,usb-hs-phy-msm8974", "qcom,usb-hs-phy";
> +			#phy-cells = <0>;
> +			clocks = <&xo_board>, <&gcc GCC_USB2A_PHY_SLEEP_CLK>;
> +			clock-names = "ref", "sleep";
> +			resets = <&gcc GCC_USB2A_PHY_BCR>, <&otg 0>;
> +			reset-names = "phy", "por";
> +			v3p3-supply = <&pm8941_l24>;
> +			v1p8-supply = <&pm8941_l6>;
> +			extcon = <&smbb>, <&usb_id>;
> +			qcom,init-seq = /bits/ 8 <0x81 0x63>;
> +		};
> +	};
> +};

Re: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy

[Stephen Boyd]

Quoting Rob Herring (2016-09-16 08:19:51)
> On Wed, Sep 07, 2016 at 02:35:19PM -0700, Stephen Boyd wrote:
> > The high-speed phy on qcom SoCs is controlled via the ULPI
> > viewport.
> > 
> > Cc: Kishon Vijay Abraham I <kishon@ti.com>
> > Cc: <devicetree@vger.kernel.org>
> > Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> > ---
> >  .../devicetree/bindings/phy/qcom,usb-hs-phy.txt    |  83 ++++++
> >  drivers/phy/Kconfig                                |   8 +
> >  drivers/phy/Makefile                               |   1 +
> >  drivers/phy/phy-qcom-usb-hs.c                      | 289 +++++++++++++++++++++
> >  4 files changed, 381 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
> >  create mode 100644 drivers/phy/phy-qcom-usb-hs.c
> > 
> > diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
> > new file mode 100644
> > index 000000000000..d7eacd63d06b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
> > @@ -0,0 +1,83 @@
> > +Qualcomm's USB HS PHY
> > +
> > +PROPERTIES
> > +
> > +- compatible:
> > +    Usage: required
> > +    Value type: <string>
> > +    Definition: Should contain "qcom,usb-hs-phy" and more specifically one of the
> > +                following:
> > +
> > +                        "qcom,usb-hs-phy-apq8064"
> > +                        "qcom,usb-hs-phy-msm8916"
> > +                        "qcom,usb-hs-phy-msm8974"
> 
> This is fine, but things are usually named <soc>-<ipblock>.
> 
> > +
> > +- #phy-cells:
> > +    Usage: required
> > +    Value type: <u32>
> > +    Definition: Should contain 0
> > +
> > +- clocks:
> > +    Usage: required
> > +    Value type: <prop-encoded-array>
> > +    Definition: Should contain clock specifier for the reference and sleep
> > +                clocks
> > +
> > +- clock-names:
> > +    Usage: required
> > +    Value type: <stringlist>
> > +    Definition: Should contain "ref" and "sleep" for the reference and sleep
> > +                clocks respectively
> > +
> > +- resets:
> > +    Usage: required
> > +    Value type: <prop-encoded-array>
> > +    Definition: Should contain the phy and POR resets
> > +
> > +- reset-names:
> > +    Usage: required
> > +    Value type: <stringlist>
> > +    Definition: Should contain "phy" and "por" for the phy and POR resets
> > +                respectively
> > +
> > +- v3p3-supply:
> > +    Usage: required
> > +    Value type: <phandle>
> > +    Definition: Should contain a reference to the 3.3V supply
> > +
> > +- v1p8-supply:
> > +    Usage: required
> > +    Value type: <phandle>
> > +    Definition: Should contain a reference to the 1.8V supply
> > +
> > +- extcon:
> 
> I don't recommend using extcon binding. It needs some work to put it 
> nicely.

:sadface:

> 
> > +    Usage: optional
> > +    Value type: <prop-encoded-array>
> > +    Definition: Should contain the vbus and ID extcons in the first and second
> > +                cells respectively
> > +
> > +- qcom,init-seq:
> > +    Usage: optional
> > +    Value type: <u8 array>
> > +    Definition: Should contain a sequence of ULPI register and address pairs to
> > +                program into the ULPI_EXT_VENDOR_SPECIFIC area. This is related
> > +                to Device Mode Eye Diagram test.
> 
> We generally nak this type of property. For 1 register I don't care so 
> much. For 100, that would be another story.
> 
> Is this value per unit, per board, per SoC? Can you limit it to certain 
> registers?

I'm told that this can be per board, depending on how it's wired from
the phy pins to the usb port. Typically it's the same though for the
boards I have, mostly because those boards are similar designs with
respect to how USB is wired. The set of registers is not that many, 4 or
5 at most. My understanding is these are tuning registers. Right now the
register part in the binding is the full register offset, and not an
offset from ULPI_EXT_VENDOR_SPECIFIC (0x80). I could change this to be
an offset from that area if you like so that this can't be abused to
write into standard ULPI registers (there really isn't any way to
enforce this in software though).

This is "borrowed" from another binding for this usb stuff that I'm
attempting to kill off, bindings/usb/msm-hsusb.txt. Just historical info
in case you're interested.

Re: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy

[Rob Herring]

On Fri, Sep 16, 2016 at 7:05 PM, Stephen Boyd <stephen.boyd@linaro.org> wrote:
> Quoting Rob Herring (2016-09-16 08:19:51)
>> On Wed, Sep 07, 2016 at 02:35:19PM -0700, Stephen Boyd wrote:
>> > The high-speed phy on qcom SoCs is controlled via the ULPI
>> > viewport.
>> >

[...]

>> > +- qcom,init-seq:
>> > +    Usage: optional
>> > +    Value type: <u8 array>
>> > +    Definition: Should contain a sequence of ULPI register and address pairs to
>> > +                program into the ULPI_EXT_VENDOR_SPECIFIC area. This is related
>> > +                to Device Mode Eye Diagram test.
>>
>> We generally nak this type of property. For 1 register I don't care so
>> much. For 100, that would be another story.
>>
>> Is this value per unit, per board, per SoC? Can you limit it to certain
>> registers?
>
> I'm told that this can be per board, depending on how it's wired from
> the phy pins to the usb port. Typically it's the same though for the
> boards I have, mostly because those boards are similar designs with
> respect to how USB is wired. The set of registers is not that many, 4 or
> 5 at most. My understanding is these are tuning registers. Right now the
> register part in the binding is the full register offset, and not an
> offset from ULPI_EXT_VENDOR_SPECIFIC (0x80). I could change this to be
> an offset from that area if you like so that this can't be abused to
> write into standard ULPI registers (there really isn't any way to
> enforce this in software though).

Okay, that sounds fine to me.

Rob