Display: no sun9i frontend driver, so the vendor's scaler path is unreachable #49

New issue

Open

opened 2026-08-28 14:22:11 +00:00 by tiagoagueda · 1 comment

tiagoagueda commented

2026-08-28 14:22:11 +00:00

Owner

sun4i_frontend.c carries compatibles for a10, a20, a23 and a33 and none for
sun9i. The dtsi declares fe0/fe1 as allwinner,sun9i-a80-display-frontend, nothing
binds them, backend->frontend stays an error pointer, and
sun4i_backend_plane_uses_frontend() therefore always returns false.

So every frame on this SoC goes down the direct backend-layer path. That works - there is a
picture - but it is not what the vendor does. The board's own sys_config, recovered from
the vendor LiveSuit image, says:

fb0_scaler_mode_enable = 1

i.e. the HDMI framebuffer goes through the scaler, DEFE1 -> DEU1 -> DEBE1.

Consequences of not having it: no hardware scaling, no YUV planes through the frontend, and
no way to test that path at all.

Groundwork already done: probe/fefix.c brings DEFE1 up far enough to be routed into the
backend (LAY_VDOEN / LAY_VDOSEL), including the FIR coefficient RAM, and probe/deufix.c
ungates and configures the DEU. Neither produced a picture on its own, but both were written
while four other faults were still in the way and deserve retrying now.

Done when

sun4i_frontend binds on sun9i, or it is established that the direct path is
sufficient and the DT nodes should go

`sun4i_frontend.c` carries compatibles for a10, a20, a23 and a33 and **none for sun9i**. The dtsi declares `fe0`/`fe1` as `allwinner,sun9i-a80-display-frontend`, nothing binds them, `backend->frontend` stays an error pointer, and `sun4i_backend_plane_uses_frontend()` therefore always returns false. So every frame on this SoC goes down the direct backend-layer path. That works - there is a picture - but it is not what the vendor does. The board's own `sys_config`, recovered from the vendor LiveSuit image, says: ``` fb0_scaler_mode_enable = 1 ``` i.e. the HDMI framebuffer goes through the scaler, `DEFE1 -> DEU1 -> DEBE1`. Consequences of not having it: no hardware scaling, no YUV planes through the frontend, and no way to test that path at all. Groundwork already done: `probe/fefix.c` brings DEFE1 up far enough to be routed into the backend (`LAY_VDOEN` / `LAY_VDOSEL`), including the FIR coefficient RAM, and `probe/deufix.c` ungates and configures the DEU. Neither produced a picture on its own, but both were written while four other faults were still in the way and deserve retrying now. **Done when** - [ ] `sun4i_frontend` binds on sun9i, or it is established that the direct path is sufficient and the DT nodes should go

tiagoagueda added the

kernel

P4-later

labels

2026-08-28 14:22:11 +00:00

tiagoagueda commented

2026-08-30 14:26:48 +00:00

Author

Owner

The mirror has a concrete starting point for this, which changes it from "no driver exists" to
"the registers are documented".

A80/Memory map places the frontend blocks explicitly:

block	range	size
DE SYS	`0x03000000 - 0x03000fff`	4 KiB
DE_FE 0	`0x03120000 - 0x0313ffff`	128 KiB
DE_FE 1	`0x03140000 - 0x0315ffff`	128 KiB

and - the useful part - it links them to the existing A10/DE_FE register guide rather than
describing them separately. If the sun9i frontend really is the A10 DE_FE at a different base,
then this is a port of a documented block, not reverse engineering from scratch, and the existing
sun4i-drm frontend code becomes the obvious reference.

Worth verifying that equivalence first, on hardware, before writing anything: read a few
identifying registers at 0x03120000 and compare against what A10/DE_FE says they should be.
That is a cheap experiment with the probe/ module pattern already in use here, and it decides
whether this issue is "port an existing driver" or "start from the manual".

From a deep pass over the offline linux-sunxi.org mirror (a80/linux-sunxi.org/wiki-backup, 4095 pages, snapshot 2026-08-29). linux-sunxi.org content is CC BY-SA; the pages named above are the attribution.

The mirror has a concrete starting point for this, which changes it from "no driver exists" to "the registers are documented". **`A80/Memory map`** places the frontend blocks explicitly: | block | range | size | |---|---|---| | DE SYS | `0x03000000 - 0x03000fff` | 4 KiB | | **DE_FE 0** | `0x03120000 - 0x0313ffff` | 128 KiB | | **DE_FE 1** | `0x03140000 - 0x0315ffff` | 128 KiB | and - the useful part - it links them to the existing **`A10/DE_FE`** register guide rather than describing them separately. If the sun9i frontend really is the A10 DE_FE at a different base, then this is a port of a documented block, not reverse engineering from scratch, and the existing `sun4i-drm` frontend code becomes the obvious reference. Worth verifying that equivalence first, on hardware, before writing anything: read a few identifying registers at `0x03120000` and compare against what `A10/DE_FE` says they should be. That is a cheap experiment with the `probe/` module pattern already in use here, and it decides whether this issue is "port an existing driver" or "start from the manual". --- *From a deep pass over the offline linux-sunxi.org mirror (`a80/linux-sunxi.org/wiki-backup`, 4095 pages, snapshot 2026-08-29). linux-sunxi.org content is CC BY-SA; the pages named above are the attribution.*

tiagoagueda referenced this issue

2026-08-30 14:26:49 +00:00

Cross-check the device tree against the wiki's A80 memory map #75

tiagoagueda referenced this issue from a commit

2026-08-30 14:27:46 +00:00

Deep-read the linux-sunxi mirror against the tracker (#73 #74 #75)