ARM: tegra: fix USB ULPI PHY reset signal inversion confusion
USB ULPI PHY reset signals are typically active low. Consequently, they
should be marked as GPIO_ACTIVE_LOW in device tree, and indeed they are in
the Linux kernel DTs, and in DT properties that U-Boot doesn't yet use.
However, in DT properties that U-Boot does use, the value has been set to
0 (== GPIO_ACTIVE_HIGH) to work around a bug in U-Boot.
This change fixes the DT to correctly represent the HW, and fixes the
Tegra USB driver to cope with the fact that dm_gpio_set_value() internally
handles any inversions implied by the DT value GPIO_ACTIVE_LOW.
Cc: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
diff --git a/arch/arm/dts/tegra20-colibri.dts b/arch/arm/dts/tegra20-colibri.dts
index a291d93..777f63e 100644
--- a/arch/arm/dts/tegra20-colibri.dts
+++ b/arch/arm/dts/tegra20-colibri.dts
@@ -39,7 +39,8 @@
usb@c5004000 {
statuc = "okay";
/* VBUS_LAN */
- nvidia,phy-reset-gpio = <&gpio TEGRA_GPIO(V, 1) GPIO_ACTIVE_HIGH>;
+ nvidia,phy-reset-gpio = <&gpio TEGRA_GPIO(V, 1)
+ GPIO_ACTIVE_LOW>;
nvidia,vbus-gpio = <&gpio TEGRA_GPIO(BB, 1) GPIO_ACTIVE_HIGH>;
};
diff --git a/arch/arm/dts/tegra20-harmony.dts b/arch/arm/dts/tegra20-harmony.dts
index cace743..5aec150 100644
--- a/arch/arm/dts/tegra20-harmony.dts
+++ b/arch/arm/dts/tegra20-harmony.dts
@@ -626,7 +626,8 @@
usb@c5004000 {
status = "okay";
- nvidia,phy-reset-gpio = <&gpio TEGRA_GPIO(V, 1) 0>;
+ nvidia,phy-reset-gpio = <&gpio TEGRA_GPIO(V, 1)
+ GPIO_ACTIVE_LOW>;
};
usb-phy@c5004000 {
diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index eb54df4..e3620da 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -600,9 +600,18 @@
/* reset ULPI phy */
if (dm_gpio_is_valid(&config->phy_reset_gpio)) {
- dm_gpio_set_value(&config->phy_reset_gpio, 0);
- mdelay(5);
+ /*
+ * This GPIO is typically active-low, and marked as such in
+ * device tree. dm_gpio_set_value() takes this into account
+ * and inverts the value we pass here if required. In other
+ * words, this first call logically asserts the reset signal,
+ * which typically results in driving the physical GPIO low,
+ * and the second call logically de-asserts the reset signal,
+ * which typically results in driver the GPIO high.
+ */
dm_gpio_set_value(&config->phy_reset_gpio, 1);
+ mdelay(5);
+ dm_gpio_set_value(&config->phy_reset_gpio, 0);
}
/* Reset the usb controller */