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-pa...@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@f0000/watchdog@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@f0000/dss@30200000");
> + fdt_del_node_path(blob,
> "/bus@f0000/pinctrl@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.v3jgtgp4yisou...@bryanbrattlof.com/
[1]
https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/?id=95010a7c186b86f738615231016aa017ac527612
