| Message ID | 20191021091509.3864-1-narmstrong@baylibre.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm/meson: add AFBC support | expand |
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
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