initialize (multiple) PHYs in xhci-plat

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 yet which were only introduced recently (documentation is available in devicetree/bindings/usb/usb-device.txt).
With this new driver the usb2-phy and usb3-phy can be specified directly in the child-node of the corresponding port of the roothub via devicetree. This can be extended by not just parsing PHYs (some of the other drivers listed above are for example also parsing a list of clocks as well) when required.

Signed-off-by Martin Blumenstingl <[email protected]>

Tested-by Chunfeng Yun <[email protected]>

---
  drivers/usb/host/Kconfig            |   3 +
  drivers/usb/host/Makefile           |   2 +
  drivers/usb/host/platform-roothub.c | 180 ++++++++++++++++++++++++++++++++++++
  drivers/usb/host/platform-roothub.h |  12 +++
  4 files changed, 197 insertions(+)

create mode 100644 drivers/usb/host/platform-roothub.c create mode 100644 drivers/usb/host/platform-roothub.h

drivers/usb/host/Kconfig +3 -0

index fa5692dec832..b8b05c786b2a 100644
@@ -805,6 +805,9 @@ config USB_HCD_SSB
 
  	  If unsure, say N.
 
+config USB_PLATFORM_ROOTHUB
+	bool
+
  config USB_HCD_TEST_MODE
  	bool "HCD test mode support"
  	---help---

drivers/usb/host/Makefile +2 -0

index cf2691fffcc0..dc817f82d632 100644
@@ -29,6 +29,8 @@ obj-$(CONFIG_USB_WHCI_HCD)	+= whci/
 
  obj-$(CONFIG_USB_PCI)	+= pci-quirks.o
 
+obj-$(CONFIG_USB_PLATFORM_ROOTHUB)	+= platform-roothub.o
+
  obj-$(CONFIG_USB_EHCI_HCD)	+= ehci-hcd.o
  obj-$(CONFIG_USB_EHCI_PCI)	+= ehci-pci.o
  obj-$(CONFIG_USB_EHCI_HCD_PLATFORM)	+= ehci-platform.o

drivers/usb/host/platform-roothub.c new file +82 -0

new file mode 100644
index 000000000000..70d2d97aa8b2
@@ -0,0 +1,180 @@
+/*
+ * platform roothub driver - a virtual PHY device which passes all phy_*
+ * function calls to multiple (actual) PHY devices. This is comes handy when
+ * initializing all PHYs on a root-hub (to keep them all in the same state).
+ *
+ * Copyright (C) 2017 Martin Blumenstingl <[email protected]>
+ *
+ * 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/of.h>
+
+#include "platform-roothub.h"
+
+#define ROOTHUB_PORTNUM		0
+
+struct platform_roothub {
+	struct phy		*phy;
+	struct list_head	list;
+};
+
+static struct platform_roothub *platform_roothub_alloc(struct device *dev)
+{
+	struct platform_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 platform_roothub_add_phy(struct device *dev,
+				    struct device_node *port_np,
+				    const char *con_id, struct list_head *list)
+{
+	struct platform_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 = platform_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 platform_roothub *platform_roothub_init(struct device *dev)
+{
+	struct device_node *roothub_np, *port_np;
+	struct platform_roothub *plat_roothub;
+	struct platform_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;
+
+	plat_roothub = platform_roothub_alloc(dev);
+	if (IS_ERR(plat_roothub))

Quoted 13 lines · 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}

Quoted 8 lines

These drivers are not using the generic devicetree USB device bindings yet which were only introduced recently (documentation is available in devicetree/bindings/usb/usb-device.txt).
With this new driver the usb2-phy and usb3-phy can be specified directly in the child-node of the corresponding port of the roothub via devicetree. This can be extended by not just parsing PHYs (some of the other drivers listed above are for example also parsing a list of clocks as well) when required.

usb_add_hcd() in usb/core/hcd.c is already finding, initializing and turning on a phy, would it make sense to expand that one to support several phys instead?

xhci will add two hcd's one for USB2 and one for USB3

Quoted 10 lines

Signed-off-by Martin Blumenstingl <[email protected]>

Tested-by Chunfeng Yun <[email protected]>

---
  drivers/usb/host/Kconfig            |   3 +
  drivers/usb/host/Makefile           |   2 +
  drivers/usb/host/platform-roothub.c | 180
++++++++++++++++++++++++++++++++++++
  drivers/usb/host/platform-roothub.h |  12 +++
  4 files changed, 197 insertions(+)

Quoted 3 lines

create mode 100644 drivers/usb/host/platform-roothub.c create mode 100644 drivers/usb/host/platform-roothub.h

Instead of creating platform-roothub files could this content be added into into core/hcd.*, core/phy.* and host/xhci-plat.c

Quoted 131 lines

drivers/usb/host/Kconfig +3 -0

index fa5692dec832..b8b05c786b2a 100644
@@ -805,6 +805,9 @@ config USB_HCD_SSB
 
          If unsure, say N.
 
+config USB_PLATFORM_ROOTHUB
+       bool
+
  config USB_HCD_TEST_MODE
        bool "HCD test mode support"
        ---help---

drivers/usb/host/Makefile +2 -0

index cf2691fffcc0..dc817f82d632 100644
@@ -29,6 +29,8 @@ obj-$(CONFIG_USB_WHCI_HCD)    += whci/
 
  obj-$(CONFIG_USB_PCI) += pci-quirks.o
 
+obj-$(CONFIG_USB_PLATFORM_ROOTHUB)     += platform-roothub.o
+
  obj-$(CONFIG_USB_EHCI_HCD)    += ehci-hcd.o
  obj-$(CONFIG_USB_EHCI_PCI)    += ehci-pci.o
  obj-$(CONFIG_USB_EHCI_HCD_PLATFORM)   += ehci-platform.o

drivers/usb/host/platform-roothub.c new file +3 -0

new file mode 100644
index 000000000000..70d2d97aa8b2
@@ -0,0 +1,180 @@
+/*
+ * platform roothub driver - a virtual PHY device which passes all phy_*
+ * function calls to multiple (actual) PHY devices. This is comes handy

when
+ * initializing all PHYs on a root-hub (to keep them all in the same state).
+ *
+ * Copyright (C) 2017 Martin Blumenstingl <[email protected]>
+ *
+ * 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/>.
+ */

drivers/usb/host/platform-roothub.c new file +17 -0

+
+#include <linux/device.h>
+#include <linux/list.h>
+#include <linux/phy/phy.h>
+#include <linux/of.h>
+#include <linux/usb/of.h>
+
+#include "platform-roothub.h"
+
+#define ROOTHUB_PORTNUM                0
+
+struct platform_roothub {
+       struct phy              *phy;
+       struct list_head        list;
+};
+
+static struct platform_roothub *platform_roothub_alloc(struct device

*dev)

drivers/usb/host/platform-roothub.c new file +4 -0

+{
+       struct platform_roothub *roothub_entry;
+
+       roothub_entry = devm_kzalloc(dev, sizeof(*roothub_entry),

GFP_KERNEL);

drivers/usb/host/platform-roothub.c new file +11 -0

+       if (!roothub_entry)
+               return ERR_PTR(-ENOMEM);
+
+       INIT_LIST_HEAD(&roothub_entry->list);
+
+       return roothub_entry;
+}
+
+static int platform_roothub_add_phy(struct device *dev,
+                                   struct device_node *port_np,
+                                   const char *con_id, struct list_head

*list)

drivers/usb/host/platform-roothub.c new file +44 -0

+{
+       struct platform_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 = platform_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 platform_roothub *platform_roothub_init(struct device *dev)
+{
+       struct device_node *roothub_np, *port_np;
+       struct platform_roothub *plat_roothub;
+       struct platform_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;
+
+       plat_roothub = platform_roothub_alloc(dev);
+       if (IS_ERR(plat_roothub))
+               return plat_roothub;
+
+       for_each_available_child_of_node(roothub_np, port_np) {
+               err = platform_roothub_add_phy(dev, port_np, "usb2-phy",
+                                              &plat_roothub->list);
+               if (err)
+                       goto err_out;
+

drivers/usb/host/platform-roothub.c line 92

Quoted 2 lines

drivers/usb/host/platform-roothub.c new file +2 -0

+               err = platform_roothub_add_phy(dev, port_np, "usb3-phy",
+                                              &plat_roothub->list);

So if the first 10 ports have the same phy, and 11th and 12th have an other one, won't we end up
with a phy list with 12 entries for 2 phys, and initialize and turn on the same first phy 10 times?

I'm also not sure I understand the reason for having the "usb3-phy" and "usb2-phy" phy-names
for the ports if we anyways just add everything to one list.

Hi Mathias,

thank you for taking the time to go through my patch

Quoted 24 lines · Mathias Nyman

Quoted 13 lines · 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}

Quoted 8 lines

These drivers are not using the generic devicetree USB device bindings yet which were only introduced recently (documentation is available in devicetree/bindings/usb/usb-device.txt).
With this new driver the usb2-phy and usb3-phy can be specified directly in the child-node of the corresponding port of the roothub via devicetree. This can be extended by not just parsing PHYs (some of the other drivers listed above are for example also parsing a list of clocks as well) when required.

Quoted 5 lines

usb_add_hcd() in usb/core/hcd.c is already finding, initializing and turning on a phy, would it make sense to expand that one to support several phys instead?

xhci will add two hcd's one for USB2 and one for USB3

that is a great suggestion - thank you for bringing this up! as a benefit we would add multiple PHY support for all the other use-cases I found (at least: ehci-platform.c, xhci-mtk.c, ohci-platform.c) - instead of just handling this in xhci-plat.c

I have one quick question regarding usb/core/hcd.c:
are hcd_bus_suspend() and hcd_bus_resume() the right places to power_{off,on} the PHYs during suspend?
(currently usb/core/hcd.c doesn't touch the PHY during suspend/resume
- xhci-mtk.c on the other hand seems to require it during a suspend/resume cycle)

Quoted 6 lines

So if the first 10 ports have the same phy, and 11th and 12th have an other one, won't we end up
with a phy list with 12 entries for 2 phys, and initialize and turn on the same first phy 10 times?

indeed, we would call phy_init() and phy_power_on() multiple times on the same PHY.
however, this is not an issue since the PHY framework is doing ref-counting for us (see [0] and [1] - the PHY driver's .init() and .power_on() callbacks will only be called once for each PHY in your scenario)

do you see any other issues with this?

Quoted 3 lines

I'm also not sure I understand the reason for having the "usb3-phy" and "usb2-phy" phy-names
for the ports if we anyways just add everything to one list.

the PHY devicetree bindings state that the "phy-names" property is
mandatory: [2]

when moving the whole multiple PHY logic to usb_add_hcd() then it even makes sense to look for specific PHYs (imho):
- let's assume we have a XHCI controller with two ports
- both ports have a USB2 PHY, but only one has a USB3 PHY
- (this basically describes the situation on the Amlogic Meson GXL SoCs, Mediatek uses similar designs)

this would result in the following flow:
1. usb_add_hcd is called for the high-speed HCD
2. we would parse the PHYs for the high-speed HCD
3. usb_add_hcd is called for the super-speed HCD
4. we would parse the PHYs for the super-speed HCD
depending on how we parse the PHYs (mapping the controller-type to phy-name "usb2-phy" or "usb3-phy") we either end up with:
- 3 PHY handles (2x USB2, 1x USB3) if we take the controller-type/phy-name into account
- 6 PHY handles (doubling the amount from the use-case above) if we don't

please let me know if there is an easier solution - I prefer simple code myself, so I don't want to add complexity where it's not needed.

This series is the outcome of a discussion with Felipe Balbi, see [0] and [1].
The quick-summary of this is:
- dwc3 already takes one USB2 and one USB3 PHY and initializes these correct
- some other HCI platform drivers (like ehci-platform.c, xhci-mtk.c and ohci-platform.c) do not have a limitation on the number of PHYs - they support one PHY per actual host port
- Amlogic Meson GXL and GXM SoCs come with a dwc3 IP block which has two or three USB2 ports enabled on the internal root-hub. The SoCs also provide separate USB2 PHYs, one per port. All USB2 PHYs (which are internally "connected" to the dwc3 roothub) need to be powered on, otherwise USB devices cannot be enumerated (even if just one PHY is disabled and if the device is plugged into another, enabled port)

In my first attempt to get USB supported on the GXL and GXM SoCs I tried to work-around the problem that I could not pass multiple PHYs to the dwc3 controller.
This was rejected by Rob Herring (which was definitely the thing to do in my opinion), see [2]

This series adds a new "platform-roothub". This can be configured through devicetree by passing a child-node with "reg = <0>" to the USB controller. Additionally there has to be a child-node for each port on the root-hub. Each of the child-nodes takes a "phys" and "phy-names" property. This allows modeling the root-hub in devicetree similar to the USB device binding (documented in devicetree/bindings/usb/usb-device.txt) This avoids and backwards-compatibility problems (which was a concern regardless of the solution, see [3]) since the binding for the root-hub was previously not specified (and we're not using the "phys" property of the controller, which might have served different purposes before, depending on the drivers).

Additionally this integrates the new platform-roothub into xhci-plat.c which automatically enables it for the dwc3 driver (in host-mode).

Changes since RFCv3 at [6]:
- moved the DT binding change from patch #3 to patch #1 as suggested by Rob Herring (and slightly adjusted the commit message to account for that)
- added Tested-by from Chunfeng Yun (who confirmed that the whole concept and implementation works fine on Mediatek SoCs - many thanks again!) to patch #2
- added Rob Herring's ACK to patches 1 and 3
- dropped RFC status (RFCv3 -> PATCH v4)

Changes since RFCv2 at [5]:
- split phy_{init,exit} and phy_power_{on,off} handling. up until RFCv2 I called phy_init plus phy_power_on in platform_roothub_power_on and phy_power_off plus phy_exit in platform_roothub_power_off. However, Chunfeng Yun (a Mediatek SoC developer - many thanks for testing my series and providing great feedback) reported that only using phy_power_off (and omitting phy_exit) during system suspend fixes an issue where USB devices would be re-enumerated when resuming. His original problem description: "In order to keep link state on mt8173, we just power off all phys(not exit) when system enter suspend, then power on them again (needn't init, otherwise device will be disconnected) when system resume, this can avoid re-enumerating device.". This fix affects patch #2 and #3 as we now have platform_roothub_init (which calls phy_init internally), platform_roothub_power_on (which calls phy_power_on internally), platform_roothub_power_off (which calls phy_power_off internally) and platform_roothub_exit (which calls phy_exit internally). suspend and resume only call platform_roothub_power_{on,off} to prevent the issue described by Chunfeng Yun (unfortunately I cannot test this because the Amlogic platform currently does not support system suspend).
- dropped two struct forward declarations from platform-roothub.h which are not used in the header file (thanks to Chunfeng Yun for spotting this)

Changes since RFCv1 at [4]:
- split the usb-xhci dt-binding documentation into a separate patch
- fixed a typo ("usb-phy" -> "phys" in the dt-binding example)
- rebased to apply against latest usb-next

[0] http://lists.infradead.org/pipermail/linux-amlogic/2017-January/001945.html
[1] http://lists.infradead.org/pipermail/linux-amlogic/2017-January/001947.html
[2] http://lists.infradead.org/pipermail/linux-amlogic/2016-November/001818.html
[3] http://lists.infradead.org/pipermail/linux-amlogic/2017-January/001948.html
[4] http://marc.info/?l=linux-usb&m=148414866303604&w=2
[5] https://www.spinics.net/lists/linux-usb/msg158967.html
[6] https://www.spinics.net/lists/devicetree/msg190426.html

Martin Blumenstingl (3):
dt-bindings: usb: add the documentation for USB root-hub
usb: host: add a generic platform USB roothub driver
usb: host: xhci: plat: integrate the platform-roothub

 .../devicetree/bindings/usb/usb-roothub.txt        |  46 ++++++
 Documentation/devicetree/bindings/usb/usb-xhci.txt |   7 +
 drivers/usb/host/Kconfig                           |   4 +
 drivers/usb/host/Makefile                          |   2 +
 drivers/usb/host/platform-roothub.c                | 180 +++++++++++++++++++++
 drivers/usb/host/platform-roothub.h                |  12 ++
 drivers/usb/host/xhci-plat.c                       |  35 +++-
 drivers/usb/host/xhci.h                            |   2 +
 8 files changed, 286 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/usb-roothub.txt
 create mode 100644 drivers/usb/host/platform-roothub.c
 create mode 100644 drivers/usb/host/platform-roothub.h

--
2.14.1

Hello Mathias, Hello Greg,

Quoted 37 lines · Martin Blumenstingl

This series is the outcome of a discussion with Felipe Balbi, see [0] and [1].
The quick-summary of this is:
- dwc3 already takes one USB2 and one USB3 PHY and initializes these correct
- some other HCI platform drivers (like ehci-platform.c, xhci-mtk.c and ohci-platform.c) do not have a limitation on the number of PHYs - they support one PHY per actual host port
- Amlogic Meson GXL and GXM SoCs come with a dwc3 IP block which has two or three USB2 ports enabled on the internal root-hub. The SoCs also provide separate USB2 PHYs, one per port. All USB2 PHYs (which are internally "connected" to the dwc3 roothub) need to be powered on, otherwise USB devices cannot be enumerated (even if just one PHY is disabled and if the device is plugged into another, enabled port)

In my first attempt to get USB supported on the GXL and GXM SoCs I tried to work-around the problem that I could not pass multiple PHYs to the dwc3 controller.
This was rejected by Rob Herring (which was definitely the thing to do in my opinion), see [2]

This series adds a new "platform-roothub". This can be configured through devicetree by passing a child-node with "reg = <0>" to the USB controller. Additionally there has to be a child-node for each port on the root-hub. Each of the child-nodes takes a "phys" and "phy-names" property. This allows modeling the root-hub in devicetree similar to the USB device binding (documented in devicetree/bindings/usb/usb-device.txt) This avoids and backwards-compatibility problems (which was a concern regardless of the solution, see [3]) since the binding for the root-hub was previously not specified (and we're not using the "phys" property of the controller, which might have served different purposes before, depending on the drivers).

Additionally this integrates the new platform-roothub into xhci-plat.c which automatically enables it for the dwc3 driver (in host-mode).

Quoted 9 lines

Changes since RFCv3 at [6]:
- moved the DT binding change from patch #3 to patch #1 as suggested by Rob Herring (and slightly adjusted the commit message to account for that)
- added Tested-by from Chunfeng Yun (who confirmed that the whole concept and implementation works fine on Mediatek SoCs - many thanks again!) to patch #2
- added Rob Herring's ACK to patches 1 and 3
- dropped RFC status (RFCv3 -> PATCH v4)

I just wanted to rebase this to v4.14-rc1 (now that this is out) - however I noticed that v4 still applies to v4.14-rc1 cleanly (the patches are still identical to v4 after rebasing).

we have an ACK from the devicetree maintainers and a "Tested-by" for a Mediatek (= non-Amlogic) SoC.
I already have patches for the Amlogic GXL/GXM platforms queued, those are just waiting on this series.

what is still missing to get this series into v4.15?

Quoted 59 lines · Martin Blumenstingl

Hello Mathias, Hello Greg,

Quoted 37 lines · Martin Blumenstingl

This series is the outcome of a discussion with Felipe Balbi, see [0] and [1].
The quick-summary of this is:
- dwc3 already takes one USB2 and one USB3 PHY and initializes these correct
- some other HCI platform drivers (like ehci-platform.c, xhci-mtk.c and ohci-platform.c) do not have a limitation on the number of PHYs - they support one PHY per actual host port
- Amlogic Meson GXL and GXM SoCs come with a dwc3 IP block which has two or three USB2 ports enabled on the internal root-hub. The SoCs also provide separate USB2 PHYs, one per port. All USB2 PHYs (which are internally "connected" to the dwc3 roothub) need to be powered on, otherwise USB devices cannot be enumerated (even if just one PHY is disabled and if the device is plugged into another, enabled port)

In my first attempt to get USB supported on the GXL and GXM SoCs I tried to work-around the problem that I could not pass multiple PHYs to the dwc3 controller.
This was rejected by Rob Herring (which was definitely the thing to do in my opinion), see [2]

This series adds a new "platform-roothub". This can be configured through devicetree by passing a child-node with "reg = <0>" to the USB controller. Additionally there has to be a child-node for each port on the root-hub. Each of the child-nodes takes a "phys" and "phy-names" property. This allows modeling the root-hub in devicetree similar to the USB device binding (documented in devicetree/bindings/usb/usb-device.txt) This avoids and backwards-compatibility problems (which was a concern regardless of the solution, see [3]) since the binding for the root-hub was previously not specified (and we're not using the "phys" property of the controller, which might have served different purposes before, depending on the drivers).

Additionally this integrates the new platform-roothub into xhci-plat.c which automatically enables it for the dwc3 driver (in host-mode).

Quoted 9 lines

Changes since RFCv3 at [6]:
- moved the DT binding change from patch #3 to patch #1 as suggested by Rob Herring (and slightly adjusted the commit message to account for that)
- added Tested-by from Chunfeng Yun (who confirmed that the whole concept and implementation works fine on Mediatek SoCs - many thanks again!) to patch #2
- added Rob Herring's ACK to patches 1 and 3
- dropped RFC status (RFCv3 -> PATCH v4)

I just wanted to rebase this to v4.14-rc1 (now that this is out) - however I noticed that v4 still applies to v4.14-rc1 cleanly (the patches are still identical to v4 after rebasing).

we have an ACK from the devicetree maintainers and a "Tested-by" for a Mediatek (= non-Amlogic) SoC.
I already have patches for the Amlogic GXL/GXM platforms queued, those are just waiting on this series.

Quoted 1 line

what is still missing to get this series into v4.15?

Well, we couldn't do anything until 4.14-rc1 is out, now that it is, let us catch up on patch review please...

Hello Greg, Hello Mathias,

Quoted 66 lines · Greg KH

Quoted 64 lines · Martin Blumenstingl

Hello Mathias, Hello Greg,

Quoted 40 lines · Martin Blumenstingl

This series is the outcome of a discussion with Felipe Balbi, see [0] and [1].
The quick-summary of this is:
- dwc3 already takes one USB2 and one USB3 PHY and initializes these correct
- some other HCI platform drivers (like ehci-platform.c, xhci-mtk.c and ohci-platform.c) do not have a limitation on the number of PHYs - they support one PHY per actual host port
- Amlogic Meson GXL and GXM SoCs come with a dwc3 IP block which has two or three USB2 ports enabled on the internal root-hub. The SoCs also provide separate USB2 PHYs, one per port. All USB2 PHYs (which are internally "connected" to the dwc3 roothub) need to be powered on, otherwise USB devices cannot be enumerated (even if just one PHY is disabled and if the device is plugged into another, enabled port)

In my first attempt to get USB supported on the GXL and GXM SoCs I tried to work-around the problem that I could not pass multiple PHYs to the dwc3 controller.
This was rejected by Rob Herring (which was definitely the thing to do in
my opinion), see [2]

This series adds a new "platform-roothub". This can be configured through
devicetree by passing a child-node with "reg = <0>" to the USB controller. Additionally there has to be a child-node for each port on the root-hub. Each of the child-nodes takes a "phys" and "phy-names" property. This allows modeling the root-hub in devicetree similar to the USB device binding (documented in devicetree/bindings/usb/usb- device.txt)
This avoids and backwards-compatibility problems (which was a concern regardless of the solution, see [3]) since the binding for the root-hub was previously not specified (and we're not using the "phys" property of the controller, which might have served different purposes before, depending on the drivers).

Additionally this integrates the new platform-roothub into xhci-plat.c which automatically enables it for the dwc3 driver (in host-mode).

Quoted 9 lines

Changes since RFCv3 at [6]:
- moved the DT binding change from patch #3 to patch #1 as suggested by Rob Herring (and slightly adjusted the commit message to account for that)
- added Tested-by from Chunfeng Yun (who confirmed that the whole concept and implementation works fine on Mediatek SoCs - many thanks again!) to patch #2
- added Rob Herring's ACK to patches 1 and 3
- dropped RFC status (RFCv3 -> PATCH v4)

I just wanted to rebase this to v4.14-rc1 (now that this is out) - however I noticed that v4 still applies to v4.14-rc1 cleanly (the patches are still identical to v4 after rebasing).

we have an ACK from the devicetree maintainers and a "Tested-by" for a Mediatek (= non-Amlogic) SoC.
I already have patches for the Amlogic GXL/GXM platforms queued, those are just waiting on this series.

what is still missing to get this series into v4.15?

Quoted 2 lines

Well, we couldn't do anything until 4.14-rc1 is out, now that it is, let us catch up on patch review please...

OK, I understand that.
please let me know once you've caught up with the review backlog - as I said I would like to get this into 4.15 if nothing else comes up during the code-review

Thank you!
Regards,
Martin

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

Quoted 69 lines · Martin Blumenstingl

Hello Greg, Hello Mathias,

Quoted 66 lines · Greg KH

Quoted 64 lines · Martin Blumenstingl

Hello Mathias, Hello Greg,

Quoted 40 lines · Martin Blumenstingl

This series is the outcome of a discussion with Felipe Balbi, see [0] and [1].
The quick-summary of this is:
- dwc3 already takes one USB2 and one USB3 PHY and initializes these correct
- some other HCI platform drivers (like ehci-platform.c, xhci-mtk.c and ohci-platform.c) do not have a limitation on the number of PHYs - they support one PHY per actual host port
- Amlogic Meson GXL and GXM SoCs come with a dwc3 IP block which has two or three USB2 ports enabled on the internal root-hub. The SoCs also provide separate USB2 PHYs, one per port. All USB2 PHYs (which are internally "connected" to the dwc3 roothub) need to be powered on, otherwise USB devices cannot be enumerated (even if just one PHY is disabled and if the device is plugged into another, enabled port)

In my first attempt to get USB supported on the GXL and GXM SoCs I tried to work-around the problem that I could not pass multiple PHYs to the dwc3 controller.
This was rejected by Rob Herring (which was definitely the thing to do in
my opinion), see [2]

This series adds a new "platform-roothub". This can be configured through
devicetree by passing a child-node with "reg = <0>" to the USB controller. Additionally there has to be a child-node for each port on the root-hub. Each of the child-nodes takes a "phys" and "phy-names" property. This allows modeling the root-hub in devicetree similar to the USB device binding (documented in devicetree/bindings/usb/usb- device.txt)
This avoids and backwards-compatibility problems (which was a concern regardless of the solution, see [3]) since the binding for the root-hub was previously not specified (and we're not using the "phys" property of the controller, which might have served different purposes before, depending on the drivers).

Additionally this integrates the new platform-roothub into xhci-plat.c which automatically enables it for the dwc3 driver (in host-mode).

Quoted 9 lines

Changes since RFCv3 at [6]:
- moved the DT binding change from patch #3 to patch #1 as suggested by Rob Herring (and slightly adjusted the commit message to account for that)
- added Tested-by from Chunfeng Yun (who confirmed that the whole concept and implementation works fine on Mediatek SoCs - many thanks again!) to patch #2
- added Rob Herring's ACK to patches 1 and 3
- dropped RFC status (RFCv3 -> PATCH v4)

I just wanted to rebase this to v4.14-rc1 (now that this is out) - however I noticed that v4 still applies to v4.14-rc1 cleanly (the patches are still identical to v4 after rebasing).

we have an ACK from the devicetree maintainers and a "Tested-by" for a Mediatek (= non-Amlogic) SoC.
I already have patches for the Amlogic GXL/GXM platforms queued, those are just waiting on this series.

what is still missing to get this series into v4.15?

Quoted 7 lines

Quoted 2 lines

Well, we couldn't do anything until 4.14-rc1 is out, now that it is, let us catch up on patch review please...

OK, I understand that.
please let me know once you've caught up with the review backlog - as I said I would like to get this into 4.15 if nothing else comes up during the code-review

This series works well on the libretech-cc (le potato) For the series:

Tested-by Jerome Brunet <[email protected]>

Quoted 78 lines · Jerome Brunet

Quoted 76 lines · Martin Blumenstingl

Hello Greg, Hello Mathias,

Quoted 64 lines · Greg KH

Quoted 63 lines · Martin Blumenstingl

Hello Mathias, Hello Greg,

Quoted 40 lines · Martin Blumenstingl

This series is the outcome of a discussion with Felipe Balbi, see [0] and [1].
The quick-summary of this is:
- dwc3 already takes one USB2 and one USB3 PHY and initializes these correct
- some other HCI platform drivers (like ehci-platform.c, xhci-mtk.c and ohci-platform.c) do not have a limitation on the number of PHYs - they support one PHY per actual host port
- Amlogic Meson GXL and GXM SoCs come with a dwc3 IP block which has two or three USB2 ports enabled on the internal root-hub. The SoCs also provide separate USB2 PHYs, one per port. All USB2 PHYs (which are internally "connected" to the dwc3 roothub) need to be powered on, otherwise USB devices cannot be enumerated (even if just one PHY is disabled and if the device is plugged into another, enabled port)

In my first attempt to get USB supported on the GXL and GXM SoCs I tried to work-around the problem that I could not pass multiple PHYs to the dwc3 controller.
This was rejected by Rob Herring (which was definitely the thing to do in
my opinion), see [2]

This series adds a new "platform-roothub". This can be configured through
devicetree by passing a child-node with "reg = <0>" to the USB controller. Additionally there has to be a child-node for each port on the root-hub. Each of the child-nodes takes a "phys" and "phy-names" property. This allows modeling the root-hub in devicetree similar to the USB device binding (documented in devicetree/bindings/usb/usb- device.txt)
This avoids and backwards-compatibility problems (which was a concern regardless of the solution, see [3]) since the binding for the root-hub was previously not specified (and we're not using the "phys" property of the controller, which might have served different purposes before, depending on the drivers).

Additionally this integrates the new platform-roothub into xhci-plat.c which automatically enables it for the dwc3 driver (in host-mode).

Quoted 9 lines

Changes since RFCv3 at [6]:
- moved the DT binding change from patch #3 to patch #1 as suggested by Rob Herring (and slightly adjusted the commit message to account for that)
- added Tested-by from Chunfeng Yun (who confirmed that the whole concept and implementation works fine on Mediatek SoCs - many thanks again!) to patch #2
- added Rob Herring's ACK to patches 1 and 3
- dropped RFC status (RFCv3 -> PATCH v4)

I just wanted to rebase this to v4.14-rc1 (now that this is out) - however I noticed that v4 still applies to v4.14-rc1 cleanly (the patches are still identical to v4 after rebasing).

we have an ACK from the devicetree maintainers and a "Tested-by" for a Mediatek (= non-Amlogic) SoC.
I already have patches for the Amlogic GXL/GXM platforms queued, those are just waiting on this series.

Quoted 4 lines

Quoted 1 line

what is still missing to get this series into v4.15?

Well, we couldn't do anything until 4.14-rc1 is out, now that it is, let us catch up on patch review please...

OK, I understand that.
please let me know once you've caught up with the review backlog - as I said I would like to get this into 4.15 if nothing else comes up during the code-review

Quoted 4 lines

This series works well on the libretech-cc (le potato) For the series:

Tested-by Jerome Brunet <[email protected]>

Hey, I have one of those boards now, was just about to try to get it to work. Is this series necessary for it to run properly on 4.14-rc?

Quoted 95 lines · Jerome Brunet

Quoted 93 lines · Martin Blumenstingl

Hello Greg, Hello Mathias,

Quoted 80 lines · Greg KH

Quoted 79 lines · Martin Blumenstingl

Hello Mathias, Hello Greg,

Quoted 54 lines · Martin Blumenstingl

This series is the outcome of a discussion with Felipe Balbi, see [0] and [1].
The quick-summary of this is:
- dwc3 already takes one USB2 and one USB3 PHY and initializes these correct
- some other HCI platform drivers (like ehci-platform.c, xhci-mtk.c and
ohci-platform.c) do not have a limitation on the number of PHYs -
they
support one PHY per actual host port
- Amlogic Meson GXL and GXM SoCs come with a dwc3 IP block which has two
or three USB2 ports enabled on the internal root-hub. The SoCs
also
provide separate USB2 PHYs, one per port. All USB2 PHYs (which are internally "connected" to the dwc3 roothub) need to be powered on, otherwise USB devices cannot be enumerated (even if just one PHY
is
disabled and if the device is plugged into another, enabled port)

In my first attempt to get USB supported on the GXL and GXM SoCs I tried
to work-around the problem that I could not pass multiple PHYs to the
dwc3 controller.
This was rejected by Rob Herring (which was definitely the thing to do
in
my opinion), see [2]

This series adds a new "platform-roothub". This can be configured through
devicetree by passing a child-node with "reg = <0>" to the USB controller. Additionally there has to be a child-node for each port on
the root-hub. Each of the child-nodes takes a "phys" and "phy-names" property. This allows modeling the root-hub in devicetree similar to the
USB device binding (documented in devicetree/bindings/usb/usb- device.txt)
This avoids and backwards-compatibility problems (which was a concern
regardless of the solution, see [3]) since the binding for the root- hub
was previously not specified (and we're not using the "phys" property of
the controller, which might have served different purposes before, depending on the drivers).

Additionally this integrates the new platform-roothub into xhci- plat.c
which automatically enables it for the dwc3 driver (in host-mode).

Quoted 11 lines

Changes since RFCv3 at [6]:
- moved the DT binding change from patch #3 to patch #1 as suggested by Rob Herring (and slightly adjusted the commit message to
account
for that)
- added Tested-by from Chunfeng Yun (who confirmed that the whole concept and implementation works fine on Mediatek SoCs - many
thanks
again!) to patch #2
- added Rob Herring's ACK to patches 1 and 3
- dropped RFC status (RFCv3 -> PATCH v4)

I just wanted to rebase this to v4.14-rc1 (now that this is out) - however I noticed that v4 still applies to v4.14-rc1 cleanly (the patches are still identical to v4 after rebasing).

we have an ACK from the devicetree maintainers and a "Tested-by" for a Mediatek (= non-Amlogic) SoC.
I already have patches for the Amlogic GXL/GXM platforms queued, those are just waiting on this series.

Quoted 4 lines

Quoted 1 line

what is still missing to get this series into v4.15?

Well, we couldn't do anything until 4.14-rc1 is out, now that it is, let us catch up on patch review please...

OK, I understand that.
please let me know once you've caught up with the review backlog - as I said I would like to get this into 4.15 if nothing else comes up during the code-review

Quoted 4 lines

This series works well on the libretech-cc (le potato) For the series:

Tested-by Jerome Brunet <[email protected]>

Hey, I have one of those boards now, was just about to try to get it to work. Is this series necessary for it to run properly on 4.14-rc?

thanks,

greg k-h