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@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
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
