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>
Current setup tries to initialize the bank driver before the parent one,
which is the inverse of what the devicetree hierarchy implies and
causes a bunch of:
ERROR: /soc/gpio@e000a000/psgpio_bank@3 PRE_KERNEL_1 40 32 <
/soc/gpio@e000a000 PRE_KERNEL_2 40 10
Change the bank driver to initialize at PRE_KERNEL_1 as the parent
drivers so that ordinals take care of priority between these two.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Simplify driver by using DT_INST_FOREACH_CHILD_STATUS_OKAY_SEP (avoids
DT_DRV_INST and auxiliary macro).
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
It is frequent to find variable definitions like this:
```c
static const struct device *dev = DEVICE_DT_GET(...)
```
That is, module level variables that are statically initialized with a
device reference. Such value is, in most cases, never changed meaning
the variable can also be declared as const (immutable). This patch
constifies all such cases.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
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>
