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
