From: Kevin Hilman <khilman@baylibre.com>
To: Neil Armstrong <narmstrong@baylibre.com>,
dri-devel@lists.freedesktop.org
Cc: linux-amlogic@lists.infradead.org, ayan.halder@arm.com,
linux-arm-kernel@lists.infradead.org,
Neil Armstrong <narmstrong@baylibre.com>
Subject: Re: [PATCH v3 0/9] drm/meson: add AFBC support
Date: Mon, 09 Dec 2019 14:09:30 -0800 [thread overview]
Message-ID: <7hk175rw11.fsf@baylibre.com> (raw)
In-Reply-To: <20191021091509.3864-1-narmstrong@baylibre.com>
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-12-09 22:09 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-21 9:15 [PATCH v3 0/9] drm/meson: add AFBC support Neil Armstrong
2019-10-21 9:15 ` [PATCH v3 1/9] drm/meson: add AFBC decoder registers for GXM and G12A Neil Armstrong
2019-10-21 9:15 ` [PATCH v3 2/9] drm/meson: add RDMA register bits defines Neil Armstrong
2019-10-21 9:15 ` [PATCH v3 3/9] drm/meson: store the framebuffer width for plane commit Neil Armstrong
2019-10-21 9:15 ` [PATCH v3 4/9] drm/meson: add RDMA module driver Neil Armstrong
2019-10-21 9:15 ` [PATCH v3 5/9] drm/meson: Add AFBCD " Neil Armstrong
2019-10-21 9:15 ` [PATCH v3 6/9] drm/meson: plane: add support for AFBC mode for OSD1 plane Neil Armstrong
2019-10-21 9:15 ` [PATCH v3 7/9] drm/meson: viu: add AFBC modules routing functions Neil Armstrong
2019-10-21 9:15 ` [PATCH v3 8/9] drm/meson: hold 32 lines after vsync to give time for AFBC start Neil Armstrong
2019-12-09 22:07 ` Kevin Hilman
2019-10-21 9:15 ` [PATCH v3 9/9] drm/meson: crtc: add OSD1 plane AFBC commit Neil Armstrong
2019-12-09 22:09 ` Kevin Hilman [this message]
2019-12-10 11:01 ` [PATCH v3 0/9] drm/meson: add AFBC support Neil Armstrong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7hk175rw11.fsf@baylibre.com \
--to=khilman@baylibre.com \
--cc=ayan.halder@arm.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=narmstrong@baylibre.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).