Re: [PATCH 00/11] Subject: [PATCH 00/11] Add DRM support for Amlogic S4

[Martin Blumenstingl <martin.blumenstingl@googlemail.com>]

Hi Ao Xu,

On Thu, Feb 5, 2026 at 12:56 PM Ao Xu <ao.xu@amlogic.com> wrote:
>
> Hi neil, martin, jerome
>
> This email proposes a refactoring of the Meson DRM driver to adopt a
> component-based pipeline management model, inspired by the ARM Komeda DRM
> driver.
First of all: thanks for working on a plan on how to move things forward!

> The current Meson DRM implementation tightly couples drm_plane and
> drm_crtc logic with specific hardware blocks (OSD MIF, AFBC, scaler,
> blend, postblend), which makes it increasingly difficult to scale to
> newer SoCs.
I have to admit that I'm new to this part of the DRM driver /
subsystem - so I will probably ask some novice questions.

> The attached /vpu-block/ file describes the proposed VPU block pipeline.
>
> This implement introduces a generic pipeline framework where:
>
> - Hardware blocks (MIF, AFBC, SCALER, BLEND, POSTBLEND) are modeled as
>    independent components with well-defined capabilities.
>
> - drm_plane and drm_crtc are responsible only for building and validating
>    a pipeline, not for directly programming hardware registers.
> - Per-block atomic state is separated from SoC-specific register layouts,
>    similar to Komeda's component_state and pipeline_state model.
I have two questions here:
- How is per-SoC register access managed?
- How are "common" (shared across multiple - or even all SoCs)
registers managed?

It seems that the komeda driver uses komeda_dev_funcs for the
per-variant access.
However, it's not clear how this scales as only two mostly identical
display controllers (D32 and D71) ever made it into the driver.

> This is achieved by introducing four core objects, as shown in the
> attached class-diagram document.
>
> - meson_vpu_block
> - meson_vpu_block_state
> - meson_pipeline
> - meson_pipeline_state
>
>
> The atomic flow is structured as shown in the attached commit-flow document.
The public A311D datasheet page 304 [0] shows that CVBS, HDMITX and
MIPI_DSI are part of the VPU block.
Those aren't mentioned in your flows. Is that because they are "after"
POSTBLEND and would therefore be part of a future refactoring
approach?

Also RMDA is shown in the same diagram as part of VPU. Neil had to
work hard to implement it back then for AFBC.
You haven't listed it in your diagrams but I assume it is going to be
part of the implementation as it is/was mandatory for AFBC.
Can you confirm my understanding here (or clear up my confusion)?

> The intention of this proposal is not to change hardware behavior, but to
> gradually restructure the driver to improve maintainability, scalability,
> and correctness of atomic state handling across different Meson SoCs.
>
> This is an initial proposal intended to gather feedback on the overall
> architecture before converting existing code paths incrementally.
Making incremental changes sounds great! The meson DRM driver is too
big to "just" copy it and make modifications (or even modifying it
directly with one huge patch).


Best regards,
Martin


[0] https://dl.khadas.com/products/vim3/datasheet/a311d-datasheet.pdf

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic