[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f431ab4e-fdd3-4771-a770-558cdba9ef75@linaro.org>
Date: Sat, 30 Dec 2023 15:10:29 +0100
From: Konrad Dybcio <konrad.dybcio@...aro.org>
To: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
Cc: Bjorn Andersson <andersson@...nel.org>, Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>, Johan Hovold <johan+linaro@...nel.org>,
Marijn Suijten <marijn.suijten@...ainline.org>,
linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org,
Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
Konrad Dybcio <konrad.dybcio@...ainline.org>
Subject: Re: [PATCH 3/3] arm64: dts: qcom: sc8280xp-crd: Add PCIe CLKREQ#
sleep state
On 29.12.2023 18:14, Manivannan Sadhasivam wrote:
> On Wed, Dec 27, 2023 at 11:28:28PM +0100, Konrad Dybcio wrote:
>> The CLKREQ pin should not be muxed to its active function when the RC
>> is asleep. Add the missing pin sleep states to resolve that.
>>
>
> I don't understand why it should not be muxed and wondering what is the actual
> issue you are seeing that lead to this conclusion.
According to my knowledge, demuxing this pin prevents the RC from
getting (possibly erronous) reference clock request signals when
running the RC shutdown sequence. Reading this again, the fixes
tags don't really fit this commit.
What's perhaps more interesting is that on msm8996, Qualcomm vendor
kernels used to remove the pull-up on the CLKREQ pin in its sleep
state, while on msm8998 through sm8550 they keep it there, always..
Perhaps an oversight?
Konrad
Powered by blists - more mailing lists