nvmem: add ocotp support for i.MX23 and i.MX28

This patch series brings read-only support for the On-Chip OTP cells in the i.MX23 and i.MX28 processor.

It has been a long time since V3 of this series [1]. The last version has been rejected because there was no standard interface to the OTP data. So this version bases on V7 of the new NVMEM framework [2] which required a nearly complete rewrite of the driver.

[1] - http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/295228.html
[2] - http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/355652.html

changes in V4:
- rename fsl_ocotp.c to mxs-ocotp.c
- adapt driver to use NVMEM framework V7
- take care of hbus clock
- increase too small timeout
- implement a wait function
- use defines from stmp_device.h
- remove owner init
- more code cleanup

changes in V3:
- drop write support
- take care of i.MX23 which has less registers
- drop unnecessary header file
- move static variables into driver data
- add devicetree probing
- fix missing bank closing in error case
- use kobj from platform device for sysfs
- add SYSFS to Kconfig
- add binding file
- code cleanup

Stefan Wahren (3):
DT: nvmem: add binding for mxs-ocotp
nvmem: add driver for ocotp in i.MX23 and i.MX28
mxs: enable ocotp for i.MX23 and i.MX28

 .../devicetree/bindings/nvmem/mxs-ocotp.txt        |   24 ++
 arch/arm/boot/dts/imx23.dtsi                       |    6 +-
 arch/arm/boot/dts/imx28.dtsi                       |    6 +-
 drivers/nvmem/Kconfig                              |   11 +
 drivers/nvmem/Makefile                             |    1 +
 drivers/nvmem/mxs-ocotp.c                          |  252 ++++++++++++++++++++
 6 files changed, 296 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/nvmem/mxs-ocotp.txt
 create mode 100644 drivers/nvmem/mxs-ocotp.c

1.7.9.5

This patch adds the devicetree bindings for the Freescale MXS On Chip OTP driver.

---
 .../devicetree/bindings/nvmem/mxs-ocotp.txt        |   24 ++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/mxs-ocotp.txt

new file mode 100644
index 0000000..cd2a8cd
@@ -0,0 +1,24 @@
+On-Chip OTP Memory for Freescale i.MX23/i.MX28
+
+Required properties:
+- compatible:
+  - "fsl,imx23-ocotp" for i.MX23
+  - "fsl,imx28-ocotp" for i.MX28
+- #address-cells : Should be 1
+- #size-cells : Should be 1
+- reg : Address and length of OTP controller registers
+- clocks : Should contain a reference to the HBus clock
+
+= Data cells =
+Are child nodes of mxs-ocotp, bindings of which as described in
+bindings/nvmem/nvmem.txt
+
+Example for i.MX28:
+
+	ocotp: ocotp at 8002c000 {
+		compatible = "fsl,imx28-ocotp", "fsl,ocotp";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		reg = <0x8002c000 0x2000>;
+		clocks = <&clks 25>;
+	};

1.7.9.5

This patch brings read-only support for the On-Chip OTP cells in the i.MX23 and i.MX28 processor. The driver implements the new NVMEM provider API.

---
 drivers/nvmem/Kconfig     |   11 ++
 drivers/nvmem/Makefile    |    1 +
 drivers/nvmem/mxs-ocotp.c |  252 +++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 264 insertions(+)
 create mode 100644 drivers/nvmem/mxs-ocotp.c

index 8db2978..f7ff940 100644
@@ -36,4 +36,15 @@ config NVMEM_SUNXI_SID
 	  This driver can also be built as a module. If so, the module
 	  will be called nvmem_sunxi_sid.
 
+config MXS_OCOTP
+	tristate "Freescale MXS On-Chip OTP Memory Support"
+	depends on ARCH_MXS
+	help
+	  If you say Y here, you will get readonly access to the
+	  One Time Programmable memory pages that are stored
+	  on the Freescale i.MX23/i.MX28 processor.
+
+	  This driver can also be built as a module. If so, the module
+	  will be called mxs-ocotp.
+
 endif

index 4328b93..b450f8d 100644
@@ -10,3 +10,4 @@ obj-$(CONFIG_QCOM_QFPROM)	+= nvmem_qfprom.o
 nvmem_qfprom-y			:= qfprom.o
 obj-$(CONFIG_NVMEM_SUNXI_SID)	+= nvmem_sunxi_sid.o
 nvmem_sunxi_sid-y		:= sunxi_sid.o
+obj-$(CONFIG_MXS_OCOTP)		+= mxs-ocotp.o

1.7.9.5

How come this driver isn't doing any manipulation with the VDDIO voltage -- or did I miss that? I seem to remember that the VDDIO had to be lowered to 2.8V before the fuses could be programmed and restored to 3.3V afterward. See for example recent mainline u-boot, drivers/misc/mxs_ocotp.c .

Best regards,
Marek Vasut

Hi Marek,

Am 20.07.2015 um 00:12 schrieb Marek Vasut:

Why should the driver implement VDDIO manipulation when there is only read-only support for the OTP bits? There is no ambition to implement write support. Maybe i should clarify that in the comments.

Btw i'm on your side that because programming the OTP from userspace is to dangerous.

Best regards
Stefan

Hi!

Urm, sorry, I missed that read-only part. I apologize.

:)

Best regards,
Marek Vasut

This patch enables On Chip OTP support for i.MX23 and i.MX28 SoCs, but keeps the old compatible string.

---
 arch/arm/boot/dts/imx23.dtsi |    6 ++++--
 arch/arm/boot/dts/imx28.dtsi |    6 ++++--
 2 files changed, 8 insertions(+), 4 deletions(-)

index bbcfb5a..777e118 100644
@@ -350,9 +350,11 @@
 			};
 
 			ocotp at 8002c000 {
-				compatible = "fsl,ocotp";
+				compatible = "fsl,imx23-ocotp", "fsl,ocotp";
+				#address-cells = <1>;
+				#size-cells = <1>;
 				reg = <0x8002c000 0x2000>;
-				status = "disabled";
+				clocks = <&clks 15>;
 			};
 
 			axi-ahb at 8002e000 {

index 4e073e8..c5b57d4 100644
@@ -936,9 +936,11 @@
 			};
 
 			ocotp: ocotp at 8002c000 {
-				compatible = "fsl,ocotp";
+				compatible = "fsl,imx28-ocotp", "fsl,ocotp";
+				#address-cells = <1>;
+				#size-cells = <1>;
 				reg = <0x8002c000 0x2000>;
-				status = "disabled";
+				clocks = <&clks 25>;
 			};
 
 			axi-ahb at 8002e000 {

1.7.9.5

Are you sure you even want this support in kernel ? Isn't it enough to have this in some manufacturing-time mutated bootloader to program the OTP once and never touch it again ?

Best regards,
Marek Vasut

Hi Marek,

Am 20.07.2015 um 00:07 schrieb Marek Vasut:

definitely. But only read-only support make sense. Please believe me, i didn't wait since last year for the NVMEM framework just for fun.

No, our products uses a previous version of this patch series to set the MAC address of a network interface from OTP data. I also get some feedback from other users that they are happy about this driver.

Regards
Stefan

Hi!

:)

OK, now I understand. This makes perfect sense indeed.

Best regards,
Marek Vasut