On Fri, Sep 26 2014 at 08:53 -0600, Kumar Gala wrote:
On Sep 26, 2014, at 9:45 AM, Lina Iyer <lina.iyer@xxxxxxxxxx> wrote:
On Wed, Sep 24 2014 at 13:30 -0600, Lina Iyer wrote:
On Wed, Sep 24 2014 at 11:53 -0600, Kumar Gala wrote:
On Sep 24, 2014, at 12:21 PM, Lina Iyer <lina.iyer@xxxxxxxxxx> wrote:
On Wed, Sep 24 2014 at 10:33 -0600, Kumar Gala wrote:
On Sep 23, 2014, at 6:51 PM, Lina Iyer <lina.iyer@xxxxxxxxxx> wrote:
+- qcom,saw2-delays: The SPM delay values that SPM sequences would refer to.
+ The register for this property is MSM_SPM_REG_SAW2_SPM_DLY.
Didn’t Stephen asked about splitting this up? Or at least treating it as an array of 3 values?
Yes he did. My response was similar to the clk-div values, its not
something you can change without hardware spec documentation.
And I need to mix the three values up, anyways before I write to the
register. Splitting it up, doesnt help understanding/configuring the SPM
any better, so didnt change it.
Hmm, will this value change from SPM to SPM on the same SoC? I’m not a fan of allowing random register values to get poked into the HW from DT. While this one case might end up being acceptable, its a terrible practice and not something I want use in the habit of doing.
Ah. Tough proposition! The SPM sequence is a bunch of random register
values, which is not open to interpretation without the programming
guides. I am not sure how I can use DT for saving all the register data
then.
I agree its nice to have nice readable parameters in the DT, but, isnt
the purpose of the DT, the hardware configuration? In an alternate way
to do this, I could put all these register writes into the driver itself
for each SoC. Ugly as it may be, it would solve the problem. However,
the device node then just has the compatible string in it and may be
some configurable elements. I fail to see the big picture of the use of
DT in such a case.
FWIW, I do understand your stance with DT, and for the most part agree
with it.
Based on our offline discussion, I will make the changes to move these
proprietary register values into the driver. I will submit a patch with
the changes soon.
Curious, do the command sequences vary SPM to SPM on the same SoC? I’m guessing the L2 SPM sequence is probably different from the CPU SPM.
Not really. CPUs are the mostly the same in an SoC but yes, they may
differ from the L2.
Also, stephen pointed out that the SPMs should probably be part of the SAW nodes and binding.
Well, the SAW nodes are essentially regulator bindings. They have no
bearing on idle part of the SAW functionality.
SPM driver will provide an API to change voltage. SPM used to need to
know the voltage and will need to for 8064, but 8074 onwards, SPM can be
skipped in setting the voltage. It might be a tad bit faster to use SPM
to communicate to the PMIC, though.
For 8064, the voltage is turned off when powering down the core and
would need to be restored back to the original value when powering back
on. The value is captured in the PMIC_DATA registers and used by the
SPM sequence.
The SAW regulator information is not related to the SPM functionality
that I am implementing here.
It seems unnecessary to have two varied functionality be bound together
just because we need to shadow the register value. We could find better
ways to do that.
thanks
--
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
