Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34;
Message-ID: <3fd31aaa-f6bf-8440-6b08-fca2803171d9@quicinc.com>
Date:   Wed, 11 Oct 2023 11:10:25 +0530
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.0
Subject: Re: [PATCH v3 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 dts file
Content-Language: en-US
To:     Konrad Dybcio <konrad.dybcio@linaro.org>,
        Komal Bajaj <quic_kbajaj@quicinc.com>, <agross@kernel.org>,
        <andersson@kernel.org>, <robh+dt@kernel.org>,
        <krzysztof.kozlowski+dt@linaro.org>, <conor+dt@kernel.org>
CC:     <linux-arm-msm@vger.kernel.org>, <devicetree@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>, <luca.weiss@fairphone.com>
References: <20231003175456.14774-1-quic_kbajaj@quicinc.com>
 <20231003175456.14774-3-quic_kbajaj@quicinc.com>
 <5da2ba4f-5bf7-46ff-8204-0c169042dbfa@linaro.org>
From:   Mukesh Ojha <quic_mojha@quicinc.com>
In-Reply-To: <5da2ba4f-5bf7-46ff-8204-0c169042dbfa@linaro.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 10/7/2023 5:02 AM, Konrad Dybcio wrote:
> On 3.10.2023 19:54, Komal Bajaj wrote:
>> Add qcm6490 devicetree file for QCM6490 SoC and QCM6490 IDP
>> platform. QCM6490 is derived from SC7280 meant for various
>> form factor including IoT.
>>
>> Supported features are, as of now:
>> * Debug UART
>> * eMMC
>> * USB
>>
>> Signed-off-by: Komal Bajaj <quic_kbajaj@quicinc.com>
>> ---
> [...]
> 
>> diff --git a/arch/arm64/boot/dts/qcom/qcm6490.dtsi b/arch/arm64/boot/dts/qcom/qcm6490.dtsi
>> new file mode 100644
>> index 000000000000..b93270cae9ae
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/qcom/qcm6490.dtsi
>> @@ -0,0 +1,94 @@
>> +// SPDX-License-Identifier: BSD-3-Clause
>> +/*
>> + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
>> + */
>> +
>> +#include "sc7280.dtsi"
>> +
>> +/*
>> + * Delete unused sc7280 memory nodes and define the memory regions
>> + * required by qcm6490
>> + */
>> +/delete-node/ &rmtfs_mem;
>> +/delete-node/ &wlan_ce_mem;
>> +
>> +/{
>> +	reserved-memory {
>> +		cdsp_secure_heap_mem: cdsp-secure-heap@81800000 {
>> +			reg = <0x0 0x81800000 0x0 0x1e00000>;
>> +			no-map;
>> +		};
>> +
>> +		camera_mem: camera@84300000 {
> Uhh.. this is totally not the same memory map that I have on a
> random msm-5.4 source+devicetree drop (which does in turn align
> with the one on QCM6490 Fairphone 5, as it should because it's
> a rebadged reference device for the most part)..
> 
> Did you guys *really* redo it between software releases?

QCM6490 fairphone is special case where same SOC is used for mobile
product and it uses sc7280 memory map.

Current patch adds support for the same SOC marketed for IOT segment
[1] and very active in the development and soon going to freeze its
memory map, so we are deriving memory map from sc7280 and creating
a new memory map for all IOT product with qcm6490.dtsi .

[1]
https://www.qualcomm.com/products/internet-of-things/industrial/building-enterprise/qcm6490

> 
> This SoC family has been on the market for quite some time,
> breaking software expectations like that is not cool, especially
> on a product with a promised lifespan of 10 years or whatever!

I agree, but we are not changing anything for product which are there
in the market instead defining a new memory map what is going to come
with qcm6490.dtsi for IOT. Sorry, the other qcm6490 soc with
fairphone(for mobile) can get confuse with qcm6490.dtsi but that
is special case and i hope, that should be fine but, let me know if
there is concern.
> 
> With that, this really seems more of a change that would belong
> in the IDP dts than the 6490-common one..


We wanted to keep it in qcm6490.dtsi as there are some more product
going to share this in future.

-Mukesh

> 
> Konrad