On Aug 14, 2014, at 11:18 PM, Lina Iyer <lina.iyer@xxxxxxxxxx> wrote: > On Thu, Aug 14, 2014 at 11:41:39AM -0500, Kumar Gala wrote: >> >> On Aug 14, 2014, at 11:18 AM, Lina Iyer <lina.iyer@xxxxxxxxxx> wrote: >> >>> On Thu, Aug 14, 2014 at 11:09:48AM -0500, Kumar Gala wrote: >>>> >>>> On Aug 12, 2014, at 2:43 PM, Lina Iyer <lina.iyer@xxxxxxxxxx> wrote: >>>> >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/arm/msm/spm-v2.txt 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 Application >>>>> +Processor Sub-System power. These SPM blocks run individual state 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 mapped 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,core-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 register, but I’m pretty sure we arent ever really setting those from DT. >>>> >>> I am pruning them off in the next revision of the patch. >>>>> +- qcom,saw2-spm-dly: Provides the values for the SPM delay command in the SPM >>>>> + sequence >>>>> +- qcom,saw2-spm-ctl: The SPM control register >>>> >>>> Can we describe this as “spm-enable”, “spm-inhibit-start-address”, “spm-wakeup-cfg”? >>>> >>>> Also, I’m 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 version > of the hardware tht needed hardware to be disabled. In general, it > wouldnt be. Why would we not do that via the “status” field? >>>> >>> Much of these registers names make it easier for developers and >>> debuggers to relate it to the hardware spec. Choosing different names >>> here though might make it readable would convolute their efforts. >> >> The point is to move away from just dumping a register value directly from DT into the device. This is pretty bad form. The names can relate to the register, etc, its just the fields that are really being used/set was the direction I was suggesting we go. >> > Hmm. I see. Let me if I can address that.. There may be some registers > 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 possibly and go from there. > >>> >>>>> +- 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 sequence where APPS >>>>> + proc won't inform the RPM. >>>>> +- qcom,saw2-spm-cmd-pc: The Power Collapse command sequence. This sequence may >>>>> + turn off other SoC components. >>>>> +- qcom,saw2-spm-cmd-gdhs: GDHS (Globally Distributed Head Switch) command >>>>> + sequence. This sequence will retain the memory but turn off the 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 wait for voltage to >>>>> + change after sending the voltage command to the PMIC. >>>>> +- >>>>> +Example: >>>>> + qcom,spm@f9089000 { >>>>> + compatible = "qcom,spm-v2"; >>>>> + #address-cells = <1>; >>>>> + #size-cells = <1>; >>>>> + reg = <0xf9089000 0x1000>; >>>>> + qcom,cpu = <&CPU0>; >>>>> + qcom,saw2-cfg = <0x1>; >>>>> + qcom,saw2-spm-dly= <0x20000400>; >>>>> + qcom,saw2-spm-ctl = <0x1>; >>>>> + qcom,saw2-spm-cmd-wfi = [03 0b 0f]; >>>>> + qcom,saw2-spm-cmd-spc = [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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html