add Tegra194 XUSB host and pad controller support

As xusb-tegra186.c will be reused for Tegra194, it would be good to protect Tegra186 soc data with CONFIG_ARCH_TEGRA_186_SOC. This commit also reshuffles Tegra186 soc data single CONFIG_ARCH_TEGRA_186_SOC will be sufficient.

Signed-off-by JC Kuo <[email protected]>

---
Changes in v4: none
Changes in v3: none
Changes in v2:
- new patch to protect Tegra186 soc data with config

 drivers/phy/tegra/xusb-tegra186.c | 70 ++++++++++++++++---------------
 1 file changed, 36 insertions(+), 34 deletions(-)

Add support for the XUSB pad controller found on Tegra194 SoCs. It is mostly similar to the same IP found on Tegra186, but the number of pads exposed differs, as do the programming sequences. Because most of the Tegra194 XUSB PADCTL registers definition and programming sequence are the same as Tegra186, Tegra194 XUSB PADCTL can share the same driver, xusb-tegra186.c, with Tegra186 XUSB PADCTL.

Tegra194 XUSB PADCTL supports up to USB 3.1 Gen 2 speed, however, it is possible for some platforms have long signal trace that could not provide sufficient electrical environment for Gen 2 speed. This patch introduce a new device node property "nvidia,disable-gen2" that can be used to specifically disable Gen 2 speed for a particular USB 3.0 port so that the port can be limited to Gen 1 speed and avoid the instability.

Signed-off-by JC Kuo <[email protected]>

---
Changes in v4: none
Changes in v3: none
Changes in v2:
- removed unnecessary #if/#endif pairs
- introduce new soc->supports_gen2 flag which indicate whether or not a soc supports USB 3.1 Gen 2 speed

 drivers/phy/tegra/Makefile        |  1 +
 drivers/phy/tegra/xusb-tegra186.c | 74 +++++++++++++++++++++++++++++++
 drivers/phy/tegra/xusb.c          |  7 +++
 drivers/phy/tegra/xusb.h          |  6 +++
 4 files changed, 88 insertions(+)

Extend the bindings to cover the set of features found in Tegra194. Note that, technically, there are four more supplies connected to the XUSB pad controller (DVDD_PEX, DVDD_PEX_PLL, HVDD_PEX and HVDD_PEX_PLL) , but the power sequencing requirements of Tegra194 require these to be under the control of the PMIC.

Tegra194 XUSB PADCTL supports up to USB 3.1 Gen 2 speed, however, it is possible for some platforms have long signal trace that could not provide sufficient electrical environment for Gen 2 speed. To deal with this, a new device node property "nvidia,disable-gen2" was added to Tegra194 that be used to specifically disable Gen 2 speed for a particular USB 3.0 port so that the port can be limited to Gen 1 speed and avoid the instability.

Quoted 6 lines · JC Kuo

Extend the bindings to cover the set of features found in Tegra194. Note that, technically, there are four more supplies connected to the XUSB pad controller (DVDD_PEX, DVDD_PEX_PLL, HVDD_PEX and HVDD_PEX_PLL) , but the power sequencing requirements of Tegra194 require these to be under the control of the PMIC.

Quoted 7 lines

Tegra194 XUSB PADCTL supports up to USB 3.1 Gen 2 speed, however, it is possible for some platforms have long signal trace that could not provide sufficient electrical environment for Gen 2 speed. To deal with this, a new device node property "nvidia,disable-gen2" was added to Tegra194 that be used to specifically disable Gen 2 speed for a particular USB 3.0 port so that the port can be limited to Gen 1 speed and avoid the instability.

I suspect this may be a common issue and we should have a common property. Typically, this kind of property is in the controller though and supports multiple speed limits. See PCI bindings for inspiration.

Quoted 15 lines · Rob Herring

Quoted 6 lines · JC Kuo

Extend the bindings to cover the set of features found in Tegra194. Note that, technically, there are four more supplies connected to the XUSB pad controller (DVDD_PEX, DVDD_PEX_PLL, HVDD_PEX and HVDD_PEX_PLL) , but the power sequencing requirements of Tegra194 require these to be under the control of the PMIC.

Quoted 7 lines

Tegra194 XUSB PADCTL supports up to USB 3.1 Gen 2 speed, however, it is possible for some platforms have long signal trace that could not provide sufficient electrical environment for Gen 2 speed. To deal with this, a new device node property "nvidia,disable-gen2" was added to Tegra194 that be used to specifically disable Gen 2 speed for a particular USB 3.0 port so that the port can be limited to Gen 1 speed and avoid the instability.

Quoted 3 lines

I suspect this may be a common issue and we should have a common property. Typically, this kind of property is in the controller though and supports multiple speed limits. See PCI bindings for inspiration.

Given that support for gen 2 speeds is dependent on signal trace length, it doesn't really make sense to restrict the whole controller to a given speed if only the signal trace for a single port exceeds the limit for which gen 2 would work.

Also, the USB PHYs are in a different hardware block than the USB controller, so this really is a property of the PHY block, not the USB controller.

Quoted 21 lines · Thierry Reding

Quoted 15 lines · Rob Herring

Quoted 6 lines · JC Kuo

Extend the bindings to cover the set of features found in Tegra194. Note that, technically, there are four more supplies connected to the XUSB pad controller (DVDD_PEX, DVDD_PEX_PLL, HVDD_PEX and HVDD_PEX_PLL) , but the power sequencing requirements of Tegra194 require these to be under the control of the PMIC.

Quoted 7 lines

Tegra194 XUSB PADCTL supports up to USB 3.1 Gen 2 speed, however, it is possible for some platforms have long signal trace that could not provide sufficient electrical environment for Gen 2 speed. To deal with this, a new device node property "nvidia,disable-gen2" was added to Tegra194 that be used to specifically disable Gen 2 speed for a particular USB 3.0 port so that the port can be limited to Gen 1 speed and avoid the instability.

Quoted 3 lines

I suspect this may be a common issue and we should have a common property. Typically, this kind of property is in the controller though and supports multiple speed limits. See PCI bindings for inspiration.

Quoted 8 lines

Given that support for gen 2 speeds is dependent on signal trace length, it doesn't really make sense to restrict the whole controller to a given speed if only the signal trace for a single port exceeds the limit for which gen 2 would work.

Also, the USB PHYs are in a different hardware block than the USB controller, so this really is a property of the PHY block, not the USB controller.

Okay, but still should be common for USB PHYs IMO.

Rob

Hi Thierry, Hi Rob, Hi Kishon,
Please let me know your thoughts of the below implementation.

1. Add a "bool disable_gen2" to "phy->attrs" structure.

2. In _of_phy_get() of phy-core.c to add the follow to parse a generic property.

	phy->attrs.disable_gen2 = of_property_read_bool(args.np,
							"usb-disable-gen2");

3. In individual phy driver, to add SOC/PHY specific programming accordingly.

Thanks,
JC

Quoted 35 lines · Rob Herring

Quoted 21 lines · Thierry Reding

Quoted 15 lines · Rob Herring

Quoted 6 lines · JC Kuo

Extend the bindings to cover the set of features found in Tegra194. Note that, technically, there are four more supplies connected to the XUSB pad controller (DVDD_PEX, DVDD_PEX_PLL, HVDD_PEX and HVDD_PEX_PLL) , but the power sequencing requirements of Tegra194 require these to be under the control of the PMIC.

Quoted 7 lines

Tegra194 XUSB PADCTL supports up to USB 3.1 Gen 2 speed, however, it is possible for some platforms have long signal trace that could not provide sufficient electrical environment for Gen 2 speed. To deal with this, a new device node property "nvidia,disable-gen2" was added to Tegra194 that be used to specifically disable Gen 2 speed for a particular USB 3.0 port so that the port can be limited to Gen 1 speed and avoid the instability.

Quoted 3 lines

I suspect this may be a common issue and we should have a common property. Typically, this kind of property is in the controller though and supports multiple speed limits. See PCI bindings for inspiration.

Quoted 8 lines

Given that support for gen 2 speeds is dependent on signal trace length, it doesn't really make sense to restrict the whole controller to a given speed if only the signal trace for a single port exceeds the limit for which gen 2 would work.

Also, the USB PHYs are in a different hardware block than the USB controller, so this really is a property of the PHY block, not the USB controller.

Okay, but still should be common for USB PHYs IMO.

Rob

Hi Thierry, Hi Rob, Hi Kishon,
Please let me know your thoughts of the below implementation.

1. Add a "bool disable_gen2" to "phy->attrs" structure.
2. In _of_phy_get() of phy-core.c to add the follow to parse a generic property.

	phy->attrs.disable_gen2 = of_property_read_bool(args.np,
							"usb-disable-gen2");

3. In individual phy driver, to add SOC/PHY specific programming accordingly.

Thanks,
JC

Quoted 35 lines · Rob Herring

Quoted 21 lines · Thierry Reding

Quoted 15 lines · Rob Herring

Quoted 6 lines · JC Kuo

Extend the bindings to cover the set of features found in Tegra194. Note that, technically, there are four more supplies connected to the XUSB pad controller (DVDD_PEX, DVDD_PEX_PLL, HVDD_PEX and HVDD_PEX_PLL) , but the power sequencing requirements of Tegra194 require these to be under the control of the PMIC.

Quoted 7 lines

Tegra194 XUSB PADCTL supports up to USB 3.1 Gen 2 speed, however, it is possible for some platforms have long signal trace that could not provide sufficient electrical environment for Gen 2 speed. To deal with this, a new device node property "nvidia,disable-gen2" was added to Tegra194 that be used to specifically disable Gen 2 speed for a particular USB 3.0 port so that the port can be limited to Gen 1 speed and avoid the instability.

Quoted 3 lines

I suspect this may be a common issue and we should have a common property. Typically, this kind of property is in the controller though and supports multiple speed limits. See PCI bindings for inspiration.

Quoted 8 lines

Given that support for gen 2 speeds is dependent on signal trace length, it doesn't really make sense to restrict the whole controller to a given speed if only the signal trace for a single port exceeds the limit for which gen 2 would work.

Also, the USB PHYs are in a different hardware block than the USB controller, so this really is a property of the PHY block, not the USB controller.

Okay, but still should be common for USB PHYs IMO.

Rob

Quoted 8 lines · JC Kuo

Hi Thierry, Hi Rob, Hi Kishon,
Please let me know your thoughts of the below implementation.

1. Add a "bool disable_gen2" to "phy->attrs" structure.
2. In _of_phy_get() of phy-core.c to add the follow to parse a generic property.

	phy->attrs.disable_gen2 = of_property_read_bool(args.np,
							"usb-disable-gen2");

Regarding this, I'm not sure how Rob imagined the generic properties to work. Perhaps he was thinking about something like the max-link-speed property found in the PCI bindings.

We could have something like this:

- max-link-speed:
If present this property specifies the USB generation supported on the PHY/port. Must be:
1: for USB 3.1 Gen 1 (a.k.a. USB 3.0)
2: for USB 3.1 Gen 2

I'm not sure if we need to consider anything prior to USB 3.0. I suppose we could do a similar mapping to what I proposed for the PHY ->set_mode callback:

- max-link-speed:

      If present this property specifies the USB generation supported on
      the PHY/port. Must be:
        0x0100: for USB 1.0 (Low-Speed)
        0x0101: for USB 1.1 (Full-Speed)
        0x0200: for USB 2.0 (Hi-Speed)
        0x0300: for USB 3.0 (SuperSpeed) (a.k.a. USB 3.1 Gen 1)
        0x0301: for USB 3.1 (SuperSpeed 10 Gbit/s) (a.k.a. USB 3.1 Gen 2)
        0x0302: for USB 3.2 (SuperSpeed 20 Gbit/s) (a.k.a. USB 3.2 Gen 2 x 2)
        ...

Or those could just be sequentially enumerated, like in the above example.

Rob, any thoughts?

Thierry

Quoted 41 lines

3. In individual phy driver, to add SOC/PHY specific programming accordingly.

Thanks,
JC

Quoted 35 lines · Rob Herring

Quoted 21 lines · Thierry Reding

Quoted 15 lines · Rob Herring

Quoted 6 lines · JC Kuo

Extend the bindings to cover the set of features found in Tegra194. Note that, technically, there are four more supplies connected to the XUSB pad controller (DVDD_PEX, DVDD_PEX_PLL, HVDD_PEX and HVDD_PEX_PLL) , but the power sequencing requirements of Tegra194 require these to be under the control of the PMIC.

Quoted 7 lines

Tegra194 XUSB PADCTL supports up to USB 3.1 Gen 2 speed, however, it is possible for some platforms have long signal trace that could not provide sufficient electrical environment for Gen 2 speed. To deal with this, a new device node property "nvidia,disable-gen2" was added to Tegra194 that be used to specifically disable Gen 2 speed for a particular USB 3.0 port so that the port can be limited to Gen 1 speed and avoid the instability.

Quoted 3 lines

I suspect this may be a common issue and we should have a common property. Typically, this kind of property is in the controller though and supports multiple speed limits. See PCI bindings for inspiration.

Quoted 8 lines

Given that support for gen 2 speeds is dependent on signal trace length, it doesn't really make sense to restrict the whole controller to a given speed if only the signal trace for a single port exceeds the limit for which gen 2 would work.

Also, the USB PHYs are in a different hardware block than the USB controller, so this really is a property of the PHY block, not the USB controller.

Okay, but still should be common for USB PHYs IMO.

Rob