[PATCH 03/15] dt-bindings: mfd: syscon: Add ti,am625-dss-dpi0-clk-ctrl compatible

[Rob Herring]

On Mon, Apr 20, 2026 at 03:54:10PM +0300, Tomi Valkeinen wrote:
> The DPI output pipeline in K3 SoCs contains the display subsystem (DSS)
> which produces the in-SoC parallel video signal, and a DPI block which
> adjusts the signal to the external MIPI DPI output.
> 
> The DSS IP has registers to configure whether the data and sync signals
> are driven on rising or falling clock edge, and on some SoCs these are
> automatically conveyed to the DPI block which needs that configuration
> to properly output the MIPI DPI signal.
> 
> However, on some SoCs the DPI block configuration has to be done
> manually, using an extra register outside the DSS, DPI0_CLK_CTRL in
> MAIN_CTRL_MMR_CFG0 block, which controls the DPI block's behavior. Note
> that while the register is named "CLK_CTRL", it's not really related to
> clocks, but the sync and data signals.
> 
> Currently the DPI0_CLK_CTRL is never written, so it's always 0, meaning
> the data and sync are always driven on a rising clock edge regardless of
> the DSS configuration.
> 
> DPI0_CLK_CTRL register seems to be an independent "quirk" register,
> inside MAIN_CTRL_MMR_CFG0 block, which contains general purpose system
> registers. The registers surrounding DPI0_CLK_CTRL seem to be controlled
> by the system firmware or linux clock drivers. So, it is just this
> single register we can map, and we can't create a syscon node for the
> whole (or big parts of) MAIN_CTRL_MMR_CFG0.
> 
> I see two options to handle the register:
> 
> 1) We could add that single register to the DSS binding as a new reg
>    block. That feels wrong, as it's not a DSS register.
> 2) Add it as a syscon node, which can then be used by tidss driver.
>    It is a bit silly to create a syscon node for a single 32-bit
>    register, though.

Is it really 1 register and nothing else in that h/w block? That's quite 
unusual.

Rob