RTEMS | Draft: bsps: Four GPIO drivers against the generic GPIO API (!1500)

[Sam Price (@TheSamPrice)]

Sam Price created a merge request: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1500

Project:Branches: TheSamPrice/rtems:gpio-drivers to rtems/rtos/rtems:main
Author: Sam Price

Four drivers against the generic GPIO API, one commit each, so they can be
split into separate MRs on request without any of the work being redone.

**Depends on !1499.** That MR is the API and its test. This branch is stacked
on it, so until it merges the diff here shows its commit first; only the four
below belong to this MR. Opened as a Draft for the same reason !1499 is.

| commit | driver | what it exercises |
|---|---|---|
| 1 | **virtual** | pins that are callbacks -- a proxy, a clock or power gate, a subsystem enable, a software signal with interrupt delivery. Built for every BSP from `spec/build/bsps/obj.yml`, the way `bsps/shared/dev/can/can-virtual.c` already is. Carries `gpio02`. |
| 2 | **TI OMAP4 / BeagleBone Black** | four banks as four controllers; FDT `ranges` walked three levels to resolve a `reg` of 0 under `target-module at 4c000`; `#interrupt-cells` taken from the interrupt parent rather than the node |
| 3 | **Zynq / ZynqMP** | *one* driver for an ARM and an AArch64 BSP, pin layout read from the device tree; banks that are not word-aligned (bank 1 is 22 pins wide, so bank 2 starts mid-word); MIO and EMIO differing in what a read means |
| 4 | **ESP32-C3** | 22 pads in one register; write-one-to-set and write-one-to-clear, so a bulk write is two stores and no read-modify-write; flash and strapping pins refused or marked; drive strength in µA mapped onto four hardware settings |

Four deliberately different controllers, because one driver proves nothing
about an abstraction. Between them they are the reason several things in the
API are shaped the way they are -- the caller-sized bitmaps, polarity applied
above the driver, `can_block` as a property, and capability separated from
board reservation.

The two FDT drivers share one binding: stock vendor properties on the
controller node, `rtems,`-prefixed child nodes describing individual pins.
Two drivers with one binding rather than two inventions.

## Verified

Built clean from a wiped build directory on three BSPs, no warnings in any
GPIO source:

| BSP | drivers compiled |
|---|---|
| `arm/xilinx_zynq_a9_qemu` | `gpio-virtual.c`, `zynq-gpio.c` |
| `arm/beagleboneblack` | `gpio-virtual.c`, `ti-gpio.c` |
| `riscv/esp32c3db` | `gpio-virtual.c`, `esp32c3-gpio.c` |

`gpio01` and `gpio02` both pass under `qemu-system-arm -M xilinx-zynq-a9`.
The virtual driver is at 183/183 coverable lines under tcgcov.

## Not verified

**No hardware.** None of the three hardware drivers has run on silicon. QEMU
does not model the Zynq PS GPIO registers at all -- a write to `DIRM_0` reads
back zero -- and there is no am335x machine in QEMU. So the FDT parsing, the
working out of the pin layout and the API plumbing are exercised, but **every
register-level behaviour in the three hardware drivers comes from a TRM and
has never been executed.**

There is also no AArch64 toolchain on this machine, so the ZynqMP half of
commit 3 is checked by reading it and as YAML, not by a build. The ARM Zynq
half builds.

If anyone has a Zynq, a BeagleBone Black or a C3 on a desk, that is the most
useful thing anyone could contribute to this.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1500
You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/namespace/49/sent_notifications/5-1x8tmg3bjw7tslg3i3s7gvv8s-1d/unsubscribe | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | Help: https://gitlab.rtems.org/help


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260922/23690abf/attachment-0001.htm>