[PATCH 0/6] arm64: ti: Use syscon for the Control Module

[Tomi Valkeinen]

Hi Andrew, Krzysztof,

On 29/05/2026 01:59, Andrew Davis wrote:
> On 5/28/26 7:53 AM, Tomi Valkeinen wrote:
>> I have been trying to get BeagleY-AI display support to upstream:
>>
>> 20260513-beagley-ai-display-v2-0-9e9bcefde6bc at ideasonboard.com
>>
>> One difficulty has been the handling of the Control Module region, as
>> we need access to a single in that region, surrounded by registers for
>> other subsystems. In my series I made the related node a syscon, thus
>> allowing versatile access to the registers:
>>
>> https://lore.kernel.org/all/20260513-beagley-ai-display- 
>> v2-14-9e9bcefde6bc at ideasonboard.com/
>>
>> However, that's not a correct way to handle it. I realized we already
>> have ti,j721e-system-controller.yaml binding for older SoCs, which has
>> syscon but it's not used for the newer TI SoCs. This series takes the
>> same binding into use for the newer SoCs.
>>
> 
> We moved away from this system-controller thing because it was always
> a hack to allow us to poke into random control registers from nodes
> throughout the DT. This was a mess and also caused issues with multiple
> mappings to the same registers (some sub nodes inside the control space
> also make their own mappings). If you need access to registers then make
> a node with those registers in the `reg` property.
> 
> The only reason we didn't get rid of `ti,j721e-system-controller.yaml`
> completely from the older SoCs was we were told it would be an ABI
> break to correct those DT files. Let's not spread that problem to
> new SoCs.
I'm still stuck on this issue.

So, to summarize, we have the big control module memory region from 
which various drivers need "random" registers. In my particular case, 
the display subsystem (DSS) driver needs to access a single register 
from the control module, but as the control module contains a lot of 
registers, there are other similar cases too (I've seen at least one 
other series, trying to add access to control module registers).

Taking AM62 SoC as an example, we have this in upstream:

https://github.com/torvalds/linux/blob/4edcdefd4083ae04b1a5656f4be6cd83ae919ef4/arch/arm64/boot/dts/ti/k3-am62-main.dtsi#L44

"main_conf" (simple-bus) node representing the control module, and nodes 
under that representing either small things like clocks or, in 
dss_oldi_io_ctrl case, a syscon.

I'm aware of three options on how to handle this.

1) Adding small syscon nodes under the main_conf, similar to the 
existing dss_oldi_io_ctrl.

I did this in the earlier series: 
https://lore.kernel.org/all/20260420-beagley-ai-display-v1-3-f628543dfd14%40ideasonboard.com/ 


2) Making the whole control module a syscon, as I do in this series.

3) Adding the required registers as a new 'reg' block under the dss' DT 
node.

Both 1) and 2) have been nacked or at least very strongly questioned. 3) 
doesn't feel right, the register is not a register for the IP but an 
external SoC integration register.

Is there an option 4)? In your opinion, is one of the above the one 
clear choice?

  Tomi