We can use GPIOs as binary digits for reading 'strapping' values. Each GPIO
is assigned a single bit and can be set high or low on the circuit board. We
already have a legacy function for reading these values. Add one that
supports driver model.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

BUILD_BUG_* macros have been defined in several headers.  It would
be nice to collect them in include/linux/bug.h like Linux.

This commit is cherry-picking useful macros from include/linux/bug.h
of Linux 4.4.

I did not import BUILD_BUG_ON_MSG() because it would not work if it
is used with include/common.h in U-Boot.  I'd like to postpone it
until the root cause (the "error()" macro in include/common.h causes
the name conflict with "__attribute__((error()))") is fixed.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

For SPL we don't really need sprintf() and with tiny-printf this is not
available. Allow this to be dropped in SPL when using tiny-printf.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Since a gpio_desc is allowed to be invalid we should return an error
indicating that the operation cannot be completed. This can happen if the
GPIO is optional - e.g. some devices may have a reset line and some may
not.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This function can be used for testing to manually request a GPIO for use,
without resorting to the legacy GPIO API.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Provide a driver-model function to look up a GPIO name. Make the standard
function use it.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Like SPI and I2C few GPIO controllers also have
multiple chip instances. This patch adds the
flag 'DM_UC_FLAG_SEQ_ALIAS' in gpio_uclass driver
to control device sequence numbering. By defalut
the dev->r_seq for gpio_uclass will alwalys
returns -1, which leads the gpio driver probe
failure when using the driver with device trees.
Signed-off-by: NBhuvanchandra DV <bhuvanchandra.dv@toradex.com>

gpio_get_values_as_int() should return an error if something goes wrong.
Also provide gpio_claim_vector(), a function to request the GPIOs and set
them to input mode. Otherwise callers have to do this themselves.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NTom Warren <twarren@nvidia.com>

This has a prototype but no implementation. It returns the global GPIO number
given a gpio_desc. It is useful for debugging in some cases.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NMarek Vasut <marex@denx.de>

The function gpio_request_list_by_name_nodev() returned -ENOSPC error,
when the loop count was greater than requested count. This was wrong,
because function should return the requested gpio count, when meets
the call request without errors. Now, the loop ends on requested
max_count.
Signed-off-by: NPrzemyslaw Marczak <p.marczak@samsung.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Add a convenience function to access the private data that a uclass stores
for each of its devices. Convert over most existing uses for consistency
and to provide an example for others.
Signed-off-by: NSimon Glass <sjg@chromium.org>

At present U-Boot sort-of supports the standard way of reading GPIOs from
device tree nodes, but the support is incomplete, a bit clunky and only
works for GPIO bindings where #gpio-cells is 2.

Add new functions to request GPIOs, taking full account of the device
tree binding. These permit requesting a GPIO with a simple call like:

   gpio_request_by_name(dev, "cd-gpios", 0, &desc, GPIOD_IS_IN);

This will request the GPIO, looking at the device's node which might be
this, for example:

   cd-gpios = <&gpio TEGRA_GPIO(B, 3) GPIO_ACTIVE_LOW>;

The GPIO will be set to input mode in this case and polarity will be
honoured by the GPIO calls.

It is also possible to request and free a list of GPIOs.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Only the GPIO driver knows about the full GPIO device tree binding used by
a device. Add a method to allow the driver to provide this information to the
uclass, including the GPIO offset within the device and flags such as the
polarity.
Signed-off-by: NSimon Glass <sjg@chromium.org>

So far driver model's GPIO uclass just implements the existing GPIO API.
This has some limitations:

- it requires manual device tree munging to support GPIOs in device tree
    (fdtdec_get_gpio() and friends)
- it does not understand polarity
- it is somewhat slower since we must scan for the GPIO device each time
- Global GPIO numbering can change if other GPIO drivers are probed
- it requires extra steps to set the GPIO direction and value

The new functions have a dm_ prefix where necessary to avoid name conflicts
but we can remove that when it is no-longer needed. The new struct gpio_desc
holds all required information about the GPIO. For now this is intended to
be stored by the client requesting the GPIO, but in future it might be
brought into the uclass in some way.

With these changes the old GPIO API still works, and uses the driver model
API underneath.
Signed-off-by: NSimon Glass <sjg@chromium.org>

For board IDs a common approach is to set aside several GPIOs for use in
determining the board ID. This can provide information about board features
and the revision.

Add a function that turns a list of GPIOs into an integer by assigning
each GPIO to a single bit.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Add a helper which permits a printf()-style format string for the requester
string.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This function can be more easily tested if it is in the uclass.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Add helpers to the uclass to allow finding out the pin function.
Signed-off-by: NSimon Glass <sjg@chromium.org>

We have several GPIO drivers now and all are doing similar things to record
which GPIOs are reserved.

Move this logic into the uclass to make the drivers similar.

We retain the request()/free() methods since currently one driver does use
these for setting up the pin.
Signed-off-by: NSimon Glass <sjg@chromium.org>

At present banks must be named and it is not possible to refer to GPIOs by
number in driver model. Some boards use numbering - e.g. OMAP. It is fairly
easy to support by detecting the absense of a bank name (which starts with
a letter).

Add support for numbered GPIOs in addition to the existing bank support.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NTom Rini <trini@ti.com>

We want 'N0' and 'n0' to mean the same thing, so ensure that case is not
considered when naming GPIO banks.
Signed-off-by: NSimon Glass <sjg@chromium.org>

using UBI and DM together leads in compiler error, as
both define a "struct device", so rename "struct device"
in include/dm/device.h to "struct udevice", as we use
linux code (MTD/UBI/UBIFS some USB code,...) and cannot
change the linux "struct device"
Signed-off-by: NHeiko Schocher <hs@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Marek Vasut <marex@denx.de>

Add driver model support for GPIOs. Since existing GPIO drivers do not use
driver model, this feature must be enabled by CONFIG_DM_GPIO. After all
GPO drivers are converted over we can perhaps remove this config.

Tests are provided for the sandbox implementation, and are a sufficient
sanity check for basic operation.

The GPIO uclass understands the concept of named banks of GPIOs, with each
GPIO device providing a single bank. Within each bank the GPIOs are numbered
using an offset from 0 to n-1. For example a bank named 'b' with 20
offsets will provide GPIOs named b0 to b19.

Anonymous GPIO banks are also supported, and are just numbered without any
prefix.

Each time a GPIO driver is added to the uclass, the GPIOs are renumbered
accordinging, so there is always a global GPIO numbering order.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NPavel Herrmann <morpheus.ibis@gmail.com>
Signed-off-by: NViktor Křivák <viktor.krivak@gmail.com>
Signed-off-by: NTomas Hlavacek <tmshlvck@gmail.com>