This driver was setting all GPIO lines to input and the data register to
zero on initialization. This does not appear to be common practice among
other GPIO drivers, and in fact caused a serious problem on the ZynqMP
platform, where between 1 and 4 of the top-most GPIO lines are
frequently used by platform firmware and Vivado as reset lines for the
programmable logic. Since these resets are active low, and their
input/output state is ignored due to how they are connected to the EMIO
GPIO outputs from the PS, this caused the PL reset to be asserted when
the GPIO driver initialized, preventing any logic using that reset from
functioning properly.
There may also be other cases where GPIO line states have already been
set by the boot loader or firmware and clearing them may result in
improper behavior or glitches on the lines during initialization.
Update the driver to disable GPIO interrupts but leave the pin
modes/states unchanged until/unless they are explicitly reconfigured.
Signed-off-by: Robert Hancock <robert.hancock@calian.com>
Add driver support for Versal Gen 2 PS/PMC GPIO controller by updating
the logic of bank index calculation.
This logic depends on "register" DT property to identify bank index
instead of depending on node instance ID as Versal Gen 2 GPIO banks
are not in sequential order as Zynqmp.
- Versal Gen 2 PS GPIO: Banks(0,3,4)
- Zynqmp PS GPIO: Banks(0,1,2,3,4,5)
Signed-off-by: Paul Alvin <alvin.paulp@amd.com>
Set up a named device MMIO memory mapping in the GPIO controller's
parent device, map the virtual memory in the init function of the
parent device.
Once the controller's register space has been successfully mapped,
propagate the mapped virtual address to all child (= GPIO bank)
devices. While it is possible to add a named mapping to every
single GPIO bank device and initialize it in the respective bank
device's init function, this would result in multiple virtual
address mappings all pointing to the same 4k of physical memory.
I assume that, although all those mappings having the same attri-
butes, such a setup is at least discouraged.
Signed-off-by: Immo Birnbaum <mail@birnbaum.immo>
In order to bring consistency in-tree, migrate all drivers to the new
prefix <zephyr/...>. Note that the conversion has been scripted, refer
to #45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Driver implementation for the Xilinx Processor System MIO / EMIO GPIO
controller as contained in the Zynq-7000 and ZynqMP (UltraScale) SoCs.
The driver is split up into source and header for a parent controller
device and source and header for 1..n child GPIO pin bank devices.
The parent device driver takes care of IRQ handling, the GPIO pin bank
driver provides pin / bank access according to the API defined by the
GPIO subsystem.
More than one device for this type of GPIO controller is required as
it provides access to a number of GPIO pins well in excess of the 32
pins addressable by the current GPIO API (whereever parameters or
return values come in the form of a bit mask):
- Zynq-7000: 54 MIO GPIO pins, 64 EMIO GPIO pins in 4 banks.
- ZynqMP: 78 MIO GPIO pins, 96 EMIO GPIO pins in 6 banks.
Signed-off-by: Immo Birnbaum <Immo.Birnbaum@weidmueller.com>
