[PATCH V4 RFC 0/3] nvmem: add ocotp support for i.MX23 and i.MX28

[PATCH V4 RFC 0/3] nvmem: add ocotp support for i.MX23 and i.MX28

[Stefan Wahren]

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

[PATCH V4 RFC 1/3] DT: nvmem: add binding for mxs-ocotp

[Stefan Wahren]

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

Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
 .../devicetree/bindings/nvmem/mxs-ocotp.txt        |   24 ++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/mxs-ocotp.txt

diff --git a/Documentation/devicetree/bindings/nvmem/mxs-ocotp.txt b/Documentation/devicetree/bindings/nvmem/mxs-ocotp.txt
new file mode 100644
index 0000000..cd2a8cd
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/mxs-ocotp.txt
@@ -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

[PATCH V4 RFC 2/3] nvmem: add driver for ocotp in i.MX23 and i.MX28

[Stefan Wahren]

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.

Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
 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

diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 8db2978..f7ff940 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -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
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 4328b93..b450f8d 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -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
diff --git a/drivers/nvmem/mxs-ocotp.c b/drivers/nvmem/mxs-ocotp.c
new file mode 100644
index 0000000..9ee146b
--- /dev/null
+++ b/drivers/nvmem/mxs-ocotp.c
@@ -0,0 +1,252 @@
+/*
+ * Freescale MXS On-Chip OTP driver
+ *
+ * Copyright (C) 2015 Stefan Wahren <stefan.wahren@i2se.com>
+ *
+ * Based on the driver from Huang Shijie and Christoph G. Baumann
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/nvmem-provider.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+#include <linux/stmp_device.h>
+
+/* OCOTP registers and bits */
+
+#define BM_OCOTP_CTRL_RD_BANK_OPEN	BIT(12)
+#define BM_OCOTP_CTRL_ERROR		BIT(9)
+#define BM_OCOTP_CTRL_BUSY		BIT(8)
+
+#define OCOTP_TIMEOUT		10000
+#define OCOTP_DATA_OFFSET	0x20
+
+struct mxs_ocotp {
+	struct clk *clk;
+	void __iomem *base;
+	struct nvmem_device *nvmem;
+};
+
+static int mxs_ocotp_wait(struct mxs_ocotp *otp)
+{
+	int timeout = OCOTP_TIMEOUT;
+	unsigned int status = 0;
+
+	while (timeout--) {
+		status = readl(otp->base);
+
+		if (!(status & (BM_OCOTP_CTRL_BUSY | BM_OCOTP_CTRL_ERROR)))
+			break;
+
+		cpu_relax();
+	}
+
+	if (status & BM_OCOTP_CTRL_BUSY)
+		return -EBUSY;
+	else if (status & BM_OCOTP_CTRL_ERROR)
+		return -EIO;
+
+	return 0;
+}
+
+static int mxs_ocotp_read(void *context, const void *reg, size_t reg_size,
+			  void *val, size_t val_size)
+{
+	struct mxs_ocotp *otp = context;
+	unsigned int offset = *(u32 *)reg;
+	u32 *buf = val;
+	int ret = 0;
+
+	writel(BM_OCOTP_CTRL_ERROR, otp->base + STMP_OFFSET_REG_CLR);
+
+	ret = mxs_ocotp_wait(otp);
+	if (ret)
+		return ret;
+
+	/* open OCOTP banks for read */
+	writel(BM_OCOTP_CTRL_RD_BANK_OPEN, otp->base + STMP_OFFSET_REG_SET);
+
+	/* approximately wait 33 hclk cycles */
+	udelay(1);
+
+	ret = mxs_ocotp_wait(otp);
+	if (ret)
+		goto close_banks;
+
+	while (val_size) {
+		if ((offset < OCOTP_DATA_OFFSET) || (offset % 16)) {
+			/* fill up non-data register */
+			*buf = 0;
+		} else {
+			*buf = readl(otp->base + offset);
+		}
+
+		buf++;
+		val_size--;
+		offset += reg_size;
+	}
+
+close_banks:
+	/* close banks for power saving */
+	writel(BM_OCOTP_CTRL_RD_BANK_OPEN, otp->base + STMP_OFFSET_REG_CLR);
+
+	return ret;
+}
+
+static int mxs_ocotp_write(void *context, const void *data, size_t count)
+{
+	/* We don't want to support writing */
+	return 0;
+}
+
+static bool mxs_ocotp_writeable_reg(struct device *dev, unsigned int reg)
+{
+	return false;
+}
+
+static struct nvmem_config ocotp_config = {
+	.name = "mxs-ocotp",
+	.owner = THIS_MODULE,
+};
+
+static const struct regmap_range imx23_ranges[] = {
+	regmap_reg_range(OCOTP_DATA_OFFSET, 0x210),
+};
+
+static const struct regmap_access_table imx23_access = {
+	.yes_ranges = imx23_ranges,
+	.n_yes_ranges = ARRAY_SIZE(imx23_ranges),
+};
+
+static const struct regmap_range imx28_ranges[] = {
+	regmap_reg_range(OCOTP_DATA_OFFSET, 0x290),
+};
+
+static const struct regmap_access_table imx28_access = {
+	.yes_ranges = imx28_ranges,
+	.n_yes_ranges = ARRAY_SIZE(imx28_ranges),
+};
+
+static struct regmap_bus mxs_ocotp_bus = {
+	.read = mxs_ocotp_read,
+	.write = mxs_ocotp_write, /* make regmap_init() happy */
+	.reg_format_endian_default = REGMAP_ENDIAN_NATIVE,
+	.val_format_endian_default = REGMAP_ENDIAN_NATIVE,
+};
+
+static struct regmap_config mxs_ocotp_config = {
+	.reg_bits = 32,
+	.val_bits = 32,
+	.reg_stride = 16,
+	.writeable_reg = mxs_ocotp_writeable_reg,
+};
+
+static const struct of_device_id mxs_ocotp_match[] = {
+	{ .compatible = "fsl,imx23-ocotp", .data = &imx23_access },
+	{ .compatible = "fsl,imx28-ocotp", .data = &imx28_access },
+	{ /* sentinel */},
+};
+MODULE_DEVICE_TABLE(of, mxs_ocotp_match);
+
+static int mxs_ocotp_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct mxs_ocotp *otp;
+	struct resource *res;
+	const struct of_device_id *match;
+	struct regmap *regmap;
+	const struct regmap_access_table *access;
+	int ret;
+
+	match = of_match_device(dev->driver->of_match_table, dev);
+	if (!match || !match->data)
+		return -EINVAL;
+
+	otp = devm_kzalloc(dev, sizeof(*otp), GFP_KERNEL);
+	if (!otp)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	otp->base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(otp->base))
+		return PTR_ERR(otp->base);
+
+	otp->clk = devm_clk_get(&pdev->dev, NULL);
+	if (IS_ERR(otp->clk))
+		return PTR_ERR(otp->clk);
+
+	ret = clk_prepare(otp->clk);
+	if (ret < 0) {
+		dev_err(dev, "failed to prepare clk: %d\n", ret);
+		return ret;
+	}
+
+	access = match->data;
+	mxs_ocotp_config.rd_table = access;
+	mxs_ocotp_config.max_register = access->yes_ranges[0].range_max;
+
+	regmap = devm_regmap_init(dev, &mxs_ocotp_bus, otp, &mxs_ocotp_config);
+	if (IS_ERR(regmap)) {
+		dev_err(dev, "regmap init failed\n");
+		ret = PTR_ERR(regmap);
+		goto err_clk;
+	}
+
+	ocotp_config.dev = dev;
+	otp->nvmem = nvmem_register(&ocotp_config);
+	if (IS_ERR(otp->nvmem)) {
+		ret = PTR_ERR(otp->nvmem);
+		goto err_clk;
+	}
+
+	platform_set_drvdata(pdev, otp);
+
+	return 0;
+
+err_clk:
+	clk_unprepare(otp->clk);
+
+	return ret;
+}
+
+static int mxs_ocotp_remove(struct platform_device *pdev)
+{
+	struct mxs_ocotp *otp = platform_get_drvdata(pdev);
+
+	clk_unprepare(otp->clk);
+
+	return nvmem_unregister(otp->nvmem);
+}
+
+static struct platform_driver mxs_ocotp_driver = {
+	.probe = mxs_ocotp_probe,
+	.remove = mxs_ocotp_remove,
+	.driver = {
+		.name = "mxs-ocotp",
+		.of_match_table = mxs_ocotp_match,
+	},
+};
+
+module_platform_driver(mxs_ocotp_driver);
+MODULE_AUTHOR("Stefan Wahren <stefan.wahren@i2se.com>");
+MODULE_DESCRIPTION("driver for OCOTP in i.MX23/i.MX28");
+MODULE_LICENSE("GPL");
-- 
1.7.9.5

[PATCH V4 RFC 2/3] nvmem: add driver for ocotp in i.MX23 and i.MX28

[Marek Vasut]

On Monday, July 20, 2015 at 12:04:58 AM, Stefan Wahren wrote:
> 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.
> 
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>

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

[PATCH V4 RFC 2/3] nvmem: add driver for ocotp in i.MX23 and i.MX28

[Stefan Wahren]

Hi Marek,

Am 20.07.2015 um 00:12 schrieb Marek Vasut:
> On Monday, July 20, 2015 at 12:04:58 AM, Stefan Wahren wrote:
>> 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.
>>
>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> 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 .

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

>
> Best regards,
> Marek Vasut
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH V4 RFC 2/3] nvmem: add driver for ocotp in i.MX23 and i.MX28

[Marek Vasut]

On Monday, July 20, 2015 at 08:45:21 AM, Stefan Wahren wrote:
> Hi Marek,

Hi!

> Am 20.07.2015 um 00:12 schrieb Marek Vasut:
> > On Monday, July 20, 2015 at 12:04:58 AM, Stefan Wahren wrote:
> >> 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.
> >> 
> >> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> > 
> > 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 .
> 
> 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.

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

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

:)

Best regards,
Marek Vasut

[PATCH V4 RFC 3/3] mxs: enable ocotp for i.MX23 and i.MX28

[Stefan Wahren]

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

Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
 arch/arm/boot/dts/imx23.dtsi |    6 ++++--
 arch/arm/boot/dts/imx28.dtsi |    6 ++++--
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
index bbcfb5a..777e118 100644
--- a/arch/arm/boot/dts/imx23.dtsi
+++ b/arch/arm/boot/dts/imx23.dtsi
@@ -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 {
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 4e073e8..c5b57d4 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -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

[PATCH V4 RFC 0/3] nvmem: add ocotp support for i.MX23 and i.MX28

[Marek Vasut]

On Monday, July 20, 2015 at 12:04:56 AM, Stefan Wahren wrote:
> 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.htm
> l

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

[PATCH V4 RFC 0/3] nvmem: add ocotp support for i.MX23 and i.MX28

[Stefan Wahren]

Hi Marek,

Am 20.07.2015 um 00:07 schrieb Marek Vasut:
> On Monday, July 20, 2015 at 12:04:56 AM, Stefan Wahren wrote:
>> 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.htm
>> l
> Are you sure you even want this support in kernel ?

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.

> Isn't it enough to have
> this in some manufacturing-time mutated bootloader to program the OTP once
> and never touch it again ?

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

>
> Best regards,
> Marek Vasut

[PATCH V4 RFC 0/3] nvmem: add ocotp support for i.MX23 and i.MX28

[Marek Vasut]

On Monday, July 20, 2015 at 08:37:01 AM, Stefan Wahren wrote:
> Hi Marek,

Hi!

> Am 20.07.2015 um 00:07 schrieb Marek Vasut:
> > On Monday, July 20, 2015 at 12:04:56 AM, Stefan Wahren wrote:
> >> 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/29522
> >> 8. html [2] -
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/355652.h
> >> tm l
> > 
> > Are you sure you even want this support in kernel ?
> 
> 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.

:)

> > Isn't it enough to have
> > this in some manufacturing-time mutated bootloader to program the OTP
> > once and never touch it again ?
> 
> 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.

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

Best regards,
Marek Vasut