summaryrefslogtreecommitdiff
path: root/arch/arm/boot/dts/tegra20-trimslice.dts
diff options
context:
space:
mode:
authorStephen Warren <swarren@nvidia.com>2013-08-21 00:00:13 +0400
committerOlof Johansson <olof@lixom.net>2013-08-22 08:36:19 +0400
commit30ca2226bea6f0db519dc53381b893cd66cb5b66 (patch)
tree082270fbbc7172f73be63700399a6d030fa3dd89 /arch/arm/boot/dts/tegra20-trimslice.dts
parentacd36357edc08649e85ff15dc4ed62353c912eff (diff)
downloadlinux-30ca2226bea6f0db519dc53381b893cd66cb5b66.tar.xz
ARM: tegra: always enable USB VBUS regulators
This fixes a regression exposed during the merge window by commit 9f310de "ARM: tegra: fix VBUS regulator GPIO polarity in DT"; namely that USB VBUS doesn't get turned on, so USB devices are not detected. This affects the internal USB port on TrimSlice (i.e. the USB->SATA bridge, to which the SSD is connected) and the external port(s) on Seaboard/ Springbank and Whistler. The Tegra DT as written in v3.11 allows two paths to enable USB VBUS: 1) Via the legacy DT binding for the USB controller; it can directly acquire a VBUS GPIO and activate it. 2) Via a regulator for VBUS, which is referenced by the new DT binding for the USB controller. Those two methods both use the same GPIO, and hence whichever of the USB controller and regulator gets probed first ends up owning the GPIO. In practice, the USB driver only supports path (1) above, since the patches to support the new USB binding are not present until v3.12:-( In practice, the regulator ends up being probed first and owning the GPIO. Since nothing enables the regulator (the USB driver code is not yet present), the regulator ends up being turned off. This originally caused no problem, because the polarity in the regulator definition was incorrect, so attempting to turn off the regulator actually turned it on, and everything worked:-( However, when testing the new USB driver code in v3.12, I noticed the incorrect polarity and fixed it in commit 9f310de "ARM: tegra: fix VBUS regulator GPIO polarity in DT". In the context of v3.11, this patch then caused the USB VBUS to actually turn off, which broke USB ports with VBUS control. I got this patch included in v3.11-rc1 since it fixed a bug in device tree (incorrect polarity specification), and hence was suitable to be included early in the rc series. I evidently did not test the patch at all, or correctly, in the context of v3.11, and hence did not notice the issue that I have explained above:-( Fix this by making the USB VBUS regulators always enabled. This way, if the regulator owns the GPIO, it will always be turned on, even if there is no USB driver code to request the regulator be turned on. Even ignoring this bug, this is a reasonable way to configure the HW anyway. If this patch is applied to v3.11, it will cause a couple pretty trivial conflicts in tegra20-{trimslice,seaboard}.dts when creating v3.12, since the context right above the added lines changed in patches destined for v3.12. Reported-by: Kyle McMartin <kmcmarti@redhat.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Olof Johansson <olof@lixom.net>
Diffstat (limited to 'arch/arm/boot/dts/tegra20-trimslice.dts')
-rw-r--r--arch/arm/boot/dts/tegra20-trimslice.dts2
1 files changed, 2 insertions, 0 deletions
diff --git a/arch/arm/boot/dts/tegra20-trimslice.dts b/arch/arm/boot/dts/tegra20-trimslice.dts
index ed4b901b0227..37c93d3c4812 100644
--- a/arch/arm/boot/dts/tegra20-trimslice.dts
+++ b/arch/arm/boot/dts/tegra20-trimslice.dts
@@ -412,6 +412,8 @@
regulator-max-microvolt = <5000000>;
enable-active-high;
gpio = <&gpio 170 0>; /* PV2 */
+ regulator-always-on;
+ regulator-boot-on;
};
};