[PATCH v2 0/3] Add the efuse driver on rockchip platform

[PATCH v2 0/3] Add the efuse driver on rockchip platform

[Caesar Wang]

The original driver is uploaded by Jianqun.
Here is his patchs:
    https://patchwork.kernel.org/patch/5410341/
    https://patchwork.kernel.org/patch/5410351/

Jianqun, nevermind!
I check-pick it and re-upload the driver for the upstream.
e.g.:
    Tested by on minnie board.(kernel-4.1-rc8)
    cd /sys/devices/platform/ffb40000.efuse
    localhost ffb40000.efuse # cat cpu_leakage_show
    cpu_version_show
    The results:
            19
            2

Changes in v2:
- Change the document decription.
- Move the efuse driver into driver/soc/vendor.
- update the efuse driver.
- Add the dts node on RK3288.

Caesar Wang (3):
  soc/rockchip: Add efuse bindings for Rockchip SoC efuse driver
  soc/rockchip: efuse: Add Rockchip SoC efuse support
  ARM: dts: Add RK3288 efuse node

 .../bindings/fuse/rockchip,rockchip-efuse.txt      |  14 ++
 arch/arm/boot/dts/rk3288.dtsi                      |   5 +
 drivers/soc/Makefile                               |   1 +
 drivers/soc/rockchip/Makefile                      |   4 +
 drivers/soc/rockchip/efuse.c                       | 212 +++++++++++++++++++++
 5 files changed, 236 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/fuse/rockchip,rockchip-efuse.txt
 create mode 100644 drivers/soc/rockchip/Makefile
 create mode 100644 drivers/soc/rockchip/efuse.c

-- 
1.9.1

[PATCH v2 1/3] soc/rockchip: Add efuse bindings for Rockchip SoC efuse driver

[Caesar Wang]

Add efuse bindings for RK3066, RK3188, RK3288 and RK3368.

Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>

---

Changes in v2:
- Change the document decription.

 .../devicetree/bindings/fuse/rockchip,rockchip-efuse.txt   | 14 ++++++++++++++
 1 file changed, 14 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/fuse/rockchip,rockchip-efuse.txt

diff --git a/Documentation/devicetree/bindings/fuse/rockchip,rockchip-efuse.txt b/Documentation/devicetree/bindings/fuse/rockchip,rockchip-efuse.txt
new file mode 100644
index 0000000..f1f338e
--- /dev/null
+++ b/Documentation/devicetree/bindings/fuse/rockchip,rockchip-efuse.txt
@@ -0,0 +1,14 @@
+ROCKCHIP RK3066/RK3188/RK3288/RK3368 efuse block.
+
+Required properties:
+- compatible : should be: "rockchip,<name>-efuse"
+  "rockchip,rk3066-efuse": found on RK3066,RK3188,RK3288 and RK3368.
+- reg: Should contain 1 entry: the entry gives the physical address and length
+       of the fuse registers.
+
+Example:
+
+	efuse: efuse at ffb40000 {
+		compatible = "rockchip,rk3066-efuse";
+		reg = <0xffb40000 0x10000>;
+	};
-- 
1.9.1

[PATCH v2 2/3] soc/rockchip: efuse: Add Rockchip SoC efuse support

[Caesar Wang]

Add driver for efuse found on Rockchip RK3066,RK3188,RK3288 and
RK3368 SoCs.

eFuse is organized as 32bits by 8 one-time programmable
electrical fuses with random access interface.

Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>

---

Changes in v2:
- Move the efuse driver into driver/soc/vendor.
- update the efuse driver.

 drivers/soc/Makefile          |   1 +
 drivers/soc/rockchip/Makefile |   4 +
 drivers/soc/rockchip/efuse.c  | 212 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 217 insertions(+)
 create mode 100644 drivers/soc/rockchip/Makefile
 create mode 100644 drivers/soc/rockchip/efuse.c

diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 70042b2..91f7f18 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -4,6 +4,7 @@
 
 obj-$(CONFIG_ARCH_MEDIATEK)	+= mediatek/
 obj-$(CONFIG_ARCH_QCOM)		+= qcom/
+obj-$(CONFIG_ARCH_ROCKCHIP)		+= rockchip/
 obj-$(CONFIG_ARCH_TEGRA)	+= tegra/
 obj-$(CONFIG_SOC_TI)		+= ti/
 obj-$(CONFIG_PLAT_VERSATILE)	+= versatile/
diff --git a/drivers/soc/rockchip/Makefile b/drivers/soc/rockchip/Makefile
new file mode 100644
index 0000000..4f5f9bd
--- /dev/null
+++ b/drivers/soc/rockchip/Makefile
@@ -0,0 +1,4 @@
+#
+# Rockchip Soc drivers
+#
+obj-$(CONFIG_ARCH_ROCKCHIP) += efuse.o
diff --git a/drivers/soc/rockchip/efuse.c b/drivers/soc/rockchip/efuse.c
new file mode 100644
index 0000000..1125320
--- /dev/null
+++ b/drivers/soc/rockchip/efuse.c
@@ -0,0 +1,212 @@
+/*
+ * Rockchip eFuse Driver
+ *
+ * Copyright (c) 2015 Rockchip Electronics Co. Ltd.
+ * Author: Jianqun Xu <jay.xu@rock-chips.com>
+ * Author: Caesar Wang <wxt@rock-chips.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * 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/io.h>
+#include <linux/kernel.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+
+#define EFUSE_A_SHIFT			6
+#define EFUSE_A_MASK			0x3ff
+#define EFUSE_PGENB			BIT(3)
+#define EFUSE_LOAD			BIT(2)
+#define EFUSE_STROBE			BIT(1)
+#define EFUSE_CSB			BIT(0)
+
+#define REG_EFUSE_CTRL			0x0000
+#define REG_EFUSE_DOUT			0x0004
+
+#define EFUSE_BUF_SIZE			32
+#define EFUSE_CHIP_VERSION_OFFSET	6
+#define EFUSE_CHIP_VERSION_MASK		0xf
+#define EFUSE_BUF_LKG_CPU		23
+
+struct rockchip_efuse_info {
+	struct device *dev;
+	void __iomem *regs;
+	u32 buf[EFUSE_BUF_SIZE];
+};
+
+static void efuse_writel(struct rockchip_efuse_info *efuse,
+			 unsigned int value,
+			 unsigned int offset)
+{
+	writel_relaxed(value, efuse->regs + offset);
+}
+
+static unsigned int efuse_readl(struct rockchip_efuse_info *efuse,
+				unsigned int offset)
+{
+	return readl_relaxed(efuse->regs + offset);
+}
+
+int rockchip_efuse_get_cpuleakage(struct platform_device *pdev,
+				  unsigned int *value)
+{
+	struct rockchip_efuse_info *efuse;
+
+	efuse = platform_get_drvdata(pdev);
+	if (!efuse)
+		return -EAGAIN;
+
+	*value = efuse->buf[EFUSE_BUF_LKG_CPU];
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(rockchip_efuse_get_cpuleakage);
+
+int rockchip_efuse_get_chip_version(struct platform_device *pdev,
+				    unsigned int *value)
+{
+	struct rockchip_efuse_info *efuse;
+
+	efuse = platform_get_drvdata(pdev);
+	if (!efuse)
+		return -EAGAIN;
+
+	*value = efuse->buf[EFUSE_CHIP_VERSION_OFFSET] &
+			EFUSE_CHIP_VERSION_MASK;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(rockchip_efuse_get_chip_version);
+
+static ssize_t cpu_leakage_show(struct device *dev,
+				struct device_attribute *attr, char *buf)
+{
+	int leakage;
+	int ret;
+	struct platform_device *pdev = to_platform_device(dev);
+
+	ret = rockchip_efuse_get_cpuleakage(pdev, &leakage);
+	if (ret)
+		return ret;
+
+	return sprintf(buf, "%d\n", leakage);
+}
+
+static ssize_t cpu_version_show(struct device *dev,
+				struct device_attribute *attr, char *buf)
+{
+	int version;
+	int ret;
+	struct platform_device *pdev = to_platform_device(dev);
+
+	ret = rockchip_efuse_get_chip_version(pdev, &version);
+	if (ret)
+		return ret;
+
+	return sprintf(buf, "%d\n", version);
+}
+
+static void rockchip_efuse_init(struct rockchip_efuse_info *efuse)
+{
+	unsigned int start;
+
+	efuse_writel(efuse, EFUSE_LOAD | EFUSE_PGENB, REG_EFUSE_CTRL);
+	udelay(1);
+
+	for (start = 0; start <= EFUSE_BUF_SIZE; start++) {
+		efuse_writel(efuse, efuse_readl(efuse, REG_EFUSE_CTRL) &
+			     (~(EFUSE_A_MASK << EFUSE_A_SHIFT)),
+			     REG_EFUSE_CTRL);
+		efuse_writel(efuse, efuse_readl(efuse, REG_EFUSE_CTRL) |
+			     ((start & EFUSE_A_MASK) << EFUSE_A_SHIFT),
+			     REG_EFUSE_CTRL);
+		udelay(1);
+		efuse_writel(efuse, efuse_readl(efuse, REG_EFUSE_CTRL) |
+			     EFUSE_STROBE, REG_EFUSE_CTRL);
+		udelay(1);
+
+		efuse->buf[start] = efuse_readl(efuse, REG_EFUSE_DOUT);
+
+		efuse_writel(efuse, efuse_readl(efuse, REG_EFUSE_CTRL) &
+			     (~EFUSE_STROBE), REG_EFUSE_CTRL);
+		udelay(1);
+	}
+
+	/* Switch to standby mode */
+	efuse_writel(efuse, EFUSE_PGENB | EFUSE_CSB, REG_EFUSE_CTRL);
+}
+
+static DEVICE_ATTR(cpu_leakage_show, 0444, cpu_leakage_show, NULL);
+static DEVICE_ATTR(cpu_version_show, 0444, cpu_version_show, NULL);
+
+static struct attribute *efuse_attributes[] = {
+	&dev_attr_cpu_leakage_show.attr,
+	&dev_attr_cpu_version_show.attr,
+	NULL,
+};
+
+static const struct attribute_group efuse_attr_group = {
+	.attrs = efuse_attributes,
+};
+
+static int rockchip_efuse_probe(struct platform_device *pdev)
+{
+	struct rockchip_efuse_info *efuse;
+	struct resource *mem;
+	int ret;
+
+	efuse = devm_kzalloc(&pdev->dev, sizeof(struct rockchip_efuse_info),
+			     GFP_KERNEL);
+	if (!efuse)
+		return -ENOMEM;
+
+	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	efuse->regs = devm_ioremap_resource(&pdev->dev, mem);
+	if (IS_ERR(efuse->regs))
+		return PTR_ERR(efuse->regs);
+
+	efuse->dev = &pdev->dev;
+
+	rockchip_efuse_init(efuse);
+
+	/*
+	 * We set driver data only after fully initializing efuse
+	 * to make sure rockchip_efuse_get_cpuleakage() and
+	 * rockchip_efuse_get_cpu_version do not return garbage.
+	 */
+	platform_set_drvdata(pdev, efuse);
+
+	ret = sysfs_create_group(&efuse->dev->kobj, &efuse_attr_group);
+	if (ret) {
+		dev_err(efuse->dev,
+			"failed to register sysfs. err: %d\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
+
+static const struct of_device_id rockchip_efuse_match[] = {
+	{ .compatible = "rockchip,rk3066-efuse", },
+	{ /* sentinel */},
+};
+
+static struct platform_driver rockchip_efuse_driver = {
+	.probe = rockchip_efuse_probe,
+	.driver = {
+		.name = "rockchip-efuse",
+		.of_match_table = of_match_ptr(rockchip_efuse_match),
+		.suppress_bind_attrs = true,
+	},
+};
+
+module_platform_driver(rockchip_efuse_driver);
-- 
1.9.1

[PATCH v2 3/3] ARM: dts: Add RK3288 efuse node

[Caesar Wang]

Add the efuse node on RK3288, we can get some information
when enable the efuse driver.
e.g.: the CPU version, leakage.....

Signed-off-by: Caesar Wang <wxt@rock-chips.com>

---

Changes in v2:
- Add the dts node on RK3288.

 arch/arm/boot/dts/rk3288.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 165968d..423355e 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -691,6 +691,11 @@
 		};
 	};
 
+	efuse: efuse at ffb40000 {
+		compatible = "rockchip,rk3066-efuse";
+		reg = <0xffb40000 0x10000>;
+	};
+
 	gic: interrupt-controller at ffc01000 {
 		compatible = "arm,gic-400";
 		interrupt-controller;
-- 
1.9.1

[PATCH v2 0/3] Add the efuse driver on rockchip platform

[Stefan Wahren]

Hi Caesar,

[add Maxime and Srinivas]

Am 16.06.2015 um 09:27 schrieb Caesar Wang:
> The original driver is uploaded by Jianqun.
> Here is his patchs:
>     https://patchwork.kernel.org/patch/5410341/
>     https://patchwork.kernel.org/patch/5410351/
>
> Jianqun, nevermind!
> I check-pick it and re-upload the driver for the upstream.
> e.g.:
>     Tested by on minnie board.(kernel-4.1-rc8)
>     cd /sys/devices/platform/ffb40000.efuse
>     localhost ffb40000.efuse # cat cpu_leakage_show
>     cpu_version_show
>     The results:
>             19
>             2
>
> Changes in v2:
> - Change the document decription.
> - Move the efuse driver into driver/soc/vendor.
> - update the efuse driver.
> - Add the dts node on RK3288.
>
>

i want to mention that there is a upcoming new framework suitable for
efuse drivers:

https://lkml.org/lkml/2015/5/21/643

Unfortunately i don't know the current development state.

Regards
Stefan

[PATCH v2 0/3] Add the efuse driver on rockchip platform

[Srinivas Kandagatla]

Hi Stefan,


On 16/06/15 09:52, Stefan Wahren wrote:
> Hi Caesar,
>
> [add Maxime and Srinivas]
>
> Am 16.06.2015 um 09:27 schrieb Caesar Wang:
>> The original driver is uploaded by Jianqun.
>> Here is his patchs:
>>      https://patchwork.kernel.org/patch/5410341/
>>      https://patchwork.kernel.org/patch/5410351/
>>
>> Jianqun, nevermind!
>> I check-pick it and re-upload the driver for the upstream.
>> e.g.:
>>      Tested by on minnie board.(kernel-4.1-rc8)
>>      cd /sys/devices/platform/ffb40000.efuse
>>      localhost ffb40000.efuse # cat cpu_leakage_show
>>      cpu_version_show
>>      The results:
>>              19
>>              2
>>
>> Changes in v2:
>> - Change the document decription.
>> - Move the efuse driver into driver/soc/vendor.
>> - update the efuse driver.
>> - Add the dts node on RK3288.
>>
>>
>
> i want to mention that there is a upcoming new framework suitable for
> efuse drivers:
>
> https://lkml.org/lkml/2015/5/21/643
>
> Unfortunately i don't know the current development state.
>

Currently this framework is used by atleast 3 drivers(qcom-tsens, 
qcom-cpr, begel-bone-cape manager) which are still floating in the 
mailing list.

I was hoping that these 3 users would getback with tested-by.. which did 
not happen for last 3-4 weeks.

I would appreciate, If you could try framework too, and let me know.

I added two of wrappers on top of v5 at: 
https://git.linaro.org/people/srinivas.kandagatla/linux.git/shortlog/refs/heads/nvmem-dev-v5


I think I should request Mark to take the framework.



--srini
> Regards
> Stefan
>
>

[PATCH v2 0/3] Add the efuse driver on rockchip platform

[Caesar Wang]

Hi Srinivas,

? 2015?06?16? 17:21, Srinivas Kandagatla ??:
> Hi Stefan,
>
>
> On 16/06/15 09:52, Stefan Wahren wrote:
>> Hi Caesar,
>>
>> [add Maxime and Srinivas]
>>
>> Am 16.06.2015 um 09:27 schrieb Caesar Wang:
>>> The original driver is uploaded by Jianqun.
>>> Here is his patchs:
>>>      https://patchwork.kernel.org/patch/5410341/
>>>      https://patchwork.kernel.org/patch/5410351/
>>>
>>> Jianqun, nevermind!
>>> I check-pick it and re-upload the driver for the upstream.
>>> e.g.:
>>>      Tested by on minnie board.(kernel-4.1-rc8)
>>>      cd /sys/devices/platform/ffb40000.efuse
>>>      localhost ffb40000.efuse # cat cpu_leakage_show
>>>      cpu_version_show
>>>      The results:
>>>              19
>>>              2
>>>
>>> Changes in v2:
>>> - Change the document decription.
>>> - Move the efuse driver into driver/soc/vendor.
>>> - update the efuse driver.
>>> - Add the dts node on RK3288.
>>>
>>>
>>
>> i want to mention that there is a upcoming new framework suitable for
>> efuse drivers:
>>
>> https://lkml.org/lkml/2015/5/21/643
>>
>> Unfortunately i don't know the current development state.
>>
>
> Currently this framework is used by atleast 3 drivers(qcom-tsens, 
> qcom-cpr, begel-bone-cape manager) which are still floating in the 
> mailing list.
>
> I was hoping that these 3 users would getback with tested-by.. which 
> did not happen for last 3-4 weeks.
>
> I would appreciate, If you could try framework too, and let me know.

Okay,
I will do that...

Doing.....
203d56b WIP: nvmem: add device tree helper functions
7d822d7 nvmem: sunxi: Move the SID driver to the nvmem framework
f54130d nvmem: qfprom: Add bindings for qfprom
6e078d2 nvmem: qfprom: Add Qualcomm QFPROM support.
750d32b nvmem: Add simple nvmem-mmio consumer helper functions.
6390111 nvmem: Add bindings for simple nvmem framework
1c02217 nvmem: Add nvmem_device based consumer apis.
61ce74f nvmem: Add a simple NVMEM framework for consumers
0f82237 nvmem: Add a simple NVMEM framework for nvmem providers
7547598 regmap: Introduce regmap_get_reg_stride.
f3bc1c0 regmap: Introduce regmap_get_max_register.
f0b3b70 ARM: rockchip: fix the SMP code style
8a28ee6 ARM: rockchip: ensure CPU to enter WFI/WFE state
609deeb ARM: rockchip: fix the CPU soft reset
2a876e4 ARM: rockchip: restore dapswjdp after suspend
e260818 Linux 4.1-rc4
ab992dc watchdog: Fix merge 'conflict'
....

At the moment, I don't know how to use this framework.
I need some time to dig it, I'm happy if you some reference(driver or 
document).

>
> I added two of wrappers on top of v5 at: 
> https://git.linaro.org/people/srinivas.kandagatla/linux.git/shortlog/refs/heads/nvmem-dev-v5
>
>
> I think I should request Mark to take the framework.
>
>
>
> --srini
>> Regards
>> Stefan
>>
>>
>
>
>

-- 
Thanks,
- Caesar

[PATCH v2 0/3] Add the efuse driver on rockchip platform

[Srinivas Kandagatla]

On 16/06/15 11:06, Caesar Wang wrote:
> Hi Srinivas,
>
> ? 2015?06?16? 17:21, Srinivas Kandagatla ??:
>> Hi Stefan,
>>
>>
>> On 16/06/15 09:52, Stefan Wahren wrote:
>>> Hi Caesar,
>>>
>>> [add Maxime and Srinivas]
>>>
>>> Am 16.06.2015 um 09:27 schrieb Caesar Wang:
>>>> The original driver is uploaded by Jianqun.
>>>> Here is his patchs:
>>>>      https://patchwork.kernel.org/patch/5410341/
>>>>      https://patchwork.kernel.org/patch/5410351/
>>>>
>>>> Jianqun, nevermind!
>>>> I check-pick it and re-upload the driver for the upstream.
>>>> e.g.:
>>>>      Tested by on minnie board.(kernel-4.1-rc8)
>>>>      cd /sys/devices/platform/ffb40000.efuse
>>>>      localhost ffb40000.efuse # cat cpu_leakage_show
>>>>      cpu_version_show
>>>>      The results:
>>>>              19
>>>>              2
>>>>
>>>> Changes in v2:
>>>> - Change the document decription.
>>>> - Move the efuse driver into driver/soc/vendor.
>>>> - update the efuse driver.
>>>> - Add the dts node on RK3288.
>>>>
>>>>
>>>
>>> i want to mention that there is a upcoming new framework suitable for
>>> efuse drivers:
>>>
>>> https://lkml.org/lkml/2015/5/21/643
>>>
>>> Unfortunately i don't know the current development state.
>>>
>>
>> Currently this framework is used by atleast 3 drivers(qcom-tsens,
>> qcom-cpr, begel-bone-cape manager) which are still floating in the
>> mailing list.
>>
>> I was hoping that these 3 users would getback with tested-by.. which
>> did not happen for last 3-4 weeks.
>>
>> I would appreciate, If you could try framework too, and let me know.
>
> Okay,
> I will do that...
>
> Doing.....
> 203d56b WIP: nvmem: add device tree helper functions
> 7d822d7 nvmem: sunxi: Move the SID driver to the nvmem framework
> f54130d nvmem: qfprom: Add bindings for qfprom
> 6e078d2 nvmem: qfprom: Add Qualcomm QFPROM support.
> 750d32b nvmem: Add simple nvmem-mmio consumer helper functions.
> 6390111 nvmem: Add bindings for simple nvmem framework
> 1c02217 nvmem: Add nvmem_device based consumer apis.
> 61ce74f nvmem: Add a simple NVMEM framework for consumers
> 0f82237 nvmem: Add a simple NVMEM framework for nvmem providers
> 7547598 regmap: Introduce regmap_get_reg_stride.
> f3bc1c0 regmap: Introduce regmap_get_max_register.
> f0b3b70 ARM: rockchip: fix the SMP code style
> 8a28ee6 ARM: rockchip: ensure CPU to enter WFI/WFE state
> 609deeb ARM: rockchip: fix the CPU soft reset
> 2a876e4 ARM: rockchip: restore dapswjdp after suspend
> e260818 Linux 4.1-rc4
> ab992dc watchdog: Fix merge 'conflict'
> ....
>
> At the moment, I don't know how to use this framework.
> I need some time to dig it, I'm happy if you some reference(driver or
> document).
These are very simple apis which are listed in nvmem-consumer.h 
nvmem-provider.h. I will try to come up with some doc very soon.. thanks 
for your patience.

I just had a look at the efuse driver and all you need is(I did not do 
any compile testing) : Have a look at qfprom.c file, the drivers are 
based on regmap, so you get lot of flexibility to add custom 
reads/caches and lot of other regmap features.

dt:
/* Provider */
	efuse: efuse at ffb40000 {
		compatible = "rockchip,rk3066-efuse";
		reg = <0xffb40000 0x10000>;
		cpu_leakage: cpu_leakage {
			reg = <17 0x4>;
		};
		chip_version: chip_version {
			reg = <0x6 0x1>;
		};
	};

/* Consumer dt: */

	consumer-driver at 0 {
		nvmem-cell = <&cpu_leakage>;
		nvmem-cell-names = "cpu-leakage";

	};

/ * consumer driver */
nvmem_cell_get()/nvmem_cell_put();
nvmem_cell_read()/nvmem_cell_write();
	
/* Provider driver */ : drivers/nvmem/rockchip_efuse.c

#include <linux/module.h>
#include <linux/of.h>
#include "nvmem-mmio.h"

int rockchip_efuse_reg_read(void *context, unsigned int reg, unsigned 
int *val)
{
	/* efuse specific read sequence */
	...
}

static struct regmap_config rockchip_efuse_regmap_config = {
	.reg_bits = 32,
	.val_bits = 8,
	.reg_stride = 1,
	.reg_read = rockchip_efuse_reg_read,
};

static struct nvmem_config econfig = {
	.name = "rockchip-efuse",
	.owner = THIS_MODULE,
};

static struct nvmem_mmio_data rockchip_efuse_data = {
	.nvmem_config = &econfig,
	.regmap_config = &rockchip_efuse_regmap_config,
};

static const struct of_device_id rockchip_efuse_of_match[] = {
	{ .compatible = "rockchip,rk3066-efuse", .data = &rockchip_efuse_data},
	{/* sentinel */},
};
MODULE_DEVICE_TABLE(of, rockchip_efuse_of_match);

static struct platform_driver rockchip_efuse_driver = {
	.probe = nvmem_mmio_probe,
	.remove = nvmem_mmio_remove,
	.driver = {
		.name = "rockchip_efuse",
		.of_match_table = rockchip_efuse_of_match,
	},
};
module_platform_driver(rockchip_efuse_driver);
MODULE_DESCRIPTION("rockchip_efuse driver");
MODULE_LICENSE("GPL v2");
>
>>
>> I added two of wrappers on top of v5 at:
>> https://git.linaro.org/people/srinivas.kandagatla/linux.git/shortlog/refs/heads/nvmem-dev-v5
>>
>>
>>
>> I think I should request Mark to take the framework.
>>
>>
>>
>> --srini
>>> Regards
>>> Stefan
>>>
>>>
>>
>>
>>
>

[PATCH v2 0/3] Add the efuse driver on rockchip platform

[Stefan Wahren]

Hi Srinivas,

Am 16.06.2015 um 12:54 schrieb Srinivas Kandagatla:
>
>
> On 16/06/15 11:06, Caesar Wang wrote:
>> Hi Srinivas,
>>
>> ? 2015?06?16? 17:21, Srinivas Kandagatla ??:
>>> Hi Stefan,
>>>
>>>
>>> On 16/06/15 09:52, Stefan Wahren wrote:
>>>> Hi Caesar,
>>>>
>>>> [add Maxime and Srinivas]
>>>>
>>>> Am 16.06.2015 um 09:27 schrieb Caesar Wang:
>>>>> The original driver is uploaded by Jianqun.
>>>>> Here is his patchs:
>>>>>      https://patchwork.kernel.org/patch/5410341/
>>>>>      https://patchwork.kernel.org/patch/5410351/
>>>>>
>>>>> Jianqun, nevermind!
>>>>> I check-pick it and re-upload the driver for the upstream.
>>>>> e.g.:
>>>>>      Tested by on minnie board.(kernel-4.1-rc8)
>>>>>      cd /sys/devices/platform/ffb40000.efuse
>>>>>      localhost ffb40000.efuse # cat cpu_leakage_show
>>>>>      cpu_version_show
>>>>>      The results:
>>>>>              19
>>>>>              2
>>>>>
>>>>> Changes in v2:
>>>>> - Change the document decription.
>>>>> - Move the efuse driver into driver/soc/vendor.
>>>>> - update the efuse driver.
>>>>> - Add the dts node on RK3288.
>>>>>
>>>>>
>>>>
>>>> i want to mention that there is a upcoming new framework suitable for
>>>> efuse drivers:
>>>>
>>>> https://lkml.org/lkml/2015/5/21/643
>>>>
>>>> Unfortunately i don't know the current development state.
>>>>
>>>
>>> Currently this framework is used by atleast 3 drivers(qcom-tsens,
>>> qcom-cpr, begel-bone-cape manager) which are still floating in the
>>> mailing list.
>>>
>>> I was hoping that these 3 users would getback with tested-by.. which
>>> did not happen for last 3-4 weeks.
>>>
>>> I would appreciate, If you could try framework too, and let me know.
>>

yes i work on OCOTP driver for MXS platform and i will try ...

>
> int rockchip_efuse_reg_read(void *context, unsigned int reg, unsigned
> int *val)
> {
>     /* efuse specific read sequence */
>     ...
> }

I will need a specific read sequence too.

Sorry for these newbie questions:

What data structure does context points to for this reg_read opteration?

Do we need range checking of reg or is it handled by the framework?

Are there any limitation for reg_read regarding sleeping or locking
operations?

In case of a read only driver, is everything handle by devicetree or do
we need an empty write operation?

Best regards
Stefan

[PATCH v2 0/3] Add the efuse driver on rockchip platform

[Srinivas Kandagatla]

On 18/06/15 08:05, Stefan Wahren wrote:
> Hi Srinivas,
>
> Am 16.06.2015 um 12:54 schrieb Srinivas Kandagatla:
>>
>>
>> On 16/06/15 11:06, Caesar Wang wrote:
>>> Hi Srinivas,
>>>
>>> ? 2015?06?16? 17:21, Srinivas Kandagatla ??:
>>>> Hi Stefan,
>>>>
>>>>
>>>> On 16/06/15 09:52, Stefan Wahren wrote:
>>>>> Hi Caesar,
>>>>>
>>>>> [add Maxime and Srinivas]
>>>>>
>>>>> Am 16.06.2015 um 09:27 schrieb Caesar Wang:
>>>>>> The original driver is uploaded by Jianqun.
>>>>>> Here is his patchs:
>>>>>>       https://patchwork.kernel.org/patch/5410341/
>>>>>>       https://patchwork.kernel.org/patch/5410351/
>>>>>>
>>>>>> Jianqun, nevermind!
>>>>>> I check-pick it and re-upload the driver for the upstream.
>>>>>> e.g.:
>>>>>>       Tested by on minnie board.(kernel-4.1-rc8)
>>>>>>       cd /sys/devices/platform/ffb40000.efuse
>>>>>>       localhost ffb40000.efuse # cat cpu_leakage_show
>>>>>>       cpu_version_show
>>>>>>       The results:
>>>>>>               19
>>>>>>               2
>>>>>>
>>>>>> Changes in v2:
>>>>>> - Change the document decription.
>>>>>> - Move the efuse driver into driver/soc/vendor.
>>>>>> - update the efuse driver.
>>>>>> - Add the dts node on RK3288.
>>>>>>
>>>>>>
>>>>>
>>>>> i want to mention that there is a upcoming new framework suitable for
>>>>> efuse drivers:
>>>>>
>>>>> https://lkml.org/lkml/2015/5/21/643
>>>>>
>>>>> Unfortunately i don't know the current development state.
>>>>>
>>>>
>>>> Currently this framework is used by atleast 3 drivers(qcom-tsens,
>>>> qcom-cpr, begel-bone-cape manager) which are still floating in the
>>>> mailing list.
>>>>
>>>> I was hoping that these 3 users would getback with tested-by.. which
>>>> did not happen for last 3-4 weeks.
>>>>
>>>> I would appreciate, If you could try framework too, and let me know.
>>>
>
> yes i work on OCOTP driver for MXS platform and i will try ...
>
>>
>> int rockchip_efuse_reg_read(void *context, unsigned int reg, unsigned
>> int *val)
>> {
>>      /* efuse specific read sequence */
>>      ...
>> }
>
> I will need a specific read sequence too.

You can have a look at 
https://git.linaro.org/people/srinivas.kandagatla/linux.git/blob/b4c3ad253747767511233687436f20144e850d67:/drivers/nvmem/rockchip-efuse.c

I did modify the rockchip driver, which I guess should be very much 
similar to what OCOTP driver would need.


>
> Sorry for these newbie questions:
>
> What data structure does context points to for this reg_read opteration?
>
> Do we need range checking of reg or is it handled by the framework?
>
We already have that in place.

> Are there any limitation for reg_read regarding sleeping or locking
> operations?
There are no limitaions as such from nvmem framework, regmap might have 
limitations w.r.t to sleeping and fast_io, as fast_io would take 
spinlocks, AFAIK the providers would not have fast_io, as they not IO 
devices.
>
> In case of a read only driver, is everything handle by devicetree or do
> we need an empty write operation?
Yes, if you pass read-only flag in the provider, the framework would not 
attempt to even write.

You will find answers to most of your question in the rochip-efuse.c file.


--srini
>
> Best regards
> Stefan
>

[PATCH v2 0/3] Add the efuse driver on rockchip platform

[Caesar Wang]

? 2015?06?18? 16:29, Srinivas Kandagatla ??:
>
>
> On 18/06/15 08:05, Stefan Wahren wrote:
>> Hi Srinivas,
>>
>> Am 16.06.2015 um 12:54 schrieb Srinivas Kandagatla:
>>>
>>>
>>> On 16/06/15 11:06, Caesar Wang wrote:
>>>> Hi Srinivas,
>>>>
>>>> ? 2015?06?16? 17:21, Srinivas Kandagatla ??:
>>>>> Hi Stefan,
>>>>>
>>>>>
>>>>> On 16/06/15 09:52, Stefan Wahren wrote:
>>>>>> Hi Caesar,
>>>>>>
>>>>>> [add Maxime and Srinivas]
>>>>>>
>>>>>> Am 16.06.2015 um 09:27 schrieb Caesar Wang:
>>>>>>> The original driver is uploaded by Jianqun.
>>>>>>> Here is his patchs:
>>>>>>>       https://patchwork.kernel.org/patch/5410341/
>>>>>>>       https://patchwork.kernel.org/patch/5410351/
>>>>>>>
>>>>>>> Jianqun, nevermind!
>>>>>>> I check-pick it and re-upload the driver for the upstream.
>>>>>>> e.g.:
>>>>>>>       Tested by on minnie board.(kernel-4.1-rc8)
>>>>>>>       cd /sys/devices/platform/ffb40000.efuse
>>>>>>>       localhost ffb40000.efuse # cat cpu_leakage_show
>>>>>>>       cpu_version_show
>>>>>>>       The results:
>>>>>>>               19
>>>>>>>               2
>>>>>>>
>>>>>>> Changes in v2:
>>>>>>> - Change the document decription.
>>>>>>> - Move the efuse driver into driver/soc/vendor.
>>>>>>> - update the efuse driver.
>>>>>>> - Add the dts node on RK3288.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> i want to mention that there is a upcoming new framework suitable 
>>>>>> for
>>>>>> efuse drivers:
>>>>>>
>>>>>> https://lkml.org/lkml/2015/5/21/643
>>>>>>
>>>>>> Unfortunately i don't know the current development state.
>>>>>>
>>>>>
>>>>> Currently this framework is used by atleast 3 drivers(qcom-tsens,
>>>>> qcom-cpr, begel-bone-cape manager) which are still floating in the
>>>>> mailing list.
>>>>>
>>>>> I was hoping that these 3 users would getback with tested-by.. which
>>>>> did not happen for last 3-4 weeks.
>>>>>
>>>>> I would appreciate, If you could try framework too, and let me know.
>>>>
>>
>> yes i work on OCOTP driver for MXS platform and i will try ...
>>
>>>
>>> int rockchip_efuse_reg_read(void *context, unsigned int reg, unsigned
>>> int *val)
>>> {
>>>      /* efuse specific read sequence */
>>>      ...
>>> }
>>
>> I will need a specific read sequence too.
>
> You can have a look at 
> https://git.linaro.org/people/srinivas.kandagatla/linux.git/blob/b4c3ad253747767511233687436f20144e850d67:/drivers/nvmem/rockchip-efuse.c
>
> I did modify the rockchip driver, which I guess should be very much 
> similar to what OCOTP driver would need.

That rockchip-efuse.c driver shouldn't be work.

An entire 8-bit word of data can be read in one read operation with 
STROBE being high and a proper address
selected (address signals A5~A7 are ?don?t cares?).

That's great if we can get the content from the .reg_read when the 
consumer driver
callback the nvmem_cell_read().

e.g.:
static struct regmap_config rockchip_efuse_regmap_config = {
     .reg_bits = 32,
     .val_bits = 8,
     .reg_stride = 1,
     .reg_read = rockchip_efuse_reg_read,
};
...
/ * consumer driver */
nvmem_cell_get()/nvmem_cell_put();
nvmem_cell_read()/nvmem_cell_write();
........


>
>
>>
>> Sorry for these newbie questions:
>>
>> What data structure does context points to for this reg_read opteration?
>>
>> Do we need range checking of reg or is it handled by the framework?
>>
> We already have that in place.
>
>> Are there any limitation for reg_read regarding sleeping or locking
>> operations?
> There are no limitaions as such from nvmem framework, regmap might 
> have limitations w.r.t to sleeping and fast_io, as fast_io would take 
> spinlocks, AFAIK the providers would not have fast_io, as they not IO 
> devices.
>>
>> In case of a read only driver, is everything handle by devicetree or do
>> we need an empty write operation?
> Yes, if you pass read-only flag in the provider, the framework would 
> not attempt to even write.
>
> You will find answers to most of your question in the rochip-efuse.c 
> file.
>
>
> --srini
>>
>> Best regards
>> Stefan
>>
>
>
>

-- 
Thanks,
- Caesar

[PATCH v2 0/3] Add the efuse driver on rockchip platform

[Shunqian Zheng]

Dear Srinivas,

On 2015?06?18? 16:29, Srinivas Kandagatla wrote:
>
>
> On 18/06/15 08:05, Stefan Wahren wrote:
>> Hi Srinivas,
>>
>> Am 16.06.2015 um 12:54 schrieb Srinivas Kandagatla:
>>>
>>>
>>> On 16/06/15 11:06, Caesar Wang wrote:
>>>> Hi Srinivas,
>>>>
>>>> ? 2015?06?16? 17:21, Srinivas Kandagatla ??:
>>>>> Hi Stefan,
>>>>>
>>>>>
>>>>> On 16/06/15 09:52, Stefan Wahren wrote:
>>>>>> Hi Caesar,
>>>>>>
>>>>>> [add Maxime and Srinivas]
>>>>>>
>>>>>> Am 16.06.2015 um 09:27 schrieb Caesar Wang:
>>>>>>> The original driver is uploaded by Jianqun.
>>>>>>> Here is his patchs:
>>>>>>> https://patchwork.kernel.org/patch/5410341/
>>>>>>> https://patchwork.kernel.org/patch/5410351/
>>>>>>>
>>>>>>> Jianqun, nevermind!
>>>>>>> I check-pick it and re-upload the driver for the upstream.
>>>>>>> e.g.:
>>>>>>>       Tested by on minnie board.(kernel-4.1-rc8)
>>>>>>>       cd /sys/devices/platform/ffb40000.efuse
>>>>>>>       localhost ffb40000.efuse # cat cpu_leakage_show
>>>>>>>       cpu_version_show
>>>>>>>       The results:
>>>>>>>               19
>>>>>>>               2
>>>>>>>
>>>>>>> Changes in v2:
>>>>>>> - Change the document decription.
>>>>>>> - Move the efuse driver into driver/soc/vendor.
>>>>>>> - update the efuse driver.
>>>>>>> - Add the dts node on RK3288.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> i want to mention that there is a upcoming new framework suitable 
>>>>>> for
>>>>>> efuse drivers:
>>>>>>
>>>>>> https://lkml.org/lkml/2015/5/21/643
>>>>>>
>>>>>> Unfortunately i don't know the current development state.
>>>>>>
>>>>>
>>>>> Currently this framework is used by atleast 3 drivers(qcom-tsens,
>>>>> qcom-cpr, begel-bone-cape manager) which are still floating in the
>>>>> mailing list.
>>>>>
>>>>> I was hoping that these 3 users would getback with tested-by.. which
>>>>> did not happen for last 3-4 weeks.
>>>>>
>>>>> I would appreciate, If you could try framework too, and let me know.
>>>>
>>
>> yes i work on OCOTP driver for MXS platform and i will try ...
>>
>>>
>>> int rockchip_efuse_reg_read(void *context, unsigned int reg, unsigned
>>> int *val)
>>> {
>>>      /* efuse specific read sequence */
>>>      ...
>>> }
>>
>> I will need a specific read sequence too.
>
> You can have a look at 
> https://git.linaro.org/people/srinivas.kandagatla/linux.git/blob/b4c3ad253747767511233687436f20144e850d67:/drivers/nvmem/rockchip-efuse.c
>
> I did modify the rockchip driver, which I guess should be very much 
> similar to what OCOTP driver would need.
I'm testing the rockchip-efuse.c driver based on nvmem framework v8, it 
works on RK3288-soc except:

1. Without the following diff, `hexdump 
/sys/bus/nvmem/devices/rockchip-efuse0/nvmem` is wrong with "INVALID 
ARGUMENT":

+++ b/drivers/nvmem/core.c
@@ -67,7 +67,7 @@ static ssize_t bin_attr_nvmem_read(struct file *filp, 
struct kobject *kobj,
         int rc;

         /* Stop the user from reading */
-       if (pos > nvmem->size)
+       if (pos > nvmem->size - 1)
                 return 0;

         if (pos + count > nvmem->size)

RK3288-efuse has  32 x 8bit regs, in dts "reg = <0xffb40000 0x20>;"
Here is the message dump from nvmem_device:
[    2.158314] nvmem:
[    2.158314]           name (null)
[    2.158314]           stride 1
[    2.158314]           word_size 1
[    2.158314]           ncells 0
[    2.158314]           id 0
[    2.158314]           users 0
[    2.158314]           size 32
[    2.158314]           read_only 0

Do you think there is a leak or I'm messing up ?

2. About the read operation, eFuse data can be read during device 
probe() and cached, OR,
     read from eFuse when needed every time. I prefer the second one but 
then, the clock of eFuse may be
     gated. So before/after reading I have to enable/disable clk like :
           devm_clk_get(dev, "hclk_efuse256");
     The trouble is I can't find a way to get the "dev" hander in :
           static int rockchip_efuse_read(void *context, const void 
*reg, size_t reg_size, void *val, size_t val_size)
     I am appreciated if you can give some advice.
     Or, do you think it's reasonable to add hooks before/after read in 
nvmem/core.c like :
           +       before_read(dev, ...);
                    rc = regmap_raw_read(nvmem->regmap, pos, buf, count);
           +       after_read(dev, ...);

3. In the /sys/bus/nvmem/devices/rockchip-efuse0/, there are files:
          /sys/devices/platform/ffb40000.efuse/rockchip-efuse0 # ls
          nvmem      of_node    power      subsystem  uevent
     Do you have a plan to add the nvmem consumers to /sys/ in nvmem 
framework?
     For example,  in dts defined the "cpu_leakage":
         efuse: efuse at ffb40000 {
                 compatible = "rockchip,rk3x-efuse";
                 reg = <0xffb40000 0x20>;
                 #address-cells = <1>;
                 #size-cells = <1>;
                 clocks = <&cru PCLK_EFUSE256>;
                 clock-names = "pclk_efuse_256";

                 cpu_leakage: cpu_leakage {
                         reg = <0x17 0x1>;
                 };
         };
    Then nvmem exposes the "cpu_leakage" file in /sys which can be 
read/write.

Thank you very much,
Shunqian Zheng
>
>
>>
>> Sorry for these newbie questions:
>>
>> What data structure does context points to for this reg_read opteration?
>>
>> Do we need range checking of reg or is it handled by the framework?
>>
> We already have that in place.
>
>> Are there any limitation for reg_read regarding sleeping or locking
>> operations?
> There are no limitaions as such from nvmem framework, regmap might 
> have limitations w.r.t to sleeping and fast_io, as fast_io would take 
> spinlocks, AFAIK the providers would not have fast_io, as they not IO 
> devices.
>>
>> In case of a read only driver, is everything handle by devicetree or do
>> we need an empty write operation?
> Yes, if you pass read-only flag in the provider, the framework would 
> not attempt to even write.
>
> You will find answers to most of your question in the rochip-efuse.c 
> file.
>
>
> --srini
>>
>> Best regards
>> Stefan
>>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip

[PATCH v2 0/3] Add the efuse driver on rockchip platform

[Srinivas Kandagatla]

Hi Shunqian,

Sorry for delay in reply, I was on Holidays..

Thanks for testing.

On 31/07/15 10:27, Shunqian Zheng wrote:
>
> 1. Without the following diff, `hexdump
> /sys/bus/nvmem/devices/rockchip-efuse0/nvmem` is wrong with "INVALID
> ARGUMENT":
>
> +++ b/drivers/nvmem/core.c
> @@ -67,7 +67,7 @@ static ssize_t bin_attr_nvmem_read(struct file *filp,
> struct kobject *kobj,
>          int rc;
>
>          /* Stop the user from reading */
> -       if (pos > nvmem->size)
> +       if (pos > nvmem->size - 1)
>                  return 0;

Yes, this should have been something like this
-       if (pos > nvmem->size)
+       if (pos >= nvmem->size)
                 return 0;

We can send a fix on top of v9 once its merged.

>
>          if (pos + count > nvmem->size)
>
> RK3288-efuse has  32 x 8bit regs, in dts "reg = <0xffb40000 0x20>;"
> Here is the message dump from nvmem_device:
> [    2.158314] nvmem:
> [    2.158314]           name (null)
> [    2.158314]           stride 1
> [    2.158314]           word_size 1
> [    2.158314]           ncells 0
> [    2.158314]           id 0
> [    2.158314]           users 0
> [    2.158314]           size 32
> [    2.158314]           read_only 0
>
> Do you think there is a leak or I'm messing up ?
>
> 2. About the read operation, eFuse data can be read during device
> probe() and cached, OR,
>      read from eFuse when needed every time. I prefer the second one but
> then, the clock of eFuse may be
>      gated. So before/after reading I have to enable/disable clk like :
>            devm_clk_get(dev, "hclk_efuse256");
>      The trouble is I can't find a way to get the "dev" hander in :
>            static int rockchip_efuse_read(void *context, const void
> *reg, size_t reg_size, void *val, size_t val_size)
>      I am appreciated if you can give some advice.


May be you should use regmap_init_mmio_clk() instead of 
regmap_init_mmio() it will take care of clks.

>      Or, do you think it's reasonable to add hooks before/after read in
> nvmem/core.c like :
>            +       before_read(dev, ...);
>                     rc = regmap_raw_read(nvmem->regmap, pos, buf, count);
>            +       after_read(dev, ...);
>


> 3. In the /sys/bus/nvmem/devices/rockchip-efuse0/, there are files:
>           /sys/devices/platform/ffb40000.efuse/rockchip-efuse0 # ls
>           nvmem      of_node    power      subsystem  uevent
>      Do you have a plan to add the nvmem consumers to /sys/ in nvmem
> framework?
yes, Am waiting for the framework to be merged, I have plans to add this 
feature.

>      For example,  in dts defined the "cpu_leakage":
>          efuse: efuse at ffb40000 {
>                  compatible = "rockchip,rk3x-efuse";
>                  reg = <0xffb40000 0x20>;
>                  #address-cells = <1>;
>                  #size-cells = <1>;
>                  clocks = <&cru PCLK_EFUSE256>;
>                  clock-names = "pclk_efuse_256";
>
>                  cpu_leakage: cpu_leakage {
>                          reg = <0x17 0x1>;
>                  };
>          };
>     Then nvmem exposes the "cpu_leakage" file in /sys which can be
> read/write.

--srini

[PATCH v2 0/3] Add the efuse driver on rockchip platform

[Shunqian Zheng]

On 2015?08?05? 00:11, Srinivas Kandagatla wrote:
> Hi Shunqian,
>
> Sorry for delay in reply, I was on Holidays..
>
> Thanks for testing.
>
> On 31/07/15 10:27, Shunqian Zheng wrote:
>>
>> 1. Without the following diff, `hexdump
>> /sys/bus/nvmem/devices/rockchip-efuse0/nvmem` is wrong with "INVALID
>> ARGUMENT":
>>
>> +++ b/drivers/nvmem/core.c
>> @@ -67,7 +67,7 @@ static ssize_t bin_attr_nvmem_read(struct file *filp,
>> struct kobject *kobj,
>>          int rc;
>>
>>          /* Stop the user from reading */
>> -       if (pos > nvmem->size)
>> +       if (pos > nvmem->size - 1)
>>                  return 0;
>
> Yes, this should have been something like this
> -       if (pos > nvmem->size)
> +       if (pos >= nvmem->size)
>                 return 0;
>
> We can send a fix on top of v9 once its merged.
>
>>
>>          if (pos + count > nvmem->size)
>>
>> RK3288-efuse has  32 x 8bit regs, in dts "reg = <0xffb40000 0x20>;"
>> Here is the message dump from nvmem_device:
>> [    2.158314] nvmem:
>> [    2.158314]           name (null)
>> [    2.158314]           stride 1
>> [    2.158314]           word_size 1
>> [    2.158314]           ncells 0
>> [    2.158314]           id 0
>> [    2.158314]           users 0
>> [    2.158314]           size 32
>> [    2.158314]           read_only 0
>>
>> Do you think there is a leak or I'm messing up ?
>>
>> 2. About the read operation, eFuse data can be read during device
>> probe() and cached, OR,
>>      read from eFuse when needed every time. I prefer the second one but
>> then, the clock of eFuse may be
>>      gated. So before/after reading I have to enable/disable clk like :
>>            devm_clk_get(dev, "hclk_efuse256");
>>      The trouble is I can't find a way to get the "dev" hander in :
>>            static int rockchip_efuse_read(void *context, const void
>> *reg, size_t reg_size, void *val, size_t val_size)
>>      I am appreciated if you can give some advice.
>
>
> May be you should use regmap_init_mmio_clk() instead of 
> regmap_init_mmio() it will take care of clks.
Thank you for you reply.
Although the regmap_init_mmio_clk() and it's series interface deal with 
the clks, but
MMIO uses its own regmap_bus{}, while the eFuse of RK3X need special 
read/write
callback functions.

I still can't find a good way to resolve this. Can you help?

Shunqian
>
>>      Or, do you think it's reasonable to add hooks before/after read in
>> nvmem/core.c like :
>>            +       before_read(dev, ...);
>>                     rc = regmap_raw_read(nvmem->regmap, pos, buf, 
>> count);
>>            +       after_read(dev, ...);
>>
>
>
>> 3. In the /sys/bus/nvmem/devices/rockchip-efuse0/, there are files:
>>           /sys/devices/platform/ffb40000.efuse/rockchip-efuse0 # ls
>>           nvmem      of_node    power      subsystem  uevent
>>      Do you have a plan to add the nvmem consumers to /sys/ in nvmem
>> framework?
> yes, Am waiting for the framework to be merged, I have plans to add 
> this feature.
>
>>      For example,  in dts defined the "cpu_leakage":
>>          efuse: efuse at ffb40000 {
>>                  compatible = "rockchip,rk3x-efuse";
>>                  reg = <0xffb40000 0x20>;
>>                  #address-cells = <1>;
>>                  #size-cells = <1>;
>>                  clocks = <&cru PCLK_EFUSE256>;
>>                  clock-names = "pclk_efuse_256";
>>
>>                  cpu_leakage: cpu_leakage {
>>                          reg = <0x17 0x1>;
>>                  };
>>          };
>>     Then nvmem exposes the "cpu_leakage" file in /sys which can be
>> read/write.
>
> --srini