Hi everyone, This series adds a DRM driver for GlandaGPU, a custom open-source 2D graphics core I designed in VHDL. It currently runs on a Cyclone V SoC (Terasic DE10-Standard), with VGA output at 640x480@60Hz. I also built a QEMU fork that emulates the same MMIO/VRAM interface as a digital twin, so I can develop and test without needing the FPGA board.
Hardware/VHDL: https://github.com/stiangglanda/GlandaGPU QEMU fork: https://github.com/stiangglanda/qemu-glandagpu Userspace tests: https://github.com/stiangglanda/GlandaGPU-userspace-tests I'm sending this as an RFC because I'd like feedback on the following points before cleaning up the series further: 1) Mainline viability of custom FPGA hardware GlandaGPU isn't a commercial chip, it's an open-source soft GPU core. The DE10-Standard itself is a regular purchasable dev board, and the RTL is public, so anyone can reproduce the exact hardware. Testing doesn't require the FPGA either, since the QEMU twin models the same interface. I know this is unusual compared to typical mainline DRM hardware. I'd like to know whether this is workable, or whether it's a dealbreaker for mainline. 2) UAPI / ioctls / userspace The driver currently exposes three fixed ioctls (CLEAR, DRAW_RECT, DRAW_LINE), mapping directly onto the current hardware command set. I have two related questions here: a) I plan to keep developing the hardware further, which will likely mean more ioctls over time (for example, polygon/3D rendering is one direction I'm considering). Is it acceptable to keep adding a new, separate ioctl for each drawing primitive like this, or should I move to a generic command-buffer submission model instead, similar to DRM_IOCTL_VIRTGPU_EXECBUFFER in virtio_gpu, before this is treated as stable? b) If I do end up with an ioctl-based acceleration UAPI, is writing a Mesa/Gallium3D driver the expected way to make it usable from userspace, or is there a lighter-weight option that makes more sense for a project this size? 3) x86 QEMU platform test device To let reviewers try the driver against the QEMU twin without cross-compiling an ARM kernel and rootfs, I registered a platform device at a fixed address on x86. I'm aware this doesn't belong in the driver itself, so I isolated it into patch 3/3 and marked it "NOT FOR MERGE". Let me know if you'd rather see it dropped entirely, relying only on documentation of the QEMU-on-ARM testing path instead. 4) Pixel format conversion glanda_pipe_update() currently does a per-pixel software conversion from XRGB8888 into the hardware's native packed format on every flip. I'm aware this is a known bottleneck. I'm planning to extend the VHDL to accept XRGB8888 natively so I can drop this conversion entirely. I'm flagging it here as a known limitation rather than blocking on it, since it's a hardware-side change and doesn't affect the UAPI. 5) drm_simple_display_pipe vs. manual plane/CRTC/encoder Since the driver only has a single plane, CRTC, and encoder, I tried converting it to use drm_simple_display_pipe instead of the manual setup. It compiled cleanly, but my userspace tests didn't behave the way I expected. I haven't figured out why yet, so I kept the manual setup for this RFC. I'm open to revisiting this if that's the preferred direction. Testing Status: The driver has been tested and verified on both the QEMU fork (x86) and physical FPGA hardware (ARM) using: - A custom static userspace test: https://github.com/stiangglanda/GlandaGPU-userspace-tests - `modetest -M glandagpu -s 36:640x480 -v` (which successfully displays the test pattern) Thanks for any feedback, Leander Kieweg Leander Kieweg (3): dt-bindings: display: Add GlandaGPU binding drm/glanda: Add initial DRM driver for GlandaGPU NOT FOR MERGE: drm/glanda: Add x86 platform test device .../bindings/display/glanda,gpu.yaml | 49 ++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + MAINTAINERS | 7 + drivers/gpu/drm/tiny/Kconfig | 25 + drivers/gpu/drm/tiny/Makefile | 1 + drivers/gpu/drm/tiny/glandagpu.c | 808 ++++++++++++++++++ include/uapi/drm/glanda_drm.h | 40 + 7 files changed, 932 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/glanda,gpu.yaml create mode 100644 drivers/gpu/drm/tiny/glandagpu.c create mode 100644 include/uapi/drm/glanda_drm.h -- 2.43.0
