With DM enabled in SPL, DM_FLAG_PRE_RELOC is required for
the omap_gpio driver to be bound to the gpio devices.
Therefore, add DM_FLAG_PRE_RELOC flag to the omap_gpio driver.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
- add new arch stm32mp for STM32 MPU/Soc based on Cortex A
- support for stm32mp157 SOC
- SPL is used as first boot stage loader
- using driver model for all the drivers, even in SPL
- all security feature are deactivated (ETZC and TZC)
- reused STM32 MCU drivers when it is possible
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Update the GPIO driver to support a live device tree.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
The @gdsys.cc addresses are supposed to be used for mailing lists.
Switch all occurrences of @gdsys.de mail addresses to their @gdsys.cc
equivalent.
Also, Dirk's address was wrong in one place; fix that as well.
Signed-off-by: Mario Six <six@gdsys.cc>
The PCA953x driver uses "gpio@%x_" as the GPIO bank name, where "%x" is
instantiated with the I2C address of the chip. While this works, it
becomes very confusing if a board has multiple PCAs with the same
address on different I2C busses, and it also becomes an issue when a
GPIO's value is to be set via the 'gpio' command, because this command
only ever sets the value of the first device it encounters, leaving the
other devices inaccessible to the command.
As to not break boards that rely on this naming scheme, we introduce a
new device tree string property "label" for the driver. If it exists, it
is used to build a bank name of the form "%s@%x_" (where %x is still
instantiated with the I2C address). If it does not exist, the legacy
labeling scheme is used.
Signed-off-by: Mario Six <mario.six@gdsys.cc>
This patch added Kconfig support for CONFIG_XILINX_GPIO
and enabled it in respective defconfig.
Signed-off-by: Vipul Kumar <vipulk@xilinx.com>
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
At present dtc produces these warnings when compiling sandbox:
arch/sandbox/dts/test.dtb: Warning (gpios_property):
Could not get phandle node for /base-gpios:num-gpios(cell 0)
arch/sandbox/dts/test.dtb: Warning (gpios_property):
Missing property '#gpio-cells' in node /reset-ctl or bad phandle
(referred from /extra-gpios:num-gpios[0])
Both are due to it assuming that the 'num-gpios' property holds a phandle
pointing to a GPIO node.
To avoid these warnings, rename the sandbox property so that it does not
include the string 'gpios'.
Signed-off-by: Simon Glass <sjg@chromium.org>
In the following statements
if (a) return a; if (a) return c;
the second return can never be executed.
Identified by cppcheck.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
The bcm283x family of SoCs have a GPIO controller that also acts as
pinctrl controller.
This patch introduces a new pinctrl driver that can actually properly mux
devices into their device tree defined pin states and is now the primary
owner of the gpio device. The previous GPIO driver gets moved into a
subdevice of the pinctrl driver, bound to the same OF node.
That way whenever a device asks for pinctrl support, it gets it
automatically from the pinctrl driver and GPIO support is still available
in the normal command line phase.
Signed-off-by: Alexander Graf <agraf@suse.de>
Finally, make the mpc8xxx driver capable of handling more GPIO devices;
this entails adding a special case for the MPC5121 SoC, and adding a set
of new compatible strings.
Signed-off-by: Mario Six <mario.six@gdsys.cc>
Rename the Kconfig option, structures (and their members), as well as
functions of the mpc85xx driver to include mpc8xxx to reflect the more
generic usage.
Signed-off-by: Mario Six <mario.six@gdsys.cc>
In preparation to making the MPC85xx GPIO driver useable for a broader
range of SoCs, rename the driver file.
Signed-off-by: Mario Six <mario.six@gdsys.cc>
Make the pca953x_gpio driver compatible with a live device tree.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Mario Six <mario.six@gdsys.cc>
Add allwinner,sun50i-h5-pinctrl compatible for H5 boards.
Signed-off-by: Chris Blake <chrisrblake93@gmail.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
[jagan: remove external link and format commit message]
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
The command portion of the GPIO driver can only be used in full SPL so
re-work to guard the command related portions and mark it as static.
Cc: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
The command portion of the GPIO driver can only be used in full SPL so
re-work to guard the command related portions and mark it as static.
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Use available DM stm32f7_gpio.c and pinctrl_stm32.c drivers
instead of board GPIO initialization.
Remove stm32_gpio.c which is no more used and migrate
structs stm32_gpio_regs and stm32_gpio_priv into
arch-stm32f4/gpio.h to not break compilation.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Since commit 051ba9e082 ("Kconfig: mx6ull: Deselect MX6UL from
CONFIG_MX6ULL") CONFIG_MX6ULL does not select CONFIG_MX6UL anymore, so
take this into consideration in all the checks for CONFIG_MX6UL.
This fixes a boot regression.
Reported-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Stefan Agner <stefan@agner.ch>
Tested-by: Breno Lima <breno.lima@nxp.com>
Tested-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Stefano Babic <sbabic@denx.de>
Tested-by: Jörg Krause <joerg.krause@embedded.rocks>
This driver really is DM GPIO one and so we need to have a correct
dependency, because DM alone doesn't provide required for CMD_GPIO
call and we're seeing build failures like this:
---------------------->8---------------------
cmd/built-in.o: In function 'do_gpio':
.../cmd/gpio.c:188: undefined reference to 'gpio_request'
...
---------------------->8---------------------
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Eugeniy Paltsev <paltsev@synopsys.com>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add generic compatible to the GPIO driver for Gen3 SoCs.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Add new compatible to the GPIO driver for R8A77995 D3 SoC.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Add new compatible to the GPIO driver for R8A77970 V3M SoC.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
When requesting a GPIO, set the PFC GPSR register to GPIO mode,
otherwise the GPIO cannot work.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Same macros are defined in various places. Collect them into
include/linux/bitops.h like Linux.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The HSDK can manage some pins via CREG registers block.
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
First, I implemented this driver as per-bank model, but it was
a design mistake.
- There are 31 banks in the maximum case. It is painful to add
so many nodes to DT.
- The IRQ control registers are shared between banks. Per-bank
design is a problem for Linux. The counterpart for Linux turned
around to the single node model.
Rework based on the driver for Linux.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
These checks cannot fail since driver model will not call a driver's
method if it cannot fully create the driver data structures.
It is confusing to have these checks and others might copy them. Drop this
code.
Signed-off-by: Simon Glass <sjg@chromium.org>
In U-Boot -ENODEV means that there is no device. When there is a problem
with the device, drivers should return an error like -ENXIO or -EREMOTEIO.
When the device tree properties cannot be read correct , they should
return -EINVAL.
Update various GPIO drivers to follow this rule, to help with consistency
for future driver writers.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Adam Ford <aford173@gmail.com>
These three drivers all use U_BOOT_DEVICE rather than device tree to
create devices, so have to do manual allocation of platform data. This is
not true for new platforms.
Add a more explicit comment so that people do not copy this approach with
new boards.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Adam Ford <aford173@gmail.com>
It does not look like this driver needs to use a bind() method. It does
not manually create devices with device_bind() nor does it create devices
using U_BOOT_DEVICE(). It seems to only use device tree.
Therefore the manual allocation of platform data is not needed and is
confusing. Also platform data should be set up by the ofdata_to_platdata()
method, not bind().
Update the driver in case others use it as a model in future.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Adam Ford <aford173@gmail.com>
Add GPIO driver for the Renesas RCar SoCs . The driver currently supports
only the RCar Gen3 R8A7795 and R8A7796 SoCs, but is easily extensible for
the other RCar SoCs as well.
This driver is meant to replace the pinmux part of SH_GPIO_PFC driver.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Remove a comment claiming that this driver only supports the RK3288,
as we also use it on the RK3368, RK3399 and (most likely) on other
variants.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Version-changes: 2
- use the dev_read_addr_ptr function in rk_gpio.c
Update the Rockchip GPIO-bank driver to support a live tree.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Version-changes: 2
- use the dev_read_addr_ptr function in rk_gpio.c
A few years ago STM32F1 SoCs support has been added :
0144caf22c gpio: stm32: add stm32f1 support
2d18ef2364 ARMv7M: add STM32F1 support
But neither STM32F1 dedicated defconfig nor board was
associated to these commits.
Got confirmation from Tom Rini and Matt Porter to remove
all this code [1]
[1] http://u-boot.10912.n7.nabble.com/Remove-STM32F1-support-td301603.html
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
This converts the following to Kconfig:
CONFIG_CMD_TCA642X
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
