[PATCH v3 0/9] drm/meson: add AFBC support

[Neil Armstrong]

On 09/12/2019 23:09, Kevin Hilman wrote:
> Neil Armstrong <narmstrong at 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 at baylibre.com>
> 
> Kevin
> 

Thanks,
Applied to drm-misc-next with typo fixup in patches 8 & 9 and review tags

Neil