Hi Ao Xu, On Tue, Feb 10, 2026 at 7:06 AM Ao Xu <[email protected]> wrote: [...] > > 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 Thank you for providing more detailed insight into your idea. Overall the approach makes sense to me. In my own words that is: separate code that's different per-SoC.
What's important to me is to still reuse/share code where possible. I'm using meson_overlay.c (even if this is not high on your priority list) as an example: - G12A requires special handling in meson_overlay_atomic_disable() - the rest of the code in this file works for all SoCs Copying the whole file (800+ lines of code) and then changing 5 lines in _atomic_disable() (in each copy of the file) will be hard to understand and maintain. Or in other words: I like your approach of allowing more flexibility to handle per-SoC specifics. Please make sure to not duplicate common/shared code. > > > >> 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. Understood. I started looking into managing the PHY clocks a while ago for Meson8/8b/8m2 (those are 32-bit ARM SoCs) and it's not straight forward. So let's indeed save them for a later date. > > > > 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. That's great to hear - thank you! Best regards, Martin
