* [PATCH v2 0/3] Add the efuse driver on rockchip platform
@ 2015-06-16 7:27 ` Caesar Wang
0 siblings, 0 replies; 32+ messages in thread
From: Caesar Wang @ 2015-06-16 7:27 UTC (permalink / raw)
To: heiko
Cc: devicetree, jay.xu, linus.walleij, galak, linux-kernel,
ijc+devicetree, linux-rockchip, robh+dt, matthias.bgg,
pawel.moll, mark.rutland, linux, linux-arm-kernel, wxt
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v2 0/3] Add the efuse driver on rockchip platform
@ 2015-06-16 7:27 ` Caesar Wang
0 siblings, 0 replies; 32+ messages in thread
From: Caesar Wang @ 2015-06-16 7:27 UTC (permalink / raw)
To: heiko-4mtYJXux2i+zQB+pC5nmwQ
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, jay.xu-TNX95d0MmH7DzftRWevZcw,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
galak-sgV2jX0FEOL9JmXXK+q4OQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w, pawel.moll-5wv7dgnIgG8,
mark.rutland-5wv7dgnIgG8, linux-lFZ/pmaqli7XmaaqVzeoHQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
wxt-TNX95d0MmH7DzftRWevZcw
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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v2 0/3] Add the efuse driver on rockchip platform
@ 2015-06-16 7:27 ` Caesar Wang
0 siblings, 0 replies; 32+ messages in thread
From: Caesar Wang @ 2015-06-16 7:27 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v2 1/3] soc/rockchip: Add efuse bindings for Rockchip SoC efuse driver
2015-06-16 7:27 ` Caesar Wang
@ 2015-06-16 7:27 ` Caesar Wang
-1 siblings, 0 replies; 32+ messages in thread
From: Caesar Wang @ 2015-06-16 7:27 UTC (permalink / raw)
To: heiko
Cc: devicetree, jay.xu, linus.walleij, galak, linux-kernel,
ijc+devicetree, linux-rockchip, robh+dt, matthias.bgg,
pawel.moll, mark.rutland, linux, linux-arm-kernel, wxt
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@ffb40000 {
+ compatible = "rockchip,rk3066-efuse";
+ reg = <0xffb40000 0x10000>;
+ };
--
1.9.1
^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH v2 1/3] soc/rockchip: Add efuse bindings for Rockchip SoC efuse driver
@ 2015-06-16 7:27 ` Caesar Wang
0 siblings, 0 replies; 32+ messages in thread
From: Caesar Wang @ 2015-06-16 7:27 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH v2 2/3] soc/rockchip: efuse: Add Rockchip SoC efuse support
2015-06-16 7:27 ` Caesar Wang
@ 2015-06-16 7:27 ` Caesar Wang
-1 siblings, 0 replies; 32+ messages in thread
From: Caesar Wang @ 2015-06-16 7:27 UTC (permalink / raw)
To: heiko
Cc: devicetree, jay.xu, linus.walleij, galak, linux-kernel,
ijc+devicetree, linux-rockchip, robh+dt, matthias.bgg,
pawel.moll, mark.rutland, linux, linux-arm-kernel, wxt
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
^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH v2 2/3] soc/rockchip: efuse: Add Rockchip SoC efuse support
@ 2015-06-16 7:27 ` Caesar Wang
0 siblings, 0 replies; 32+ messages in thread
From: Caesar Wang @ 2015-06-16 7:27 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH v2 3/3] ARM: dts: Add RK3288 efuse node
2015-06-16 7:27 ` Caesar Wang
@ 2015-06-16 7:27 ` Caesar Wang
-1 siblings, 0 replies; 32+ messages in thread
From: Caesar Wang @ 2015-06-16 7:27 UTC (permalink / raw)
To: heiko
Cc: devicetree, jay.xu, linus.walleij, galak, linux-kernel,
ijc+devicetree, linux-rockchip, robh+dt, matthias.bgg,
pawel.moll, mark.rutland, linux, linux-arm-kernel, wxt
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@ffb40000 {
+ compatible = "rockchip,rk3066-efuse";
+ reg = <0xffb40000 0x10000>;
+ };
+
gic: interrupt-controller@ffc01000 {
compatible = "arm,gic-400";
interrupt-controller;
--
1.9.1
^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH v2 3/3] ARM: dts: Add RK3288 efuse node
@ 2015-06-16 7:27 ` Caesar Wang
0 siblings, 0 replies; 32+ messages in thread
From: Caesar Wang @ 2015-06-16 7:27 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 32+ messages in thread
* Re: [PATCH v2 0/3] Add the efuse driver on rockchip platform
2015-06-16 7:27 ` Caesar Wang
@ 2015-06-16 8:52 ` Stefan Wahren
-1 siblings, 0 replies; 32+ messages in thread
From: Stefan Wahren @ 2015-06-16 8:52 UTC (permalink / raw)
To: Caesar Wang
Cc: heiko, mark.rutland, devicetree, linux, pawel.moll,
ijc+devicetree, linus.walleij, linux-kernel, linux-rockchip,
robh+dt, galak, matthias.bgg, jay.xu, linux-arm-kernel,
Maxime Ripard, Srinivas Kandagatla
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v2 0/3] Add the efuse driver on rockchip platform
@ 2015-06-16 8:52 ` Stefan Wahren
0 siblings, 0 replies; 32+ messages in thread
From: Stefan Wahren @ 2015-06-16 8:52 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v2 0/3] Add the efuse driver on rockchip platform
2015-06-16 8:52 ` Stefan Wahren
@ 2015-06-16 9:21 ` Srinivas Kandagatla
-1 siblings, 0 replies; 32+ messages in thread
From: Srinivas Kandagatla @ 2015-06-16 9:21 UTC (permalink / raw)
To: Stefan Wahren, Caesar Wang
Cc: heiko, mark.rutland, devicetree, linux, pawel.moll,
ijc+devicetree, linus.walleij, linux-kernel, linux-rockchip,
robh+dt, galak, matthias.bgg, jay.xu, linux-arm-kernel,
Maxime Ripard
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
>
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v2 0/3] Add the efuse driver on rockchip platform
@ 2015-06-16 9:21 ` Srinivas Kandagatla
0 siblings, 0 replies; 32+ messages in thread
From: Srinivas Kandagatla @ 2015-06-16 9:21 UTC (permalink / raw)
To: linux-arm-kernel
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
>
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v2 0/3] Add the efuse driver on rockchip platform
2015-06-16 9:21 ` Srinivas Kandagatla
@ 2015-06-16 10:06 ` Caesar Wang
-1 siblings, 0 replies; 32+ messages in thread
From: Caesar Wang @ 2015-06-16 10:06 UTC (permalink / raw)
To: Srinivas Kandagatla, Stefan Wahren
Cc: heiko, mark.rutland, devicetree, linux, pawel.moll,
ijc+devicetree, linus.walleij, linux-kernel, linux-rockchip,
robh+dt, galak, matthias.bgg, jay.xu, linux-arm-kernel,
Maxime Ripard
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v2 0/3] Add the efuse driver on rockchip platform
@ 2015-06-16 10:06 ` Caesar Wang
0 siblings, 0 replies; 32+ messages in thread
From: Caesar Wang @ 2015-06-16 10:06 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v2 0/3] Add the efuse driver on rockchip platform
@ 2015-06-16 10:54 ` Srinivas Kandagatla
0 siblings, 0 replies; 32+ messages in thread
From: Srinivas Kandagatla @ 2015-06-16 10:54 UTC (permalink / raw)
To: Caesar Wang, Stefan Wahren
Cc: heiko, mark.rutland, devicetree, linux, pawel.moll,
ijc+devicetree, linus.walleij, linux-kernel, linux-rockchip,
robh+dt, galak, matthias.bgg, jay.xu, linux-arm-kernel,
Maxime Ripard
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@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@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
>>>
>>>
>>
>>
>>
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v2 0/3] Add the efuse driver on rockchip platform
@ 2015-06-16 10:54 ` Srinivas Kandagatla
0 siblings, 0 replies; 32+ messages in thread
From: Srinivas Kandagatla @ 2015-06-16 10:54 UTC (permalink / raw)
To: Caesar Wang, Stefan Wahren
Cc: heiko-4mtYJXux2i+zQB+pC5nmwQ, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA, linux-lFZ/pmaqli7XmaaqVzeoHQ,
pawel.moll-5wv7dgnIgG8, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, galak-sgV2jX0FEOL9JmXXK+q4OQ,
matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w,
jay.xu-TNX95d0MmH7DzftRWevZcw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Maxime Ripard
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@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@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
>>>
>>>
>>
>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v2 0/3] Add the efuse driver on rockchip platform
@ 2015-06-16 10:54 ` Srinivas Kandagatla
0 siblings, 0 replies; 32+ messages in thread
From: Srinivas Kandagatla @ 2015-06-16 10:54 UTC (permalink / raw)
To: linux-arm-kernel
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
>>>
>>>
>>
>>
>>
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v2 0/3] Add the efuse driver on rockchip platform
@ 2015-06-18 7:05 ` Stefan Wahren
0 siblings, 0 replies; 32+ messages in thread
From: Stefan Wahren @ 2015-06-18 7:05 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: Caesar Wang, heiko, mark.rutland, devicetree, linux, pawel.moll,
ijc+devicetree, linus.walleij, linux-kernel, linux-rockchip,
robh+dt, galak, matthias.bgg, jay.xu, linux-arm-kernel,
Maxime Ripard
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v2 0/3] Add the efuse driver on rockchip platform
@ 2015-06-18 7:05 ` Stefan Wahren
0 siblings, 0 replies; 32+ messages in thread
From: Stefan Wahren @ 2015-06-18 7:05 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: Caesar Wang, heiko-4mtYJXux2i+zQB+pC5nmwQ,
mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-lFZ/pmaqli7XmaaqVzeoHQ, pawel.moll-5wv7dgnIgG8,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, galak-sgV2jX0FEOL9JmXXK+q4OQ,
matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w,
jay.xu-TNX95d0MmH7DzftRWevZcw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Maxime Ripard
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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v2 0/3] Add the efuse driver on rockchip platform
@ 2015-06-18 7:05 ` Stefan Wahren
0 siblings, 0 replies; 32+ messages in thread
From: Stefan Wahren @ 2015-06-18 7:05 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v2 0/3] Add the efuse driver on rockchip platform
2015-06-18 7:05 ` Stefan Wahren
@ 2015-06-18 8:29 ` Srinivas Kandagatla
-1 siblings, 0 replies; 32+ messages in thread
From: Srinivas Kandagatla @ 2015-06-18 8:29 UTC (permalink / raw)
To: Stefan Wahren
Cc: Caesar Wang, heiko, mark.rutland, devicetree, linux, pawel.moll,
ijc+devicetree, linus.walleij, linux-kernel, linux-rockchip,
robh+dt, galak, matthias.bgg, jay.xu, linux-arm-kernel,
Maxime Ripard
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
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v2 0/3] Add the efuse driver on rockchip platform
@ 2015-06-18 8:29 ` Srinivas Kandagatla
0 siblings, 0 replies; 32+ messages in thread
From: Srinivas Kandagatla @ 2015-06-18 8:29 UTC (permalink / raw)
To: linux-arm-kernel
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
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v2 0/3] Add the efuse driver on rockchip platform
@ 2015-06-18 9:08 ` Caesar Wang
0 siblings, 0 replies; 32+ messages in thread
From: Caesar Wang @ 2015-06-18 9:08 UTC (permalink / raw)
To: Srinivas Kandagatla, Stefan Wahren
Cc: heiko, mark.rutland, devicetree, linux, pawel.moll,
ijc+devicetree, linus.walleij, linux-kernel, linux-rockchip,
robh+dt, galak, matthias.bgg, jay.xu, linux-arm-kernel,
Maxime Ripard
在 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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v2 0/3] Add the efuse driver on rockchip platform
@ 2015-06-18 9:08 ` Caesar Wang
0 siblings, 0 replies; 32+ messages in thread
From: Caesar Wang @ 2015-06-18 9:08 UTC (permalink / raw)
To: Srinivas Kandagatla, Stefan Wahren
Cc: heiko-4mtYJXux2i+zQB+pC5nmwQ, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA, linux-lFZ/pmaqli7XmaaqVzeoHQ,
pawel.moll-5wv7dgnIgG8, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, galak-sgV2jX0FEOL9JmXXK+q4OQ,
matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w,
jay.xu-TNX95d0MmH7DzftRWevZcw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Maxime Ripard
在 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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v2 0/3] Add the efuse driver on rockchip platform
@ 2015-06-18 9:08 ` Caesar Wang
0 siblings, 0 replies; 32+ messages in thread
From: Caesar Wang @ 2015-06-18 9:08 UTC (permalink / raw)
To: linux-arm-kernel
? 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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v2 0/3] Add the efuse driver on rockchip platform
2015-06-18 8:29 ` Srinivas Kandagatla
@ 2015-07-31 9:27 ` Shunqian Zheng
-1 siblings, 0 replies; 32+ messages in thread
From: Shunqian Zheng @ 2015-07-31 9:27 UTC (permalink / raw)
To: Srinivas Kandagatla, Stefan Wahren
Cc: mark.rutland, devicetree, linux, heiko, pawel.moll,
ijc+devicetree, linus.walleij, linux-kernel, linux-rockchip,
robh+dt, galak, matthias.bgg, Maxime Ripard, jay.xu,
linux-arm-kernel, Caesar Wang
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@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@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v2 0/3] Add the efuse driver on rockchip platform
@ 2015-07-31 9:27 ` Shunqian Zheng
0 siblings, 0 replies; 32+ messages in thread
From: Shunqian Zheng @ 2015-07-31 9:27 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v2 0/3] Add the efuse driver on rockchip platform
2015-07-31 9:27 ` Shunqian Zheng
@ 2015-08-04 16:11 ` Srinivas Kandagatla
-1 siblings, 0 replies; 32+ messages in thread
From: Srinivas Kandagatla @ 2015-08-04 16:11 UTC (permalink / raw)
To: shunqian.zheng, Stefan Wahren
Cc: mark.rutland, devicetree, linux, heiko, pawel.moll,
ijc+devicetree, linus.walleij, linux-kernel, linux-rockchip,
robh+dt, galak, matthias.bgg, Maxime Ripard, jay.xu,
linux-arm-kernel, Caesar Wang
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@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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v2 0/3] Add the efuse driver on rockchip platform
@ 2015-08-04 16:11 ` Srinivas Kandagatla
0 siblings, 0 replies; 32+ messages in thread
From: Srinivas Kandagatla @ 2015-08-04 16:11 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v2 0/3] Add the efuse driver on rockchip platform
2015-08-04 16:11 ` Srinivas Kandagatla
@ 2015-08-06 1:10 ` Shunqian Zheng
-1 siblings, 0 replies; 32+ messages in thread
From: Shunqian Zheng @ 2015-08-06 1:10 UTC (permalink / raw)
To: Srinivas Kandagatla, Stefan Wahren
Cc: mark.rutland, devicetree, linux, heiko, pawel.moll,
ijc+devicetree, linus.walleij, linux-kernel, linux-rockchip,
robh+dt, galak, matthias.bgg, Maxime Ripard, jay.xu,
linux-arm-kernel, Caesar Wang
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@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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v2 0/3] Add the efuse driver on rockchip platform
@ 2015-08-06 1:10 ` Shunqian Zheng
0 siblings, 0 replies; 32+ messages in thread
From: Shunqian Zheng @ 2015-08-06 1:10 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2015-08-06 1:10 UTC | newest]
Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-16 7:27 [PATCH v2 0/3] Add the efuse driver on rockchip platform Caesar Wang
2015-06-16 7:27 ` Caesar Wang
2015-06-16 7:27 ` Caesar Wang
2015-06-16 7:27 ` [PATCH v2 1/3] soc/rockchip: Add efuse bindings for Rockchip SoC efuse driver Caesar Wang
2015-06-16 7:27 ` Caesar Wang
2015-06-16 7:27 ` [PATCH v2 2/3] soc/rockchip: efuse: Add Rockchip SoC efuse support Caesar Wang
2015-06-16 7:27 ` Caesar Wang
2015-06-16 7:27 ` [PATCH v2 3/3] ARM: dts: Add RK3288 efuse node Caesar Wang
2015-06-16 7:27 ` Caesar Wang
2015-06-16 8:52 ` [PATCH v2 0/3] Add the efuse driver on rockchip platform Stefan Wahren
2015-06-16 8:52 ` Stefan Wahren
2015-06-16 9:21 ` Srinivas Kandagatla
2015-06-16 9:21 ` Srinivas Kandagatla
2015-06-16 10:06 ` Caesar Wang
2015-06-16 10:06 ` Caesar Wang
2015-06-16 10:54 ` Srinivas Kandagatla
2015-06-16 10:54 ` Srinivas Kandagatla
2015-06-16 10:54 ` Srinivas Kandagatla
2015-06-18 7:05 ` Stefan Wahren
2015-06-18 7:05 ` Stefan Wahren
2015-06-18 7:05 ` Stefan Wahren
2015-06-18 8:29 ` Srinivas Kandagatla
2015-06-18 8:29 ` Srinivas Kandagatla
2015-06-18 9:08 ` Caesar Wang
2015-06-18 9:08 ` Caesar Wang
2015-06-18 9:08 ` Caesar Wang
2015-07-31 9:27 ` Shunqian Zheng
2015-07-31 9:27 ` Shunqian Zheng
2015-08-04 16:11 ` Srinivas Kandagatla
2015-08-04 16:11 ` Srinivas Kandagatla
2015-08-06 1:10 ` Shunqian Zheng
2015-08-06 1:10 ` Shunqian Zheng
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.