Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32;
Message-ID: <30b4c424-39ee-7ae6-faf2-c5ba32dda07f@linaro.org>
Date:   Thu, 2 Nov 2023 14:32:30 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.9.0
Subject: Re: [PATCH RFC 2/8] arm64: dts: qcom: add initial SM8650 dtsi
To:     neil.armstrong@linaro.org, Andy Gross <agross@kernel.org>,
        Bjorn Andersson <andersson@kernel.org>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Conor Dooley <conor+dt@kernel.org>
Cc:     linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org
References: <20231025-topic-sm8650-upstream-dt-v1-0-a821712af62f@linaro.org>
 <20231025-topic-sm8650-upstream-dt-v1-2-a821712af62f@linaro.org>
 <691f1781-906c-411f-90f6-e1cc71062253@linaro.org>
 <e86fa7b4-635c-4fd5-9b3c-ade96ddf5c0f@linaro.org>
From:   Konrad Dybcio <konrad.dybcio@linaro.org>
In-Reply-To: <e86fa7b4-635c-4fd5-9b3c-ade96ddf5c0f@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk


On 02/11/2023 11:54, Neil Armstrong wrote:
> On 25/10/2023 11:01, Konrad Dybcio wrote:
>>
>>
>> On 10/25/23 09:47, Neil Armstrong wrote:
>>> Add initial DTSI for the Qualcomm SM8650 platform,
>>> only contains nodes which doesn't depend on interconnect.
>>>
>>> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
>>> ---[...]
>>
>>> +            CLUSTER_SLEEP_1: cluster-sleep-1 {
>>> +                compatible = "domain-idle-state";
>>> +                arm,psci-suspend-param = <0x4100c344>;
>> I think this parameter signals the AOSS to attempt system
>> suspend and CLUSTER_SLEEP is a shallower, separate state.
> 
> OK, so downstream call this state "APSS_OFF" and the other state
> calling 0x41000044 "CLUSTER_PWR_DN"Well, the name APSS_OFF suggests that all clusters go offline so
that would be a bit more complex than a simple "cut power to this
cluster"


> On sm8[345]0 and qdu1000/sm4450 there's both states called 
> CLUSTER_SLEEP_0 and CLUSTER_SLEEP_1,
> and referenced into CLUSTER_PD cluster power domain.
> 
> I assume this is the same as SM8550, so what's the issue ?
It's just that we've been naming it in the most generic way possible
and that it could be more descriptive, especially given its
correlation with different things

Konrad