From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lina Iyer Subject: Re: [PATCH v2 03/10] qcom: spm: Add Subsystem Power Manager (SPM) driver for QCOM chipsets Date: Fri, 15 Aug 2014 21:41:43 -0600 Message-ID: <20140816034143.GC46224@ilina-mac.local> References: <1407872640-6732-1-git-send-email-lina.iyer@linaro.org> <1407872640-6732-4-git-send-email-lina.iyer@linaro.org> <61C7FA07-985E-41DC-AD3F-BCFA0920ED0E@codeaurora.org> <20140814161828.GB35102@ilina-mac.local> <77E5D26F-DD0A-411C-A183-528D6359EB69@codeaurora.org> <20140815041805.GB43455@ilina-mac.local> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from mail-ig0-f176.google.com ([209.85.213.176]:33686 "EHLO mail-ig0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751276AbaHPDlr (ORCPT ); Fri, 15 Aug 2014 23:41:47 -0400 Received: by mail-ig0-f176.google.com with SMTP id hn18so3679255igb.3 for ; Fri, 15 Aug 2014 20:41:46 -0700 (PDT) Content-Disposition: inline In-Reply-To: Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org To: Kumar Gala Cc: Daniel Lezcano , Kevin Hilman , Amit Kucheria , Stephen Boyd , David Brown , linux-arm-msm@vger.kernel.org, msivasub@codeaurora.org, Praveen Chidamabram , Murali Nalajala On Fri, Aug 15, 2014 at 08:42:17AM -0500, Kumar Gala wrote: > >On Aug 14, 2014, at 11:18 PM, Lina Iyer wrote: > >> On Thu, Aug 14, 2014 at 11:41:39AM -0500, Kumar Gala wrote: >>> >>> On Aug 14, 2014, at 11:18 AM, Lina Iyer wrot= e: >>> >>>> On Thu, Aug 14, 2014 at 11:09:48AM -0500, Kumar Gala wrote: >>>>> >>>>> On Aug 12, 2014, at 2:43 PM, Lina Iyer wro= te: >>>>> >>>>>> >>>>>> diff --git a/Documentation/devicetree/bindings/arm/msm/spm-v2.tx= t b/Documentation/devicetree/bindings/arm/msm/spm-v2.txt >>>>>> new file mode 100644 >>>>>> index 0000000..3130f4b >>>>>> --- /dev/null >>>>>> +++ b/Documentation/devicetree/bindings/arm/msm/spm-v2.txt >>>>>> @@ -0,0 +1,62 @@ >>>>>> +* MSM Subsystem Power Manager (spm-v2) >>>>>> + >>>>>> +S4 generation of MSMs have SPM hardware blocks to control the A= pplication >>>>>> +Processor Sub-System power. These SPM blocks run individual sta= te machine >>>>>> +to determine what the core (L2 or Krait/Scorpion) would do when= the WFI >>>>>> +instruction is executed by the core. >>>>>> + >>>>>> +The devicetree representation of the SPM block should be: >>>>>> + >>>>>> +Required properties >>>>>> + >>>>>> +- compatible: Could be one of - >>>>>> + "qcom,spm-v2.1" >>>>>> + "qcom,spm-v3.0" >>>>>> +- reg: The physical address and the size of the SPM's memory ma= pped registers >>>>>> +- qcom,cpu: phandle for the CPU that the SPM block is attached = to. On targets >>>>>> + that dont support CPU phandles the driver would support qcom,c= ore-id. >>>>>> + This field is required on only for SPMs that control the CPU. >>>>>> +- qcom,saw2-cfg: SAW2 configuration register >>>>> >>>>> Can we change this to qcom,saw2-clk-div as that is what is really= getting set, I know there are a few other fields in the saw2-cfg regis= ter, but I=E2=80=99m pretty sure we arent ever really setting those fro= m DT. >>>>> >>>> I am pruning them off in the next revision of the patch. >>>>>> +- qcom,saw2-spm-dly: Provides the values for the SPM delay comm= and in the SPM >>>>>> + sequence >>>>>> +- qcom,saw2-spm-ctl: The SPM control register >>>>> >>>>> Can we describe this as =E2=80=9Cspm-enable=E2=80=9D, =E2=80=9Csp= m-inhibit-start-address=E2=80=9D, =E2=80=9Cspm-wakeup-cfg=E2=80=9D? >>>>> >>>>> Also, I=E2=80=99m unclear why would we have a case that spm would= be disabled? >> SPM would mostly be disabled for debug reasons or if there was a ver= sion >> of the hardware tht needed hardware to be disabled. In general, it >> wouldnt be. > >Why would we not do that via the =E2=80=9Cstatus=E2=80=9D field? > We could do that instead too. >>>>> >>>> Much of these registers names make it easier for developers and >>>> debuggers to relate it to the hardware spec. Choosing different na= mes >>>> here though might make it readable would convolute their efforts. >>> >>> The point is to move away from just dumping a register value direct= ly from DT into the device. This is pretty bad form. The names can re= late to the register, etc, its just the fields that are really being us= ed/set was the direction I was suggesting we go. >>> >> Hmm. I see. Let me if I can address that.. There may be some registe= rs >> where I may not have such a luxury, will give it a try. > >Lets see, some registers are possibly ok, so lets try as much as possi= bly and go from there. Ok. > >> >>>> >>>>>> +- qcom,name: The name with which a SPM device is identified by = the power >>>>>> + management code. >>>>>> + >>>>>> +Optional properties >>>>>> + >>>>>> +- qcom,saw2-pmic-data0..7: Specify the pmic data value and the = associated FTS >>>>>> + (Fast Transient Switch) index to send the PMIC data to >>>>>> +- qcom,vctl-port: The PVC (PMIC Virtual Channel) port used for = changing >>>>>> + voltage >>>>>> +- qcom,phase-port: The PVC port used for changing the number of= phases >>>>>> +- qcom,pfm-port: The PVC port used for enabling PWM/PFM modes >>>>>> +- qcom,saw2-spm-cmd-wfi: The WFI command sequence >>>>>> +- qcom,saw2-spm-cmd-ret: The Retention command sequence >>>>>> +- qcom,saw2-spm-cmd-spc: The Standalone PC command sequence >>>>>> +- qcom,saw2-spm-cmd-pc-no-rpm: The Power Collapse command seque= nce where APPS >>>>>> + proc won't inform the RPM. >>>>>> +- qcom,saw2-spm-cmd-pc: The Power Collapse command sequence. Th= is sequence may >>>>>> + turn off other SoC components. >>>>>> +- qcom,saw2-spm-cmd-gdhs: GDHS (Globally Distributed Head Switc= h) command >>>>>> + sequence. This sequence will retain the memory but turn off th= e logic. >>>>>> +- qcom,cpu-vctl-list: List of cpu node phandles, whose voltage = the spm device >>>>>> + can control. >>>>>> +- qcom,vctl-timeout-us: The timeout value in microseconds to wa= it for voltage to >>>>>> + change after sending the voltage command to the PMIC. >>>>>> +- >>>>>> +Example: >>>>>> + qcom,spm@f9089000 { >>>>>> + compatible =3D "qcom,spm-v2"; >>>>>> + #address-cells =3D <1>; >>>>>> + #size-cells =3D <1>; >>>>>> + reg =3D <0xf9089000 0x1000>; >>>>>> + qcom,cpu =3D <&CPU0>; >>>>>> + qcom,saw2-cfg =3D <0x1>; >>>>>> + qcom,saw2-spm-dly=3D <0x20000400>; >>>>>> + qcom,saw2-spm-ctl =3D <0x1>; >>>>>> + qcom,saw2-spm-cmd-wfi =3D [03 0b 0f]; >>>>>> + qcom,saw2-spm-cmd-spc =3D [00 20 50 80 60 70 10 92 >>>>>> + a0 b0 03 68 70 3b 92 a0 b0 >>>>>> + 82 2b 50 10 30 02 22 30 0f]; >>>>>> + }; >>>>> >>>>> -- >>>>> Employee of Qualcomm Innovation Center, Inc. >>>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum= , hosted by The Linux Foundation >>>>> >>> >>> - k >>> >>> -- >>> Employee of Qualcomm Innovation Center, Inc. >>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, = hosted by The Linux Foundation >>> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-arm-= msm" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > >--=20 >Employee of Qualcomm Innovation Center, Inc. >Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hos= ted by The Linux Foundation >