[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20230619-topic-sc8280xp-idle-v1-0-35a8b98451d0@linaro.org>
Date: Mon, 19 Jun 2023 18:18:52 +0200
From: Konrad Dybcio <konrad.dybcio@...aro.org>
To: Andy Gross <agross@...nel.org>,
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>
Cc: Marijn Suijten <marijn.suijten@...ainline.org>,
linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org,
Konrad Dybcio <konrad.dybcio@...ainline.org>,
Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>
Subject: [PATCH RFT RFC 0/3] Fix up SC8280XP idle states
Comparing the data available in the downstream sources with what's there
upstream, it was easy to spot some differences. This series aligns what
we have upstream with what is there on the vendor kernel.
The big asterisk there is that the downstream sources for SC8280XP can't
always be trusted. A simple test shows that the lower idle states that
were previously missing are implemented in the firmware (Linux reports no
errors and enters them).
HOWEVER
The only cluster idle state that's been present until now (the deepest
one) is now barely used if at all, as the scheduler seems to deem it
inefficient or so.
Hence, a request for testing and comments, especially from those who
use the X13s daily or have reliable setup to measure the power usage.
Signed-off-by: Konrad Dybcio <konrad.dybcio@...aro.org>
---
Konrad Dybcio (3):
arm64: dts: qcom: sc8280xp: Add lower cluster idle states
arm64: dts: qcom: sc8280xp: Add missing CPU idle states
arm64: dts: qcom: sc8280xp: Fix up idle state periods
arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 72 +++++++++++++++++++++++++---------
1 file changed, 54 insertions(+), 18 deletions(-)
---
base-commit: 47045630bc409ce6606d97b790895210dd1d517d
change-id: 20230619-topic-sc8280xp-idle-00fc007234c8
Best regards,
--
Konrad Dybcio <konrad.dybcio@...aro.org>
Powered by blists - more mailing lists