On Aug 14, 2014, at 11:18 PM, Lina Iyer <lina.i...@linaro.org> 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.i...@linaro.org> 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.i...@linaro.org> 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 majord...@vger.kernel.org
> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
