On 11/5/2024 3:47 PM, Tingguo Cheng wrote:
On 11/1/2024 4:28 AM, Elliot Berman wrote:
On Mon, Oct 28, 2024 at 03:14:49PM +0200, Dmitry Baryshkov wrote:
On Mon, Oct 28, 2024 at 02:09:45PM +0100, Konrad Dybcio wrote:
On 28.10.2024 10:41 AM, Dmitry Baryshkov wrote:
On Mon, 28 Oct 2024 at 10:40, Tingguo Cheng
<quic_tingguoc@xxxxxxxxxxx> wrote:
On 10/28/2024 4:23 PM, Dmitry Baryshkov wrote:
On Mon, Oct 28, 2024 at 04:03:25PM +0800, Tingguo Cheng wrote:
Enable PMIC and PMIC peripherals for qcs615-ride board.
Signed-off-by: Tingguo Cheng <quic_tingguoc@xxxxxxxxxxx>
---
arch/arm64/boot/dts/qcom/qcs615-ride.dts | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcs615-ride.dts b/arch/
arm64/boot/dts/qcom/qcs615-ride.dts
index
ee6cab3924a6d71f29934a8debba3a832882abdd..37358f080827bbe4484c14c5f159e813810c2119 100644
--- a/arch/arm64/boot/dts/qcom/qcs615-ride.dts
+++ b/arch/arm64/boot/dts/qcom/qcs615-ride.dts
@@ -6,6 +6,7 @@
#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
#include "qcs615.dtsi"
+#include "pm8150.dtsi"
/ {
model = "Qualcomm Technologies, Inc. QCS615 Ride";
compatible = "qcom,qcs615-ride", "qcom,qcs615";
@@ -210,6 +211,20 @@ &rpmhcc {
clocks = <&xo_board_clk>;
};
+&pon {
+ /delete-property/ mode-bootloader;
+ /delete-property/ mode-recovery;
Why?
Because boot modes will be supported on PSCI module from another
patch,
reboot-modes are required to remove from PMIC side.
I don't know why "required to remove" is here. We *could* continue to
program the SDAM from Linux.
Sure, we could continue to program the SDAM from Linux. Regarding PSCI
and PMIC both are dealing with reboot-modes, we need to consider more.
That being said, I don't know that the firmware/bootloader from the
QCS615 Ride has the concept of "reboot to recovery" since it's not an
Android ecosystem. I'd let Tingguo comment on it.
About mode-recovery:
pm8150.dtsi is originally designed for mobile/android devices in which
reboot modes are managed by PMIC driver, that's why I think the modes
are there in pm8150.dtsi.
About QCS615 Ride:
QCS615 Ride use a pmm6155au(that's a variant of pm8150) and it's a Linux
system. But we involved pm8150.dtsi for "the meaning of variant". That's
why the "recovery-mode" is there. Maybe we can treat this as a change
for "the variant" as well(Only for QCS615 ride as Dmitry said).
Do we know whether the PSCI call does the same thing under the hood?
It might be writing to the SDAM. For example, SAR2130P also uses PM8150
and, if I'm not mistaken, SDAM for reboot mode.
Yes, PSCI does the same thing under the hood.
What is going here is that we have introduced the SYSTEM_RESET2 vendor
resets in some firmwares which run on boards that use PM8150. Based on
context here (IOW: I might be a little wrong on the details), I guess
QCS615 Ride is being added to Qualcomm Linux stack, which has newer
firmware that supports using the SYSTEM_RESET2 vendor resets.
IMO, we should move the mode-bootloader/mode-recovery properties out of
pm8150.dtsi and into the applicable board.dts. As Bjorn mentioned, the
interpretation of the cookie values is specific to the board's firmware,
not the the pmic*. Tingguo, can you submit patches to do that?
Of course, Should we split the "moving modes out of pm8150.dtsi" into
another patch series? Because there are some boards need to change and
this patch series is for "Adds SPMI bus, PMIC and peripherals for qcs615".
Regards,
Elliot
*: In general, the cookie values are consistent. Some values are only
applicable on automotive board or mobile board though (or IOT).
update v4:
https://lore.kernel.org/lkml/20241112-adds-spmi-pmic-peripherals-for-qcs615-v4-0-f0e54d8b6516@xxxxxxxxxxx/
--
Thank you & BRs
Tingguo
