Now that the DM core sets driver_data before calling bind(), this driver
can make use of driver_data to determine the set of child devices to
create, rather than manually re-implementing the matching logic in code.
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Add zynq_gpio_get_function() which return status on gpio pin.
This function enables gpio status command.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
With the addition of GPIO_ACTIVE_LOW parsing in gpio-uclass,
the Exynos/S5P gpio driver doesn't need a custom xlate routine.
Signed-off-by: Eric Nelson <eric@nelint.com>
Acked-by: Simon Glass <sjg@chromium.org>
Acked-by: Minkyu Kang <mk7.kang@samsung.com>
With the addition of GPIO_ACTIVE_LOW parsing in gpio-uclass,
the Rockchip gpio driver doesn't need a custom xlate routine.
Signed-off-by: Eric Nelson <eric@nelint.com>
Acked-by: Simon Glass <sjg@chromium.org>
With the addition of GPIO_ACTIVE_LOW parsing in gpio-uclass,
the pic32 gpio driver doesn't need a custom xlate routine.
Signed-off-by: Eric Nelson <eric@nelint.com>
Acked-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Purna Chandra Mandal <purna.mandal@microchip.com>
With the addition of GPIO_ACTIVE_LOW parsing in gpio-uclass,
the omap gpio driver doesn't need a custom xlate routine.
Signed-off-by: Eric Nelson <eric@nelint.com>
Acked-by: Simon Glass <sjg@chromium.org>
With the addition of GPIO_ACTIVE_LOW parsing in gpio-uclass,
the intel_broadwell driver doesn't need a custom xlate routine.
Signed-off-by: Eric Nelson <eric@nelint.com>
Acked-by: Simon Glass <sjg@chromium.org>
Many drivers use a common form of offset + flags for device
tree nodes. e.g.:
<&gpio1 2 GPIO_ACTIVE_LOW>
This patch adds a common implementation of this type of parsing
and calls it when a gpio driver doesn't supply its' own xlate
routine.
This will allow removal of the driver-specific versions in a
handful of drivers and simplify the addition of new drivers.
Signed-off-by: Eric Nelson <eric@nelint.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
Introduce driver to support "fairchild,74hc595" devices.
1. Take linux drivers/drivers/gpio/gpio-74x164.c as reference.
2. Following the naming used in Linux driver with gen_7x164 as the prefix.
3. Enable CONFIG_DM_74X164 to use this driver.
4. Follow Documentation/devicetree/bindings/gpio/gpio-74x164.txt to add device
nodes
5. Tested on i.MX6 UltraLite with 74LV595 using gpio command and oscillograph.
Signed-off-by: Peng Fan <van.freenix@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Chin Liang See <clsee@altera.com>
Cc: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Introduce a new driver that supports driver model for pca953x.
The pca953x chips are used as I2C I/O expanders.
This driver is designed to support the following chips:
"
4 bits: pca9536, pca9537
8 bits: max7310, max7315, pca6107, pca9534, pca9538, pca9554,
pca9556, pca9557, pca9574, tca6408, xra1202
16 bits: max7312, max7313, pca9535, pca9539, pca9555, pca9575,
tca6416
24 bits: tca6424
40 bits: pca9505, pca9698
"
But for now this driver only supports max 24 bits and pca953x compatible
chips. pca957x compatible chips are not supported now.
These can be addressed when we need to add such support for the different
chips.
This driver has been tested on i.MX6 SoloX Sabreauto board with max7310
i2c expander using gpio command as following:
=>gpio status -a
Bank gpio@30_:
gpio@30_0: input: 1 [ ]
=> dm tree:
i2c [ ] | | `-- i2c@021a8000
gpio [ ] | | |-- gpio@30
gpio [ ] | | `-- gpio@32
Signed-off-by: Peng Fan <van.freenix@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Wenyou Yang <wenyou.yang@atmel.com>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Purna Chandra Mandal <purna.mandal@microchip.com>
Cc: Thomas Chou <thomas@wytron.com.tw>
Cc: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
Cc: Andrea Scian <andrea.scian@dave.eu>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Michal Simek <michal.simek@xilinx.com> #on ZynqMP zcu102
If get_dev_addr fails it will return FDT_ADDR_T_NONE and:
>>> "priv->pid == 4294967295U" is always false regardless of the values of its operands. This occurs as the logical operand of if.
Cc: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
Reported-by: Coverity (CID: 143913)
Signed-off-by: Tom Rini <trini@konsulko.com>
Warnings:
w+../drivers/gpio/pca953x.c: In function ‘do_pca953x’:
w+../drivers/gpio/pca953x.c:220:5: warning: cast from pointer to integer
of different size [-Wpointer-to-int-cast]
w+../drivers/gpio/pca953x.c:233:10: warning: cast from pointer to
integer of different size [-Wpointer-to-int-cast]
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Enable ZYNQ_GPIO for ZynqMP using Kconfig. It enables the GPIO
driver support for ZynqMP.
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Move all the gpio definitions to driver file as
there is no use of them in other files.
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Remove non driver model support as it moved
to driver model. Dont need non driver model
anymore.
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Enable DM GPIO and ZYNQ GPIO using kconfig instead of the board
config file.
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
This patch adds the missing configuration of the output value to the
gpio_direction_output() function. Without this, calling
gpio_direction_output() does not set the out-value at all and only
configures the gpio as output.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Kevin Smith <kevin.smith@elecsyscorp.com>
Reviewed-by: Kevin Smith <kevin.smith@elecsyscorp.com>
This driver supports GPIOs present on PM8916 PMIC.
There are 2 device drivers inside:
- GPIO driver (4 "generic" GPIOs)
- Keypad driver that presents itself as GPIO with 2 inputs (power and reset)
Signed-off-by: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Add support for gpio controllers on Qualcomm Snapdragon devices.
This devices are usually called Top Level Mode Multiplexing in
Qualcomm documentation.
Signed-off-by: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Currently, fdtdec_get_addr_size() does not support the address
translation, so it cannot handle device trees with non-straight
"ranges" properties. (This would be a problem with DTS for UniPhier
ARMv8 SoCs.)
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
VBUS drive is supported on AXP221 and later PMICs. Rework the macros
so we can support this on later PMICs without too much work.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This patch adds a DM GPIO driver for the Marvell MVEBU SoCs. There are
other non-DM drivers that might be used on these platforms. But this
patch creates a new DM driver. Which will be used by all Armada XP/38x
boards. Other MVEBU SoC (Kirkwood / Orion) may follow once they
support DM as well.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Dirk Eibach <dirk.eibach@gdsys.cc>
Cc: Phil Sutter <phil@nwl.cc>
Cc: Kevin Smith <kevin.smith@elecsyscorp.com>
Cc: Luka Perkov <luka.perkov@sartura.hr>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Kevin Smith <kevin.smith@elecsyscorp.com>
Tested-by: Kevin Smith <kevin.smith@elecsyscorp.com>
Signed-off-by: Stefan Roese <sr@denx.de>
The kernel has different compatible strings for the pio block
because the pin-muxing is different on all the different SoCs,
but sunxi_gpio.c only support the basic gpio functionality, which
is identical everywhere. Add the missing compatible strings for
various SoC models.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Add a GPIO driver for the GPIO peripheral found on broadwell devices.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Bin Meng <bmeng.cn@gmail.com>
We don't need this anymore - we can use device tree and the new pinconfig
driver instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Rather than setting up the pin configuration in the GPIO driver, use the
new pinctrl driver to do it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The Intel GPIO driver can set up the GPIO pin mapping when the first GPIO
is probed. However, it assumes that the first GPIO to be probed is in the
first GPIO bank. If this is not the case then the init will write to the
wrong registers.
Fix this. Also add a note that this code is deprecated. We should move to
using device tree instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Some functions do not change the struct gpio_desc parameter. Update these to
use const so this is clear.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
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: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This GPIO controller device is used on UniPhier SoCs.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Simon Glass <sjg@chromium.org>
Base addresses for GPIOs could be different for different socs, this
patch moves the base addresses from driver to the soc specific location.
Signed-off-by: Vikas Manocha <vikas.manocha@st.com>
This patch removes the gpio clock enable from gpio driver & move it in the
board code, making it possible to use the gpio driver with other socs.
Signed-off-by: Vikas Manocha <vikas.manocha@st.com>
The tegra GPIO controller has two ways of reading the value of a GPIO. It
can supply the 'input' value (which is the value read from the pin) and the
'output' value (which is the value being driven from the pin. With a GPIO
set to output mode, the 'input' value is always low which is not very
useful.
This has the unfortunate result that setting a GPIO high still leaves it
showing as low in the 'gpio status' command.
Adjust the driver to check which direction the GPIO is set to, then read
the value from the appropriate register: 'input' for input GPIOs, 'output'
for output GPIOs.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Correct spelling of "U-Boot" shall be used in all written text
(documentation, comments in source files etc.).
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Minkyu Kang <mk7.kang@samsung.com>
At present this GPIO driver still uses the legacy PCI API. Now that
we have proper PCH drivers we can use those to obtain the information
we need. While the device tree has nodes for the GPIO peripheral it is
not in the right place. It should be on the PCI bus as a sub-peripheral
of the PCH device.
Update the device tree files to show the GPIO controller within the PCH,
so that PCI access works as expected. This also adds '#address-cells'
and '#size-cells' to the PCH node.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
All boards using this driver are with device tree support,
hence drop the legacy code in driver to have a pure DT solution.
Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
In PIC32 GPIO controller is part of PIC32 pin controller.
PIC32 has ten independently programmable ports and each with multiple pins.
Each of these pins can be configured and used as GPIO, provided they
are not in use for other peripherals.
Signed-off-by: Purna Chandra Mandal <purna.mandal@microchip.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@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: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Provide this method so that 'gpio status' works fully. It now shows
whether a pin is used for input, output or some other function.
Signed-off-by: Simon Glass <sjg@chromium.org>
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: Simon Glass <sjg@chromium.org>
In a number of places we had wordings of the GPL (or LGPL in a few
cases) license text that were split in such a way that it wasn't caught
previously. Convert all of these to the correct SPDX-License-Identifier
tag.
Signed-off-by: Tom Rini <trini@konsulko.com>
Override the default name_to_gpio() function with one that
accepts strings of the form bank:pin. If a colon is present
in the provided name, it behaves like the default version.
This lets the "gpio" command work with sane names rather than
requiring the user to enter the bank/pin composite in decimal.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Reviewed-by: Stefano Babic <sbabic@denx.de>
Change ioremap() to map_physmem(), as it is more used in u-boot.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Reviewed-by: Marek Vasut <marex@denx.de>
Convert altera_pio to driver model.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Acked-by: Chin Liang See <clsee@altera.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
With DM_GPIO, gpio parameters like ACTIVE_(LOW/HIGH) are to be
parsed in xlate gpio drivers-ops. Since xlate is not implemented
in omap_gpio driver, the driver considers all gpio to be
ACTIVE_HIGH which is the default case and fails to return actual
gpio status for ACTIVE_LOW gpios. So adding .xlate ops to
omap_gpio.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Stop prefixing the axp functions for setting voltages, etc. with the
model number, there ever is only one pmic driver built into u-boot,
this allows simplifying the callers.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
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 2fccd2d96b "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: 2fccd2d96b ("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>
* 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>
This is a convenient way for a driver to get the hardware address of a
device, when regmap or syscon are not being used. Change existing callers
to use it as an example to others.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Fix gpio_read: gpio input (INDT) and gpio output (OUTDT) registers
have different offset. gpio_read must be performed from INDT.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
This function can return an error. Correct the detection of this error so
that it works even with large 32-bit addresses.
The return value is set up for returning an I/O address but the function is
also used to return a memory-mapped address. Adjust the return code to make
this work.
Also add a bit more debugging.
Signed-off-by: Simon Glass <sjg@chromium.org>
These calls seem to be incorrect. The function expects an I/O address but
the existing callers pass the value at an I/O address. Fix it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add driver for the DesignWare APB GPIO IP block.
This driver is DM capable and probes from DT.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Simon Glass <sjg@chromium.org>
We have flipped CONFIG_SPL_DISABLE_OF_CONTROL. We have cleansing
devices, $(SPL_) and CONFIG_IS_ENABLED(), so we are ready to clear
away the ugly logic in include/fdtdec.h:
#ifdef CONFIG_OF_CONTROL
# if defined(CONFIG_SPL_BUILD) && !defined(SPL_OF_CONTROL)
# define OF_CONTROL 0
# else
# define OF_CONTROL 1
# endif
#else
# define OF_CONTROL 0
#endif
Now CONFIG_IS_ENABLED(OF_CONTROL) is the substitute. It refers to
CONFIG_OF_CONTROL for U-boot proper and CONFIG_SPL_OF_CONTROL for
SPL.
Also, we no longer have to cancel CONFIG_OF_CONTROL in
include/config_uncmd_spl.h and scripts/Makefile.spl.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
sun6i and later have a couple of io-blocks which are shared between the
main CPU core and the "R" cpu which is small embedded cpu which can be
active while the main system is suspended.
These gpio banks sit at a different mmio address then the normal banks,
and have a separate devicetree node and compatible, this adds support for
these banks to the sunxi-gpio code when built with device-model support.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
The "method" parameter was part of the original port of the driver from
the kernel. At some point this may have been added to allow for future
differentiation (as omap1 and omap2 have different GPIO IP blocks, so
this wasn't an unreasonable thing to do). At this point however it's
just extra overhead, so drop.
Signed-off-by: Tom Rini <trini@konsulko.com>
The menuconfig for drivers are getting more and more cluttered
and unreadable because too many entries are displayed in a single
flat menu. Use hierarchic menu for each category.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
[trini: Update to apply again in a few places, drop USB hunk]
Signed-off-by: Tom Rini <trini@konsulko.com>
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: Simon 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: Simon Glass <sjg@chromium.org>
The LPC32XX GPIO driver platdata currently contains GPIO state information,
which should go into priv_data. Thus rename lpc32xx_gpio_platdata to
lpc32xx_gpio_priv and convert to use dev_get_priv() instead.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Tested-by: Albert ARIBAUD <albert.aribaud@3adev.fr>
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: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
Add "allwinner,sun8i-a33-pinctrl", this is used by the latest upstream
linux sunxi dts files.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Every pin can be configured now from the device tree. A dt-bindings
has been added to describe the different property available.
Change-Id: I1668886062655f83700d0e7bbbe3ad09b19ee975
Signed-off-by: Gabriel Huau <contact@huau-gabriel.fr>
Acked-by: Simon Glass <sjg@chromium.org>
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: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
The GPIO driver didn't correctly compute the bank offset
from the GPIO number and caused random writes into the
GPIO block address space. Fix the driver so it actually
does the writes correctly. While at it, make use of the
clrsetbits_le32() mechanisms.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Minkyu Kang <mk7.kang@samsung.com>
Cc: Vladimir Zapolskiy <vz@mleia.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Now that all sunxi boards are using driver-model for gpio (*), we can remove
the non driver-model support from the axp gpio code, and the glue to call
into the axp gpio code from the sunxi_gpio non driver-model code.
*) For the regular u-boot build, SPL still uses non driver-model gpio for
now, but the SPL never uses axp gpios support and we were already not building
axp-gpio support for the SPL.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Add driver-model support to the axp_gpio code, note that this needs a small
tweak to the driver-model version of sunxi_name_to_gpio to deal with the
vbus detect and enable pins which are not standard numbered gpios.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
