* [PATCH v4 0/5] add Tegra194 XUSB host and pad controller support
@ 2019-10-09 2:43 JC Kuo
2019-10-09 2:43 ` [PATCH v4 1/5] phy: tegra: xusb: Protect Tegra186 soc with config JC Kuo
` (4 more replies)
0 siblings, 5 replies; 15+ messages in thread
From: JC Kuo @ 2019-10-09 2:43 UTC (permalink / raw)
To: gregkh, thierry.reding, jonathanh, kishon
Cc: linux-tegra, linux-usb, linux-kernel, devicetree, nkristam, JC Kuo
This series introduces support for Tegra194 XUSB host and pad
controller. Tegra194 XUSB host and pad controller are highly
similar to the controllers found on Tegra186. Therefore, it's
possible to resue xhci-tegra.c and xusb-tegra186.c for Tegra194.
Changelog:
v4:
xhci: tegra: Parameterize mailbox register addresses
- removed from v4 as it has been accepted in v3
usb: host: xhci-tegra: Add Tegra194 XHCI support
- removed from v4 as it has been accepted in v3
phy: tegra: xusb: Add Tegra194 support
- no change
dt-bindings: phy: tegra: Add Tegra194 support
- no change
arm64: tegra: Add XUSB and pad controller on Tegra194
- no change
arm64: tegra: Add XUSB and pad controller on Tegra194
- no change
arm64: tegra: Enable XUSB host in P2972-0000 board
- no change
v3:
add change log to cover latter
v2:
xhci: tegra: Parameterize mailbox register addresses
- no change
usb: host: xhci-tegra: Add Tegra194 XHCI support
- no change
phy: tegra: xusb: Protect Tegra186 soc with config
- new patch to protect Tegra186 soc data with config
phy: tegra: xusb: Add Tegra194 support
- 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
dt-bindings: phy: tegra: Add Tegra194 support
- fix a typo
arm64: tegra: Add XUSB and pad controller on Tegra194
- renamed xhci@3610000 with usb@3610000
- moved padctl@3520000 and usb@3610000 inside /cbb
- cleaned up "clocks" property of usb@3610000 node
- added blanks lines to visually separate blocks
arm64: tegra: Enable XUSB host in P2972-0000 board
- use capitalization of regulator names
- fix gpio property of VDD_5V_SATA regulator
JC Kuo (5):
phy: tegra: xusb: Protect Tegra186 soc with config
phy: tegra: xusb: Add Tegra194 support
dt-bindings: phy: tegra: Add Tegra194 support
arm64: tegra: Add XUSB and pad controller on Tegra194
arm64: tegra: Enable XUSB host in P2972-0000 board
.../phy/nvidia,tegra124-xusb-padctl.txt | 16 ++
.../arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 36 ++++-
.../boot/dts/nvidia/tegra194-p2972-0000.dts | 62 ++++++++
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 139 +++++++++++++++++
drivers/phy/tegra/Makefile | 1 +
drivers/phy/tegra/xusb-tegra186.c | 144 +++++++++++++-----
drivers/phy/tegra/xusb.c | 7 +
drivers/phy/tegra/xusb.h | 6 +
8 files changed, 376 insertions(+), 35 deletions(-)
--
2.17.1
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH v4 1/5] phy: tegra: xusb: Protect Tegra186 soc with config
2019-10-09 2:43 [PATCH v4 0/5] add Tegra194 XUSB host and pad controller support JC Kuo
@ 2019-10-09 2:43 ` JC Kuo
2019-10-14 13:11 ` Thierry Reding
2019-10-09 2:43 ` [PATCH v4 2/5] phy: tegra: xusb: Add Tegra194 support JC Kuo
` (3 subsequent siblings)
4 siblings, 1 reply; 15+ messages in thread
From: JC Kuo @ 2019-10-09 2:43 UTC (permalink / raw)
To: gregkh, thierry.reding, jonathanh, kishon
Cc: linux-tegra, linux-usb, linux-kernel, devicetree, nkristam, JC Kuo
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 <jckuo@nvidia.com>
---
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(-)
diff --git a/drivers/phy/tegra/xusb-tegra186.c b/drivers/phy/tegra/xusb-tegra186.c
index 6f3afaf9398f..3b60270f2009 100644
--- a/drivers/phy/tegra/xusb-tegra186.c
+++ b/drivers/phy/tegra/xusb-tegra186.c
@@ -503,19 +503,6 @@ static const char * const tegra186_usb2_functions[] = {
"xusb",
};
-static const struct tegra_xusb_lane_soc tegra186_usb2_lanes[] = {
- TEGRA186_LANE("usb2-0", 0, 0, 0, usb2),
- TEGRA186_LANE("usb2-1", 0, 0, 0, usb2),
- TEGRA186_LANE("usb2-2", 0, 0, 0, usb2),
-};
-
-static const struct tegra_xusb_pad_soc tegra186_usb2_pad = {
- .name = "usb2",
- .num_lanes = ARRAY_SIZE(tegra186_usb2_lanes),
- .lanes = tegra186_usb2_lanes,
- .ops = &tegra186_usb2_pad_ops,
-};
-
static int tegra186_usb2_port_enable(struct tegra_xusb_port *port)
{
return 0;
@@ -765,27 +752,6 @@ static const char * const tegra186_usb3_functions[] = {
"xusb",
};
-static const struct tegra_xusb_lane_soc tegra186_usb3_lanes[] = {
- TEGRA186_LANE("usb3-0", 0, 0, 0, usb3),
- TEGRA186_LANE("usb3-1", 0, 0, 0, usb3),
- TEGRA186_LANE("usb3-2", 0, 0, 0, usb3),
-};
-
-static const struct tegra_xusb_pad_soc tegra186_usb3_pad = {
- .name = "usb3",
- .num_lanes = ARRAY_SIZE(tegra186_usb3_lanes),
- .lanes = tegra186_usb3_lanes,
- .ops = &tegra186_usb3_pad_ops,
-};
-
-static const struct tegra_xusb_pad_soc * const tegra186_pads[] = {
- &tegra186_usb2_pad,
- &tegra186_usb3_pad,
-#if 0 /* TODO implement */
- &tegra186_hsic_pad,
-#endif
-};
-
static int
tegra186_xusb_read_fuse_calibration(struct tegra186_xusb_padctl *padctl)
{
@@ -862,6 +828,7 @@ static const struct tegra_xusb_padctl_ops tegra186_xusb_padctl_ops = {
.remove = tegra186_xusb_padctl_remove,
};
+#if IS_ENABLED(CONFIG_ARCH_TEGRA_186_SOC)
static const char * const tegra186_xusb_padctl_supply_names[] = {
"avdd-pll-erefeut",
"avdd-usb",
@@ -869,6 +836,40 @@ static const char * const tegra186_xusb_padctl_supply_names[] = {
"vddio-hsic",
};
+static const struct tegra_xusb_lane_soc tegra186_usb2_lanes[] = {
+ TEGRA186_LANE("usb2-0", 0, 0, 0, usb2),
+ TEGRA186_LANE("usb2-1", 0, 0, 0, usb2),
+ TEGRA186_LANE("usb2-2", 0, 0, 0, usb2),
+};
+
+static const struct tegra_xusb_pad_soc tegra186_usb2_pad = {
+ .name = "usb2",
+ .num_lanes = ARRAY_SIZE(tegra186_usb2_lanes),
+ .lanes = tegra186_usb2_lanes,
+ .ops = &tegra186_usb2_pad_ops,
+};
+
+static const struct tegra_xusb_lane_soc tegra186_usb3_lanes[] = {
+ TEGRA186_LANE("usb3-0", 0, 0, 0, usb3),
+ TEGRA186_LANE("usb3-1", 0, 0, 0, usb3),
+ TEGRA186_LANE("usb3-2", 0, 0, 0, usb3),
+};
+
+static const struct tegra_xusb_pad_soc tegra186_usb3_pad = {
+ .name = "usb3",
+ .num_lanes = ARRAY_SIZE(tegra186_usb3_lanes),
+ .lanes = tegra186_usb3_lanes,
+ .ops = &tegra186_usb3_pad_ops,
+};
+
+static const struct tegra_xusb_pad_soc * const tegra186_pads[] = {
+ &tegra186_usb2_pad,
+ &tegra186_usb3_pad,
+#if 0 /* TODO implement */
+ &tegra186_hsic_pad,
+#endif
+};
+
const struct tegra_xusb_padctl_soc tegra186_xusb_padctl_soc = {
.num_pads = ARRAY_SIZE(tegra186_pads),
.pads = tegra186_pads,
@@ -893,6 +894,7 @@ const struct tegra_xusb_padctl_soc tegra186_xusb_padctl_soc = {
.num_supplies = ARRAY_SIZE(tegra186_xusb_padctl_supply_names),
};
EXPORT_SYMBOL_GPL(tegra186_xusb_padctl_soc);
+#endif
MODULE_AUTHOR("JC Kuo <jckuo@nvidia.com>");
MODULE_DESCRIPTION("NVIDIA Tegra186 XUSB Pad Controller driver");
--
2.17.1
^ permalink raw reply related [flat|nested] 15+ messages in thread
* [PATCH v4 2/5] phy: tegra: xusb: Add Tegra194 support
2019-10-09 2:43 [PATCH v4 0/5] add Tegra194 XUSB host and pad controller support JC Kuo
2019-10-09 2:43 ` [PATCH v4 1/5] phy: tegra: xusb: Protect Tegra186 soc with config JC Kuo
@ 2019-10-09 2:43 ` JC Kuo
2019-10-14 13:12 ` Thierry Reding
2019-10-09 2:43 ` [PATCH v4 3/5] dt-bindings: phy: tegra: " JC Kuo
` (2 subsequent siblings)
4 siblings, 1 reply; 15+ messages in thread
From: JC Kuo @ 2019-10-09 2:43 UTC (permalink / raw)
To: gregkh, thierry.reding, jonathanh, kishon
Cc: linux-tegra, linux-usb, linux-kernel, devicetree, nkristam, JC Kuo
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 <jckuo@nvidia.com>
---
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(+)
diff --git a/drivers/phy/tegra/Makefile b/drivers/phy/tegra/Makefile
index 320dd389f34d..89b84067cb4c 100644
--- a/drivers/phy/tegra/Makefile
+++ b/drivers/phy/tegra/Makefile
@@ -6,4 +6,5 @@ phy-tegra-xusb-$(CONFIG_ARCH_TEGRA_124_SOC) += xusb-tegra124.o
phy-tegra-xusb-$(CONFIG_ARCH_TEGRA_132_SOC) += xusb-tegra124.o
phy-tegra-xusb-$(CONFIG_ARCH_TEGRA_210_SOC) += xusb-tegra210.o
phy-tegra-xusb-$(CONFIG_ARCH_TEGRA_186_SOC) += xusb-tegra186.o
+phy-tegra-xusb-$(CONFIG_ARCH_TEGRA_194_SOC) += xusb-tegra186.o
obj-$(CONFIG_PHY_TEGRA194_P2U) += phy-tegra194-p2u.o
diff --git a/drivers/phy/tegra/xusb-tegra186.c b/drivers/phy/tegra/xusb-tegra186.c
index 3b60270f2009..74baa1dbca6c 100644
--- a/drivers/phy/tegra/xusb-tegra186.c
+++ b/drivers/phy/tegra/xusb-tegra186.c
@@ -64,6 +64,11 @@
#define SSPX_ELPG_CLAMP_EN_EARLY(x) BIT(1 + (x) * 3)
#define SSPX_ELPG_VCORE_DOWN(x) BIT(2 + (x) * 3)
+#define XUSB_PADCTL_SS_PORT_CFG 0x2c
+#define PORTX_SPEED_SUPPORT_SHIFT(x) ((x) * 4)
+#define PORTX_SPEED_SUPPORT_MASK (0x3)
+#define PORT_SPEED_SUPPORT_GEN1 (0x0)
+
#define XUSB_PADCTL_USB2_OTG_PADX_CTL0(x) (0x88 + (x) * 0x40)
#define HS_CURR_LEVEL(x) ((x) & 0x3f)
#define TERM_SEL BIT(25)
@@ -622,6 +627,15 @@ static int tegra186_usb3_phy_power_on(struct phy *phy)
padctl_writel(padctl, value, XUSB_PADCTL_SS_PORT_CAP);
+ if (padctl->soc->supports_gen2 && port->disable_gen2) {
+ value = padctl_readl(padctl, XUSB_PADCTL_SS_PORT_CFG);
+ value &= ~(PORTX_SPEED_SUPPORT_MASK <<
+ PORTX_SPEED_SUPPORT_SHIFT(index));
+ value |= (PORT_SPEED_SUPPORT_GEN1 <<
+ PORTX_SPEED_SUPPORT_SHIFT(index));
+ padctl_writel(padctl, value, XUSB_PADCTL_SS_PORT_CFG);
+ }
+
value = padctl_readl(padctl, XUSB_PADCTL_ELPG_PROGRAM_1);
value &= ~SSPX_ELPG_VCORE_DOWN(index);
padctl_writel(padctl, value, XUSB_PADCTL_ELPG_PROGRAM_1);
@@ -896,6 +910,66 @@ const struct tegra_xusb_padctl_soc tegra186_xusb_padctl_soc = {
EXPORT_SYMBOL_GPL(tegra186_xusb_padctl_soc);
#endif
+#if IS_ENABLED(CONFIG_ARCH_TEGRA_194_SOC)
+static const char * const tegra194_xusb_padctl_supply_names[] = {
+ "avdd-usb",
+ "vclamp-usb",
+};
+
+static const struct tegra_xusb_lane_soc tegra194_usb2_lanes[] = {
+ TEGRA186_LANE("usb2-0", 0, 0, 0, usb2),
+ TEGRA186_LANE("usb2-1", 0, 0, 0, usb2),
+ TEGRA186_LANE("usb2-2", 0, 0, 0, usb2),
+ TEGRA186_LANE("usb2-3", 0, 0, 0, usb2),
+};
+
+static const struct tegra_xusb_pad_soc tegra194_usb2_pad = {
+ .name = "usb2",
+ .num_lanes = ARRAY_SIZE(tegra194_usb2_lanes),
+ .lanes = tegra194_usb2_lanes,
+ .ops = &tegra186_usb2_pad_ops,
+};
+
+static const struct tegra_xusb_lane_soc tegra194_usb3_lanes[] = {
+ TEGRA186_LANE("usb3-0", 0, 0, 0, usb3),
+ TEGRA186_LANE("usb3-1", 0, 0, 0, usb3),
+ TEGRA186_LANE("usb3-2", 0, 0, 0, usb3),
+ TEGRA186_LANE("usb3-3", 0, 0, 0, usb3),
+};
+
+static const struct tegra_xusb_pad_soc tegra194_usb3_pad = {
+ .name = "usb3",
+ .num_lanes = ARRAY_SIZE(tegra194_usb3_lanes),
+ .lanes = tegra194_usb3_lanes,
+ .ops = &tegra186_usb3_pad_ops,
+};
+
+static const struct tegra_xusb_pad_soc * const tegra194_pads[] = {
+ &tegra194_usb2_pad,
+ &tegra194_usb3_pad,
+};
+
+const struct tegra_xusb_padctl_soc tegra194_xusb_padctl_soc = {
+ .num_pads = ARRAY_SIZE(tegra194_pads),
+ .pads = tegra194_pads,
+ .ports = {
+ .usb2 = {
+ .ops = &tegra186_usb2_port_ops,
+ .count = 4,
+ },
+ .usb3 = {
+ .ops = &tegra186_usb3_port_ops,
+ .count = 4,
+ },
+ },
+ .ops = &tegra186_xusb_padctl_ops,
+ .supply_names = tegra194_xusb_padctl_supply_names,
+ .num_supplies = ARRAY_SIZE(tegra194_xusb_padctl_supply_names),
+ .supports_gen2 = true,
+};
+EXPORT_SYMBOL_GPL(tegra194_xusb_padctl_soc);
+#endif
+
MODULE_AUTHOR("JC Kuo <jckuo@nvidia.com>");
MODULE_DESCRIPTION("NVIDIA Tegra186 XUSB Pad Controller driver");
MODULE_LICENSE("GPL v2");
diff --git a/drivers/phy/tegra/xusb.c b/drivers/phy/tegra/xusb.c
index 2ea8497af82a..e359a75d9543 100644
--- a/drivers/phy/tegra/xusb.c
+++ b/drivers/phy/tegra/xusb.c
@@ -65,6 +65,12 @@ static const struct of_device_id tegra_xusb_padctl_of_match[] = {
.compatible = "nvidia,tegra186-xusb-padctl",
.data = &tegra186_xusb_padctl_soc,
},
+#endif
+#if defined(CONFIG_ARCH_TEGRA_194_SOC)
+ {
+ .compatible = "nvidia,tegra194-xusb-padctl",
+ .data = &tegra194_xusb_padctl_soc,
+ },
#endif
{ }
};
@@ -738,6 +744,7 @@ static int tegra_xusb_usb3_port_parse_dt(struct tegra_xusb_usb3_port *usb3)
usb3->port = value;
usb3->internal = of_property_read_bool(np, "nvidia,internal");
+ usb3->disable_gen2 = of_property_read_bool(np, "nvidia,disable-gen2");
usb3->supply = devm_regulator_get(&port->dev, "vbus");
return PTR_ERR_OR_ZERO(usb3->supply);
diff --git a/drivers/phy/tegra/xusb.h b/drivers/phy/tegra/xusb.h
index 093076ca27fd..8312129caf96 100644
--- a/drivers/phy/tegra/xusb.h
+++ b/drivers/phy/tegra/xusb.h
@@ -332,6 +332,7 @@ struct tegra_xusb_usb3_port {
bool context_saved;
unsigned int port;
bool internal;
+ bool disable_gen2;
u32 tap1;
u32 amp;
@@ -389,6 +390,8 @@ struct tegra_xusb_padctl_soc {
const char * const *supply_names;
unsigned int num_supplies;
+
+ bool supports_gen2;
};
struct tegra_xusb_padctl {
@@ -444,5 +447,8 @@ extern const struct tegra_xusb_padctl_soc tegra210_xusb_padctl_soc;
#if defined(CONFIG_ARCH_TEGRA_186_SOC)
extern const struct tegra_xusb_padctl_soc tegra186_xusb_padctl_soc;
#endif
+#if defined(CONFIG_ARCH_TEGRA_194_SOC)
+extern const struct tegra_xusb_padctl_soc tegra194_xusb_padctl_soc;
+#endif
#endif /* __PHY_TEGRA_XUSB_H */
--
2.17.1
^ permalink raw reply related [flat|nested] 15+ messages in thread
* [PATCH v4 3/5] dt-bindings: phy: tegra: Add Tegra194 support
2019-10-09 2:43 [PATCH v4 0/5] add Tegra194 XUSB host and pad controller support JC Kuo
2019-10-09 2:43 ` [PATCH v4 1/5] phy: tegra: xusb: Protect Tegra186 soc with config JC Kuo
2019-10-09 2:43 ` [PATCH v4 2/5] phy: tegra: xusb: Add Tegra194 support JC Kuo
@ 2019-10-09 2:43 ` JC Kuo
2019-10-09 23:39 ` Rob Herring
2019-10-09 2:43 ` [PATCH v4 4/5] arm64: tegra: Add XUSB and pad controller on Tegra194 JC Kuo
2019-10-09 2:43 ` [PATCH v4 5/5] arm64: tegra: Enable XUSB host in P2972-0000 board JC Kuo
4 siblings, 1 reply; 15+ messages in thread
From: JC Kuo @ 2019-10-09 2:43 UTC (permalink / raw)
To: gregkh, thierry.reding, jonathanh, kishon
Cc: linux-tegra, linux-usb, linux-kernel, devicetree, nkristam, 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.
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.
Signed-off-by: JC Kuo <jckuo@nvidia.com>
---
Changes in v4: none
Changes in v3: none
Changes in v2:
- fix a typo
.../bindings/phy/nvidia,tegra124-xusb-padctl.txt | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt b/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt
index 9fb682e47c29..59d870fa42e9 100644
--- a/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt
+++ b/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt
@@ -37,6 +37,7 @@ Required properties:
- Tegra132: "nvidia,tegra132-xusb-padctl", "nvidia,tegra124-xusb-padctl"
- Tegra210: "nvidia,tegra210-xusb-padctl"
- Tegra186: "nvidia,tegra186-xusb-padctl"
+ - Tegra194: "nvidia,tegra194-xusb-padctl"
- reg: Physical base address and length of the controller's registers.
- resets: Must contain an entry for each entry in reset-names.
- reset-names: Must include the following entries:
@@ -62,6 +63,10 @@ For Tegra186:
- vclamp-usb-supply: Bias rail for USB pad. Must supply 1.8 V.
- vddio-hsic-supply: HSIC PHY power supply. Must supply 1.2 V.
+For Tegra194:
+- avdd-usb-supply: USB I/Os, VBUS, ID, REXT, D+/D- power supply. Must supply
+ 3.3 V.
+- vclamp-usb-supply: Bias rail for USB pad. Must supply 1.8 V.
Pad nodes:
==========
@@ -154,6 +159,11 @@ For Tegra210, the list of valid PHY nodes is given below:
- sata: sata-0
- functions: "usb3-ss", "sata"
+For Tegra194, the list of valid PHY nodes is given below:
+- usb2: usb2-0, usb2-1, usb2-2, usb2-3
+ - functions: "xusb"
+- usb3: usb3-0, usb3-1, usb3-2, usb3-3
+ - functions: "xusb"
Port nodes:
===========
@@ -221,6 +231,9 @@ Optional properties:
is internal. In the absence of this property the port is considered to be
external.
+- nvidia,disable-gen2: A boolean property whose presence determines that a port
+ should be limited to USB 3.1 Gen 1. This property is only for Tegra194.
+
For Tegra124 and Tegra132, the XUSB pad controller exposes the following
ports:
- 3x USB2: usb2-0, usb2-1, usb2-2
@@ -233,6 +246,9 @@ For Tegra210, the XUSB pad controller exposes the following ports:
- 2x HSIC: hsic-0, hsic-1
- 4x super-speed USB: usb3-0, usb3-1, usb3-2, usb3-3
+For Tegra194, the XUSB pad controller exposes the following ports:
+- 4x USB2: usb2-0, usb2-1, usb2-2, usb2-3
+- 4x super-speed USB: usb3-0, usb3-1, usb3-2, usb3-3
Examples:
=========
--
2.17.1
^ permalink raw reply related [flat|nested] 15+ messages in thread
* [PATCH v4 4/5] arm64: tegra: Add XUSB and pad controller on Tegra194
2019-10-09 2:43 [PATCH v4 0/5] add Tegra194 XUSB host and pad controller support JC Kuo
` (2 preceding siblings ...)
2019-10-09 2:43 ` [PATCH v4 3/5] dt-bindings: phy: tegra: " JC Kuo
@ 2019-10-09 2:43 ` JC Kuo
2019-10-09 2:43 ` [PATCH v4 5/5] arm64: tegra: Enable XUSB host in P2972-0000 board JC Kuo
4 siblings, 0 replies; 15+ messages in thread
From: JC Kuo @ 2019-10-09 2:43 UTC (permalink / raw)
To: gregkh, thierry.reding, jonathanh, kishon
Cc: linux-tegra, linux-usb, linux-kernel, devicetree, nkristam, JC Kuo
Adds the XUSB pad and XUSB controllers on Tegra194.
Signed-off-by: JC Kuo <jckuo@nvidia.com>
---
Changes in v4: none
Changes in v3: none
Changes in v2:
- renamed xhci@3610000 with usb@3610000
- moved padctl@3520000 and usb@3610000 inside /cbb
- cleaned up "clocks" property of usb@3610000 node
- added blanks lines to visually separate blocks
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 139 +++++++++++++++++++++++
1 file changed, 139 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 3c0cf54f0aab..3c7ea264bc1c 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -487,6 +487,145 @@
status = "disabled";
};
+ xusb_padctl: padctl@3520000 {
+ compatible = "nvidia,tegra194-xusb-padctl";
+ reg = <0x03520000 0x1000>,
+ <0x03540000 0x1000>;
+ reg-names = "padctl", "ao";
+
+ resets = <&bpmp TEGRA194_RESET_XUSB_PADCTL>;
+ reset-names = "padctl";
+
+ status = "disabled";
+
+ pads {
+ usb2 {
+ clocks = <&bpmp TEGRA194_CLK_USB2_TRK>;
+ clock-names = "trk";
+
+ lanes {
+ usb2-0 {
+ nvidia,function = "xusb";
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ usb2-1 {
+ nvidia,function = "xusb";
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ usb2-2 {
+ nvidia,function = "xusb";
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ usb2-3 {
+ nvidia,function = "xusb";
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ usb3 {
+ lanes {
+ usb3-0 {
+ nvidia,function = "xusb";
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ usb3-1 {
+ nvidia,function = "xusb";
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ usb3-2 {
+ nvidia,function = "xusb";
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ usb3-3 {
+ nvidia,function = "xusb";
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+ };
+ };
+ };
+
+ ports {
+ usb2-0 {
+ status = "disabled";
+ };
+
+ usb2-1 {
+ status = "disabled";
+ };
+
+ usb2-2 {
+ status = "disabled";
+ };
+
+ usb2-3 {
+ status = "disabled";
+ };
+
+ usb3-0 {
+ status = "disabled";
+ };
+
+ usb3-1 {
+ status = "disabled";
+ };
+
+ usb3-2 {
+ status = "disabled";
+ };
+
+ usb3-3 {
+ status = "disabled";
+ };
+ };
+ };
+
+ usb@3610000 {
+ compatible = "nvidia,tegra194-xusb";
+ reg = <0x03610000 0x40000>,
+ < 0x03600000 0x10000>;
+ reg-names = "hcd", "fpci";
+
+ interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>;
+
+ clocks = <&bpmp TEGRA194_CLK_XUSB_CORE_HOST>,
+ <&bpmp TEGRA194_CLK_XUSB_FALCON>,
+ <&bpmp TEGRA194_CLK_XUSB_CORE_SS>,
+ <&bpmp TEGRA194_CLK_XUSB_SS>,
+ <&bpmp TEGRA194_CLK_CLK_M>,
+ <&bpmp TEGRA194_CLK_XUSB_FS>,
+ <&bpmp TEGRA194_CLK_UTMIPLL>,
+ <&bpmp TEGRA194_CLK_CLK_M>,
+ <&bpmp TEGRA194_CLK_PLLE>;
+ clock-names = "xusb_host", "xusb_falcon_src",
+ "xusb_ss", "xusb_ss_src", "xusb_hs_src",
+ "xusb_fs_src", "pll_u_480m", "clk_m",
+ "pll_e";
+
+ power-domains = <&bpmp TEGRA194_POWER_DOMAIN_XUSBC>,
+ <&bpmp TEGRA194_POWER_DOMAIN_XUSBA>;
+ power-domain-names = "xusb_host", "xusb_ss";
+
+ nvidia,xusb-padctl = <&xusb_padctl>;
+ status = "disabled";
+ };
+
gic: interrupt-controller@3881000 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
--
2.17.1
^ permalink raw reply related [flat|nested] 15+ messages in thread
* [PATCH v4 5/5] arm64: tegra: Enable XUSB host in P2972-0000 board
2019-10-09 2:43 [PATCH v4 0/5] add Tegra194 XUSB host and pad controller support JC Kuo
` (3 preceding siblings ...)
2019-10-09 2:43 ` [PATCH v4 4/5] arm64: tegra: Add XUSB and pad controller on Tegra194 JC Kuo
@ 2019-10-09 2:43 ` JC Kuo
4 siblings, 0 replies; 15+ messages in thread
From: JC Kuo @ 2019-10-09 2:43 UTC (permalink / raw)
To: gregkh, thierry.reding, jonathanh, kishon
Cc: linux-tegra, linux-usb, linux-kernel, devicetree, nkristam, JC Kuo
This commit enables XUSB host and pad controller in Tegra194
P2972-0000 board.
Signed-off-by: JC Kuo <jckuo@nvidia.com>
---
Changes in v4: none
Changes in v3: none
Changes in v2:
- use capitalization of regulator names
- fix gpio property of VDD_5V_SATA regulator
.../arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 36 ++++++++++-
.../boot/dts/nvidia/tegra194-p2972-0000.dts | 62 +++++++++++++++++++
2 files changed, 97 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi b/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
index 4c38426a6969..e7d5e8a30f93 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
@@ -66,6 +66,29 @@
vmmc-supply = <&vdd_emmc_3v3>;
};
+ padctl@3520000 {
+ avdd-usb-supply = <&vdd_usb_3v3>;
+ vclamp-usb-supply = <&vdd_1v8ao>;
+
+ ports {
+ usb2-1 {
+ vbus-supply = <&vdd_5v0_sys>;
+ };
+
+ usb2-3 {
+ vbus-supply = <&vdd_5v_sata>;
+ };
+
+ usb3-0 {
+ vbus-supply = <&vdd_5v0_sys>;
+ };
+
+ usb3-3 {
+ vbus-supply = <&vdd_5v0_sys>;
+ };
+ };
+ };
+
rtc@c2a0000 {
status = "okay";
};
@@ -229,7 +252,7 @@
regulator-max-microvolt = <3300000>;
};
- ldo5 {
+ vdd_usb_3v3: ldo5 {
regulator-name = "VDD_USB_3V3";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
@@ -313,5 +336,16 @@
regulator-boot-on;
enable-active-low;
};
+
+ vdd_5v_sata: regulator@4 {
+ compatible = "regulator-fixed";
+ reg = <4>;
+
+ regulator-name = "VDD_5V_SATA";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio TEGRA194_MAIN_GPIO(Z, 1) GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
};
};
diff --git a/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts b/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
index d47cd8c4dd24..b60eef64c487 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
+++ b/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
@@ -62,6 +62,68 @@
GPIO_ACTIVE_LOW>;
};
};
+ padctl@3520000 {
+ status = "okay";
+
+ pads {
+ usb2 {
+ lanes {
+ usb2-1 {
+ status = "okay";
+ };
+
+ usb2-3 {
+ status = "okay";
+ };
+ };
+ };
+
+ usb3 {
+ lanes {
+ usb3-0 {
+ status = "okay";
+ };
+
+ usb3-3 {
+ status = "okay";
+ };
+ };
+ };
+ };
+
+ ports {
+ usb2-1 {
+ mode = "host";
+ status = "okay";
+ };
+
+ usb2-3 {
+ mode = "host";
+ status = "okay";
+ };
+
+ usb3-0 {
+ nvidia,usb2-companion = <1>;
+ status = "okay";
+ };
+
+ usb3-3 {
+ nvidia,usb2-companion = <3>;
+ nvidia,disable-gen2;
+ status = "okay";
+ };
+ };
+ };
+
+ usb@3610000 {
+ status = "okay";
+
+ phys = <&{/cbb/padctl@3520000/pads/usb2/lanes/usb2-1}>,
+ <&{/cbb/padctl@3520000/pads/usb2/lanes/usb2-3}>,
+ <&{/cbb/padctl@3520000/pads/usb3/lanes/usb3-0}>,
+ <&{/cbb/padctl@3520000/pads/usb3/lanes/usb3-3}>;
+ phy-names = "usb2-1", "usb2-3", "usb3-0", "usb3-3";
+ };
};
pcie@14100000 {
--
2.17.1
^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH v4 3/5] dt-bindings: phy: tegra: Add Tegra194 support
2019-10-09 2:43 ` [PATCH v4 3/5] dt-bindings: phy: tegra: " JC Kuo
@ 2019-10-09 23:39 ` Rob Herring
2019-10-14 13:17 ` Thierry Reding
0 siblings, 1 reply; 15+ messages in thread
From: Rob Herring @ 2019-10-09 23:39 UTC (permalink / raw)
To: JC Kuo
Cc: gregkh, thierry.reding, jonathanh, kishon, linux-tegra,
linux-usb, linux-kernel, devicetree, nkristam
On Wed, Oct 09, 2019 at 10:43:41AM +0800, JC Kuo wrote:
> 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.
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.
Rob
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v4 1/5] phy: tegra: xusb: Protect Tegra186 soc with config
2019-10-09 2:43 ` [PATCH v4 1/5] phy: tegra: xusb: Protect Tegra186 soc with config JC Kuo
@ 2019-10-14 13:11 ` Thierry Reding
0 siblings, 0 replies; 15+ messages in thread
From: Thierry Reding @ 2019-10-14 13:11 UTC (permalink / raw)
To: JC Kuo
Cc: gregkh, jonathanh, kishon, linux-tegra, linux-usb, linux-kernel,
devicetree, nkristam
[-- Attachment #1: Type: text/plain, Size: 651 bytes --]
On Wed, Oct 09, 2019 at 10:43:39AM +0800, JC Kuo wrote:
> 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 <jckuo@nvidia.com>
> ---
> 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(-)
Acked-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v4 2/5] phy: tegra: xusb: Add Tegra194 support
2019-10-09 2:43 ` [PATCH v4 2/5] phy: tegra: xusb: Add Tegra194 support JC Kuo
@ 2019-10-14 13:12 ` Thierry Reding
0 siblings, 0 replies; 15+ messages in thread
From: Thierry Reding @ 2019-10-14 13:12 UTC (permalink / raw)
To: JC Kuo
Cc: gregkh, jonathanh, kishon, linux-tegra, linux-usb, linux-kernel,
devicetree, nkristam
[-- Attachment #1: Type: text/plain, Size: 1500 bytes --]
On Wed, Oct 09, 2019 at 10:43:40AM +0800, JC Kuo wrote:
> 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 <jckuo@nvidia.com>
> ---
> 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(+)
Acked-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v4 3/5] dt-bindings: phy: tegra: Add Tegra194 support
2019-10-09 23:39 ` Rob Herring
@ 2019-10-14 13:17 ` Thierry Reding
2019-10-14 13:40 ` Rob Herring
0 siblings, 1 reply; 15+ messages in thread
From: Thierry Reding @ 2019-10-14 13:17 UTC (permalink / raw)
To: Rob Herring
Cc: JC Kuo, gregkh, jonathanh, kishon, linux-tegra, linux-usb,
linux-kernel, devicetree, nkristam
[-- Attachment #1: Type: text/plain, Size: 1573 bytes --]
On Wed, Oct 09, 2019 at 06:39:00PM -0500, Rob Herring wrote:
> On Wed, Oct 09, 2019 at 10:43:41AM +0800, JC Kuo wrote:
> > 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.
>
> 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.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v4 3/5] dt-bindings: phy: tegra: Add Tegra194 support
2019-10-14 13:17 ` Thierry Reding
@ 2019-10-14 13:40 ` Rob Herring
2019-10-17 7:48 ` JC Kuo
0 siblings, 1 reply; 15+ messages in thread
From: Rob Herring @ 2019-10-14 13:40 UTC (permalink / raw)
To: Thierry Reding
Cc: JC Kuo, Greg Kroah-Hartman, Jon Hunter, Kishon Vijay Abraham I,
linux-tegra, Linux USB List, linux-kernel, devicetree,
Nagarjuna Kristam
On Mon, Oct 14, 2019 at 8:17 AM Thierry Reding <thierry.reding@gmail.com> wrote:
>
> On Wed, Oct 09, 2019 at 06:39:00PM -0500, Rob Herring wrote:
> > On Wed, Oct 09, 2019 at 10:43:41AM +0800, JC Kuo wrote:
> > > 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.
> >
> > 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.
Okay, but still should be common for USB PHYs IMO.
Rob
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v4 3/5] dt-bindings: phy: tegra: Add Tegra194 support
2019-10-14 13:40 ` Rob Herring
@ 2019-10-17 7:48 ` JC Kuo
2019-10-17 11:44 ` Thierry Reding
2019-10-17 12:01 ` Thierry Reding
0 siblings, 2 replies; 15+ messages in thread
From: JC Kuo @ 2019-10-17 7:48 UTC (permalink / raw)
To: Rob Herring, Thierry Reding
Cc: Greg Kroah-Hartman, Jon Hunter, Kishon Vijay Abraham I,
linux-tegra, Linux USB List, linux-kernel, devicetree,
Nagarjuna Kristam
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
On 10/14/19 9:40 PM, Rob Herring wrote:
> On Mon, Oct 14, 2019 at 8:17 AM Thierry Reding <thierry.reding@gmail.com> wrote:
>>
>> On Wed, Oct 09, 2019 at 06:39:00PM -0500, Rob Herring wrote:
>>> On Wed, Oct 09, 2019 at 10:43:41AM +0800, JC Kuo wrote:
>>>> 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.
>>>
>>> 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.
>
> Okay, but still should be common for USB PHYs IMO.
>
> Rob
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v4 3/5] dt-bindings: phy: tegra: Add Tegra194 support
2019-10-17 7:48 ` JC Kuo
@ 2019-10-17 11:44 ` Thierry Reding
2019-10-17 12:01 ` Thierry Reding
1 sibling, 0 replies; 15+ messages in thread
From: Thierry Reding @ 2019-10-17 11:44 UTC (permalink / raw)
To: JC Kuo
Cc: Rob Herring, Greg Kroah-Hartman, Jon Hunter,
Kishon Vijay Abraham I, linux-tegra, Linux USB List,
linux-kernel, devicetree, Nagarjuna Kristam
[-- Attachment #1: Type: text/plain, Size: 3354 bytes --]
On Thu, Oct 17, 2019 at 03:48:52PM +0800, JC Kuo wrote:
> 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.
phy->attrs is pretty bus agnostic, so adding a USB-specific property
doesn't sound like the right thing to do here.
> 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.
Could this perhaps be done using the ->set_mode() callback? We don't
currently implement that, but we could implement it and then perhaps use
the submode parameter to distinguish between USB 3.1 Gen 1 and USB 3.1
Gen 2. Perhaps a good mapping would look like this:
USB 3.1 Gen 1: mode = PHY_MODE_USB_HOST_SS, submode = 0x0300
USB 3.1 Gen 2: mode = PHY_MODE_USB_HOST_SS, submode = 0x0301
The above basically reflects that USB 3.1 Gen 1 is really USB 3.0. This
would also work with other speeds:
USB 2.0: mode = PHY_MODE_USB_HOST_HS, submode = 0x0200
etc. I suppose to make this clearer we could add defines for the various
submodes. It seems like submode may be intended to represent one of the
interface modes defined by USBPHY_INTERFACE_MODE_*, but perhaps it can
be repurposed for PHY_MODE_USB_HOST_SS?
Thierry
>
> Thanks,
> JC
>
> On 10/14/19 9:40 PM, Rob Herring wrote:
> > On Mon, Oct 14, 2019 at 8:17 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> >>
> >> On Wed, Oct 09, 2019 at 06:39:00PM -0500, Rob Herring wrote:
> >>> On Wed, Oct 09, 2019 at 10:43:41AM +0800, JC Kuo wrote:
> >>>> 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.
> >>>
> >>> 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.
> >
> > Okay, but still should be common for USB PHYs IMO.
> >
> > Rob
> >
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v4 3/5] dt-bindings: phy: tegra: Add Tegra194 support
2019-10-17 7:48 ` JC Kuo
2019-10-17 11:44 ` Thierry Reding
@ 2019-10-17 12:01 ` Thierry Reding
2019-11-26 4:21 ` Nagarjuna Kristam
1 sibling, 1 reply; 15+ messages in thread
From: Thierry Reding @ 2019-10-17 12:01 UTC (permalink / raw)
To: JC Kuo, Rob Herring
Cc: Greg Kroah-Hartman, Jon Hunter, Kishon Vijay Abraham I,
linux-tegra, Linux USB List, linux-kernel, devicetree,
Nagarjuna Kristam
[-- Attachment #1: Type: text/plain, Size: 3569 bytes --]
On Thu, Oct 17, 2019 at 03:48:52PM +0800, JC Kuo wrote:
> 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
> 3. In individual phy driver, to add SOC/PHY specific programming accordingly.
>
> Thanks,
> JC
>
> On 10/14/19 9:40 PM, Rob Herring wrote:
> > On Mon, Oct 14, 2019 at 8:17 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> >>
> >> On Wed, Oct 09, 2019 at 06:39:00PM -0500, Rob Herring wrote:
> >>> On Wed, Oct 09, 2019 at 10:43:41AM +0800, JC Kuo wrote:
> >>>> 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.
> >>>
> >>> 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.
> >
> > Okay, but still should be common for USB PHYs IMO.
> >
> > Rob
> >
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v4 3/5] dt-bindings: phy: tegra: Add Tegra194 support
2019-10-17 12:01 ` Thierry Reding
@ 2019-11-26 4:21 ` Nagarjuna Kristam
0 siblings, 0 replies; 15+ messages in thread
From: Nagarjuna Kristam @ 2019-11-26 4:21 UTC (permalink / raw)
To: Thierry Reding, JC Kuo, Rob Herring
Cc: Greg Kroah-Hartman, Jon Hunter, Kishon Vijay Abraham I,
linux-tegra, Linux USB List, linux-kernel, devicetree
On 17-10-2019 17:31, Thierry Reding wrote:
> On Thu, Oct 17, 2019 at 03:48:52PM +0800, JC Kuo wrote:
>> 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
>
"Documentation/devicetree/bindings/usb/generic.txt" file already has dt-property named
maximum-speed, which fulfills current requirement. So to disable gen2 feature simply
add below entry to corresponding usb3 port entry.
padctl@3520000 {
status = "okay";
ports {
usb3-3 {
maximum-speed = "super-speed";
};
};
Read the property using API usb_get_maximum_speed.
Thanks,
Nagarjuna
>> 3. In individual phy driver, to add SOC/PHY specific programming accordingly.
>>
>> Thanks,
>> JC
>>
>> On 10/14/19 9:40 PM, Rob Herring wrote:
>>> On Mon, Oct 14, 2019 at 8:17 AM Thierry Reding <thierry.reding@gmail.com> wrote:
>>>>
>>>> On Wed, Oct 09, 2019 at 06:39:00PM -0500, Rob Herring wrote:
>>>>> On Wed, Oct 09, 2019 at 10:43:41AM +0800, JC Kuo wrote:
>>>>>> 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.
>>>>>
>>>>> 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.
>>>
>>> Okay, but still should be common for USB PHYs IMO.
>>>
>>> Rob
>>>
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2019-11-26 4:20 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-09 2:43 [PATCH v4 0/5] add Tegra194 XUSB host and pad controller support JC Kuo
2019-10-09 2:43 ` [PATCH v4 1/5] phy: tegra: xusb: Protect Tegra186 soc with config JC Kuo
2019-10-14 13:11 ` Thierry Reding
2019-10-09 2:43 ` [PATCH v4 2/5] phy: tegra: xusb: Add Tegra194 support JC Kuo
2019-10-14 13:12 ` Thierry Reding
2019-10-09 2:43 ` [PATCH v4 3/5] dt-bindings: phy: tegra: " JC Kuo
2019-10-09 23:39 ` Rob Herring
2019-10-14 13:17 ` Thierry Reding
2019-10-14 13:40 ` Rob Herring
2019-10-17 7:48 ` JC Kuo
2019-10-17 11:44 ` Thierry Reding
2019-10-17 12:01 ` Thierry Reding
2019-11-26 4:21 ` Nagarjuna Kristam
2019-10-09 2:43 ` [PATCH v4 4/5] arm64: tegra: Add XUSB and pad controller on Tegra194 JC Kuo
2019-10-09 2:43 ` [PATCH v4 5/5] arm64: tegra: Enable XUSB host in P2972-0000 board JC Kuo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).