Hi All,
This discussion is triggered once again from recent chat with Stephen Boyd and
my need to access qfprom for tsens driver.
On MSM parts there are some efuses (called qfprom) these fuses store things like
calibration data, speed bins.. etc. Drivers like cpufreq, thermal sensors would
read out this data for configuring the driver. As qfprom is a mmio on QCOM parts
and is kinda shared resource, drivers which need data from qfrom can access it
by using syscon or use eeprom/efuse framework. Both of them, will do the job,
but as of today there is no eeprom, framework in the kernel, so accessing qfprom
via syscon seems to be more generic and the only option with current kernel
situation.
But there are some side effects of this approach,
1> code duplication: drivers which needs to access qfprom have to talk to syscon
and get hold of regmap, offset, size and then do regmap reads. This will be
kinda redone in every driver which needs access to qfprom.
2> handling multiple resources: with out some extra dt code in drivers its not
easy to get hold of multple qfprom resources.
3> register stride: syscon by default has a register stride of word size.
So this wrapper + "a syscon fix" addresses the above issues making syscon more
friendly for qfprom.
With this approach DT looks like:
qfprom: qfprom@00700000 {
compatible = "qcom,qfprom", "syscon";
reg = <0x00700000 0x1000>;
stride = <1>;
};
tsens: tsens {
#thermal-sensor-cells = <1>;
compatible = "qcom,apq8064-tsens";
qcom,qfprom = <&qfprom 0x404 0x10>, <&qfprom 0x414 0x10>;
qcom,qfprom-names = "calib", "backup_calib";
};
and the driver side looks like:
cdata = qfprom_get_data(dev, 0, &sz);
cdata_backup = qfprom_get_data(dev, 1, &sz);
Questions:
- Should we wait for more generic eeprom/efuse interfaces? With no time line in place?
- Should we take a simplistic approach and move to using these wrappers till we
get some eeprom/efuse apis in the kernel?
- Are there any better ways to represent qfprom via DT nodes?
Stephen had similar discussions [1] some time back in July 2014, but nothing
really changed since then. With the given situation Am proposing these patches
to get something that works on top of mainline which will unblock upstreaming
tsens and hopefully help other drivers like cpufreq an abstracted way to get
hold of qfprom data.
So here are my WIP patches for your comments/disussions.. :-)
Thanks,
srini
[1] http://comments.gmane.org/gmane.linux.ports.arm.msm/8142
Srinivas Kandagatla (2):
WIP: mfd: syscon: Add register stride to DT bindings.
WIP: Add wrappers for qfprom access via syscon
Documentation/devicetree/bindings/mfd/syscon.txt | 3 +
.../devicetree/bindings/soc/qcom/qfprom.txt | 29 +++++
drivers/mfd/syscon.c | 9 ++
drivers/soc/qcom/Kconfig | 7 ++
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/qfprom.c | 134 +++++++++++++++++++++
6 files changed, 183 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/qcom/qfprom.txt
create mode 100644 drivers/soc/qcom/qfprom.c
--
1.9.1
--
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
