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.
Thanks,
Lina.
--
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
