Re: [PATCH v3 2/2] arm64: dts: qcom: qcs615-ride: Enable PMIC peripherals

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

> > 
> > 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?

Regards,
Elliot

*: In general, the cookie values are consistent. Some values are only
applicable on automotive board or mobile board though (or IOT).





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux