Re: [PATCH 0/6] arm64: ti: Use syscon for the Control Module
From: Tomi Valkeinen
Date: Fri Jun 26 2026 - 07:42:47 EST
Hi Andrew, Krzysztof,
On 29/05/2026 01:59, Andrew Davis wrote:
On 5/28/26 7:53 AM, Tomi Valkeinen wrote:I'm still stuck on this issue.
I have been trying to get BeagleY-AI display support to upstream:
20260513-beagley-ai-display-v2-0-9e9bcefde6bc@xxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxx/
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.
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