diff options
author | Stephen Warren <swarren@nvidia.com> | 2015-09-23 12:13:00 -0600 |
---|---|---|
committer | Tom Warren <twarren@nvidia.com> | 2015-10-02 11:05:01 -0700 |
commit | 0c35e3a8b406061005c481fccdb9bf2cfe09fd41 (patch) | |
tree | 1edd617874e710ac18e9f112860a7055b7cd10dd /include/configs | |
parent | f9d3cab091522c8470e9ebd4a8967d00f49efc4a (diff) | |
download | u-boot-imx-0c35e3a8b406061005c481fccdb9bf2cfe09fd41.zip u-boot-imx-0c35e3a8b406061005c481fccdb9bf2cfe09fd41.tar.gz u-boot-imx-0c35e3a8b406061005c481fccdb9bf2cfe09fd41.tar.bz2 |
ARM: tegra: don't enable GPIOs until direction is set
Tegra's GPIO driver currently enables pins as GPIO as soon as they're
requested. This is not safe, since the desired direction and output value
are not yet known. This could cause a glitch on the output pins between
gpio_request() and gpio_direction_*(), depending on what values happen to
be in the GPIO controller's in/out and out-value registers vs. the final
desired configuration.
To solve this, defer enabling pins as GPIOs until some gpio_direction_*()
is invoked, and the desired configuration is explicitly programmed.
In theory this change could cause regressions, if code exists that claims
a GPIO, never explicitly sets a direction, and then gets/sets the GPIO
value based on that assumption. However, I've read through all the Tegra-
related board files and device drivers that touch GPIOs and I do not see
such buggy code anywhere.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Diffstat (limited to 'include/configs')
0 files changed, 0 insertions, 0 deletions