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

[Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>]

Hi,

On 05/05/2026 22:35, Rob Herring wrote:
> 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.
It is just this one register that the DSS driver is interested in, and 
that register is surrounded by registers used by other, unrelated, 
drivers or the system firmware.

This has been discussed in some older threads, and to summarize:

The Soc has a so called CTRL_MMR (control memory-mapped-registers) area 
at 0x100000, size 0x20000. It's a dumping ground for all kinds of system 
integration registers. In the current binding, this has been just a 
simple-bus, containing some sub-nodes (shortened version):

main_conf: bus@100000 {
	compatible = "simple-bus";
	reg = <0x00 0x00100000 0x00 0x20000>;

	phy_gmii_sel: phy@4044 {
		compatible = "ti,am654-phy-gmii-sel";
	};

	audio_refclk0: clock-controller@82e0 {
		compatible = "ti,am62-audio-refclk";
	};

	dss_oldi_io_ctrl: dss-oldi-io-ctrl@8600 {
		compatible = "ti,am625-dss-oldi-io-ctrl", "syscon";
	};
};

There already was the dss-oldi-io-ctrl, so this new 
am625-dss-dpi0-clk-ctrl was added the same way as we needed a syscon.

After some testing, changing the whole main_conf to a syscon seems to 
work ok, even if inside it there are devices mapping parts of the same 
memory area (although I'm not sure how to test all those devices). I 
originally thought mapping the same memory area from two different 
driers would immediately fail.

So, instead of adding a new special syscon node for this single 
register, as done in this patch, I think we can just make the whole 
main_conf a syscon, and point to it from the display subsystem node:

	ti,dpi-io-ctrl = <&main_conf>;

Then the driver would need to access the register with offset 0x8300. 
But I'm a bit reluctant to add such a SoC-integration related offset to 
the driver. Even if the register would stay the same from SoC model to 
another, the offset could change. So, we could, in the display subsystem 
node, do:

	ti,dpi-io-ctrl = <&main_conf 0x8300>;

The driver can use syscon_regmap_lookup_by_phandle_args() and thus get 
the offset from the dts. I think this works ok, so I'll make that change 
for v2 unless someone has better ideas.

  Tomi