mbox series

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

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

Message

Neil Armstrong Oct. 21, 2019, 9:15 a.m. UTC
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].

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.

Changes since v2 of [3] and [4]:
- Merge of RDMA patchset
- Fix suspend/resume when AFBC is enabled
- Re-enabled vsync_force otherwise RDMA is also stopped

Changes since v1 at [2]:
- Discards XRGB modes with YTR, only allow XBGR with YTR
- Add non-YTR modifiers for G12A
- Disable completely XRGB modes for GXM, until we find how to disable YTR
- Add proper argb remap for XRGB modes
- Enable OSD_STAT sync signal

[1] https://android.googlesource.com/device/amlogic/yukawa/+/refs/heads/master/gpu/
[2] https://patchwork.freedesktop.org/series/67832/#rev1
[3] https://patchwork.freedesktop.org/series/67832/#rev2
[4] https://patchwork.freedesktop.org/series/68021/#rev2

Neil Armstrong (9):
  drm/meson: add AFBC decoder registers for GXM and G12A
  drm/meson: add RDMA register bits defines
  drm/meson: store the framebuffer width for plane commit
  drm/meson: add RDMA module driver
  drm/meson: Add AFBCD module driver
  drm/meson: plane: add support for AFBC mode for OSD1 plane
  drm/meson: viu: add AFBC modules routing functions
  drm/meson: hold 32 lines after vsync to give time for AFBC start
  drm/meson: crtc: add OSD1 plane AFBC commit

 drivers/gpu/drm/meson/Makefile          |   1 +
 drivers/gpu/drm/meson/meson_crtc.c      |  79 ++++-
 drivers/gpu/drm/meson/meson_drv.c       |  50 ++-
 drivers/gpu/drm/meson/meson_drv.h       |  23 ++
 drivers/gpu/drm/meson/meson_osd_afbcd.c | 389 ++++++++++++++++++++++++
 drivers/gpu/drm/meson/meson_osd_afbcd.h |  28 ++
 drivers/gpu/drm/meson/meson_plane.c     | 229 ++++++++++++--
 drivers/gpu/drm/meson/meson_rdma.c      | 135 ++++++++
 drivers/gpu/drm/meson/meson_rdma.h      |  21 ++
 drivers/gpu/drm/meson/meson_registers.h | 110 +++++++
 drivers/gpu/drm/meson/meson_viu.c       |  83 ++++-
 drivers/gpu/drm/meson/meson_viu.h       |  19 ++
 12 files changed, 1123 insertions(+), 44 deletions(-)
 create mode 100644 drivers/gpu/drm/meson/meson_osd_afbcd.c
 create mode 100644 drivers/gpu/drm/meson/meson_osd_afbcd.h
 create mode 100644 drivers/gpu/drm/meson/meson_rdma.c
 create mode 100644 drivers/gpu/drm/meson/meson_rdma.h

Comments

Kevin Hilman Dec. 9, 2019, 10:09 p.m. UTC | #1
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
Neil Armstrong Dec. 10, 2019, 11:01 a.m. UTC | #2
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