Display: the layer address needs a physical/DMA fixup nobody has explained #48

New issue

Open

opened 2026-08-28 14:22:11 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

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

Owner

sun4i_backend_update_layer_buffer() now adds PHYS_OFFSET to the address before
encoding it, under a needs_dram_phys_offset quirk for sun9i. That is empirical.

What was measured on a Tronsmart Draco AW80:

framebuffer, physical            0xfc900000   (holds modetest's SMPTE bars)
programmed by mainline           0xdc900000   (uninitialised DRAM)
difference                       0x20000000   = the base of DRAM on this SoC

The layer address is held in bits across two registers, so the hardware uses
((h4add << 32) | l32add) >> 3. Both addresses give the same l32add, differing only in
the four h4add bits - 6 versus 7 - which is why this hid behind everything else.

There is no dma-ranges anywhere in this SoC's device tree, so of_dma_configure()
should be giving an identity mapping and drm_fb_dma_get_gem_addr() should already return
the physical address. Why it does not has not been established.

Until it is, the quirk is a symptom fix and must not be proposed anywhere.

Done when

the source of the offset is identified, and either the DT or the driver is corrected
properly

`sun4i_backend_update_layer_buffer()` now adds `PHYS_OFFSET` to the address before encoding it, under a `needs_dram_phys_offset` quirk for sun9i. **That is empirical.** What was measured on a Tronsmart Draco AW80: ``` framebuffer, physical 0xfc900000 (holds modetest's SMPTE bars) programmed by mainline 0xdc900000 (uninitialised DRAM) difference 0x20000000 = the base of DRAM on this SoC ``` The layer address is held in bits across two registers, so the hardware uses `((h4add << 32) | l32add) >> 3`. Both addresses give the same `l32add`, differing only in the four `h4add` bits - 6 versus 7 - which is why this hid behind everything else. **There is no `dma-ranges` anywhere in this SoC's device tree**, so `of_dma_configure()` should be giving an identity mapping and `drm_fb_dma_get_gem_addr()` should already return the physical address. Why it does not has not been established. Until it is, the quirk is a symptom fix and must not be proposed anywhere. **Done when** - [ ] the source of the offset is identified, and either the DT or the driver is corrected properly

tiagoagueda added the

kernel

P3-normal

labels

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

tiagoagueda referenced this issue

2026-08-29 16:36:21 +00:00

Recover the last 512 MiB: 4 GiB fitted, 3.5 GiB reachable #61

tiagoagueda referenced this issue

2026-08-30 08:21:10 +00:00

U-Boot: no MAC driver is built — enable the GMAC to unlock TFTP boot #39

tiagoagueda referenced this issue