summaryrefslogtreecommitdiff
path: root/include/configs/ls2085a_simu.h
diff options
context:
space:
mode:
authorStephen Warren <swarren@nvidia.com>2015-09-23 12:13:00 -0600
committerTom Warren <twarren@nvidia.com>2015-10-02 11:05:01 -0700
commit0c35e3a8b406061005c481fccdb9bf2cfe09fd41 (patch)
tree1edd617874e710ac18e9f112860a7055b7cd10dd /include/configs/ls2085a_simu.h
parentf9d3cab091522c8470e9ebd4a8967d00f49efc4a (diff)
downloadu-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/ls2085a_simu.h')
0 files changed, 0 insertions, 0 deletions