On 09/12/2019 23:09, Kevin Hilman wrote:
Neil Armstrong narmstrong@baylibre.com writes:
This adds support for the ARM Framebuffer Compression decoders found in the Amlogic GXM and G12A SoCs.
This patchset is a merge of v2 "drm/meson: add AFBC support" at [3] and v2 "drm/meson: implement RDMA for AFBC reset on vsync" at [4].
Oops, replied to the wrong series earlier...
The VPU embeds a "Register DMA" that can write a sequence of registers on the VPU AHB bus, either manually or triggered by an internal IRQ event like VSYNC or a line input counter.
The Amlogic GXM and G12A AFBC decoder are totally different, the GXM only handling only the AFBC v1.0 modes and the G12A decoder handling the AFBC v1.2 modes.
The G12A AFBC decoder is an external IP integrated in the video pipeline, and the GXM AFBC decoder seems to the an Amlogic custom decoder more tighly integrated in the video pipeline.
The GXM AFBC decoder can handle only one AFBC plane for 2 available OSD planes available in HW, and the G12A AFBC decoder can handle up to 4 AFBC planes for up to 3 OSD planes available in HW.
The Amlogic GXM supports 16x16 SPARSE and 16x16 SPLIT AFBC buffers up to 4k.
On the other side, for G12A SPLIT is mandatory in 16x16 block mode, but for 4k modes 32x8+SPLIT AFBC buffers is manadatory for performances reasons.
The Amlogic GXM and G12A AFBC decoders are integrated very differently.
The Amlogic GXM has a direct output path to the OSD1 VIU pixel input, because the GXM AFBC decoder seem to be a custom IP developed by Amlogic.
On the other side, the Amlogic G12A AFBC decoder seems to be an external IP that emit pixels on an AXI master hooked to a "Mali Unpack" block feeding the OSD1 VIU pixel input. This uses a weird "0x1000000" internal HW physical address on both sides to transfer the pixels.
For Amlogic GXM, the supported pixel formats are the same as the normal linear OSD1 mode.
On the other side, Amlogic added support for all AFBC v1.2 formats for the G12A AFBC integration.
The initial RDMA implementation handles a single channel (over 8), triggered by the VSYNC irq and does not handle the RDMA irq.
The RDMA will be usefull to reset and program the AFBC decoder unit on each vsync without involving the interrupt handler that can be masked for a long period of time, producing display glitches.
For this we use the meson_rdma_writel_sync() which adds the register write tuple (VPU register offset and register value) to the RDMA buffer and write the value to the HW.
When enabled, the RDMA is enabled to rewritte the same sequence at the next VSYNC event, until a new buffer is committed to the OSD plane.
For testing, the only available AFBC buffer generation is the Android Yukawa Dvalin Android Mali blobs found at [1].
Both SoCs has been tested using buffers generated under AOSP, but only G12A was tested using a runtime stream of AFBC buffers, GXM was only tested using static buffers loaded from files.
Reviewed-by: Kevin Hilman khilman@baylibre.com
Kevin
Thanks, Applied to drm-misc-next with typo fixup in patches 8 & 9 and review tags
Neil