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