* [PATCH v7 usb-next 1/4] dt-bindings: usb: add the documentation for USB root-hub
2017-10-23 21:57 ` Martin Blumenstingl
@ 2017-10-23 21:57 ` Martin Blumenstingl
-1 siblings, 0 replies; 34+ messages in thread
From: Martin Blumenstingl @ 2017-10-23 21:57 UTC (permalink / raw)
To: linux-usb-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
felipe.balbi-VuQAYsv1563Yd54FQh9/CA,
mathias.nyman-ral2JQCrhuEAvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4
Cc: mark.rutland-5wv7dgnIgG8,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz, Martin Blumenstingl
A USB root-hub may have several PHYs which need to be configured before
the root-hub starts working.
This adds the documentation for such a USB root-hub as well as a hint
regarding the child-nodes on XHCI controllers which can include the
roothub.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
.../devicetree/bindings/usb/usb-roothub.txt | 46 ++++++++++++++++++++++
Documentation/devicetree/bindings/usb/usb-xhci.txt | 7 ++++
2 files changed, 53 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/usb-roothub.txt
diff --git a/Documentation/devicetree/bindings/usb/usb-roothub.txt b/Documentation/devicetree/bindings/usb/usb-roothub.txt
new file mode 100644
index 000000000000..fc0797d7cee9
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb-roothub.txt
@@ -0,0 +1,46 @@
+Generic USB root-hub Properties
+
+similar to the USB device bindings (documented in usb-device.txt from the
+current directory) this provides support for configuring the root-hub.
+
+Required properties:
+- compatible: should be at least one of "usb1d6b,3", "usb1d6b,2"
+- reg: must be 0.
+- address-cells: must be 1
+- size-cells: must be 0
+
+Required sub-nodes:
+a sub-node per actual USB port is required. each sub-node supports the
+following properties:
+ Required properties:
+ - reg: the port number on the root-hub (mandatory)
+ Optional properties:
+ - phys: optional, from the *Generic PHY* bindings (mandatory needed
+ when phy-names is given)
+ - phy-names: optional, from the *Generic PHY* bindings; supported names
+ are "usb2-phy" or "usb3-phy"
+
+Example:
+ &usb1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ roothub@0 {
+ compatible = "usb1d6b,3", "usb1d6b,2";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ port@1 {
+ reg = <1>;
+ phys = <&usb2_phy1>, <&usb3_phy1>;
+ phy-names = "usb2-phy", "usb3-phy";
+ };
+
+ port@2 {
+ reg = <2>;
+ phys = <&usb2_phy2>, <&usb3_phy2>;
+ phy-names = "usb2-phy", "usb3-phy";
+ };
+ };
+ }
diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
index ae6e484a8d7c..5b49ba9f2f9a 100644
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -30,6 +30,13 @@ Optional properties:
- usb3-lpm-capable: determines if platform is USB3 LPM capable
- quirk-broken-port-ped: set if the controller has broken port disable mechanism
+sub-nodes:
+- optionally there can be a node for the root-hub, see usb-roothub.txt in the
+ current directory
+- one or more nodes with reg 1-31 for each port to which a device is connected.
+ See usb-device.txt in the current directory for more information.
+
+
Example:
usb@f0931000 {
compatible = "generic-xhci";
--
2.14.2
--
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
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v7 usb-next 1/4] dt-bindings: usb: add the documentation for USB root-hub
@ 2017-10-23 21:57 ` Martin Blumenstingl
0 siblings, 0 replies; 34+ messages in thread
From: Martin Blumenstingl @ 2017-10-23 21:57 UTC (permalink / raw)
To: linus-amlogic
A USB root-hub may have several PHYs which need to be configured before
the root-hub starts working.
This adds the documentation for such a USB root-hub as well as a hint
regarding the child-nodes on XHCI controllers which can include the
roothub.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/usb/usb-roothub.txt | 46 ++++++++++++++++++++++
Documentation/devicetree/bindings/usb/usb-xhci.txt | 7 ++++
2 files changed, 53 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/usb-roothub.txt
diff --git a/Documentation/devicetree/bindings/usb/usb-roothub.txt b/Documentation/devicetree/bindings/usb/usb-roothub.txt
new file mode 100644
index 000000000000..fc0797d7cee9
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb-roothub.txt
@@ -0,0 +1,46 @@
+Generic USB root-hub Properties
+
+similar to the USB device bindings (documented in usb-device.txt from the
+current directory) this provides support for configuring the root-hub.
+
+Required properties:
+- compatible: should be at least one of "usb1d6b,3", "usb1d6b,2"
+- reg: must be 0.
+- address-cells: must be 1
+- size-cells: must be 0
+
+Required sub-nodes:
+a sub-node per actual USB port is required. each sub-node supports the
+following properties:
+ Required properties:
+ - reg: the port number on the root-hub (mandatory)
+ Optional properties:
+ - phys: optional, from the *Generic PHY* bindings (mandatory needed
+ when phy-names is given)
+ - phy-names: optional, from the *Generic PHY* bindings; supported names
+ are "usb2-phy" or "usb3-phy"
+
+Example:
+ &usb1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ roothub at 0 {
+ compatible = "usb1d6b,3", "usb1d6b,2";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ port at 1 {
+ reg = <1>;
+ phys = <&usb2_phy1>, <&usb3_phy1>;
+ phy-names = "usb2-phy", "usb3-phy";
+ };
+
+ port at 2 {
+ reg = <2>;
+ phys = <&usb2_phy2>, <&usb3_phy2>;
+ phy-names = "usb2-phy", "usb3-phy";
+ };
+ };
+ }
diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
index ae6e484a8d7c..5b49ba9f2f9a 100644
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -30,6 +30,13 @@ Optional properties:
- usb3-lpm-capable: determines if platform is USB3 LPM capable
- quirk-broken-port-ped: set if the controller has broken port disable mechanism
+sub-nodes:
+- optionally there can be a node for the root-hub, see usb-roothub.txt in the
+ current directory
+- one or more nodes with reg 1-31 for each port to which a device is connected.
+ See usb-device.txt in the current directory for more information.
+
+
Example:
usb at f0931000 {
compatible = "generic-xhci";
--
2.14.2
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v7 usb-next 2/4] usb: core: add a wrapper for the USB PHYs on the root-hub
2017-10-23 21:57 ` Martin Blumenstingl
@ 2017-10-23 21:57 ` Martin Blumenstingl
-1 siblings, 0 replies; 34+ messages in thread
From: Martin Blumenstingl @ 2017-10-23 21:57 UTC (permalink / raw)
To: linux-usb-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
felipe.balbi-VuQAYsv1563Yd54FQh9/CA,
mathias.nyman-ral2JQCrhuEAvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4
Cc: mark.rutland-5wv7dgnIgG8,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz, Martin Blumenstingl
Many SoC platforms have separate devices for the USB PHY which are
registered through the generic PHY framework. These PHYs have to be
enabled to make the USB controller actually work. They also have to be
disabled again on shutdown/suspend.
Currently (at least) the following HCI platform drivers are using custom
code to obtain all PHYs via devicetree for the roothub/controller and
disable/enable them when required:
- ehci-platform.c has ehci_platform_power_{on,off}
- xhci-mtk.c has xhci_mtk_phy_{init,exit,power_on,power_off}
- ohci-platform.c has ohci_platform_power_{on,off}
These drivers are not using the generic devicetree USB device bindings
(for the root-hub) yet which were only introduced recently (documentation
is available in devicetree/bindings/usb/usb-device.txt).
With this new wrapper the usb2-phy and usb3-phy can be specified directly
in the child-node of the corresponding port of the roothub via
devicetree.
This allows SoCs like the Amlogic Meson GXL family to operate correctly
because all USB PHYs are initialized (instead of the first USB PHY
only).
Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Tested-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
drivers/usb/core/Makefile | 2 +-
drivers/usb/core/phy.c | 176 ++++++++++++++++++++++++++++++++++++++++++++++
drivers/usb/core/phy.h | 7 ++
3 files changed, 184 insertions(+), 1 deletion(-)
create mode 100644 drivers/usb/core/phy.c
create mode 100644 drivers/usb/core/phy.h
diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
index 250ec1d662d9..b6e181d08bf6 100644
--- a/drivers/usb/core/Makefile
+++ b/drivers/usb/core/Makefile
@@ -5,7 +5,7 @@
usbcore-y := usb.o hub.o hcd.o urb.o message.o driver.o
usbcore-y += config.o file.o buffer.o sysfs.o endpoint.o
usbcore-y += devio.o notify.o generic.o quirks.o devices.o
-usbcore-y += port.o
+usbcore-y += phy.o port.o
usbcore-$(CONFIG_OF) += of.o
usbcore-$(CONFIG_USB_PCI) += hcd-pci.o
diff --git a/drivers/usb/core/phy.c b/drivers/usb/core/phy.c
new file mode 100644
index 000000000000..31245b4abdbf
--- /dev/null
+++ b/drivers/usb/core/phy.c
@@ -0,0 +1,176 @@
+/*
+ * USB PHY roothub driver - a wrapper for multiple PHYs which passes all phy_*
+ * function calls to multiple (actual) PHY devices. This is comes handy when
+ * initializing all PHYs on a root-hub and to keep them all in the same state.
+ *
+ * Copyright (C) 2017 Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/device.h>
+#include <linux/list.h>
+#include <linux/phy/phy.h>
+#include <linux/of.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+#include <linux/usb/of.h>
+
+#include "phy.h"
+
+#define ROOTHUB_PORTNUM 0
+
+struct usb_phy_roothub {
+ struct phy *phy;
+ struct list_head list;
+};
+
+static struct usb_phy_roothub *usb_phy_roothub_alloc(struct device *dev)
+{
+ struct usb_phy_roothub *roothub_entry;
+
+ roothub_entry = devm_kzalloc(dev, sizeof(*roothub_entry), GFP_KERNEL);
+ if (!roothub_entry)
+ return ERR_PTR(-ENOMEM);
+
+ INIT_LIST_HEAD(&roothub_entry->list);
+
+ return roothub_entry;
+}
+
+static int usb_phy_roothub_add_phy(struct device *dev,
+ struct device_node *port_np,
+ const char *con_id, struct list_head *list)
+{
+ struct usb_phy_roothub *roothub_entry;
+ struct phy *phy = devm_of_phy_get(dev, port_np, con_id);
+
+ if (IS_ERR_OR_NULL(phy)) {
+ if (!phy || PTR_ERR(phy) == -ENODEV)
+ return 0;
+ else
+ return PTR_ERR(phy);
+ }
+
+ roothub_entry = usb_phy_roothub_alloc(dev);
+ if (IS_ERR(roothub_entry))
+ return PTR_ERR(roothub_entry);
+
+ roothub_entry->phy = phy;
+
+ list_add_tail(&roothub_entry->list, list);
+
+ return 0;
+}
+
+struct usb_phy_roothub *usb_phy_roothub_init(struct device *dev)
+{
+ struct device_node *roothub_np, *port_np;
+ struct usb_phy_roothub *phy_roothub;
+ struct usb_phy_roothub *roothub_entry;
+ struct list_head *head;
+ int err;
+
+ roothub_np = usb_of_get_child_node(dev->of_node, ROOTHUB_PORTNUM);
+ if (!of_device_is_available(roothub_np))
+ return NULL;
+
+ phy_roothub = usb_phy_roothub_alloc(dev);
+ if (IS_ERR(phy_roothub))
+ return phy_roothub;
+
+ for_each_available_child_of_node(roothub_np, port_np) {
+ err = usb_phy_roothub_add_phy(dev, port_np, "usb2-phy",
+ &phy_roothub->list);
+ if (err)
+ goto err_out;
+
+ err = usb_phy_roothub_add_phy(dev, port_np, "usb3-phy",
+ &phy_roothub->list);
+ if (err)
+ goto err_out;
+ }
+
+ head = &phy_roothub->list;
+
+ list_for_each_entry(roothub_entry, head, list) {
+ err = phy_init(roothub_entry->phy);
+ if (err)
+ goto err_exit_phys;
+ }
+
+ return phy_roothub;
+
+err_exit_phys:
+ list_for_each_entry_continue_reverse(roothub_entry, head, list)
+ phy_exit(roothub_entry->phy);
+
+err_out:
+ return ERR_PTR(err);
+}
+EXPORT_SYMBOL_GPL(usb_phy_roothub_init);
+
+int usb_phy_roothub_exit(struct usb_phy_roothub *phy_roothub)
+{
+ struct usb_phy_roothub *roothub_entry;
+ struct list_head *head;
+ int err, ret = 0;
+
+ if (!phy_roothub)
+ return 0;
+
+ head = &phy_roothub->list;
+
+ list_for_each_entry(roothub_entry, head, list) {
+ err = phy_exit(roothub_entry->phy);
+ if (err)
+ ret = ret;
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(usb_phy_roothub_exit);
+
+int usb_phy_roothub_power_on(struct usb_phy_roothub *phy_roothub)
+{
+ struct usb_phy_roothub *roothub_entry;
+ struct list_head *head;
+ int err;
+
+ if (!phy_roothub)
+ return 0;
+
+ head = &phy_roothub->list;
+
+ list_for_each_entry(roothub_entry, head, list) {
+ err = phy_power_on(roothub_entry->phy);
+ if (err)
+ goto err_out;
+ }
+
+ return 0;
+
+err_out:
+ list_for_each_entry_continue_reverse(roothub_entry, head, list)
+ phy_power_off(roothub_entry->phy);
+
+ return err;
+}
+EXPORT_SYMBOL_GPL(usb_phy_roothub_power_on);
+
+void usb_phy_roothub_power_off(struct usb_phy_roothub *phy_roothub)
+{
+ struct usb_phy_roothub *roothub_entry;
+
+ if (!phy_roothub)
+ return;
+
+ list_for_each_entry_reverse(roothub_entry, &phy_roothub->list, list)
+ phy_power_off(roothub_entry->phy);
+}
+EXPORT_SYMBOL_GPL(usb_phy_roothub_power_off);
diff --git a/drivers/usb/core/phy.h b/drivers/usb/core/phy.h
new file mode 100644
index 000000000000..6fde59bfbff8
--- /dev/null
+++ b/drivers/usb/core/phy.h
@@ -0,0 +1,7 @@
+struct usb_phy_roothub;
+
+struct usb_phy_roothub *usb_phy_roothub_init(struct device *dev);
+int usb_phy_roothub_exit(struct usb_phy_roothub *phy_roothub);
+
+int usb_phy_roothub_power_on(struct usb_phy_roothub *phy_roothub);
+void usb_phy_roothub_power_off(struct usb_phy_roothub *phy_roothub);
--
2.14.2
--
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
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v7 usb-next 2/4] usb: core: add a wrapper for the USB PHYs on the root-hub
@ 2017-10-23 21:57 ` Martin Blumenstingl
0 siblings, 0 replies; 34+ messages in thread
From: Martin Blumenstingl @ 2017-10-23 21:57 UTC (permalink / raw)
To: linus-amlogic
Many SoC platforms have separate devices for the USB PHY which are
registered through the generic PHY framework. These PHYs have to be
enabled to make the USB controller actually work. They also have to be
disabled again on shutdown/suspend.
Currently (at least) the following HCI platform drivers are using custom
code to obtain all PHYs via devicetree for the roothub/controller and
disable/enable them when required:
- ehci-platform.c has ehci_platform_power_{on,off}
- xhci-mtk.c has xhci_mtk_phy_{init,exit,power_on,power_off}
- ohci-platform.c has ohci_platform_power_{on,off}
These drivers are not using the generic devicetree USB device bindings
(for the root-hub) yet which were only introduced recently (documentation
is available in devicetree/bindings/usb/usb-device.txt).
With this new wrapper the usb2-phy and usb3-phy can be specified directly
in the child-node of the corresponding port of the roothub via
devicetree.
This allows SoCs like the Amlogic Meson GXL family to operate correctly
because all USB PHYs are initialized (instead of the first USB PHY
only).
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Tested-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/usb/core/Makefile | 2 +-
drivers/usb/core/phy.c | 176 ++++++++++++++++++++++++++++++++++++++++++++++
drivers/usb/core/phy.h | 7 ++
3 files changed, 184 insertions(+), 1 deletion(-)
create mode 100644 drivers/usb/core/phy.c
create mode 100644 drivers/usb/core/phy.h
diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
index 250ec1d662d9..b6e181d08bf6 100644
--- a/drivers/usb/core/Makefile
+++ b/drivers/usb/core/Makefile
@@ -5,7 +5,7 @@
usbcore-y := usb.o hub.o hcd.o urb.o message.o driver.o
usbcore-y += config.o file.o buffer.o sysfs.o endpoint.o
usbcore-y += devio.o notify.o generic.o quirks.o devices.o
-usbcore-y += port.o
+usbcore-y += phy.o port.o
usbcore-$(CONFIG_OF) += of.o
usbcore-$(CONFIG_USB_PCI) += hcd-pci.o
diff --git a/drivers/usb/core/phy.c b/drivers/usb/core/phy.c
new file mode 100644
index 000000000000..31245b4abdbf
--- /dev/null
+++ b/drivers/usb/core/phy.c
@@ -0,0 +1,176 @@
+/*
+ * USB PHY roothub driver - a wrapper for multiple PHYs which passes all phy_*
+ * function calls to multiple (actual) PHY devices. This is comes handy when
+ * initializing all PHYs on a root-hub and to keep them all in the same state.
+ *
+ * Copyright (C) 2017 Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/device.h>
+#include <linux/list.h>
+#include <linux/phy/phy.h>
+#include <linux/of.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+#include <linux/usb/of.h>
+
+#include "phy.h"
+
+#define ROOTHUB_PORTNUM 0
+
+struct usb_phy_roothub {
+ struct phy *phy;
+ struct list_head list;
+};
+
+static struct usb_phy_roothub *usb_phy_roothub_alloc(struct device *dev)
+{
+ struct usb_phy_roothub *roothub_entry;
+
+ roothub_entry = devm_kzalloc(dev, sizeof(*roothub_entry), GFP_KERNEL);
+ if (!roothub_entry)
+ return ERR_PTR(-ENOMEM);
+
+ INIT_LIST_HEAD(&roothub_entry->list);
+
+ return roothub_entry;
+}
+
+static int usb_phy_roothub_add_phy(struct device *dev,
+ struct device_node *port_np,
+ const char *con_id, struct list_head *list)
+{
+ struct usb_phy_roothub *roothub_entry;
+ struct phy *phy = devm_of_phy_get(dev, port_np, con_id);
+
+ if (IS_ERR_OR_NULL(phy)) {
+ if (!phy || PTR_ERR(phy) == -ENODEV)
+ return 0;
+ else
+ return PTR_ERR(phy);
+ }
+
+ roothub_entry = usb_phy_roothub_alloc(dev);
+ if (IS_ERR(roothub_entry))
+ return PTR_ERR(roothub_entry);
+
+ roothub_entry->phy = phy;
+
+ list_add_tail(&roothub_entry->list, list);
+
+ return 0;
+}
+
+struct usb_phy_roothub *usb_phy_roothub_init(struct device *dev)
+{
+ struct device_node *roothub_np, *port_np;
+ struct usb_phy_roothub *phy_roothub;
+ struct usb_phy_roothub *roothub_entry;
+ struct list_head *head;
+ int err;
+
+ roothub_np = usb_of_get_child_node(dev->of_node, ROOTHUB_PORTNUM);
+ if (!of_device_is_available(roothub_np))
+ return NULL;
+
+ phy_roothub = usb_phy_roothub_alloc(dev);
+ if (IS_ERR(phy_roothub))
+ return phy_roothub;
+
+ for_each_available_child_of_node(roothub_np, port_np) {
+ err = usb_phy_roothub_add_phy(dev, port_np, "usb2-phy",
+ &phy_roothub->list);
+ if (err)
+ goto err_out;
+
+ err = usb_phy_roothub_add_phy(dev, port_np, "usb3-phy",
+ &phy_roothub->list);
+ if (err)
+ goto err_out;
+ }
+
+ head = &phy_roothub->list;
+
+ list_for_each_entry(roothub_entry, head, list) {
+ err = phy_init(roothub_entry->phy);
+ if (err)
+ goto err_exit_phys;
+ }
+
+ return phy_roothub;
+
+err_exit_phys:
+ list_for_each_entry_continue_reverse(roothub_entry, head, list)
+ phy_exit(roothub_entry->phy);
+
+err_out:
+ return ERR_PTR(err);
+}
+EXPORT_SYMBOL_GPL(usb_phy_roothub_init);
+
+int usb_phy_roothub_exit(struct usb_phy_roothub *phy_roothub)
+{
+ struct usb_phy_roothub *roothub_entry;
+ struct list_head *head;
+ int err, ret = 0;
+
+ if (!phy_roothub)
+ return 0;
+
+ head = &phy_roothub->list;
+
+ list_for_each_entry(roothub_entry, head, list) {
+ err = phy_exit(roothub_entry->phy);
+ if (err)
+ ret = ret;
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(usb_phy_roothub_exit);
+
+int usb_phy_roothub_power_on(struct usb_phy_roothub *phy_roothub)
+{
+ struct usb_phy_roothub *roothub_entry;
+ struct list_head *head;
+ int err;
+
+ if (!phy_roothub)
+ return 0;
+
+ head = &phy_roothub->list;
+
+ list_for_each_entry(roothub_entry, head, list) {
+ err = phy_power_on(roothub_entry->phy);
+ if (err)
+ goto err_out;
+ }
+
+ return 0;
+
+err_out:
+ list_for_each_entry_continue_reverse(roothub_entry, head, list)
+ phy_power_off(roothub_entry->phy);
+
+ return err;
+}
+EXPORT_SYMBOL_GPL(usb_phy_roothub_power_on);
+
+void usb_phy_roothub_power_off(struct usb_phy_roothub *phy_roothub)
+{
+ struct usb_phy_roothub *roothub_entry;
+
+ if (!phy_roothub)
+ return;
+
+ list_for_each_entry_reverse(roothub_entry, &phy_roothub->list, list)
+ phy_power_off(roothub_entry->phy);
+}
+EXPORT_SYMBOL_GPL(usb_phy_roothub_power_off);
diff --git a/drivers/usb/core/phy.h b/drivers/usb/core/phy.h
new file mode 100644
index 000000000000..6fde59bfbff8
--- /dev/null
+++ b/drivers/usb/core/phy.h
@@ -0,0 +1,7 @@
+struct usb_phy_roothub;
+
+struct usb_phy_roothub *usb_phy_roothub_init(struct device *dev);
+int usb_phy_roothub_exit(struct usb_phy_roothub *phy_roothub);
+
+int usb_phy_roothub_power_on(struct usb_phy_roothub *phy_roothub);
+void usb_phy_roothub_power_off(struct usb_phy_roothub *phy_roothub);
--
2.14.2
^ permalink raw reply related [flat|nested] 34+ messages in thread
[parent not found: <20171023215718.3446-3-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v7 usb-next 2/4] usb: core: add a wrapper for the USB PHYs on the root-hub
2017-10-23 21:57 ` Martin Blumenstingl
@ 2017-10-24 0:06 ` Chunfeng Yun
-1 siblings, 0 replies; 34+ messages in thread
From: Chunfeng Yun @ 2017-10-24 0:06 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
felipe.balbi-VuQAYsv1563Yd54FQh9/CA,
mathias.nyman-ral2JQCrhuEAvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4,
mark.rutland-5wv7dgnIgG8,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz
On Mon, 2017-10-23 at 23:57 +0200, Martin Blumenstingl wrote:
> Many SoC platforms have separate devices for the USB PHY which are
> registered through the generic PHY framework. These PHYs have to be
> enabled to make the USB controller actually work. They also have to be
> disabled again on shutdown/suspend.
>
> Currently (at least) the following HCI platform drivers are using custom
> code to obtain all PHYs via devicetree for the roothub/controller and
> disable/enable them when required:
> - ehci-platform.c has ehci_platform_power_{on,off}
> - xhci-mtk.c has xhci_mtk_phy_{init,exit,power_on,power_off}
> - ohci-platform.c has ohci_platform_power_{on,off}
>
> These drivers are not using the generic devicetree USB device bindings
> (for the root-hub) yet which were only introduced recently (documentation
> is available in devicetree/bindings/usb/usb-device.txt).
>
> With this new wrapper the usb2-phy and usb3-phy can be specified directly
> in the child-node of the corresponding port of the roothub via
> devicetree.
> This allows SoCs like the Amlogic Meson GXL family to operate correctly
> because all USB PHYs are initialized (instead of the first USB PHY
> only).
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> Tested-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
> drivers/usb/core/Makefile | 2 +-
> drivers/usb/core/phy.c | 176 ++++++++++++++++++++++++++++++++++++++++++++++
> drivers/usb/core/phy.h | 7 ++
> 3 files changed, 184 insertions(+), 1 deletion(-)
> create mode 100644 drivers/usb/core/phy.c
> create mode 100644 drivers/usb/core/phy.h
>
> diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
> index 250ec1d662d9..b6e181d08bf6 100644
> --- a/drivers/usb/core/Makefile
> +++ b/drivers/usb/core/Makefile
> @@ -5,7 +5,7 @@
> usbcore-y := usb.o hub.o hcd.o urb.o message.o driver.o
> usbcore-y += config.o file.o buffer.o sysfs.o endpoint.o
> usbcore-y += devio.o notify.o generic.o quirks.o devices.o
> -usbcore-y += port.o
> +usbcore-y += phy.o port.o
>
> usbcore-$(CONFIG_OF) += of.o
> usbcore-$(CONFIG_USB_PCI) += hcd-pci.o
> diff --git a/drivers/usb/core/phy.c b/drivers/usb/core/phy.c
> new file mode 100644
> index 000000000000..31245b4abdbf
> --- /dev/null
> +++ b/drivers/usb/core/phy.c
...
> diff --git a/drivers/usb/core/phy.h b/drivers/usb/core/phy.h
> new file mode 100644
> index 000000000000..6fde59bfbff8
> --- /dev/null
> +++ b/drivers/usb/core/phy.h
> @@ -0,0 +1,7 @@
> +struct usb_phy_roothub;
> +
> +struct usb_phy_roothub *usb_phy_roothub_init(struct device *dev);
> +int usb_phy_roothub_exit(struct usb_phy_roothub *phy_roothub);
> +
> +int usb_phy_roothub_power_on(struct usb_phy_roothub *phy_roothub);
> +void usb_phy_roothub_power_off(struct usb_phy_roothub *phy_roothub);
Tested-by: Chunfeng Yun <chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Acked-by: Chunfeng Yun <chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
--
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v7 usb-next 2/4] usb: core: add a wrapper for the USB PHYs on the root-hub
@ 2017-10-24 0:06 ` Chunfeng Yun
0 siblings, 0 replies; 34+ messages in thread
From: Chunfeng Yun @ 2017-10-24 0:06 UTC (permalink / raw)
To: linus-amlogic
On Mon, 2017-10-23 at 23:57 +0200, Martin Blumenstingl wrote:
> Many SoC platforms have separate devices for the USB PHY which are
> registered through the generic PHY framework. These PHYs have to be
> enabled to make the USB controller actually work. They also have to be
> disabled again on shutdown/suspend.
>
> Currently (at least) the following HCI platform drivers are using custom
> code to obtain all PHYs via devicetree for the roothub/controller and
> disable/enable them when required:
> - ehci-platform.c has ehci_platform_power_{on,off}
> - xhci-mtk.c has xhci_mtk_phy_{init,exit,power_on,power_off}
> - ohci-platform.c has ohci_platform_power_{on,off}
>
> These drivers are not using the generic devicetree USB device bindings
> (for the root-hub) yet which were only introduced recently (documentation
> is available in devicetree/bindings/usb/usb-device.txt).
>
> With this new wrapper the usb2-phy and usb3-phy can be specified directly
> in the child-node of the corresponding port of the roothub via
> devicetree.
> This allows SoCs like the Amlogic Meson GXL family to operate correctly
> because all USB PHYs are initialized (instead of the first USB PHY
> only).
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> Tested-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> drivers/usb/core/Makefile | 2 +-
> drivers/usb/core/phy.c | 176 ++++++++++++++++++++++++++++++++++++++++++++++
> drivers/usb/core/phy.h | 7 ++
> 3 files changed, 184 insertions(+), 1 deletion(-)
> create mode 100644 drivers/usb/core/phy.c
> create mode 100644 drivers/usb/core/phy.h
>
> diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
> index 250ec1d662d9..b6e181d08bf6 100644
> --- a/drivers/usb/core/Makefile
> +++ b/drivers/usb/core/Makefile
> @@ -5,7 +5,7 @@
> usbcore-y := usb.o hub.o hcd.o urb.o message.o driver.o
> usbcore-y += config.o file.o buffer.o sysfs.o endpoint.o
> usbcore-y += devio.o notify.o generic.o quirks.o devices.o
> -usbcore-y += port.o
> +usbcore-y += phy.o port.o
>
> usbcore-$(CONFIG_OF) += of.o
> usbcore-$(CONFIG_USB_PCI) += hcd-pci.o
> diff --git a/drivers/usb/core/phy.c b/drivers/usb/core/phy.c
> new file mode 100644
> index 000000000000..31245b4abdbf
> --- /dev/null
> +++ b/drivers/usb/core/phy.c
...
> diff --git a/drivers/usb/core/phy.h b/drivers/usb/core/phy.h
> new file mode 100644
> index 000000000000..6fde59bfbff8
> --- /dev/null
> +++ b/drivers/usb/core/phy.h
> @@ -0,0 +1,7 @@
> +struct usb_phy_roothub;
> +
> +struct usb_phy_roothub *usb_phy_roothub_init(struct device *dev);
> +int usb_phy_roothub_exit(struct usb_phy_roothub *phy_roothub);
> +
> +int usb_phy_roothub_power_on(struct usb_phy_roothub *phy_roothub);
> +void usb_phy_roothub_power_off(struct usb_phy_roothub *phy_roothub);
Tested-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Acked-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v7 usb-next 3/4] usb: core: hcd: integrate the PHY roothub wrapper
2017-10-23 21:57 ` Martin Blumenstingl
@ 2017-10-23 21:57 ` Martin Blumenstingl
-1 siblings, 0 replies; 34+ messages in thread
From: Martin Blumenstingl @ 2017-10-23 21:57 UTC (permalink / raw)
To: linux-usb-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
felipe.balbi-VuQAYsv1563Yd54FQh9/CA,
mathias.nyman-ral2JQCrhuEAvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4
Cc: mark.rutland-5wv7dgnIgG8,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz, Martin Blumenstingl
This integrates the PHY roothub wrapper into the core hcd
infrastructure. Multiple PHYs which are part of the roothub devicetree
node (which is a sub-node of the sysdev's node) are now managed
(= powered on/off when needed), by the new usb_phy_roothub code.
One example where this is required is the Amlogic GXL and GXM SoCs:
They are using a dwc3 USB controller with up to three ports enabled on
the internal roothub. Using only the top-level "phy" properties does not
work here since one can only specify one "usb2-phy" and one "usb3-phy",
while actually at least two "usb2-phy" have to be specified.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Tested-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Acked-by: Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org>
---
drivers/usb/core/hcd.c | 26 ++++++++++++++++++++++++++
include/linux/usb/hcd.h | 1 +
2 files changed, 27 insertions(+)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 67aa3d039b9b..6ee97222cdad 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -50,6 +50,7 @@
#include <linux/usb/otg.h>
#include "usb.h"
+#include "phy.h"
/*-------------------------------------------------------------------------*/
@@ -2271,6 +2272,8 @@ int hcd_bus_suspend(struct usb_device *rhdev, pm_message_t msg)
usb_set_device_state(rhdev, USB_STATE_SUSPENDED);
hcd->state = HC_STATE_SUSPENDED;
+ usb_phy_roothub_power_off(hcd->phy_roothub);
+
/* Did we race with a root-hub wakeup event? */
if (rhdev->do_remote_wakeup) {
char buffer[6];
@@ -2307,6 +2310,11 @@ int hcd_bus_resume(struct usb_device *rhdev, pm_message_t msg)
dev_dbg(&rhdev->dev, "skipped %s of dead bus\n", "resume");
return 0;
}
+
+ status = usb_phy_roothub_power_on(hcd->phy_roothub);
+ if (status)
+ return status;
+
if (!hcd->driver->bus_resume)
return -ENOENT;
if (HCD_RH_RUNNING(hcd))
@@ -2344,6 +2352,7 @@ int hcd_bus_resume(struct usb_device *rhdev, pm_message_t msg)
}
} else {
hcd->state = old_state;
+ usb_phy_roothub_power_off(hcd->phy_roothub);
dev_dbg(&rhdev->dev, "bus %s fail, err %d\n",
"resume", status);
if (status != -ESHUTDOWN)
@@ -2780,6 +2789,16 @@ int usb_add_hcd(struct usb_hcd *hcd,
}
}
+ hcd->phy_roothub = usb_phy_roothub_init(hcd->self.sysdev);
+ if (IS_ERR(hcd->phy_roothub)) {
+ retval = PTR_ERR(hcd->phy_roothub);
+ goto err_phy_roothub_init;
+ }
+
+ retval = usb_phy_roothub_power_on(hcd->phy_roothub);
+ if (retval)
+ goto err_usb_phy_roothub_power_on;
+
dev_info(hcd->self.controller, "%s\n", hcd->product_desc);
/* Keep old behaviour if authorized_default is not in [0, 1]. */
@@ -2944,6 +2963,10 @@ int usb_add_hcd(struct usb_hcd *hcd,
err_register_bus:
hcd_buffer_destroy(hcd);
err_create_buf:
+ usb_phy_roothub_power_off(hcd->phy_roothub);
+err_usb_phy_roothub_power_on:
+ usb_phy_roothub_exit(hcd->phy_roothub);
+err_phy_roothub_init:
if (IS_ENABLED(CONFIG_GENERIC_PHY) && hcd->remove_phy && hcd->phy) {
phy_power_off(hcd->phy);
phy_exit(hcd->phy);
@@ -3028,6 +3051,9 @@ void usb_remove_hcd(struct usb_hcd *hcd)
usb_deregister_bus(&hcd->self);
hcd_buffer_destroy(hcd);
+ usb_phy_roothub_power_off(hcd->phy_roothub);
+ usb_phy_roothub_exit(hcd->phy_roothub);
+
if (IS_ENABLED(CONFIG_GENERIC_PHY) && hcd->remove_phy && hcd->phy) {
phy_power_off(hcd->phy);
phy_exit(hcd->phy);
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index a1f03ebfde47..6915b2afc209 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -103,6 +103,7 @@ struct usb_hcd {
*/
struct usb_phy *usb_phy;
struct phy *phy;
+ struct usb_phy_roothub *phy_roothub;
/* Flags that need to be manipulated atomically because they can
* change while the host controller is running. Always use
--
2.14.2
--
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
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v7 usb-next 3/4] usb: core: hcd: integrate the PHY roothub wrapper
@ 2017-10-23 21:57 ` Martin Blumenstingl
0 siblings, 0 replies; 34+ messages in thread
From: Martin Blumenstingl @ 2017-10-23 21:57 UTC (permalink / raw)
To: linus-amlogic
This integrates the PHY roothub wrapper into the core hcd
infrastructure. Multiple PHYs which are part of the roothub devicetree
node (which is a sub-node of the sysdev's node) are now managed
(= powered on/off when needed), by the new usb_phy_roothub code.
One example where this is required is the Amlogic GXL and GXM SoCs:
They are using a dwc3 USB controller with up to three ports enabled on
the internal roothub. Using only the top-level "phy" properties does not
work here since one can only specify one "usb2-phy" and one "usb3-phy",
while actually at least two "usb2-phy" have to be specified.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Tested-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
---
drivers/usb/core/hcd.c | 26 ++++++++++++++++++++++++++
include/linux/usb/hcd.h | 1 +
2 files changed, 27 insertions(+)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 67aa3d039b9b..6ee97222cdad 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -50,6 +50,7 @@
#include <linux/usb/otg.h>
#include "usb.h"
+#include "phy.h"
/*-------------------------------------------------------------------------*/
@@ -2271,6 +2272,8 @@ int hcd_bus_suspend(struct usb_device *rhdev, pm_message_t msg)
usb_set_device_state(rhdev, USB_STATE_SUSPENDED);
hcd->state = HC_STATE_SUSPENDED;
+ usb_phy_roothub_power_off(hcd->phy_roothub);
+
/* Did we race with a root-hub wakeup event? */
if (rhdev->do_remote_wakeup) {
char buffer[6];
@@ -2307,6 +2310,11 @@ int hcd_bus_resume(struct usb_device *rhdev, pm_message_t msg)
dev_dbg(&rhdev->dev, "skipped %s of dead bus\n", "resume");
return 0;
}
+
+ status = usb_phy_roothub_power_on(hcd->phy_roothub);
+ if (status)
+ return status;
+
if (!hcd->driver->bus_resume)
return -ENOENT;
if (HCD_RH_RUNNING(hcd))
@@ -2344,6 +2352,7 @@ int hcd_bus_resume(struct usb_device *rhdev, pm_message_t msg)
}
} else {
hcd->state = old_state;
+ usb_phy_roothub_power_off(hcd->phy_roothub);
dev_dbg(&rhdev->dev, "bus %s fail, err %d\n",
"resume", status);
if (status != -ESHUTDOWN)
@@ -2780,6 +2789,16 @@ int usb_add_hcd(struct usb_hcd *hcd,
}
}
+ hcd->phy_roothub = usb_phy_roothub_init(hcd->self.sysdev);
+ if (IS_ERR(hcd->phy_roothub)) {
+ retval = PTR_ERR(hcd->phy_roothub);
+ goto err_phy_roothub_init;
+ }
+
+ retval = usb_phy_roothub_power_on(hcd->phy_roothub);
+ if (retval)
+ goto err_usb_phy_roothub_power_on;
+
dev_info(hcd->self.controller, "%s\n", hcd->product_desc);
/* Keep old behaviour if authorized_default is not in [0, 1]. */
@@ -2944,6 +2963,10 @@ int usb_add_hcd(struct usb_hcd *hcd,
err_register_bus:
hcd_buffer_destroy(hcd);
err_create_buf:
+ usb_phy_roothub_power_off(hcd->phy_roothub);
+err_usb_phy_roothub_power_on:
+ usb_phy_roothub_exit(hcd->phy_roothub);
+err_phy_roothub_init:
if (IS_ENABLED(CONFIG_GENERIC_PHY) && hcd->remove_phy && hcd->phy) {
phy_power_off(hcd->phy);
phy_exit(hcd->phy);
@@ -3028,6 +3051,9 @@ void usb_remove_hcd(struct usb_hcd *hcd)
usb_deregister_bus(&hcd->self);
hcd_buffer_destroy(hcd);
+ usb_phy_roothub_power_off(hcd->phy_roothub);
+ usb_phy_roothub_exit(hcd->phy_roothub);
+
if (IS_ENABLED(CONFIG_GENERIC_PHY) && hcd->remove_phy && hcd->phy) {
phy_power_off(hcd->phy);
phy_exit(hcd->phy);
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index a1f03ebfde47..6915b2afc209 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -103,6 +103,7 @@ struct usb_hcd {
*/
struct usb_phy *usb_phy;
struct phy *phy;
+ struct usb_phy_roothub *phy_roothub;
/* Flags that need to be manipulated atomically because they can
* change while the host controller is running. Always use
--
2.14.2
^ permalink raw reply related [flat|nested] 34+ messages in thread
[parent not found: <20171023215718.3446-4-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v7 usb-next 3/4] usb: core: hcd: integrate the PHY roothub wrapper
2017-10-23 21:57 ` Martin Blumenstingl
@ 2017-10-24 0:07 ` Chunfeng Yun
-1 siblings, 0 replies; 34+ messages in thread
From: Chunfeng Yun @ 2017-10-24 0:07 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
felipe.balbi-VuQAYsv1563Yd54FQh9/CA,
mathias.nyman-ral2JQCrhuEAvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4,
mark.rutland-5wv7dgnIgG8,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz
On Mon, 2017-10-23 at 23:57 +0200, Martin Blumenstingl wrote:
> This integrates the PHY roothub wrapper into the core hcd
> infrastructure. Multiple PHYs which are part of the roothub devicetree
> node (which is a sub-node of the sysdev's node) are now managed
> (= powered on/off when needed), by the new usb_phy_roothub code.
>
> One example where this is required is the Amlogic GXL and GXM SoCs:
> They are using a dwc3 USB controller with up to three ports enabled on
> the internal roothub. Using only the top-level "phy" properties does not
> work here since one can only specify one "usb2-phy" and one "usb3-phy",
> while actually at least two "usb2-phy" have to be specified.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> Tested-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> Acked-by: Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org>
> ---
> drivers/usb/core/hcd.c | 26 ++++++++++++++++++++++++++
> include/linux/usb/hcd.h | 1 +
> 2 files changed, 27 insertions(+)
>
> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
> index 67aa3d039b9b..6ee97222cdad 100644
> --- a/drivers/usb/core/hcd.c
> +++ b/drivers/usb/core/hcd.c
> @@ -50,6 +50,7 @@
> #include <linux/usb/otg.h>
>
> #include "usb.h"
> +#include "phy.h"
>
>
> /*-------------------------------------------------------------------------*/
> @@ -2271,6 +2272,8 @@ int hcd_bus_suspend(struct usb_device *rhdev, pm_message_t msg)
> usb_set_device_state(rhdev, USB_STATE_SUSPENDED);
> hcd->state = HC_STATE_SUSPENDED;
>
> + usb_phy_roothub_power_off(hcd->phy_roothub);
> +
> /* Did we race with a root-hub wakeup event? */
> if (rhdev->do_remote_wakeup) {
> char buffer[6];
> @@ -2307,6 +2310,11 @@ int hcd_bus_resume(struct usb_device *rhdev, pm_message_t msg)
> dev_dbg(&rhdev->dev, "skipped %s of dead bus\n", "resume");
> return 0;
> }
> +
> + status = usb_phy_roothub_power_on(hcd->phy_roothub);
> + if (status)
> + return status;
> +
> if (!hcd->driver->bus_resume)
> return -ENOENT;
> if (HCD_RH_RUNNING(hcd))
> @@ -2344,6 +2352,7 @@ int hcd_bus_resume(struct usb_device *rhdev, pm_message_t msg)
> }
> } else {
> hcd->state = old_state;
> + usb_phy_roothub_power_off(hcd->phy_roothub);
> dev_dbg(&rhdev->dev, "bus %s fail, err %d\n",
> "resume", status);
> if (status != -ESHUTDOWN)
> @@ -2780,6 +2789,16 @@ int usb_add_hcd(struct usb_hcd *hcd,
> }
> }
>
> + hcd->phy_roothub = usb_phy_roothub_init(hcd->self.sysdev);
> + if (IS_ERR(hcd->phy_roothub)) {
> + retval = PTR_ERR(hcd->phy_roothub);
> + goto err_phy_roothub_init;
> + }
> +
> + retval = usb_phy_roothub_power_on(hcd->phy_roothub);
> + if (retval)
> + goto err_usb_phy_roothub_power_on;
> +
> dev_info(hcd->self.controller, "%s\n", hcd->product_desc);
>
> /* Keep old behaviour if authorized_default is not in [0, 1]. */
> @@ -2944,6 +2963,10 @@ int usb_add_hcd(struct usb_hcd *hcd,
> err_register_bus:
> hcd_buffer_destroy(hcd);
> err_create_buf:
> + usb_phy_roothub_power_off(hcd->phy_roothub);
> +err_usb_phy_roothub_power_on:
> + usb_phy_roothub_exit(hcd->phy_roothub);
> +err_phy_roothub_init:
> if (IS_ENABLED(CONFIG_GENERIC_PHY) && hcd->remove_phy && hcd->phy) {
> phy_power_off(hcd->phy);
> phy_exit(hcd->phy);
> @@ -3028,6 +3051,9 @@ void usb_remove_hcd(struct usb_hcd *hcd)
> usb_deregister_bus(&hcd->self);
> hcd_buffer_destroy(hcd);
>
> + usb_phy_roothub_power_off(hcd->phy_roothub);
> + usb_phy_roothub_exit(hcd->phy_roothub);
> +
> if (IS_ENABLED(CONFIG_GENERIC_PHY) && hcd->remove_phy && hcd->phy) {
> phy_power_off(hcd->phy);
> phy_exit(hcd->phy);
> diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
> index a1f03ebfde47..6915b2afc209 100644
> --- a/include/linux/usb/hcd.h
> +++ b/include/linux/usb/hcd.h
> @@ -103,6 +103,7 @@ struct usb_hcd {
> */
> struct usb_phy *usb_phy;
> struct phy *phy;
> + struct usb_phy_roothub *phy_roothub;
>
> /* Flags that need to be manipulated atomically because they can
> * change while the host controller is running. Always use
Tested-by: Chunfeng Yun <chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Acked-by: Chunfeng Yun <chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
--
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v7 usb-next 3/4] usb: core: hcd: integrate the PHY roothub wrapper
@ 2017-10-24 0:07 ` Chunfeng Yun
0 siblings, 0 replies; 34+ messages in thread
From: Chunfeng Yun @ 2017-10-24 0:07 UTC (permalink / raw)
To: linus-amlogic
On Mon, 2017-10-23 at 23:57 +0200, Martin Blumenstingl wrote:
> This integrates the PHY roothub wrapper into the core hcd
> infrastructure. Multiple PHYs which are part of the roothub devicetree
> node (which is a sub-node of the sysdev's node) are now managed
> (= powered on/off when needed), by the new usb_phy_roothub code.
>
> One example where this is required is the Amlogic GXL and GXM SoCs:
> They are using a dwc3 USB controller with up to three ports enabled on
> the internal roothub. Using only the top-level "phy" properties does not
> work here since one can only specify one "usb2-phy" and one "usb3-phy",
> while actually at least two "usb2-phy" have to be specified.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> Tested-by: Neil Armstrong <narmstrong@baylibre.com>
> Acked-by: Alan Stern <stern@rowland.harvard.edu>
> ---
> drivers/usb/core/hcd.c | 26 ++++++++++++++++++++++++++
> include/linux/usb/hcd.h | 1 +
> 2 files changed, 27 insertions(+)
>
> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
> index 67aa3d039b9b..6ee97222cdad 100644
> --- a/drivers/usb/core/hcd.c
> +++ b/drivers/usb/core/hcd.c
> @@ -50,6 +50,7 @@
> #include <linux/usb/otg.h>
>
> #include "usb.h"
> +#include "phy.h"
>
>
> /*-------------------------------------------------------------------------*/
> @@ -2271,6 +2272,8 @@ int hcd_bus_suspend(struct usb_device *rhdev, pm_message_t msg)
> usb_set_device_state(rhdev, USB_STATE_SUSPENDED);
> hcd->state = HC_STATE_SUSPENDED;
>
> + usb_phy_roothub_power_off(hcd->phy_roothub);
> +
> /* Did we race with a root-hub wakeup event? */
> if (rhdev->do_remote_wakeup) {
> char buffer[6];
> @@ -2307,6 +2310,11 @@ int hcd_bus_resume(struct usb_device *rhdev, pm_message_t msg)
> dev_dbg(&rhdev->dev, "skipped %s of dead bus\n", "resume");
> return 0;
> }
> +
> + status = usb_phy_roothub_power_on(hcd->phy_roothub);
> + if (status)
> + return status;
> +
> if (!hcd->driver->bus_resume)
> return -ENOENT;
> if (HCD_RH_RUNNING(hcd))
> @@ -2344,6 +2352,7 @@ int hcd_bus_resume(struct usb_device *rhdev, pm_message_t msg)
> }
> } else {
> hcd->state = old_state;
> + usb_phy_roothub_power_off(hcd->phy_roothub);
> dev_dbg(&rhdev->dev, "bus %s fail, err %d\n",
> "resume", status);
> if (status != -ESHUTDOWN)
> @@ -2780,6 +2789,16 @@ int usb_add_hcd(struct usb_hcd *hcd,
> }
> }
>
> + hcd->phy_roothub = usb_phy_roothub_init(hcd->self.sysdev);
> + if (IS_ERR(hcd->phy_roothub)) {
> + retval = PTR_ERR(hcd->phy_roothub);
> + goto err_phy_roothub_init;
> + }
> +
> + retval = usb_phy_roothub_power_on(hcd->phy_roothub);
> + if (retval)
> + goto err_usb_phy_roothub_power_on;
> +
> dev_info(hcd->self.controller, "%s\n", hcd->product_desc);
>
> /* Keep old behaviour if authorized_default is not in [0, 1]. */
> @@ -2944,6 +2963,10 @@ int usb_add_hcd(struct usb_hcd *hcd,
> err_register_bus:
> hcd_buffer_destroy(hcd);
> err_create_buf:
> + usb_phy_roothub_power_off(hcd->phy_roothub);
> +err_usb_phy_roothub_power_on:
> + usb_phy_roothub_exit(hcd->phy_roothub);
> +err_phy_roothub_init:
> if (IS_ENABLED(CONFIG_GENERIC_PHY) && hcd->remove_phy && hcd->phy) {
> phy_power_off(hcd->phy);
> phy_exit(hcd->phy);
> @@ -3028,6 +3051,9 @@ void usb_remove_hcd(struct usb_hcd *hcd)
> usb_deregister_bus(&hcd->self);
> hcd_buffer_destroy(hcd);
>
> + usb_phy_roothub_power_off(hcd->phy_roothub);
> + usb_phy_roothub_exit(hcd->phy_roothub);
> +
> if (IS_ENABLED(CONFIG_GENERIC_PHY) && hcd->remove_phy && hcd->phy) {
> phy_power_off(hcd->phy);
> phy_exit(hcd->phy);
> diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
> index a1f03ebfde47..6915b2afc209 100644
> --- a/include/linux/usb/hcd.h
> +++ b/include/linux/usb/hcd.h
> @@ -103,6 +103,7 @@ struct usb_hcd {
> */
> struct usb_phy *usb_phy;
> struct phy *phy;
> + struct usb_phy_roothub *phy_roothub;
>
> /* Flags that need to be manipulated atomically because they can
> * change while the host controller is running. Always use
Tested-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Acked-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v7 usb-next 3/4] usb: core: hcd: integrate the PHY roothub wrapper
2017-10-23 21:57 ` Martin Blumenstingl
@ 2017-10-26 5:42 ` Manu Gautam
-1 siblings, 0 replies; 34+ messages in thread
From: Manu Gautam @ 2017-10-26 5:42 UTC (permalink / raw)
To: Martin Blumenstingl, linux-usb-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
felipe.balbi-VuQAYsv1563Yd54FQh9/CA,
mathias.nyman-ral2JQCrhuEAvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4
Cc: mark.rutland-5wv7dgnIgG8,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz
Hi,
On 10/24/2017 3:27 AM, Martin Blumenstingl wrote:
> This integrates the PHY roothub wrapper into the core hcd
> infrastructure. Multiple PHYs which are part of the roothub devicetree
> node (which is a sub-node of the sysdev's node) are now managed
> (= powered on/off when needed), by the new usb_phy_roothub code.
>
> One example where this is required is the Amlogic GXL and GXM SoCs:
> They are using a dwc3 USB controller with up to three ports enabled on
> the internal roothub. Using only the top-level "phy" properties does not
> work here since one can only specify one "usb2-phy" and one "usb3-phy",
> while actually at least two "usb2-phy" have to be specified.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> Tested-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> Acked-by: Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org>
> ---
> drivers/usb/core/hcd.c | 26 ++++++++++++++++++++++++++
> include/linux/usb/hcd.h | 1 +
> 2 files changed, 27 insertions(+)
>
> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
> index 67aa3d039b9b..6ee97222cdad 100644
> --- a/drivers/usb/core/hcd.c
> +++ b/drivers/usb/core/hcd.c
> @@ -50,6 +50,7 @@
> #include <linux/usb/otg.h>
>
> #include "usb.h"
> +#include "phy.h"
>
>
> /*-------------------------------------------------------------------------*/
> @@ -2271,6 +2272,8 @@ int hcd_bus_suspend(struct usb_device *rhdev, pm_message_t msg)
> usb_set_device_state(rhdev, USB_STATE_SUSPENDED);
> hcd->state = HC_STATE_SUSPENDED;
>
> + usb_phy_roothub_power_off(hcd->phy_roothub);
> +
For system-suspend it should be ok.
But, in case of runtime/auto suspend, I think PHYs shouldn't be powered off.
Should we have check for that like-
if (!PMSG_IS_AUTO(msg))
usb_phy_roothub_power_off()
Similar check in hcd_bus_resume?
> /* Did we race with a root-hub wakeup event? */
> if (rhdev->do_remote_wakeup) {
> char buffer[6];
> @@ -2307,6 +2310,11 @@ int hcd_bus_resume(struct usb_device *rhdev, pm_message_t msg)
> dev_dbg(&rhdev->dev, "skipped %s of dead bus\n", "resume");
> return 0;
> }
> +
> + status = usb_phy_roothub_power_on(hcd->phy_roothub);
> + if (status)
> + return status;
> +
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v7 usb-next 3/4] usb: core: hcd: integrate the PHY roothub wrapper
@ 2017-10-26 5:42 ` Manu Gautam
0 siblings, 0 replies; 34+ messages in thread
From: Manu Gautam @ 2017-10-26 5:42 UTC (permalink / raw)
To: linus-amlogic
Hi,
On 10/24/2017 3:27 AM, Martin Blumenstingl wrote:
> This integrates the PHY roothub wrapper into the core hcd
> infrastructure. Multiple PHYs which are part of the roothub devicetree
> node (which is a sub-node of the sysdev's node) are now managed
> (= powered on/off when needed), by the new usb_phy_roothub code.
>
> One example where this is required is the Amlogic GXL and GXM SoCs:
> They are using a dwc3 USB controller with up to three ports enabled on
> the internal roothub. Using only the top-level "phy" properties does not
> work here since one can only specify one "usb2-phy" and one "usb3-phy",
> while actually at least two "usb2-phy" have to be specified.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> Tested-by: Neil Armstrong <narmstrong@baylibre.com>
> Acked-by: Alan Stern <stern@rowland.harvard.edu>
> ---
> drivers/usb/core/hcd.c | 26 ++++++++++++++++++++++++++
> include/linux/usb/hcd.h | 1 +
> 2 files changed, 27 insertions(+)
>
> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
> index 67aa3d039b9b..6ee97222cdad 100644
> --- a/drivers/usb/core/hcd.c
> +++ b/drivers/usb/core/hcd.c
> @@ -50,6 +50,7 @@
> #include <linux/usb/otg.h>
>
> #include "usb.h"
> +#include "phy.h"
>
>
> /*-------------------------------------------------------------------------*/
> @@ -2271,6 +2272,8 @@ int hcd_bus_suspend(struct usb_device *rhdev, pm_message_t msg)
> usb_set_device_state(rhdev, USB_STATE_SUSPENDED);
> hcd->state = HC_STATE_SUSPENDED;
>
> + usb_phy_roothub_power_off(hcd->phy_roothub);
> +
For system-suspend it should be ok.
But, in case of runtime/auto suspend, I think PHYs shouldn't be powered off.
Should we have check for that like-
if (!PMSG_IS_AUTO(msg))
??? usb_phy_roothub_power_off()
Similar check in hcd_bus_resume?
> /* Did we race with a root-hub wakeup event? */
> if (rhdev->do_remote_wakeup) {
> char buffer[6];
> @@ -2307,6 +2310,11 @@ int hcd_bus_resume(struct usb_device *rhdev, pm_message_t msg)
> dev_dbg(&rhdev->dev, "skipped %s of dead bus\n", "resume");
> return 0;
> }
> +
> + status = usb_phy_roothub_power_on(hcd->phy_roothub);
> + if (status)
> + return status;
> +
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 34+ messages in thread
[parent not found: <89fc89e9-4510-2283-aad4-59eacf5cf925-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>]
* Re: [PATCH v7 usb-next 3/4] usb: core: hcd: integrate the PHY roothub wrapper
2017-10-26 5:42 ` Manu Gautam
@ 2017-10-30 23:10 ` Martin Blumenstingl
-1 siblings, 0 replies; 34+ messages in thread
From: Martin Blumenstingl @ 2017-10-30 23:10 UTC (permalink / raw)
To: Manu Gautam
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
felipe.balbi-VuQAYsv1563Yd54FQh9/CA,
mathias.nyman-ral2JQCrhuEAvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4,
mark.rutland-5wv7dgnIgG8,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz
Hi Manu,
thank you for reviewing this!
On Thu, Oct 26, 2017 at 7:42 AM, Manu Gautam <mgautam-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
> Hi,
>
>
> On 10/24/2017 3:27 AM, Martin Blumenstingl wrote:
>> This integrates the PHY roothub wrapper into the core hcd
>> infrastructure. Multiple PHYs which are part of the roothub devicetree
>> node (which is a sub-node of the sysdev's node) are now managed
>> (= powered on/off when needed), by the new usb_phy_roothub code.
>>
>> One example where this is required is the Amlogic GXL and GXM SoCs:
>> They are using a dwc3 USB controller with up to three ports enabled on
>> the internal roothub. Using only the top-level "phy" properties does not
>> work here since one can only specify one "usb2-phy" and one "usb3-phy",
>> while actually at least two "usb2-phy" have to be specified.
>>
>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
>> Tested-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>> Acked-by: Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org>
>> ---
>> drivers/usb/core/hcd.c | 26 ++++++++++++++++++++++++++
>> include/linux/usb/hcd.h | 1 +
>> 2 files changed, 27 insertions(+)
>>
>> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
>> index 67aa3d039b9b..6ee97222cdad 100644
>> --- a/drivers/usb/core/hcd.c
>> +++ b/drivers/usb/core/hcd.c
>> @@ -50,6 +50,7 @@
>> #include <linux/usb/otg.h>
>>
>> #include "usb.h"
>> +#include "phy.h"
>>
>>
>> /*-------------------------------------------------------------------------*/
>> @@ -2271,6 +2272,8 @@ int hcd_bus_suspend(struct usb_device *rhdev, pm_message_t msg)
>> usb_set_device_state(rhdev, USB_STATE_SUSPENDED);
>> hcd->state = HC_STATE_SUSPENDED;
>>
>> + usb_phy_roothub_power_off(hcd->phy_roothub);
>> +
>
> For system-suspend it should be ok.
> But, in case of runtime/auto suspend, I think PHYs shouldn't be powered off.
> Should we have check for that like-
>
> if (!PMSG_IS_AUTO(msg))
> usb_phy_roothub_power_off()
>
> Similar check in hcd_bus_resume?
disclaimer: I must admit that I am not very familiar with the PM code
and even worse: the platform I'm developing with does not have suspend support
can I take your suggestion and include it in the next version of this
series or should we wait for feedback from another developer on this
topic?
>
>> /* Did we race with a root-hub wakeup event? */
>> if (rhdev->do_remote_wakeup) {
>> char buffer[6];
>> @@ -2307,6 +2310,11 @@ int hcd_bus_resume(struct usb_device *rhdev, pm_message_t msg)
>> dev_dbg(&rhdev->dev, "skipped %s of dead bus\n", "resume");
>> return 0;
>> }
>> +
>> + status = usb_phy_roothub_power_on(hcd->phy_roothub);
>> + if (status)
>> + return status;
>> +
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
Regards
Martin
--
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v7 usb-next 3/4] usb: core: hcd: integrate the PHY roothub wrapper
@ 2017-10-30 23:10 ` Martin Blumenstingl
0 siblings, 0 replies; 34+ messages in thread
From: Martin Blumenstingl @ 2017-10-30 23:10 UTC (permalink / raw)
To: linus-amlogic
Hi Manu,
thank you for reviewing this!
On Thu, Oct 26, 2017 at 7:42 AM, Manu Gautam <mgautam@codeaurora.org> wrote:
> Hi,
>
>
> On 10/24/2017 3:27 AM, Martin Blumenstingl wrote:
>> This integrates the PHY roothub wrapper into the core hcd
>> infrastructure. Multiple PHYs which are part of the roothub devicetree
>> node (which is a sub-node of the sysdev's node) are now managed
>> (= powered on/off when needed), by the new usb_phy_roothub code.
>>
>> One example where this is required is the Amlogic GXL and GXM SoCs:
>> They are using a dwc3 USB controller with up to three ports enabled on
>> the internal roothub. Using only the top-level "phy" properties does not
>> work here since one can only specify one "usb2-phy" and one "usb3-phy",
>> while actually at least two "usb2-phy" have to be specified.
>>
>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>> Tested-by: Neil Armstrong <narmstrong@baylibre.com>
>> Acked-by: Alan Stern <stern@rowland.harvard.edu>
>> ---
>> drivers/usb/core/hcd.c | 26 ++++++++++++++++++++++++++
>> include/linux/usb/hcd.h | 1 +
>> 2 files changed, 27 insertions(+)
>>
>> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
>> index 67aa3d039b9b..6ee97222cdad 100644
>> --- a/drivers/usb/core/hcd.c
>> +++ b/drivers/usb/core/hcd.c
>> @@ -50,6 +50,7 @@
>> #include <linux/usb/otg.h>
>>
>> #include "usb.h"
>> +#include "phy.h"
>>
>>
>> /*-------------------------------------------------------------------------*/
>> @@ -2271,6 +2272,8 @@ int hcd_bus_suspend(struct usb_device *rhdev, pm_message_t msg)
>> usb_set_device_state(rhdev, USB_STATE_SUSPENDED);
>> hcd->state = HC_STATE_SUSPENDED;
>>
>> + usb_phy_roothub_power_off(hcd->phy_roothub);
>> +
>
> For system-suspend it should be ok.
> But, in case of runtime/auto suspend, I think PHYs shouldn't be powered off.
> Should we have check for that like-
>
> if (!PMSG_IS_AUTO(msg))
> usb_phy_roothub_power_off()
>
> Similar check in hcd_bus_resume?
disclaimer: I must admit that I am not very familiar with the PM code
and even worse: the platform I'm developing with does not have suspend support
can I take your suggestion and include it in the next version of this
series or should we wait for feedback from another developer on this
topic?
>
>> /* Did we race with a root-hub wakeup event? */
>> if (rhdev->do_remote_wakeup) {
>> char buffer[6];
>> @@ -2307,6 +2310,11 @@ int hcd_bus_resume(struct usb_device *rhdev, pm_message_t msg)
>> dev_dbg(&rhdev->dev, "skipped %s of dead bus\n", "resume");
>> return 0;
>> }
>> +
>> + status = usb_phy_roothub_power_on(hcd->phy_roothub);
>> + if (status)
>> + return status;
>> +
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
Regards
Martin
^ permalink raw reply [flat|nested] 34+ messages in thread
[parent not found: <CAFBinCD0kMkoWT4veoH8ZM7Rj2XwdvuE+tr7mM4n0J86eaOL-Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v7 usb-next 3/4] usb: core: hcd: integrate the PHY roothub wrapper
2017-10-30 23:10 ` Martin Blumenstingl
@ 2017-10-31 11:30 ` Chunfeng Yun
-1 siblings, 0 replies; 34+ messages in thread
From: Chunfeng Yun @ 2017-10-31 11:30 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: Manu Gautam, linux-usb-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
felipe.balbi-VuQAYsv1563Yd54FQh9/CA,
mathias.nyman-ral2JQCrhuEAvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4,
mark.rutland-5wv7dgnIgG8,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz
Hi Martin,
On Tue, 2017-10-31 at 00:10 +0100, Martin Blumenstingl wrote:
> Hi Manu,
>
> thank you for reviewing this!
>
> On Thu, Oct 26, 2017 at 7:42 AM, Manu Gautam <mgautam-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
> > Hi,
> >
> >
> > On 10/24/2017 3:27 AM, Martin Blumenstingl wrote:
> >> This integrates the PHY roothub wrapper into the core hcd
> >> infrastructure. Multiple PHYs which are part of the roothub devicetree
> >> node (which is a sub-node of the sysdev's node) are now managed
> >> (= powered on/off when needed), by the new usb_phy_roothub code.
> >>
> >> One example where this is required is the Amlogic GXL and GXM SoCs:
> >> They are using a dwc3 USB controller with up to three ports enabled on
> >> the internal roothub. Using only the top-level "phy" properties does not
> >> work here since one can only specify one "usb2-phy" and one "usb3-phy",
> >> while actually at least two "usb2-phy" have to be specified.
> >>
> >> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> >> Tested-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> >> Acked-by: Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org>
> >> ---
> >> drivers/usb/core/hcd.c | 26 ++++++++++++++++++++++++++
> >> include/linux/usb/hcd.h | 1 +
> >> 2 files changed, 27 insertions(+)
> >>
> >> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
> >> index 67aa3d039b9b..6ee97222cdad 100644
> >> --- a/drivers/usb/core/hcd.c
> >> +++ b/drivers/usb/core/hcd.c
> >> @@ -50,6 +50,7 @@
> >> #include <linux/usb/otg.h>
> >>
> >> #include "usb.h"
> >> +#include "phy.h"
> >>
> >>
> >> /*-------------------------------------------------------------------------*/
> >> @@ -2271,6 +2272,8 @@ int hcd_bus_suspend(struct usb_device *rhdev, pm_message_t msg)
> >> usb_set_device_state(rhdev, USB_STATE_SUSPENDED);
> >> hcd->state = HC_STATE_SUSPENDED;
> >>
> >> + usb_phy_roothub_power_off(hcd->phy_roothub);
> >> +
> >
> > For system-suspend it should be ok.
> > But, in case of runtime/auto suspend, I think PHYs shouldn't be powered off.
> > Should we have check for that like-
> >
> > if (!PMSG_IS_AUTO(msg))
> > usb_phy_roothub_power_off()
> >
I test it after adding "if (!PMSG_IS_AUTO(msg)) ...", the PHYS are not
powered off in the case of runtime/auto suspend (hcd-bus automatically
suspend if no devices are attached), but powered off when system enter
suspend mode by "echo mem > /sys/power/state" etc.
So the behavior is the same as the earlier version that the PHYs are
directly controlled by the host driver, maybe this is a better way for
backward compatibility.
> > Similar check in hcd_bus_resume?
> disclaimer: I must admit that I am not very familiar with the PM code
> and even worse: the platform I'm developing with does not have suspend support
>
> can I take your suggestion and include it in the next version of this
> series or should we wait for feedback from another developer on this
> topic?
>
> >
> >> /* Did we race with a root-hub wakeup event? */
> >> if (rhdev->do_remote_wakeup) {
> >> char buffer[6];
> >> @@ -2307,6 +2310,11 @@ int hcd_bus_resume(struct usb_device *rhdev, pm_message_t msg)
> >> dev_dbg(&rhdev->dev, "skipped %s of dead bus\n", "resume");
> >> return 0;
> >> }
> >> +
> >> + status = usb_phy_roothub_power_on(hcd->phy_roothub);
> >> + if (status)
> >> + return status;
> >> +
> >
> > --
> > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> > a Linux Foundation Collaborative Project
> >
>
>
> Regards
> Martin
--
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v7 usb-next 3/4] usb: core: hcd: integrate the PHY roothub wrapper
@ 2017-10-31 11:30 ` Chunfeng Yun
0 siblings, 0 replies; 34+ messages in thread
From: Chunfeng Yun @ 2017-10-31 11:30 UTC (permalink / raw)
To: linus-amlogic
Hi Martin,
On Tue, 2017-10-31 at 00:10 +0100, Martin Blumenstingl wrote:
> Hi Manu,
>
> thank you for reviewing this!
>
> On Thu, Oct 26, 2017 at 7:42 AM, Manu Gautam <mgautam@codeaurora.org> wrote:
> > Hi,
> >
> >
> > On 10/24/2017 3:27 AM, Martin Blumenstingl wrote:
> >> This integrates the PHY roothub wrapper into the core hcd
> >> infrastructure. Multiple PHYs which are part of the roothub devicetree
> >> node (which is a sub-node of the sysdev's node) are now managed
> >> (= powered on/off when needed), by the new usb_phy_roothub code.
> >>
> >> One example where this is required is the Amlogic GXL and GXM SoCs:
> >> They are using a dwc3 USB controller with up to three ports enabled on
> >> the internal roothub. Using only the top-level "phy" properties does not
> >> work here since one can only specify one "usb2-phy" and one "usb3-phy",
> >> while actually at least two "usb2-phy" have to be specified.
> >>
> >> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> >> Tested-by: Neil Armstrong <narmstrong@baylibre.com>
> >> Acked-by: Alan Stern <stern@rowland.harvard.edu>
> >> ---
> >> drivers/usb/core/hcd.c | 26 ++++++++++++++++++++++++++
> >> include/linux/usb/hcd.h | 1 +
> >> 2 files changed, 27 insertions(+)
> >>
> >> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
> >> index 67aa3d039b9b..6ee97222cdad 100644
> >> --- a/drivers/usb/core/hcd.c
> >> +++ b/drivers/usb/core/hcd.c
> >> @@ -50,6 +50,7 @@
> >> #include <linux/usb/otg.h>
> >>
> >> #include "usb.h"
> >> +#include "phy.h"
> >>
> >>
> >> /*-------------------------------------------------------------------------*/
> >> @@ -2271,6 +2272,8 @@ int hcd_bus_suspend(struct usb_device *rhdev, pm_message_t msg)
> >> usb_set_device_state(rhdev, USB_STATE_SUSPENDED);
> >> hcd->state = HC_STATE_SUSPENDED;
> >>
> >> + usb_phy_roothub_power_off(hcd->phy_roothub);
> >> +
> >
> > For system-suspend it should be ok.
> > But, in case of runtime/auto suspend, I think PHYs shouldn't be powered off.
> > Should we have check for that like-
> >
> > if (!PMSG_IS_AUTO(msg))
> > usb_phy_roothub_power_off()
> >
I test it after adding "if (!PMSG_IS_AUTO(msg)) ...", the PHYS are not
powered off in the case of runtime/auto suspend (hcd-bus automatically
suspend if no devices are attached), but powered off when system enter
suspend mode by "echo mem > /sys/power/state" etc.
So the behavior is the same as the earlier version that the PHYs are
directly controlled by the host driver, maybe this is a better way for
backward compatibility.
> > Similar check in hcd_bus_resume?
> disclaimer: I must admit that I am not very familiar with the PM code
> and even worse: the platform I'm developing with does not have suspend support
>
> can I take your suggestion and include it in the next version of this
> series or should we wait for feedback from another developer on this
> topic?
>
> >
> >> /* Did we race with a root-hub wakeup event? */
> >> if (rhdev->do_remote_wakeup) {
> >> char buffer[6];
> >> @@ -2307,6 +2310,11 @@ int hcd_bus_resume(struct usb_device *rhdev, pm_message_t msg)
> >> dev_dbg(&rhdev->dev, "skipped %s of dead bus\n", "resume");
> >> return 0;
> >> }
> >> +
> >> + status = usb_phy_roothub_power_on(hcd->phy_roothub);
> >> + if (status)
> >> + return status;
> >> +
> >
> > --
> > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> > a Linux Foundation Collaborative Project
> >
>
>
> Regards
> Martin
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v7 usb-next 4/4] dt-bindings: usb: xhci: include the roothub and a device in the example
2017-10-23 21:57 ` Martin Blumenstingl
@ 2017-10-23 21:57 ` Martin Blumenstingl
-1 siblings, 0 replies; 34+ messages in thread
From: Martin Blumenstingl @ 2017-10-23 21:57 UTC (permalink / raw)
To: linux-usb-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
felipe.balbi-VuQAYsv1563Yd54FQh9/CA,
mathias.nyman-ral2JQCrhuEAvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4
Cc: mark.rutland-5wv7dgnIgG8,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz, Martin Blumenstingl
This extends the existing example from the USB xHCI binding
documentation so it includes the roothub and an actual device.
The goal of this is to show that the roothub is specified alongside the
actual devices on the USB bus (which is important because a device on
the USB bus - for example a hub - might need it's own phys / phy-names
properties. modelling the roothub as separate device and not nesting the
other devices on the bus below the roothub allows us to keep the
properties, for example the PHYs, separated).
Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
---
Documentation/devicetree/bindings/usb/usb-xhci.txt | 23 ++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
index 5b49ba9f2f9a..20e5ce2b016a 100644
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -42,4 +42,27 @@ Example:
compatible = "generic-xhci";
reg = <0xf0931000 0x8c8>;
interrupts = <0x0 0x4e 0x0>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* see usb-roothub.txt */
+ roothub@0 {
+ compatible = "usb1d6b,3", "usb1d6b,2";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ port@1 {
+ reg = <1>;
+ phys = <&usb2_phy1>, <&usb3_phy1>;
+ phy-names = "usb2-phy", "usb3-phy";
+ };
+ };
+
+ /* see usb-device.txt */
+ hub: genesys@1 {
+ compatible = "usb5e3,608";
+ reg = <1>;
+ };
};
--
2.14.2
--
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
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v7 usb-next 4/4] dt-bindings: usb: xhci: include the roothub and a device in the example
@ 2017-10-23 21:57 ` Martin Blumenstingl
0 siblings, 0 replies; 34+ messages in thread
From: Martin Blumenstingl @ 2017-10-23 21:57 UTC (permalink / raw)
To: linus-amlogic
This extends the existing example from the USB xHCI binding
documentation so it includes the roothub and an actual device.
The goal of this is to show that the roothub is specified alongside the
actual devices on the USB bus (which is important because a device on
the USB bus - for example a hub - might need it's own phys / phy-names
properties. modelling the roothub as separate device and not nesting the
other devices on the bus below the roothub allows us to keep the
properties, for example the PHYs, separated).
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
Documentation/devicetree/bindings/usb/usb-xhci.txt | 23 ++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
index 5b49ba9f2f9a..20e5ce2b016a 100644
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -42,4 +42,27 @@ Example:
compatible = "generic-xhci";
reg = <0xf0931000 0x8c8>;
interrupts = <0x0 0x4e 0x0>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* see usb-roothub.txt */
+ roothub at 0 {
+ compatible = "usb1d6b,3", "usb1d6b,2";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ port at 1 {
+ reg = <1>;
+ phys = <&usb2_phy1>, <&usb3_phy1>;
+ phy-names = "usb2-phy", "usb3-phy";
+ };
+ };
+
+ /* see usb-device.txt */
+ hub: genesys at 1 {
+ compatible = "usb5e3,608";
+ reg = <1>;
+ };
};
--
2.14.2
^ permalink raw reply related [flat|nested] 34+ messages in thread
[parent not found: <20171023215718.3446-5-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v7 usb-next 4/4] dt-bindings: usb: xhci: include the roothub and a device in the example
2017-10-23 21:57 ` Martin Blumenstingl
@ 2017-10-27 3:29 ` Rob Herring
-1 siblings, 0 replies; 34+ messages in thread
From: Rob Herring @ 2017-10-27 3:29 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
felipe.balbi-VuQAYsv1563Yd54FQh9/CA,
mathias.nyman-ral2JQCrhuEAvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4,
mark.rutland-5wv7dgnIgG8,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz
On Mon, Oct 23, 2017 at 11:57:18PM +0200, Martin Blumenstingl wrote:
> This extends the existing example from the USB xHCI binding
> documentation so it includes the roothub and an actual device.
> The goal of this is to show that the roothub is specified alongside the
> actual devices on the USB bus (which is important because a device on
> the USB bus - for example a hub - might need it's own phys / phy-names
> properties. modelling the roothub as separate device and not nesting the
> other devices on the bus below the roothub allows us to keep the
> properties, for example the PHYs, separated).
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> ---
> Documentation/devicetree/bindings/usb/usb-xhci.txt | 23 ++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
> index 5b49ba9f2f9a..20e5ce2b016a 100644
> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
> @@ -42,4 +42,27 @@ Example:
> compatible = "generic-xhci";
> reg = <0xf0931000 0x8c8>;
> interrupts = <0x0 0x4e 0x0>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* see usb-roothub.txt */
> + roothub@0 {
> + compatible = "usb1d6b,3", "usb1d6b,2";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + port@1 {
> + reg = <1>;
> + phys = <&usb2_phy1>, <&usb3_phy1>;
> + phy-names = "usb2-phy", "usb3-phy";
> + };
> + };
> +
> + /* see usb-device.txt */
> + hub: genesys@1 {
What do the 0 and 1 addresses correspond to?
> + compatible = "usb5e3,608";
> + reg = <1>;
> + };
> };
> --
> 2.14.2
>
--
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v7 usb-next 4/4] dt-bindings: usb: xhci: include the roothub and a device in the example
@ 2017-10-27 3:29 ` Rob Herring
0 siblings, 0 replies; 34+ messages in thread
From: Rob Herring @ 2017-10-27 3:29 UTC (permalink / raw)
To: linus-amlogic
On Mon, Oct 23, 2017 at 11:57:18PM +0200, Martin Blumenstingl wrote:
> This extends the existing example from the USB xHCI binding
> documentation so it includes the roothub and an actual device.
> The goal of this is to show that the roothub is specified alongside the
> actual devices on the USB bus (which is important because a device on
> the USB bus - for example a hub - might need it's own phys / phy-names
> properties. modelling the roothub as separate device and not nesting the
> other devices on the bus below the roothub allows us to keep the
> properties, for example the PHYs, separated).
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> ---
> Documentation/devicetree/bindings/usb/usb-xhci.txt | 23 ++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
> index 5b49ba9f2f9a..20e5ce2b016a 100644
> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
> @@ -42,4 +42,27 @@ Example:
> compatible = "generic-xhci";
> reg = <0xf0931000 0x8c8>;
> interrupts = <0x0 0x4e 0x0>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* see usb-roothub.txt */
> + roothub at 0 {
> + compatible = "usb1d6b,3", "usb1d6b,2";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + port at 1 {
> + reg = <1>;
> + phys = <&usb2_phy1>, <&usb3_phy1>;
> + phy-names = "usb2-phy", "usb3-phy";
> + };
> + };
> +
> + /* see usb-device.txt */
> + hub: genesys at 1 {
What do the 0 and 1 addresses correspond to?
> + compatible = "usb5e3,608";
> + reg = <1>;
> + };
> };
> --
> 2.14.2
>
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v7 usb-next 4/4] dt-bindings: usb: xhci: include the roothub and a device in the example
2017-10-27 3:29 ` Rob Herring
@ 2017-10-27 19:20 ` Martin Blumenstingl
-1 siblings, 0 replies; 34+ messages in thread
From: Martin Blumenstingl @ 2017-10-27 19:20 UTC (permalink / raw)
To: Rob Herring
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
felipe.balbi-VuQAYsv1563Yd54FQh9/CA,
mathias.nyman-ral2JQCrhuEAvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4,
mark.rutland-5wv7dgnIgG8,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz
Hi Rob,
On Fri, Oct 27, 2017 at 5:29 AM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Mon, Oct 23, 2017 at 11:57:18PM +0200, Martin Blumenstingl wrote:
>> This extends the existing example from the USB xHCI binding
>> documentation so it includes the roothub and an actual device.
>> The goal of this is to show that the roothub is specified alongside the
>> actual devices on the USB bus (which is important because a device on
>> the USB bus - for example a hub - might need it's own phys / phy-names
>> properties. modelling the roothub as separate device and not nesting the
>> other devices on the bus below the roothub allows us to keep the
>> properties, for example the PHYs, separated).
>>
>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/usb/usb-xhci.txt | 23 ++++++++++++++++++++++
>> 1 file changed, 23 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>> index 5b49ba9f2f9a..20e5ce2b016a 100644
>> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
>> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>> @@ -42,4 +42,27 @@ Example:
>> compatible = "generic-xhci";
>> reg = <0xf0931000 0x8c8>;
>> interrupts = <0x0 0x4e 0x0>;
>> +
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + /* see usb-roothub.txt */
>> + roothub@0 {
>> + compatible = "usb1d6b,3", "usb1d6b,2";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <0>;
>> +
>> + port@1 {
>> + reg = <1>;
>> + phys = <&usb2_phy1>, <&usb3_phy1>;
>> + phy-names = "usb2-phy", "usb3-phy";
>> + };
>> + };
>> +
>> + /* see usb-device.txt */
>> + hub: genesys@1 {
>
> What do the 0 and 1 addresses correspond to?
0 is the address of the root-hub, 1 is the first device on the root-hub
based on my previous dt-binding patch Arnd assumed that the devices
would be moved in the hierarchy: [0]
however, my understanding is that (at least for now) the root-hub node
(identified by reg = <0>) is used to describe only the root-hub (which
allows initializing the PHYs), not the devices that are connected to
it
here's an example from my Khadas VIM (which matches the example from
my patch, except: a) it has a different USB hub connected at port 1 b)
it has two ports on the root-hub)
this is a stripped and commented version of "cat /sys/kernel/debug/usb/devices"
T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=5000 MxCh= 0
D: Ver= 3.00 Cls=09(hub ) Sub=00 Prot=03 MxPS= 9 #Cfgs= 1
P: Vendor=1d6b ProdID=0003 Rev= 3.14
-> (USB3 root-hub from a dwc3 controller) in the device-tree example
this belongs to &usb/roothub@0
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 2
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0002 Rev= 3.14
-> (USB2 root-hub from a dwc3 controller) in the device-tree example
this also belongs to &usb/roothub@0
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 4
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=1a40 ProdID=0801 Rev= 1.00
-> (USB2 hub soldered to the board, connected to root-hub port 1) in
the device-tree example this belongs to &usb/genesys@1
T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#= 3 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=090c ProdID=1000 Rev= 7.22
-> USB thumb drive connected to the USB hub, not listed in the
device-tree example but it would be listed below &usb/genesys@1
>> + compatible = "usb5e3,608";
>> + reg = <1>;
>> + };
>> };
>> --
>> 2.14.2
>>
Martin
[0] http://lists.infradead.org/pipermail/linux-amlogic/2017-October/005091.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
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v7 usb-next 4/4] dt-bindings: usb: xhci: include the roothub and a device in the example
@ 2017-10-27 19:20 ` Martin Blumenstingl
0 siblings, 0 replies; 34+ messages in thread
From: Martin Blumenstingl @ 2017-10-27 19:20 UTC (permalink / raw)
To: linus-amlogic
Hi Rob,
On Fri, Oct 27, 2017 at 5:29 AM, Rob Herring <robh@kernel.org> wrote:
> On Mon, Oct 23, 2017 at 11:57:18PM +0200, Martin Blumenstingl wrote:
>> This extends the existing example from the USB xHCI binding
>> documentation so it includes the roothub and an actual device.
>> The goal of this is to show that the roothub is specified alongside the
>> actual devices on the USB bus (which is important because a device on
>> the USB bus - for example a hub - might need it's own phys / phy-names
>> properties. modelling the roothub as separate device and not nesting the
>> other devices on the bus below the roothub allows us to keep the
>> properties, for example the PHYs, separated).
>>
>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>> ---
>> Documentation/devicetree/bindings/usb/usb-xhci.txt | 23 ++++++++++++++++++++++
>> 1 file changed, 23 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>> index 5b49ba9f2f9a..20e5ce2b016a 100644
>> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
>> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>> @@ -42,4 +42,27 @@ Example:
>> compatible = "generic-xhci";
>> reg = <0xf0931000 0x8c8>;
>> interrupts = <0x0 0x4e 0x0>;
>> +
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + /* see usb-roothub.txt */
>> + roothub at 0 {
>> + compatible = "usb1d6b,3", "usb1d6b,2";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <0>;
>> +
>> + port at 1 {
>> + reg = <1>;
>> + phys = <&usb2_phy1>, <&usb3_phy1>;
>> + phy-names = "usb2-phy", "usb3-phy";
>> + };
>> + };
>> +
>> + /* see usb-device.txt */
>> + hub: genesys at 1 {
>
> What do the 0 and 1 addresses correspond to?
0 is the address of the root-hub, 1 is the first device on the root-hub
based on my previous dt-binding patch Arnd assumed that the devices
would be moved in the hierarchy: [0]
however, my understanding is that (at least for now) the root-hub node
(identified by reg = <0>) is used to describe only the root-hub (which
allows initializing the PHYs), not the devices that are connected to
it
here's an example from my Khadas VIM (which matches the example from
my patch, except: a) it has a different USB hub connected at port 1 b)
it has two ports on the root-hub)
this is a stripped and commented version of "cat /sys/kernel/debug/usb/devices"
T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=5000 MxCh= 0
D: Ver= 3.00 Cls=09(hub ) Sub=00 Prot=03 MxPS= 9 #Cfgs= 1
P: Vendor=1d6b ProdID=0003 Rev= 3.14
-> (USB3 root-hub from a dwc3 controller) in the device-tree example
this belongs to &usb/roothub at 0
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 2
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0002 Rev= 3.14
-> (USB2 root-hub from a dwc3 controller) in the device-tree example
this also belongs to &usb/roothub at 0
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 4
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=1a40 ProdID=0801 Rev= 1.00
-> (USB2 hub soldered to the board, connected to root-hub port 1) in
the device-tree example this belongs to &usb/genesys at 1
T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#= 3 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=090c ProdID=1000 Rev= 7.22
-> USB thumb drive connected to the USB hub, not listed in the
device-tree example but it would be listed below &usb/genesys at 1
>> + compatible = "usb5e3,608";
>> + reg = <1>;
>> + };
>> };
>> --
>> 2.14.2
>>
Martin
[0] http://lists.infradead.org/pipermail/linux-amlogic/2017-October/005091.html
^ permalink raw reply [flat|nested] 34+ messages in thread
[parent not found: <CAFBinCALbByzAiAqTOzGj6XHASGwWX34xg7GKf=Fa6_eiCEnkA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v7 usb-next 4/4] dt-bindings: usb: xhci: include the roothub and a device in the example
2017-10-27 19:20 ` Martin Blumenstingl
@ 2017-10-27 19:55 ` Alan Stern
-1 siblings, 0 replies; 34+ messages in thread
From: Alan Stern @ 2017-10-27 19:55 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: Rob Herring, linux-usb-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
felipe.balbi-VuQAYsv1563Yd54FQh9/CA,
mathias.nyman-ral2JQCrhuEAvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4,
mark.rutland-5wv7dgnIgG8,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w
On Fri, 27 Oct 2017, Martin Blumenstingl wrote:
> Hi Rob,
>
> On Fri, Oct 27, 2017 at 5:29 AM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > On Mon, Oct 23, 2017 at 11:57:18PM +0200, Martin Blumenstingl wrote:
> >> This extends the existing example from the USB xHCI binding
> >> documentation so it includes the roothub and an actual device.
> >> The goal of this is to show that the roothub is specified alongside the
> >> actual devices on the USB bus (which is important because a device on
> >> the USB bus - for example a hub - might need it's own phys / phy-names
> >> properties. modelling the roothub as separate device and not nesting the
> >> other devices on the bus below the roothub allows us to keep the
> >> properties, for example the PHYs, separated).
> >>
> >> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> >> ---
> >> Documentation/devicetree/bindings/usb/usb-xhci.txt | 23 ++++++++++++++++++++++
> >> 1 file changed, 23 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
> >> index 5b49ba9f2f9a..20e5ce2b016a 100644
> >> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
> >> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
> >> @@ -42,4 +42,27 @@ Example:
> >> compatible = "generic-xhci";
> >> reg = <0xf0931000 0x8c8>;
> >> interrupts = <0x0 0x4e 0x0>;
> >> +
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> +
> >> + /* see usb-roothub.txt */
> >> + roothub@0 {
> >> + compatible = "usb1d6b,3", "usb1d6b,2";
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> + reg = <0>;
> >> +
> >> + port@1 {
> >> + reg = <1>;
> >> + phys = <&usb2_phy1>, <&usb3_phy1>;
> >> + phy-names = "usb2-phy", "usb3-phy";
> >> + };
> >> + };
> >> +
> >> + /* see usb-device.txt */
> >> + hub: genesys@1 {
> >
> > What do the 0 and 1 addresses correspond to?
> 0 is the address of the root-hub, 1 is the first device on the root-hub
> based on my previous dt-binding patch Arnd assumed that the devices
> would be moved in the hierarchy: [0]
> however, my understanding is that (at least for now) the root-hub node
> (identified by reg = <0>) is used to describe only the root-hub (which
> allows initializing the PHYs), not the devices that are connected to
> it
>
> here's an example from my Khadas VIM (which matches the example from
> my patch, except: a) it has a different USB hub connected at port 1 b)
> it has two ports on the root-hub)
> this is a stripped and commented version of "cat /sys/kernel/debug/usb/devices"
>
> T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=5000 MxCh= 0
> D: Ver= 3.00 Cls=09(hub ) Sub=00 Prot=03 MxPS= 9 #Cfgs= 1
> P: Vendor=1d6b ProdID=0003 Rev= 3.14
> -> (USB3 root-hub from a dwc3 controller) in the device-tree example
> this belongs to &usb/roothub@0
>
> T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 2
> D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=1d6b ProdID=0002 Rev= 3.14
> -> (USB2 root-hub from a dwc3 controller) in the device-tree example
> this also belongs to &usb/roothub@0
>
> T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 4
> D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=1a40 ProdID=0801 Rev= 1.00
> -> (USB2 hub soldered to the board, connected to root-hub port 1) in
> the device-tree example this belongs to &usb/genesys@1
>
> T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#= 3 Spd=480 MxCh= 0
> D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
> P: Vendor=090c ProdID=1000 Rev= 7.22
> -> USB thumb drive connected to the USB hub, not listed in the
> device-tree example but it would be listed below &usb/genesys@1
Two things to be aware of:
1. /sys/kernel/debug/usb/devices has an off-by-one error in the
"Port=" field. Every value you see should actually be one
higher than it is. It has been this way for many, many years
so we can't fix it now.
2. Port numbers are meaningless for root hubs, because root hubs
by definition are not connected to any upstream USB ports.
Alan Stern
--
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v7 usb-next 4/4] dt-bindings: usb: xhci: include the roothub and a device in the example
@ 2017-10-27 19:55 ` Alan Stern
0 siblings, 0 replies; 34+ messages in thread
From: Alan Stern @ 2017-10-27 19:55 UTC (permalink / raw)
To: linus-amlogic
On Fri, 27 Oct 2017, Martin Blumenstingl wrote:
> Hi Rob,
>
> On Fri, Oct 27, 2017 at 5:29 AM, Rob Herring <robh@kernel.org> wrote:
> > On Mon, Oct 23, 2017 at 11:57:18PM +0200, Martin Blumenstingl wrote:
> >> This extends the existing example from the USB xHCI binding
> >> documentation so it includes the roothub and an actual device.
> >> The goal of this is to show that the roothub is specified alongside the
> >> actual devices on the USB bus (which is important because a device on
> >> the USB bus - for example a hub - might need it's own phys / phy-names
> >> properties. modelling the roothub as separate device and not nesting the
> >> other devices on the bus below the roothub allows us to keep the
> >> properties, for example the PHYs, separated).
> >>
> >> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> >> ---
> >> Documentation/devicetree/bindings/usb/usb-xhci.txt | 23 ++++++++++++++++++++++
> >> 1 file changed, 23 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
> >> index 5b49ba9f2f9a..20e5ce2b016a 100644
> >> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
> >> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
> >> @@ -42,4 +42,27 @@ Example:
> >> compatible = "generic-xhci";
> >> reg = <0xf0931000 0x8c8>;
> >> interrupts = <0x0 0x4e 0x0>;
> >> +
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> +
> >> + /* see usb-roothub.txt */
> >> + roothub at 0 {
> >> + compatible = "usb1d6b,3", "usb1d6b,2";
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> + reg = <0>;
> >> +
> >> + port at 1 {
> >> + reg = <1>;
> >> + phys = <&usb2_phy1>, <&usb3_phy1>;
> >> + phy-names = "usb2-phy", "usb3-phy";
> >> + };
> >> + };
> >> +
> >> + /* see usb-device.txt */
> >> + hub: genesys at 1 {
> >
> > What do the 0 and 1 addresses correspond to?
> 0 is the address of the root-hub, 1 is the first device on the root-hub
> based on my previous dt-binding patch Arnd assumed that the devices
> would be moved in the hierarchy: [0]
> however, my understanding is that (at least for now) the root-hub node
> (identified by reg = <0>) is used to describe only the root-hub (which
> allows initializing the PHYs), not the devices that are connected to
> it
>
> here's an example from my Khadas VIM (which matches the example from
> my patch, except: a) it has a different USB hub connected at port 1 b)
> it has two ports on the root-hub)
> this is a stripped and commented version of "cat /sys/kernel/debug/usb/devices"
>
> T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=5000 MxCh= 0
> D: Ver= 3.00 Cls=09(hub ) Sub=00 Prot=03 MxPS= 9 #Cfgs= 1
> P: Vendor=1d6b ProdID=0003 Rev= 3.14
> -> (USB3 root-hub from a dwc3 controller) in the device-tree example
> this belongs to &usb/roothub at 0
>
> T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 2
> D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=1d6b ProdID=0002 Rev= 3.14
> -> (USB2 root-hub from a dwc3 controller) in the device-tree example
> this also belongs to &usb/roothub at 0
>
> T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 4
> D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=1a40 ProdID=0801 Rev= 1.00
> -> (USB2 hub soldered to the board, connected to root-hub port 1) in
> the device-tree example this belongs to &usb/genesys at 1
>
> T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#= 3 Spd=480 MxCh= 0
> D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
> P: Vendor=090c ProdID=1000 Rev= 7.22
> -> USB thumb drive connected to the USB hub, not listed in the
> device-tree example but it would be listed below &usb/genesys at 1
Two things to be aware of:
1. /sys/kernel/debug/usb/devices has an off-by-one error in the
"Port=" field. Every value you see should actually be one
higher than it is. It has been this way for many, many years
so we can't fix it now.
2. Port numbers are meaningless for root hubs, because root hubs
by definition are not connected to any upstream USB ports.
Alan Stern
^ permalink raw reply [flat|nested] 34+ messages in thread
[parent not found: <Pine.LNX.4.44L0.1710271550360.1355-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>]
* Re: [PATCH v7 usb-next 4/4] dt-bindings: usb: xhci: include the roothub and a device in the example
2017-10-27 19:55 ` Alan Stern
@ 2017-10-28 13:33 ` Martin Blumenstingl
-1 siblings, 0 replies; 34+ messages in thread
From: Martin Blumenstingl @ 2017-10-28 13:33 UTC (permalink / raw)
To: Alan Stern
Cc: Rob Herring, linux-usb-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
felipe.balbi-VuQAYsv1563Yd54FQh9/CA,
mathias.nyman-ral2JQCrhuEAvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4,
mark.rutland-5wv7dgnIgG8,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w
Hi Alan,
On Fri, Oct 27, 2017 at 9:55 PM, Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> wrote:
> On Fri, 27 Oct 2017, Martin Blumenstingl wrote:
>
>> Hi Rob,
>>
>> On Fri, Oct 27, 2017 at 5:29 AM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> > On Mon, Oct 23, 2017 at 11:57:18PM +0200, Martin Blumenstingl wrote:
>> >> This extends the existing example from the USB xHCI binding
>> >> documentation so it includes the roothub and an actual device.
>> >> The goal of this is to show that the roothub is specified alongside the
>> >> actual devices on the USB bus (which is important because a device on
>> >> the USB bus - for example a hub - might need it's own phys / phy-names
>> >> properties. modelling the roothub as separate device and not nesting the
>> >> other devices on the bus below the roothub allows us to keep the
>> >> properties, for example the PHYs, separated).
>> >>
>> >> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
>> >> ---
>> >> Documentation/devicetree/bindings/usb/usb-xhci.txt | 23 ++++++++++++++++++++++
>> >> 1 file changed, 23 insertions(+)
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>> >> index 5b49ba9f2f9a..20e5ce2b016a 100644
>> >> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
>> >> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>> >> @@ -42,4 +42,27 @@ Example:
>> >> compatible = "generic-xhci";
>> >> reg = <0xf0931000 0x8c8>;
>> >> interrupts = <0x0 0x4e 0x0>;
>> >> +
>> >> + #address-cells = <1>;
>> >> + #size-cells = <0>;
>> >> +
>> >> + /* see usb-roothub.txt */
>> >> + roothub@0 {
>> >> + compatible = "usb1d6b,3", "usb1d6b,2";
>> >> + #address-cells = <1>;
>> >> + #size-cells = <0>;
>> >> + reg = <0>;
>> >> +
>> >> + port@1 {
>> >> + reg = <1>;
>> >> + phys = <&usb2_phy1>, <&usb3_phy1>;
>> >> + phy-names = "usb2-phy", "usb3-phy";
>> >> + };
>> >> + };
>> >> +
>> >> + /* see usb-device.txt */
>> >> + hub: genesys@1 {
>> >
>> > What do the 0 and 1 addresses correspond to?
>> 0 is the address of the root-hub, 1 is the first device on the root-hub
>> based on my previous dt-binding patch Arnd assumed that the devices
>> would be moved in the hierarchy: [0]
>> however, my understanding is that (at least for now) the root-hub node
>> (identified by reg = <0>) is used to describe only the root-hub (which
>> allows initializing the PHYs), not the devices that are connected to
>> it
>>
>> here's an example from my Khadas VIM (which matches the example from
>> my patch, except: a) it has a different USB hub connected at port 1 b)
>> it has two ports on the root-hub)
>> this is a stripped and commented version of "cat /sys/kernel/debug/usb/devices"
>>
>> T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=5000 MxCh= 0
>> D: Ver= 3.00 Cls=09(hub ) Sub=00 Prot=03 MxPS= 9 #Cfgs= 1
>> P: Vendor=1d6b ProdID=0003 Rev= 3.14
>> -> (USB3 root-hub from a dwc3 controller) in the device-tree example
>> this belongs to &usb/roothub@0
>>
>> T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 2
>> D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
>> P: Vendor=1d6b ProdID=0002 Rev= 3.14
>> -> (USB2 root-hub from a dwc3 controller) in the device-tree example
>> this also belongs to &usb/roothub@0
>>
>> T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 4
>> D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
>> P: Vendor=1a40 ProdID=0801 Rev= 1.00
>> -> (USB2 hub soldered to the board, connected to root-hub port 1) in
>> the device-tree example this belongs to &usb/genesys@1
>>
>> T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#= 3 Spd=480 MxCh= 0
>> D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
>> P: Vendor=090c ProdID=1000 Rev= 7.22
>> -> USB thumb drive connected to the USB hub, not listed in the
>> device-tree example but it would be listed below &usb/genesys@1
>
> Two things to be aware of:
>
> 1. /sys/kernel/debug/usb/devices has an off-by-one error in the
> "Port=" field. Every value you see should actually be one
> higher than it is. It has been this way for many, many years
> so we can't fix it now.
here's the output of "lsusb -t" (which is easier to read I guess):
# lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/0p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 3: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M
> 2. Port numbers are meaningless for root hubs, because root hubs
> by definition are not connected to any upstream USB ports.
thanks for explaining
Regards,
Martin
--
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v7 usb-next 4/4] dt-bindings: usb: xhci: include the roothub and a device in the example
@ 2017-10-28 13:33 ` Martin Blumenstingl
0 siblings, 0 replies; 34+ messages in thread
From: Martin Blumenstingl @ 2017-10-28 13:33 UTC (permalink / raw)
To: linus-amlogic
Hi Alan,
On Fri, Oct 27, 2017 at 9:55 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Fri, 27 Oct 2017, Martin Blumenstingl wrote:
>
>> Hi Rob,
>>
>> On Fri, Oct 27, 2017 at 5:29 AM, Rob Herring <robh@kernel.org> wrote:
>> > On Mon, Oct 23, 2017 at 11:57:18PM +0200, Martin Blumenstingl wrote:
>> >> This extends the existing example from the USB xHCI binding
>> >> documentation so it includes the roothub and an actual device.
>> >> The goal of this is to show that the roothub is specified alongside the
>> >> actual devices on the USB bus (which is important because a device on
>> >> the USB bus - for example a hub - might need it's own phys / phy-names
>> >> properties. modelling the roothub as separate device and not nesting the
>> >> other devices on the bus below the roothub allows us to keep the
>> >> properties, for example the PHYs, separated).
>> >>
>> >> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>> >> ---
>> >> Documentation/devicetree/bindings/usb/usb-xhci.txt | 23 ++++++++++++++++++++++
>> >> 1 file changed, 23 insertions(+)
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>> >> index 5b49ba9f2f9a..20e5ce2b016a 100644
>> >> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
>> >> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>> >> @@ -42,4 +42,27 @@ Example:
>> >> compatible = "generic-xhci";
>> >> reg = <0xf0931000 0x8c8>;
>> >> interrupts = <0x0 0x4e 0x0>;
>> >> +
>> >> + #address-cells = <1>;
>> >> + #size-cells = <0>;
>> >> +
>> >> + /* see usb-roothub.txt */
>> >> + roothub at 0 {
>> >> + compatible = "usb1d6b,3", "usb1d6b,2";
>> >> + #address-cells = <1>;
>> >> + #size-cells = <0>;
>> >> + reg = <0>;
>> >> +
>> >> + port at 1 {
>> >> + reg = <1>;
>> >> + phys = <&usb2_phy1>, <&usb3_phy1>;
>> >> + phy-names = "usb2-phy", "usb3-phy";
>> >> + };
>> >> + };
>> >> +
>> >> + /* see usb-device.txt */
>> >> + hub: genesys at 1 {
>> >
>> > What do the 0 and 1 addresses correspond to?
>> 0 is the address of the root-hub, 1 is the first device on the root-hub
>> based on my previous dt-binding patch Arnd assumed that the devices
>> would be moved in the hierarchy: [0]
>> however, my understanding is that (at least for now) the root-hub node
>> (identified by reg = <0>) is used to describe only the root-hub (which
>> allows initializing the PHYs), not the devices that are connected to
>> it
>>
>> here's an example from my Khadas VIM (which matches the example from
>> my patch, except: a) it has a different USB hub connected at port 1 b)
>> it has two ports on the root-hub)
>> this is a stripped and commented version of "cat /sys/kernel/debug/usb/devices"
>>
>> T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=5000 MxCh= 0
>> D: Ver= 3.00 Cls=09(hub ) Sub=00 Prot=03 MxPS= 9 #Cfgs= 1
>> P: Vendor=1d6b ProdID=0003 Rev= 3.14
>> -> (USB3 root-hub from a dwc3 controller) in the device-tree example
>> this belongs to &usb/roothub at 0
>>
>> T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 2
>> D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
>> P: Vendor=1d6b ProdID=0002 Rev= 3.14
>> -> (USB2 root-hub from a dwc3 controller) in the device-tree example
>> this also belongs to &usb/roothub at 0
>>
>> T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 4
>> D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
>> P: Vendor=1a40 ProdID=0801 Rev= 1.00
>> -> (USB2 hub soldered to the board, connected to root-hub port 1) in
>> the device-tree example this belongs to &usb/genesys at 1
>>
>> T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#= 3 Spd=480 MxCh= 0
>> D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
>> P: Vendor=090c ProdID=1000 Rev= 7.22
>> -> USB thumb drive connected to the USB hub, not listed in the
>> device-tree example but it would be listed below &usb/genesys at 1
>
> Two things to be aware of:
>
> 1. /sys/kernel/debug/usb/devices has an off-by-one error in the
> "Port=" field. Every value you see should actually be one
> higher than it is. It has been this way for many, many years
> so we can't fix it now.
here's the output of "lsusb -t" (which is easier to read I guess):
# lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/0p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 3: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M
> 2. Port numbers are meaningless for root hubs, because root hubs
> by definition are not connected to any upstream USB ports.
thanks for explaining
Regards,
Martin
^ permalink raw reply [flat|nested] 34+ messages in thread
[parent not found: <CAFBinCBocmr6fywO9vqWu+ngfrbG=FBFqdEvYEBWR84VgMANpw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v7 usb-next 4/4] dt-bindings: usb: xhci: include the roothub and a device in the example
2017-10-28 13:33 ` Martin Blumenstingl
@ 2017-10-30 14:08 ` Arnd Bergmann
-1 siblings, 0 replies; 34+ messages in thread
From: Arnd Bergmann @ 2017-10-30 14:08 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: Alan Stern, Rob Herring, linux-usb-u79uwXL29TY76Z2rM5mHXA,
gregkh, felipe.balbi-VuQAYsv1563Yd54FQh9/CA,
mathias.nyman-ral2JQCrhuEAvxtiuMwx3w, DTML, Mark Rutland,
open list:ARM/Amlogic Meson SoC support, Chunfeng Yun
On Sat, Oct 28, 2017 at 3:33 PM, Martin Blumenstingl
<martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
> On Fri, Oct 27, 2017 at 9:55 PM, Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> wrote:
>> On Fri, 27 Oct 2017, Martin Blumenstingl wrote:
>>> >> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>> >> index 5b49ba9f2f9a..20e5ce2b016a 100644
>>> >> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>> >> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>> >> @@ -42,4 +42,27 @@ Example:
>>> >> compatible = "generic-xhci";
>>> >> reg = <0xf0931000 0x8c8>;
>>> >> interrupts = <0x0 0x4e 0x0>;
>>> >> +
>>> >> + #address-cells = <1>;
>>> >> + #size-cells = <0>;
>>> >> +
>>> >> + /* see usb-roothub.txt */
>>> >> + roothub@0 {
>>> >> + compatible = "usb1d6b,3", "usb1d6b,2";
>>> >> + #address-cells = <1>;
>>> >> + #size-cells = <0>;
>>> >> + reg = <0>;
>>> >> +
>>> >> + port@1 {
>>> >> + reg = <1>;
>>> >> + phys = <&usb2_phy1>, <&usb3_phy1>;
>>> >> + phy-names = "usb2-phy", "usb3-phy";
>>> >> + };
>>> >> + };
>>> >> +
>>> >> + /* see usb-device.txt */
>>> >> + hub: genesys@1 {
>> Two things to be aware of:
>>
>> 1. /sys/kernel/debug/usb/devices has an off-by-one error in the
>> "Port=" field. Every value you see should actually be one
>> higher than it is. It has been this way for many, many years
>> so we can't fix it now.
> here's the output of "lsusb -t" (which is easier to read I guess):
> # lsusb -t
> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/0p, 5000M
> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/2p, 480M
> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
> |__ Port 3: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M
I see two possible problems here:
* Linux does show the root hub as a parent of the external hub,
while the DT shows them as two unrelated children of the host
controller. This clearly doesn't reflect the reality, and may come
to bite us again later when we try to extend it in some other way.
* Listing the root hub as compatible="usb1d6b,3" encodes a Linux
implementation detail into the OS-independent DT ABI: The
root hub does not actually have this vendor/device ID, it's
just something we make up in Linux.
I think you mentioned that an earlier version of the patch set
did not have the root hub at all but instead listed the PHYs directly
under the host controller. Can you summarize what the problem
with that approach was?
Is it correct that roothub@0/port@1 corresponds to the same
connector that genesys@1 is connected to?
Arnd
--
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v7 usb-next 4/4] dt-bindings: usb: xhci: include the roothub and a device in the example
@ 2017-10-30 14:08 ` Arnd Bergmann
0 siblings, 0 replies; 34+ messages in thread
From: Arnd Bergmann @ 2017-10-30 14:08 UTC (permalink / raw)
To: linus-amlogic
On Sat, Oct 28, 2017 at 3:33 PM, Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:
> On Fri, Oct 27, 2017 at 9:55 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
>> On Fri, 27 Oct 2017, Martin Blumenstingl wrote:
>>> >> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>> >> index 5b49ba9f2f9a..20e5ce2b016a 100644
>>> >> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>> >> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>> >> @@ -42,4 +42,27 @@ Example:
>>> >> compatible = "generic-xhci";
>>> >> reg = <0xf0931000 0x8c8>;
>>> >> interrupts = <0x0 0x4e 0x0>;
>>> >> +
>>> >> + #address-cells = <1>;
>>> >> + #size-cells = <0>;
>>> >> +
>>> >> + /* see usb-roothub.txt */
>>> >> + roothub at 0 {
>>> >> + compatible = "usb1d6b,3", "usb1d6b,2";
>>> >> + #address-cells = <1>;
>>> >> + #size-cells = <0>;
>>> >> + reg = <0>;
>>> >> +
>>> >> + port at 1 {
>>> >> + reg = <1>;
>>> >> + phys = <&usb2_phy1>, <&usb3_phy1>;
>>> >> + phy-names = "usb2-phy", "usb3-phy";
>>> >> + };
>>> >> + };
>>> >> +
>>> >> + /* see usb-device.txt */
>>> >> + hub: genesys at 1 {
>> Two things to be aware of:
>>
>> 1. /sys/kernel/debug/usb/devices has an off-by-one error in the
>> "Port=" field. Every value you see should actually be one
>> higher than it is. It has been this way for many, many years
>> so we can't fix it now.
> here's the output of "lsusb -t" (which is easier to read I guess):
> # lsusb -t
> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/0p, 5000M
> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/2p, 480M
> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
> |__ Port 3: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M
I see two possible problems here:
* Linux does show the root hub as a parent of the external hub,
while the DT shows them as two unrelated children of the host
controller. This clearly doesn't reflect the reality, and may come
to bite us again later when we try to extend it in some other way.
* Listing the root hub as compatible="usb1d6b,3" encodes a Linux
implementation detail into the OS-independent DT ABI: The
root hub does not actually have this vendor/device ID, it's
just something we make up in Linux.
I think you mentioned that an earlier version of the patch set
did not have the root hub at all but instead listed the PHYs directly
under the host controller. Can you summarize what the problem
with that approach was?
Is it correct that roothub at 0/port at 1 corresponds to the same
connector that genesys at 1 is connected to?
Arnd
^ permalink raw reply [flat|nested] 34+ messages in thread
[parent not found: <CAK8P3a1xdUy7g991MbtrSTYFsM864MQDc61=sLZmfSMwrokCBg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v7 usb-next 4/4] dt-bindings: usb: xhci: include the roothub and a device in the example
2017-10-30 14:08 ` Arnd Bergmann
@ 2017-10-30 22:59 ` Martin Blumenstingl
-1 siblings, 0 replies; 34+ messages in thread
From: Martin Blumenstingl @ 2017-10-30 22:59 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Alan Stern, Rob Herring, linux-usb-u79uwXL29TY76Z2rM5mHXA,
gregkh, felipe.balbi-VuQAYsv1563Yd54FQh9/CA,
mathias.nyman-ral2JQCrhuEAvxtiuMwx3w, DTML, Mark Rutland,
open list:ARM/Amlogic Meson SoC support, Chunfeng Yun
Hi Arnd,
On Mon, Oct 30, 2017 at 3:08 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Sat, Oct 28, 2017 at 3:33 PM, Martin Blumenstingl
> <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
>> On Fri, Oct 27, 2017 at 9:55 PM, Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> wrote:
>>> On Fri, 27 Oct 2017, Martin Blumenstingl wrote:
>>>> >> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>>> >> index 5b49ba9f2f9a..20e5ce2b016a 100644
>>>> >> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>>> >> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>>> >> @@ -42,4 +42,27 @@ Example:
>>>> >> compatible = "generic-xhci";
>>>> >> reg = <0xf0931000 0x8c8>;
>>>> >> interrupts = <0x0 0x4e 0x0>;
>>>> >> +
>>>> >> + #address-cells = <1>;
>>>> >> + #size-cells = <0>;
>>>> >> +
>>>> >> + /* see usb-roothub.txt */
>>>> >> + roothub@0 {
>>>> >> + compatible = "usb1d6b,3", "usb1d6b,2";
>>>> >> + #address-cells = <1>;
>>>> >> + #size-cells = <0>;
>>>> >> + reg = <0>;
>>>> >> +
>>>> >> + port@1 {
>>>> >> + reg = <1>;
>>>> >> + phys = <&usb2_phy1>, <&usb3_phy1>;
>>>> >> + phy-names = "usb2-phy", "usb3-phy";
>>>> >> + };
>>>> >> + };
>>>> >> +
>>>> >> + /* see usb-device.txt */
>>>> >> + hub: genesys@1 {
>
>>> Two things to be aware of:
>>>
>>> 1. /sys/kernel/debug/usb/devices has an off-by-one error in the
>>> "Port=" field. Every value you see should actually be one
>>> higher than it is. It has been this way for many, many years
>>> so we can't fix it now.
>> here's the output of "lsusb -t" (which is easier to read I guess):
>> # lsusb -t
>> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/0p, 5000M
>> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/2p, 480M
>> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
>> |__ Port 3: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M
>
> I see two possible problems here:
>
> * Linux does show the root hub as a parent of the external hub,
> while the DT shows them as two unrelated children of the host
> controller. This clearly doesn't reflect the reality, and may come
> to bite us again later when we try to extend it in some other way.
ok, I see your point here
> * Listing the root hub as compatible="usb1d6b,3" encodes a Linux
> implementation detail into the OS-independent DT ABI: The
> root hub does not actually have this vendor/device ID, it's
> just something we make up in Linux.
I see, this would have to be more generic then (compatible =
"usb-root-hub", etc..)
however, let's postpone this discussion and evaluate more options (see below)
> I think you mentioned that an earlier version of the patch set
> did not have the root hub at all but instead listed the PHYs directly
> under the host controller. Can you summarize what the problem
> with that approach was?
this is going on for a while now, I think it started with Rob's
comment here: [0]
I do not remember any explicit NACKs on that idea
I took a step back and tried to figure out the
requirements/constraints again (in no specific order):
a) we need to initialize multiple PHYs on an xHCI controller
b) other USB controller implementation already initialize multiple
PHYs (see [1]) and we must not break these
c) we need to make sure that we don't get any conflicts when specifying PHYs
(for example: if we pass the PHY for the root-hub/controller port 1
at &usb/device@1 then we may run into a problem where device@1 also
requires a USB PHY. I'm not sure if such cases exist in real-life
though)
d) currently the devicetree phy bindings state that a phy-names
property is mandatory (see [2], I interpret this as 'we cannot have
"phys = <...>" without "phy-names = ...'")
e) existing USB OF helper functions (like of_usb_get_dr_mode_by_phy)
rely on the fact that the PHY is specified directly at the controller
f) DT hierarchy should match the reality
g) ...feel free to name more
defining the PHYs directly under the controller node gives these
results (my own interpretation):
a) we can implement this similar to my current patch (the only
difference would be where the code takes the PHYs from)
b) I am not familiar with these other drivers, however we might be
able to fix those by simply removing the "parse all PHYs" code from
them (and rely on our new code)
c) I don't see any problems, if a controller needs more than just an
USB PHY then we could still use the "phy-names" to skip all non USB
PHYs
d) we would either have to make phy-names optional for this specific
use-case or come up with a convention how the phy-names should be
built for our case
e) of_usb_get_dr_mode_by_phy and friends would still work - no changes required
f) hierarchy matches the reality if we define that the root-hub is not
specified in device-tree (this would mean that we simply treat the
PHYs as properties of the controller, I'm not aware of any other
"root-hub" specific properties)
defining the PHYs in a root-hub node gives these results (my own
interpretation):
a) that's what this series does
b) we're not touching the other implementations - however, existing
.dts files would have to be changed to switch to this new binding
c) the root-hub is currently separated, so there are no conflicts
(needs more thoughts though if we need to nest the USB devices below
the root-hub)
d) phy-names can be specified easily and non USB PHYs are skipped by
the current code already
e) of_usb_get_dr_mode_by_phy and friends would have to be adjusted
(not part of this series yet)
f) the root-hub is now described in devicetree but the hierarchy may
not be correct
could you please let me know if you see more requirements or constraints?
do you agree with my interpretation of the two possible solutions (and
even more important: which are the ones you don't agree with)?
> Is it correct that roothub@0/port@1 corresponds to the same
> connector that genesys@1 is connected to?
yes, both refer to the same port/connector
Regards
Martin
[0] http://lists.infradead.org/pipermail/linux-amlogic/2016-November/001818.html
[1] http://lists.infradead.org/pipermail/linux-amlogic/2017-January/001947.html
[2] http://elixir.free-electrons.com/linux/v4.13.9/source/Documentation/devicetree/bindings/phy/phy-bindings.txt#L33
--
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v7 usb-next 4/4] dt-bindings: usb: xhci: include the roothub and a device in the example
@ 2017-10-30 22:59 ` Martin Blumenstingl
0 siblings, 0 replies; 34+ messages in thread
From: Martin Blumenstingl @ 2017-10-30 22:59 UTC (permalink / raw)
To: linus-amlogic
Hi Arnd,
On Mon, Oct 30, 2017 at 3:08 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Sat, Oct 28, 2017 at 3:33 PM, Martin Blumenstingl
> <martin.blumenstingl@googlemail.com> wrote:
>> On Fri, Oct 27, 2017 at 9:55 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
>>> On Fri, 27 Oct 2017, Martin Blumenstingl wrote:
>>>> >> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>>> >> index 5b49ba9f2f9a..20e5ce2b016a 100644
>>>> >> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>>> >> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>>> >> @@ -42,4 +42,27 @@ Example:
>>>> >> compatible = "generic-xhci";
>>>> >> reg = <0xf0931000 0x8c8>;
>>>> >> interrupts = <0x0 0x4e 0x0>;
>>>> >> +
>>>> >> + #address-cells = <1>;
>>>> >> + #size-cells = <0>;
>>>> >> +
>>>> >> + /* see usb-roothub.txt */
>>>> >> + roothub at 0 {
>>>> >> + compatible = "usb1d6b,3", "usb1d6b,2";
>>>> >> + #address-cells = <1>;
>>>> >> + #size-cells = <0>;
>>>> >> + reg = <0>;
>>>> >> +
>>>> >> + port at 1 {
>>>> >> + reg = <1>;
>>>> >> + phys = <&usb2_phy1>, <&usb3_phy1>;
>>>> >> + phy-names = "usb2-phy", "usb3-phy";
>>>> >> + };
>>>> >> + };
>>>> >> +
>>>> >> + /* see usb-device.txt */
>>>> >> + hub: genesys at 1 {
>
>>> Two things to be aware of:
>>>
>>> 1. /sys/kernel/debug/usb/devices has an off-by-one error in the
>>> "Port=" field. Every value you see should actually be one
>>> higher than it is. It has been this way for many, many years
>>> so we can't fix it now.
>> here's the output of "lsusb -t" (which is easier to read I guess):
>> # lsusb -t
>> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/0p, 5000M
>> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/2p, 480M
>> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
>> |__ Port 3: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M
>
> I see two possible problems here:
>
> * Linux does show the root hub as a parent of the external hub,
> while the DT shows them as two unrelated children of the host
> controller. This clearly doesn't reflect the reality, and may come
> to bite us again later when we try to extend it in some other way.
ok, I see your point here
> * Listing the root hub as compatible="usb1d6b,3" encodes a Linux
> implementation detail into the OS-independent DT ABI: The
> root hub does not actually have this vendor/device ID, it's
> just something we make up in Linux.
I see, this would have to be more generic then (compatible =
"usb-root-hub", etc..)
however, let's postpone this discussion and evaluate more options (see below)
> I think you mentioned that an earlier version of the patch set
> did not have the root hub at all but instead listed the PHYs directly
> under the host controller. Can you summarize what the problem
> with that approach was?
this is going on for a while now, I think it started with Rob's
comment here: [0]
I do not remember any explicit NACKs on that idea
I took a step back and tried to figure out the
requirements/constraints again (in no specific order):
a) we need to initialize multiple PHYs on an xHCI controller
b) other USB controller implementation already initialize multiple
PHYs (see [1]) and we must not break these
c) we need to make sure that we don't get any conflicts when specifying PHYs
(for example: if we pass the PHY for the root-hub/controller port 1
at &usb/device at 1 then we may run into a problem where device at 1 also
requires a USB PHY. I'm not sure if such cases exist in real-life
though)
d) currently the devicetree phy bindings state that a phy-names
property is mandatory (see [2], I interpret this as 'we cannot have
"phys = <...>" without "phy-names = ...'")
e) existing USB OF helper functions (like of_usb_get_dr_mode_by_phy)
rely on the fact that the PHY is specified directly at the controller
f) DT hierarchy should match the reality
g) ...feel free to name more
defining the PHYs directly under the controller node gives these
results (my own interpretation):
a) we can implement this similar to my current patch (the only
difference would be where the code takes the PHYs from)
b) I am not familiar with these other drivers, however we might be
able to fix those by simply removing the "parse all PHYs" code from
them (and rely on our new code)
c) I don't see any problems, if a controller needs more than just an
USB PHY then we could still use the "phy-names" to skip all non USB
PHYs
d) we would either have to make phy-names optional for this specific
use-case or come up with a convention how the phy-names should be
built for our case
e) of_usb_get_dr_mode_by_phy and friends would still work - no changes required
f) hierarchy matches the reality if we define that the root-hub is not
specified in device-tree (this would mean that we simply treat the
PHYs as properties of the controller, I'm not aware of any other
"root-hub" specific properties)
defining the PHYs in a root-hub node gives these results (my own
interpretation):
a) that's what this series does
b) we're not touching the other implementations - however, existing
.dts files would have to be changed to switch to this new binding
c) the root-hub is currently separated, so there are no conflicts
(needs more thoughts though if we need to nest the USB devices below
the root-hub)
d) phy-names can be specified easily and non USB PHYs are skipped by
the current code already
e) of_usb_get_dr_mode_by_phy and friends would have to be adjusted
(not part of this series yet)
f) the root-hub is now described in devicetree but the hierarchy may
not be correct
could you please let me know if you see more requirements or constraints?
do you agree with my interpretation of the two possible solutions (and
even more important: which are the ones you don't agree with)?
> Is it correct that roothub at 0/port at 1 corresponds to the same
> connector that genesys at 1 is connected to?
yes, both refer to the same port/connector
Regards
Martin
[0] http://lists.infradead.org/pipermail/linux-amlogic/2016-November/001818.html
[1] http://lists.infradead.org/pipermail/linux-amlogic/2017-January/001947.html
[2] http://elixir.free-electrons.com/linux/v4.13.9/source/Documentation/devicetree/bindings/phy/phy-bindings.txt#L33
^ permalink raw reply [flat|nested] 34+ messages in thread
[parent not found: <CAFBinCBJuL7J7847ZU0jO=O0WuwNZj_oBT4NO1+ge11dEbQL+w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v7 usb-next 4/4] dt-bindings: usb: xhci: include the roothub and a device in the example
2017-10-30 22:59 ` Martin Blumenstingl
@ 2017-11-12 20:48 ` Martin Blumenstingl
-1 siblings, 0 replies; 34+ messages in thread
From: Martin Blumenstingl @ 2017-11-12 20:48 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Alan Stern, Rob Herring, linux-usb-u79uwXL29TY76Z2rM5mHXA,
gregkh, felipe.balbi-VuQAYsv1563Yd54FQh9/CA,
mathias.nyman-ral2JQCrhuEAvxtiuMwx3w, DTML, Mark Rutland,
open list:ARM/Amlogic Meson SoC support, Chunfeng Yun
Hi Arnd (and anyone else who is interested in this),
On Mon, Oct 30, 2017 at 11:59 PM, Martin Blumenstingl
<martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
> Hi Arnd,
>
> On Mon, Oct 30, 2017 at 3:08 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
>> On Sat, Oct 28, 2017 at 3:33 PM, Martin Blumenstingl
>> <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
>>> On Fri, Oct 27, 2017 at 9:55 PM, Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> wrote:
>>>> On Fri, 27 Oct 2017, Martin Blumenstingl wrote:
>>>>> >> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>>>> >> index 5b49ba9f2f9a..20e5ce2b016a 100644
>>>>> >> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>>>> >> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>>>> >> @@ -42,4 +42,27 @@ Example:
>>>>> >> compatible = "generic-xhci";
>>>>> >> reg = <0xf0931000 0x8c8>;
>>>>> >> interrupts = <0x0 0x4e 0x0>;
>>>>> >> +
>>>>> >> + #address-cells = <1>;
>>>>> >> + #size-cells = <0>;
>>>>> >> +
>>>>> >> + /* see usb-roothub.txt */
>>>>> >> + roothub@0 {
>>>>> >> + compatible = "usb1d6b,3", "usb1d6b,2";
>>>>> >> + #address-cells = <1>;
>>>>> >> + #size-cells = <0>;
>>>>> >> + reg = <0>;
>>>>> >> +
>>>>> >> + port@1 {
>>>>> >> + reg = <1>;
>>>>> >> + phys = <&usb2_phy1>, <&usb3_phy1>;
>>>>> >> + phy-names = "usb2-phy", "usb3-phy";
>>>>> >> + };
>>>>> >> + };
>>>>> >> +
>>>>> >> + /* see usb-device.txt */
>>>>> >> + hub: genesys@1 {
>>
>>>> Two things to be aware of:
>>>>
>>>> 1. /sys/kernel/debug/usb/devices has an off-by-one error in the
>>>> "Port=" field. Every value you see should actually be one
>>>> higher than it is. It has been this way for many, many years
>>>> so we can't fix it now.
>>> here's the output of "lsusb -t" (which is easier to read I guess):
>>> # lsusb -t
>>> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/0p, 5000M
>>> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/2p, 480M
>>> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
>>> |__ Port 3: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M
>>
>> I see two possible problems here:
>>
>> * Linux does show the root hub as a parent of the external hub,
>> while the DT shows them as two unrelated children of the host
>> controller. This clearly doesn't reflect the reality, and may come
>> to bite us again later when we try to extend it in some other way.
> ok, I see your point here
>
>> * Listing the root hub as compatible="usb1d6b,3" encodes a Linux
>> implementation detail into the OS-independent DT ABI: The
>> root hub does not actually have this vendor/device ID, it's
>> just something we make up in Linux.
> I see, this would have to be more generic then (compatible =
> "usb-root-hub", etc..)
> however, let's postpone this discussion and evaluate more options (see below)
>
>> I think you mentioned that an earlier version of the patch set
>> did not have the root hub at all but instead listed the PHYs directly
>> under the host controller. Can you summarize what the problem
>> with that approach was?
> this is going on for a while now, I think it started with Rob's
> comment here: [0]
> I do not remember any explicit NACKs on that idea
>
> I took a step back and tried to figure out the
> requirements/constraints again (in no specific order):
> a) we need to initialize multiple PHYs on an xHCI controller
> b) other USB controller implementation already initialize multiple
> PHYs (see [1]) and we must not break these
> c) we need to make sure that we don't get any conflicts when specifying PHYs
> (for example: if we pass the PHY for the root-hub/controller port 1
> at &usb/device@1 then we may run into a problem where device@1 also
> requires a USB PHY. I'm not sure if such cases exist in real-life
> though)
> d) currently the devicetree phy bindings state that a phy-names
> property is mandatory (see [2], I interpret this as 'we cannot have
> "phys = <...>" without "phy-names = ...'")
> e) existing USB OF helper functions (like of_usb_get_dr_mode_by_phy)
> rely on the fact that the PHY is specified directly at the controller
> f) DT hierarchy should match the reality
> g) ...feel free to name more
>
> defining the PHYs directly under the controller node gives these
> results (my own interpretation):
> a) we can implement this similar to my current patch (the only
> difference would be where the code takes the PHYs from)
> b) I am not familiar with these other drivers, however we might be
> able to fix those by simply removing the "parse all PHYs" code from
> them (and rely on our new code)
> c) I don't see any problems, if a controller needs more than just an
> USB PHY then we could still use the "phy-names" to skip all non USB
> PHYs
> d) we would either have to make phy-names optional for this specific
> use-case or come up with a convention how the phy-names should be
> built for our case
> e) of_usb_get_dr_mode_by_phy and friends would still work - no changes required
> f) hierarchy matches the reality if we define that the root-hub is not
> specified in device-tree (this would mean that we simply treat the
> PHYs as properties of the controller, I'm not aware of any other
> "root-hub" specific properties)
>
> defining the PHYs in a root-hub node gives these results (my own
> interpretation):
> a) that's what this series does
> b) we're not touching the other implementations - however, existing
> .dts files would have to be changed to switch to this new binding
> c) the root-hub is currently separated, so there are no conflicts
> (needs more thoughts though if we need to nest the USB devices below
> the root-hub)
> d) phy-names can be specified easily and non USB PHYs are skipped by
> the current code already
> e) of_usb_get_dr_mode_by_phy and friends would have to be adjusted
> (not part of this series yet)
> f) the root-hub is now described in devicetree but the hierarchy may
> not be correct
>
> could you please let me know if you see more requirements or constraints?
> do you agree with my interpretation of the two possible solutions (and
> even more important: which are the ones you don't agree with)?
did you have time to go through this yet?
I have more time to work on this next week
>> Is it correct that roothub@0/port@1 corresponds to the same
>> connector that genesys@1 is connected to?
> yes, both refer to the same port/connector
>
>
> Regards
> Martin
>
>
> [0] http://lists.infradead.org/pipermail/linux-amlogic/2016-November/001818.html
> [1] http://lists.infradead.org/pipermail/linux-amlogic/2017-January/001947.html
> [2] http://elixir.free-electrons.com/linux/v4.13.9/source/Documentation/devicetree/bindings/phy/phy-bindings.txt#L33
Regards
Martin
--
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v7 usb-next 4/4] dt-bindings: usb: xhci: include the roothub and a device in the example
@ 2017-11-12 20:48 ` Martin Blumenstingl
0 siblings, 0 replies; 34+ messages in thread
From: Martin Blumenstingl @ 2017-11-12 20:48 UTC (permalink / raw)
To: linus-amlogic
Hi Arnd (and anyone else who is interested in this),
On Mon, Oct 30, 2017 at 11:59 PM, Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:
> Hi Arnd,
>
> On Mon, Oct 30, 2017 at 3:08 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Sat, Oct 28, 2017 at 3:33 PM, Martin Blumenstingl
>> <martin.blumenstingl@googlemail.com> wrote:
>>> On Fri, Oct 27, 2017 at 9:55 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
>>>> On Fri, 27 Oct 2017, Martin Blumenstingl wrote:
>>>>> >> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>>>> >> index 5b49ba9f2f9a..20e5ce2b016a 100644
>>>>> >> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>>>> >> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>>>> >> @@ -42,4 +42,27 @@ Example:
>>>>> >> compatible = "generic-xhci";
>>>>> >> reg = <0xf0931000 0x8c8>;
>>>>> >> interrupts = <0x0 0x4e 0x0>;
>>>>> >> +
>>>>> >> + #address-cells = <1>;
>>>>> >> + #size-cells = <0>;
>>>>> >> +
>>>>> >> + /* see usb-roothub.txt */
>>>>> >> + roothub at 0 {
>>>>> >> + compatible = "usb1d6b,3", "usb1d6b,2";
>>>>> >> + #address-cells = <1>;
>>>>> >> + #size-cells = <0>;
>>>>> >> + reg = <0>;
>>>>> >> +
>>>>> >> + port at 1 {
>>>>> >> + reg = <1>;
>>>>> >> + phys = <&usb2_phy1>, <&usb3_phy1>;
>>>>> >> + phy-names = "usb2-phy", "usb3-phy";
>>>>> >> + };
>>>>> >> + };
>>>>> >> +
>>>>> >> + /* see usb-device.txt */
>>>>> >> + hub: genesys at 1 {
>>
>>>> Two things to be aware of:
>>>>
>>>> 1. /sys/kernel/debug/usb/devices has an off-by-one error in the
>>>> "Port=" field. Every value you see should actually be one
>>>> higher than it is. It has been this way for many, many years
>>>> so we can't fix it now.
>>> here's the output of "lsusb -t" (which is easier to read I guess):
>>> # lsusb -t
>>> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/0p, 5000M
>>> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/2p, 480M
>>> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
>>> |__ Port 3: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M
>>
>> I see two possible problems here:
>>
>> * Linux does show the root hub as a parent of the external hub,
>> while the DT shows them as two unrelated children of the host
>> controller. This clearly doesn't reflect the reality, and may come
>> to bite us again later when we try to extend it in some other way.
> ok, I see your point here
>
>> * Listing the root hub as compatible="usb1d6b,3" encodes a Linux
>> implementation detail into the OS-independent DT ABI: The
>> root hub does not actually have this vendor/device ID, it's
>> just something we make up in Linux.
> I see, this would have to be more generic then (compatible =
> "usb-root-hub", etc..)
> however, let's postpone this discussion and evaluate more options (see below)
>
>> I think you mentioned that an earlier version of the patch set
>> did not have the root hub at all but instead listed the PHYs directly
>> under the host controller. Can you summarize what the problem
>> with that approach was?
> this is going on for a while now, I think it started with Rob's
> comment here: [0]
> I do not remember any explicit NACKs on that idea
>
> I took a step back and tried to figure out the
> requirements/constraints again (in no specific order):
> a) we need to initialize multiple PHYs on an xHCI controller
> b) other USB controller implementation already initialize multiple
> PHYs (see [1]) and we must not break these
> c) we need to make sure that we don't get any conflicts when specifying PHYs
> (for example: if we pass the PHY for the root-hub/controller port 1
> at &usb/device at 1 then we may run into a problem where device at 1 also
> requires a USB PHY. I'm not sure if such cases exist in real-life
> though)
> d) currently the devicetree phy bindings state that a phy-names
> property is mandatory (see [2], I interpret this as 'we cannot have
> "phys = <...>" without "phy-names = ...'")
> e) existing USB OF helper functions (like of_usb_get_dr_mode_by_phy)
> rely on the fact that the PHY is specified directly at the controller
> f) DT hierarchy should match the reality
> g) ...feel free to name more
>
> defining the PHYs directly under the controller node gives these
> results (my own interpretation):
> a) we can implement this similar to my current patch (the only
> difference would be where the code takes the PHYs from)
> b) I am not familiar with these other drivers, however we might be
> able to fix those by simply removing the "parse all PHYs" code from
> them (and rely on our new code)
> c) I don't see any problems, if a controller needs more than just an
> USB PHY then we could still use the "phy-names" to skip all non USB
> PHYs
> d) we would either have to make phy-names optional for this specific
> use-case or come up with a convention how the phy-names should be
> built for our case
> e) of_usb_get_dr_mode_by_phy and friends would still work - no changes required
> f) hierarchy matches the reality if we define that the root-hub is not
> specified in device-tree (this would mean that we simply treat the
> PHYs as properties of the controller, I'm not aware of any other
> "root-hub" specific properties)
>
> defining the PHYs in a root-hub node gives these results (my own
> interpretation):
> a) that's what this series does
> b) we're not touching the other implementations - however, existing
> .dts files would have to be changed to switch to this new binding
> c) the root-hub is currently separated, so there are no conflicts
> (needs more thoughts though if we need to nest the USB devices below
> the root-hub)
> d) phy-names can be specified easily and non USB PHYs are skipped by
> the current code already
> e) of_usb_get_dr_mode_by_phy and friends would have to be adjusted
> (not part of this series yet)
> f) the root-hub is now described in devicetree but the hierarchy may
> not be correct
>
> could you please let me know if you see more requirements or constraints?
> do you agree with my interpretation of the two possible solutions (and
> even more important: which are the ones you don't agree with)?
did you have time to go through this yet?
I have more time to work on this next week
>> Is it correct that roothub at 0/port at 1 corresponds to the same
>> connector that genesys at 1 is connected to?
> yes, both refer to the same port/connector
>
>
> Regards
> Martin
>
>
> [0] http://lists.infradead.org/pipermail/linux-amlogic/2016-November/001818.html
> [1] http://lists.infradead.org/pipermail/linux-amlogic/2017-January/001947.html
> [2] http://elixir.free-electrons.com/linux/v4.13.9/source/Documentation/devicetree/bindings/phy/phy-bindings.txt#L33
Regards
Martin
^ permalink raw reply [flat|nested] 34+ messages in thread