Re: [PATCH 3/4] arm64: dts: add support for A4 based Amlogic BA400

From: Xianwei Zhao <xianwei.zhao@amlogic.com>
To: Jerome Brunet <jbrunet@baylibre.com>
Cc: Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
	Kevin Hilman <khilman@baylibre.com>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-amlogic@lists.infradead.org
Subject: Re: [PATCH 3/4] arm64: dts: add support for A4 based Amlogic BA400
Date: Fri, 15 Mar 2024 16:48:40 +0800	[thread overview]
Message-ID: <fee79370-b992-46a0-a675-80b913d48e05@amlogic.com> (raw)
In-Reply-To: <1jcyrxi2l0.fsf@starbuckisacylon.baylibre.com>

Hi Jerome,
     Thanks for your reply.

On 2024/3/14 17:26, Jerome Brunet wrote:
> [ EXTERNAL EMAIL ]
> 
> On Thu 14 Mar 2024 at 16:08, Xianwei Zhao <xianwei.zhao@amlogic.com> wrote:
> 
>>>> +
>>>> +#include "amlogic-a4.dtsi"
>>> Could you describe how the a4 and a5 differs from each other ?
>>> The description given in the commit description is the same.
>>> Beside the a53 vs a55, I'm not seeing much of a difference.
>>> Admittedly, there is not much yet but I wonder if a4 and a5 should have
>>> a common dtsi.
>>>
>> They are mostly the same, A5 include HiFi-DSP and NPU, but A4 is not. And
>> some peripheral modules are different, such as SPI and Ehernet phy.
>>
>> I would like to wait for the follow-on chips to come out before considering
>> a merger with common dtsi file.
>>
> 
> No, Please do it now. There is no reason for the community to review the
> same thing twice if the SoCs are "mostly the same".
> 
OK, I will do it.
>>>> +
>>>> +/ {
>>>> +     model = "Amlogic A113L2 ba400 Development Board";
>>>> +     compatible = "amlogic,ba400","amlogic,a4";
>>>> +     interrupt-parent = <&gic>;
>>>> +     #address-cells = <2>;
>>>> +     #size-cells = <2>;
>>>> +
>>>> +     aliases {
>>>> +             serial0 = &uart_b;
>>>> +     };
>>>> +
>>>> +     memory@0 {
>>>> +             device_type = "memory";
>>>> +             reg = <0x0 0x0 0x0 0x40000000>;
>>>> +     };
>>>> +
>>>> +     reserved-memory {
>>>> +             #address-cells = <2>;
>>>> +             #size-cells = <2>;
>>>> +             ranges;
>>>> +
>>>> +             /* 52 MiB reserved for ARM Trusted Firmware */
>>> That's a lot of memory to blindly reserve.
>>> Any chance we can stop doing that and have u-boot amend reserved memory
>>> zone based on the actual needs of the device ?
>> Yes. U-boot will change size of reserved memory base on actual usage.
> 
> Then u-boot should add (not change) the memory if necessary.
> Please drop this.
> 
Amlogic's u-boot will change the reserved memory size, size is not an 
issue. But Some one use u-boot himself not Amlogic's, If here drop this, 
there is a strange problem when it runs.
>>>
>>>> +             secmon_reserved:linux,secmon {
>>>> +                     compatible = "shared-dma-pool";
>>>> +                     no-map;
>>>> +                     alignment = <0x0 0x400000>;
>>>> +                     reg = <0x0 0x05000000 0x0 0x3400000>;
>>>> +             };
>>>> +     };
>>>> +};
>>>> +
> 

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