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

[Ao Xu <ao.xu@amlogic.com>]

在 2026/2/10 5:26, Martin Blumenstingl 写道:
> [ EXTERNAL EMAIL ]
>
> 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!

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

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