Forward-port pvrsrvkm from kernel 3.4 to mainline #58

New issue

Open

opened 2026-08-29 15:40:47 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-08-29 15:40:47 +00:00

Owner

Part of #55, and the bulk of the work.

rogue_km (DDK 1.3, dual GPL/MIT) builds against Linux 3.4. We need it on 7.2, ARMv7. It is 427
files, but almost all churn is confined to the OS abstraction layer,
services/server/env/linux/ - that is the DDK's design intent and what makes this tractable.

Approach

Set up an out-of-tree build against our tree and let it fail. Collect the whole error list
before fixing anything.
Work the OS layer. Expect at least: get_user_pages() signature churn;
vm_operations_struct.fault becoming vm_fault_t fault(struct vm_fault *); VM_RESERVED ->
VM_DONTEXPAND | VM_DONTDUMP; create_proc_entry -> proc_create + proc_ops;
do_gettimeofday -> ktime_get_ts64; kmap_atomic -> kmap_local_page; access_ok() losing
its type argument; dma_buf_export() taking dma_buf_export_info; DMA API attrs and
dma_map_sgtable; idr/ida rework.
Rewrite the system layer. services/system/rgx_sunxi/{sysconfig,sunxi_init}.c uses
hardcoded SUNXI_* constants and mach/ includes that do not exist in mainline. Convert to a
real platform_driver with of_match_table, devm_platform_ioremap_resource(),
platform_get_irq(), devm_clk_get(), devm_regulator_get(). This is a rewrite, not a patch -
the file is short.

Reference, not base

TI maintains ti-img-rogue-driver for the same DDK family against modern kernels. Its env/linux
layer shows the correct modern idioms and is worth reading closely.

Do not copy it wholesale - its DDK is far newer, and our DDK 1.3 userspace blobs would reject
the resulting bridge.

Done when

Module builds, loads, probes, /dev/pvrsrvkm appears, no oops. No GPU activity is expected at
this gate. Needs #57 (the DT node) first; does not need the board.

Part of #55, and the bulk of the work. `rogue_km` (DDK 1.3, dual GPL/MIT) builds against Linux 3.4. We need it on 7.2, ARMv7. It is 427 files, but **almost all churn is confined to the OS abstraction layer**, `services/server/env/linux/` - that is the DDK's design intent and what makes this tractable. ## Approach 1. Set up an out-of-tree build against our tree and let it fail. **Collect the whole error list before fixing anything.** 2. Work the OS layer. Expect at least: `get_user_pages()` signature churn; `vm_operations_struct.fault` becoming `vm_fault_t fault(struct vm_fault *)`; `VM_RESERVED` -> `VM_DONTEXPAND | VM_DONTDUMP`; `create_proc_entry` -> `proc_create` + `proc_ops`; `do_gettimeofday` -> `ktime_get_ts64`; `kmap_atomic` -> `kmap_local_page`; `access_ok()` losing its type argument; `dma_buf_export()` taking `dma_buf_export_info`; DMA API attrs and `dma_map_sgtable`; idr/ida rework. 3. **Rewrite the system layer.** `services/system/rgx_sunxi/{sysconfig,sunxi_init}.c` uses hardcoded `SUNXI_*` constants and `mach/` includes that do not exist in mainline. Convert to a real `platform_driver` with `of_match_table`, `devm_platform_ioremap_resource()`, `platform_get_irq()`, `devm_clk_get()`, `devm_regulator_get()`. This is a rewrite, not a patch - the file is short. ## Reference, not base TI maintains `ti-img-rogue-driver` for the same DDK family against modern kernels. Its `env/linux` layer shows the correct modern idioms and is worth reading closely. **Do not copy it wholesale** - its DDK is far newer, and our DDK 1.3 userspace blobs would reject the resulting bridge. ## Done when Module builds, loads, probes, `/dev/pvrsrvkm` appears, no oops. No GPU activity is expected at this gate. Needs #57 (the DT node) first; does not need the board.

tiagoagueda added the

kernel

P3-normal

labels

2026-08-29 15:40:47 +00:00

tiagoagueda referenced this issue

2026-08-29 15:41:18 +00:00

PowerVR G6230: bring the GPU up under mainline Linux #55

tiagoagueda referenced this issue

2026-08-30 06:07:44 +00:00

Pushing to Forgejo works from one machine and one protocol only #62

tiagoagueda referenced this issue