Re: [PATCH v4 2/3] usb: host: add a generic platform USB roothub driver

On 07.10.2017 20:08, Martin Blumenstingl wrote:

Hi Mathias,

thank you for taking the time to go through my patch

On Wed, Oct 4, 2017 at 3:05 PM, Mathias Nyman
[off-list ref] wrote:

quoted

On 04.09.2017 00:38, Martin Blumenstingl wrote:

quoted

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.

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)

I'm not sure what would be the correct place, hcd_bus_suspend() will be called
twice for xhci, oce for each hcd, so then we need to make sure we only turn off
phys related to that hcd. Host controller can still be running when bus is suspended.

xhci-mtk turns off phy when host controller is suspended and stopped.

quoted

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)

Ok

do you see any other issues with this?

Not really, fine by me.

quoted

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.

Ah, ok, I'm used to the ACPI tables way of listing ports where a physical USB3 connector
(HS & SS) is actually described as two separate ports. one HS and one SS.
With this layout one port can have only one PHY.

The Amlogic Meson GXL with two physical USB connectors (USB2&3 and USB2 only)
would look something like this in ACPI:

Device (RHUB) {
	...
	Device (HS01) {...}
	Device (HS02) {...}
	Device (SS01) {...}

xhci register layout is similar.
Each port has its own port status/control register.
Depending on if a USB2 or USB3 device is connected to a physical connector it will trigger
different port status registers.

Not sure which way is better.

-Mathias

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