Re: [PATCH 2/2] arm64: dts: Add support for phyBOARD-Electra-AM642

From: Nishanth Menon <nm@ti.com>
To: Wadim Egorov <W.Egorov@phytec.de>
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"vigneshr@ti.com" <vigneshr@ti.com>,
	"kristo@kernel.org" <kristo@kernel.org>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"krzysztof.kozlowski+dt@linaro.org"
	<krzysztof.kozlowski+dt@linaro.org>
Subject: Re: [PATCH 2/2] arm64: dts: Add support for phyBOARD-Electra-AM642
Date: Wed, 2 Nov 2022 14:41:46 -0500	[thread overview]
Message-ID: <20221102194146.zyaw2yzl7q4b6r7u@ducky> (raw)
In-Reply-To: <1c73c3a0-458a-0005-f9a7-2d879e70cfe3@phytec.de>

On 16:56-20221102, Wadim Egorov wrote:
[...]

> >> +
> >> +#include <dt-bindings/gpio/gpio.h>
> >> +#include <dt-bindings/leds/common.h>
> >> +#include <dt-bindings/net/ti-dp83867.h>
> >> +
> >> +/ {
> >> +	model = "PHYTEC phyCORE-AM64x";
> >> +	compatible = "phytec,am64-phycore-som";
> > Does this match the binding?
> 
> Not very sure about the compatible I should chose here. It is probably not very 
> important since the compatible gets overridden by the carrier which specifies 
> the am642 SoC.
> Seems like the TI SoMs (k3-j7*som*.dtsi) do not add a compatible at all.
> 
> Or do you think we should add the "ti,am642" compatible here?

If the compatible of SoM makes much sense as a standalone OR usable
elsewhere, then it could be an enum option to allow for som, soC as a
valid combination.

On the other hand, simplistically, it does look like SoM (like the j7es
processor board) serves no specific purpose standalone, in which case
skipping it is more appropriate.

> >> +
> >> +		rtos_ipc_memory_region: ipc-memories@a5000000 {
> >> +			reg = <0x00 0xa5000000 0x00 0x00800000>;
> >> +			alignment = <0x1000>;

Since it is no-map, alignment does'nt serve any purpose, right?

> >> +			no-map;
> >> +		};
> > Does this memory map work for All usage of the SoM and firmware
> > combinations? OR would you like to keep the immutable memory map
> > reservation in the base device tree and use overlay for firmware
> > combination?
> 
> Can you be a bit more specific about the firmware and the combinations you are 
> talking about?
> For now, I just applied the same memory maps as the k3-am642-evm.dts.
> 
> Are you referring to the variants of the AM64 which can come with more or less 
> R5 cores?
> So an AM644 and AM641 would need different entries here and should be adjusted 
> e.g. per dt overlays?
> In that case it would be nice to have a minimal set of regions defined in the 
> som.dtsi.

Two things:
In the actual usage of the board, do folks tend to stick with the memory
map OR does the memory map tend to change? there are specific stuff like
DM or tisci or tfa that does look mandatory.

Further, if there are variations like the processor variations you
mention with differing R5 combinations (processor and firmware),
overlays will be your friend as it can scale across multiple carrier
board options as well.

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel