[PATCH 1/3] arm: mach-k3: am62a: Fixup CPU core, DSS, CAN-FD and Video-codec nodes in fdt

[Aparna Patra]

On 30/04/25 20:50, Bryan Brattlof wrote:
> On April 30, 2025 thus sayeth Aparna Patra:
>> AM62A SOC is available in multiple variants:
>> -CPU cores (Cortex-A) AM62Ax1 (1 core),
>>   AM62Ax2 (2 cores), AM62Ax4 (4 cores)
>> -With and without DSS, CAN-FD & Video-codec support
>>
>> Remove the relevant FDT nodes by reading the actual configuration
>> from the SoC registers, with that change it is possible to have a single
>> dts/dtb file handling the different variants at runtime.
>>
>> Signed-off-by: Aparna Patra <a-patra at ti.com>
>> ---
>>   arch/arm/mach-k3/am62ax/am62a7_fdt.c          | 41 +++++++++++++++++++
>>   .../arm/mach-k3/include/mach/am62a_hardware.h | 40 ++++++++++++++++++
>>   2 files changed, 81 insertions(+)
>>
>> diff --git a/arch/arm/mach-k3/am62ax/am62a7_fdt.c b/arch/arm/mach-k3/am62ax/am62a7_fdt.c
>> index 7f764ab36b..56fd658202 100644
>> --- a/arch/arm/mach-k3/am62ax/am62a7_fdt.c
>> +++ b/arch/arm/mach-k3/am62ax/am62a7_fdt.c
>> @@ -8,8 +8,49 @@
>>   
>>   #include "../common_fdt.h"
>>   
>> +static void fdt_fixup_cores_wdt_nodes_am62a(void *blob, int core_nr)
>> +{
>> +	char node_path[32];
>> +
>> +	if (core_nr < 1)
>> +		return;
>> +
>> +	for (; core_nr < 4; core_nr++) {
>> +		snprintf(node_path, sizeof(node_path), "/cpus/cpu@%d", core_nr);
>> +		fdt_del_node_path(blob, node_path);
>> +		snprintf(node_path, sizeof(node_path), "/cpus/cpu-map/cluster0/core%d", core_nr);
>> +		fdt_del_node_path(blob, node_path);
>> +		snprintf(node_path, sizeof(node_path), "/bus at f0000/watchdog at e0%d0000", core_nr);
>> +		fdt_del_node_path(blob, node_path);
>> +	}
>> +}
>> +
>> +static void fdt_fixup_dss_nodes_am62a(void *blob, bool has_dss)
>> +{
>> +	if (!has_dss) {
>> +		fdt_del_node_path(blob, "/bus at f0000/dss at 30200000");
>> +		fdt_del_node_path(blob, "/bus at f0000/pinctrl at f4000/main-dss0-default-pins");
> So for a little background on the upcoming paragraph[0]
>
> I completely agree we should remove the dss{} node but don't think it's
> wise of us to start trying to unwind the allocation or configuration of
> the hardware when the hardware isn't there.
>
> In my eyes because we can't really trust the names for the memory
> carveouts, mailbox and, pinmux nodes as they are just describing their
> use and are fairly unstable as the boards age we would need to keep up
> with each node's bindings and follow all the pinmux, mboxes,
> memory-region phandles via their properties to undo all those nodes
> which leaves us making too many opinionated decisions on how best to do
> that in my opinion.
>
> Anywho from that first link I'm trusting Andrew has a plan which from
> what I've seen could look something like an overlay[1] But time will
> tell.
>
> ~Bryan
>
> [0] https://lore.kernel.org/all/20250419150451.v3jgtgp4yisou65u@bryanbrattlof.com/
> [1] https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/?id=95010a7c186b86f738615231016aa017ac527612
Sure Bryan, I will test without the pinmux fixup, and send out the 
modified patches.

Thanks,
Aparna
>