After rework in lib/fdtdec.c, the function fdtdec_get_addr()
doesn't work for nodes with #size-cells property set to 0.

To get GPIO's 'reg' property, the code should use one of:
fdtdec_get_addr_size_auto_no/parent() function.

Fortunately dm core provides a function to get the property.

This commit reworks function gpio_exynos_bind(), to properly
use dev_get_addr() for GPIO device.

This prevents setting a wrong base register for Exynos GPIOs.

Tested on: Odroid U3/X2, Trats, Trats2, Odroid XU3, Snow (by Simon).

Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>

In order to make it clear what the parameters to set_config() and
set_direction() mean, and similarly for the return values from the
respective get_*(), define named constants for these values.

Disassembly shows no diff in the generated code, except that the
order of the code in the branches of tegra_gpio_get_function() gets
modified without affecting behaviour.

Suggested-by: Tom Warren <twarren@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>

These enum values aren't used anywhere. Remove them.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>

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>

Tegra's gpio_config_table() currently uses common GPIO APIs. These used
to work without requesting the GPIO, but since commit 2fccd2d96bad "tegra:
Convert tegra GPIO driver to use driver model" no longer do so. This
prevents any of the GPIO initialization table from being applied to HW.
Fix gpio_config_table() to directly program the HW to solve this.

Fixes: 2fccd2d96bad ("tegra: Convert tegra GPIO driver to use driver model")
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>

The current simplify lpc32xx gpio driver implementation assume a
maximum of 32 GPIO per port; there are a total of 22 GPI, 24 GPO
and 6 GPIO to managed on port 3.

Update the driver to fix the following:
1) When requesting GPI_xx and GPO_xx on port 3 (xx is the same number)
   the second call to "gpio_request" will return -EBUSY.

2) The status of GPO_xx pin report the status of the
   corresponding GPI_xx pin when using the "gpio status" command.

3) The gpio driver may setup the direction register for the wrong
   gpio when calling "gpio_direction_input" (GPI_xx) or
   "gpio_direction_output" (GPO_xx) on port 3; the call to the
   direction is require to use the "gpio status" command.

The following change were done in the driver:
1) port3 GPI are cache in a separate 32 bits in the array.
2) port3 direction register written only for GPIO pins.
3) port3 GPO & GPIO (as output) are read using "p3_outp_state".
4) LPC32XX_GPI_P3_GRP updated to match the change.

Signed-off-by: Sylvain Lemieux <slemieux@tycoint.com>

This supports RK3288 at present. It does not implement functions or support
for pull up/down.

Signed-off-by: Simon Glass <sjg@chromium.org>

* Add mxc_gpio support for imx7d SoC
* Use CONFIG_MX7 to extend mxc gpio driver support for imx7d

Signed-off-by: Peng Fan <Peng.Fan@freescale.com>
Signed-off-by: Adrian Alonso <aalonso@freescale.com>