在 2026/2/10 5:26, Martin Blumenstingl 写道:
[ EXTERNAL EMAIL ]
Hi Ao Xu,
On Thu, Feb 5, 2026 at 12:56 PM Ao Xu <[email protected]> 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!
Hi，martin
thanks for your comments.
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.
I would like to first describe the current state.
In atomic_update and atomic_disable, register values are derived
from the property information and stored into the priv->viu and
priv->afbc structures.
In meson_crtc_irq, the previously saved values are then written into
the hardware registers.
In future SoCs, we may encounter the following scenarios:
* The register addresses of a given block may change. For example, on
S905X2, the OSD1 scaler registers are located at 0x1dc0–0x1dcd,
while on A311D2, the same OSD1 scaler registers move to 0x5a00–0x5a0d.
* A block's functionality may be reduced or extended, which can
include changes to existing register bits or the introduction of new
control registers. For instance, the OSD MIF block previously
required canvas configuration, while on T7C the canvas mechanism is
completely removed.
* An entire block may be removed or newly added. For example, GFCD,
which internally integrates AFBC and AFRC hardware modules, is
present on A9.
Register programming is performed through RDMA hardware.When RDMA is
available, the flow is different.
In atomic_update and atomic_disable, register values are written
directly into the RDMA register table, and there is no need to cache
the register values in software.
Once all register writes are prepared, rdma_config is used to let
the hardware flush the RDMA register table into the real registers
on the next VSync.
On a given SoC, each internal block contains fields that determine which
register set it should use.
This information is SoC-specific and must be provided by the SoC description
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?
This proposal focuses only on VPU OSD and video-related blocks.
Encoder and connector handling is a separate and much larger topic.
I am currently investigating how to reuse existing PHY and clock tree
interfaces for that part, but it is intentionally kept out of this
proposal.
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)?
Yes, we will add RDMA function support firstly.
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
