mxs: add ocotp support for i.MX23 and i.MX28
Subsystems (4)
v3 cover mxs: add ocotp support for i.MX23 and i.MX28
This patch series brings readonly support for the On Chip OTP cells in the i.MX23 and i.MX28 processor. The driver uses files (one for each cell) in sysfs as interface.
This series based on the second version of the patches from Christoph G. Baumann, but without write support which is too invasive.
The driver has been tested only with a i.MX28 board, so feedback from i.MX23 users are very welcome.
changes in V3:
- drop write support
- take care of i.MX23 which has less registers
- drop unnecessary header file
- move static variables into driver data
- add devicetree probing
- fix missing bank closing in error case
- use kobj from platform device for sysfs
- add SYSFS to Kconfig
- add binding file
- code cleanup
Stefan Wahren (3):
mxs: add binding for fsl ocotp
mxs: add driver for ocotp in i.MX23 and i.MX28
mxs: enable ocotp for i.MX23 and i.MX28
.../devicetree/bindings/misc/fsl,octop.txt | 14 + arch/arm/boot/dts/imx23.dtsi | 3 +- arch/arm/boot/dts/imx28.dtsi | 3 +- drivers/misc/Kconfig | 13 + drivers/misc/Makefile | 1 + drivers/misc/fsl_ocotp.c | 332 ++++++++++++++++++++ 6 files changed, 362 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/misc/fsl,octop.txt create mode 100644 drivers/misc/fsl_ocotp.c
Signature · 1 line
1.7.9.5
RFC PATCH v3 1/3 mxs: add binding for fsl ocotp
This patch adds the Device tree bindings for the Freescale MXS On Chip OTP driver.
--- .../devicetree/bindings/misc/fsl,octop.txt | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 Documentation/devicetree/bindings/misc/fsl,octop.txt
Documentation/devicetree/bindings/misc/fsl,octop.txt new file +14 -0
@@ -0,0 +1,14 @@ +On-Chip OTP Memory for Freescale MX23/MX28 + +Required properties: +- compatible: + - "fsl,imx23-ocotp" for MX23 + - "fsl,imx23-ocotp" for MX28 +- reg : Address and length of OTP controller registers + +Example: + + ocotp: ocotp at 8002c000 { + compatible = "fsl,imx28-ocotp", "fsl,ocotp"; + reg = <0x8002c000 0x2000>; + };
Signature · 1 line
1.7.9.5
RFC PATCH v3 2/3 mxs: add driver for ocotp in i.MX23 and i.MX28
In reply to Stefan WahrenThis patch brings readonly support for the On Chip OTP cells in the i.MX23 and i.MX28 processor. The driver uses files (one for each cell) in sysfs as interface.
--- drivers/misc/Kconfig | 13 ++ drivers/misc/Makefile | 1 + drivers/misc/fsl_ocotp.c | 332 ++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 346 insertions(+) create mode 100644 drivers/misc/fsl_ocotp.c
drivers/misc/Kconfig +13 -0
@@ -515,6 +515,19 @@ config VEXPRESS_SYSCFG bus. System Configuration interface is one of the possible means of generating transactions on this bus. +config FSL_OCOTP + tristate "Freescale MXS On-Chip OTP Memory Support" + depends on ARCH_MXS && SYSFS + help + If you say Y here, you will get support for a readonly + SysFS interface for the One Time Programmable memory pages that + are stored on the Freescale i.MX23/i.MX28 processor. + + To compile this driver as a module, choose M here: the module + will be called fsl_ocotp. + + If unsure, it is safe to say N. + source "drivers/misc/c2port/Kconfig" source "drivers/misc/eeprom/Kconfig" source "drivers/misc/cb710/Kconfig"
drivers/misc/Makefile +1 -0
@@ -55,3 +55,4 @@ obj-y += mic/ obj-$(CONFIG_GENWQE) += genwqe/ obj-$(CONFIG_ECHO) += echo/ obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o +obj-$(CONFIG_FSL_OCOTP) += fsl_ocotp.o
drivers/misc/fsl_ocotp.c new file +332 -0
332 lines not on this page · raw message
Signature · 1 line
1.7.9.5
Arnd Bergmann
maintainerRFC PATCH v3 2/3 mxs: add driver for ocotp in i.MX23 and i.MX28
Quoted 23 lines · On Saturday 18 October 2014 10:32:51 Stefan Wahren wrote:
This patch brings readonly support for the On Chip OTP cells in the i.MX23 and i.MX28 processor. The driver uses files (one for each cell) in sysfs as interface.
Signed-off-by Stefan Wahren <[email protected]>--- drivers/misc/Kconfig | 13 ++ drivers/misc/Makefile | 1 + drivers/misc/fsl_ocotp.c | 332 ++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 346 insertions(+) create mode 100644 drivers/misc/fsl_ocotp.cdrivers/misc/Kconfig +3
-0@@ -515,6 +515,19 @@ config VEXPRESS_SYSCFG bus. System Configuration interface is one of the possible means of generating transactions on this bus. +config FSL_OCOTP + tristate "Freescale MXS On-Chip OTP Memory Support" + depends on ARCH_MXS && SYSFS
drivers/misc/Kconfig config VEXPRESS_SYSCFG · line 530
Quoted 10 lines
drivers/misc/Kconfig +9
-0+ help + If you say Y here, you will get support for a readonly + SysFS interface for the One Time Programmable memory pages that + are stored on the Freescale i.MX23/i.MX28 processor. + + To compile this driver as a module, choose M here: the module + will be called fsl_ocotp. + + If unsure, it is safe to say N.
I think this needs to be an MTD driver, not a "misc" driver, and it should use the proper MTD interfaces instead of introducing an incompatible set of interfaces.
Arnd
RFC PATCH v3 2/3 mxs: add driver for ocotp in i.MX23 and i.MX28
Hi Arnd,
Am 20.10.2014 um 16:44 schrieb Arnd Bergmann:
Quoted 11 lines · On Saturday 18 October 2014 10:32:51 Stefan Wahren wrote:
Quoted 5 lines
This patch brings readonly support for the On Chip OTP cells in the i.MX23 and i.MX28 processor. The driver uses files (one for each cell) in sysfs as interface.
...
I think this needs to be an MTD driver, not a "misc" driver, and it should use the proper MTD interfaces instead of introducing an incompatible set of interfaces.
Arnd
phew that sounds like a lot of work and much complexity.
Am i right, that i should drop the sysfs interface?
Does MTD drivers have a readonly text (non binary) user interface?
Best regards
Stefan
Arnd Bergmann
maintainerRFC PATCH v3 2/3 mxs: add driver for ocotp in i.MX23 and i.MX28
Quoted 12 lines · On Monday 20 October 2014 17:32:37 Stefan Wahren wrote:
Am 20.10.2014 um 16:44 schrieb Arnd Bergmann:
Quoted 10 lines · On Saturday 18 October 2014 10:32:51 Stefan Wahren wrote:
Quoted 5 lines
This patch brings readonly support for the On Chip OTP cells in the i.MX23 and i.MX28 processor. The driver uses files (one for each cell) in sysfs as interface.
...
I think this needs to be an MTD driver, not a "misc" driver, and it should use the proper MTD interfaces instead of introducing an incompatible set of interfaces.
Quoted 7 lines
Quoted 1 line
Arnd
phew that sounds like a lot of work and much complexity.
Am i right, that i should drop the sysfs interface?
Does MTD drivers have a readonly text (non binary) user interface?
I haven't looked at the MTD OTP interface in detail, but most of the other SoCs seem to use it.
Arnd
RFC PATCH v3 2/3 mxs: add driver for ocotp in i.MX23 and i.MX28
In reply to Arnd BergmannQuoted 30 lines · Arnd Bergmann
Quoted 29 lines · On Saturday 18 October 2014 10:32:51 Stefan Wahren wrote:
This patch brings readonly support for the On Chip OTP cells in the i.MX23 and i.MX28 processor. The driver uses files (one for each cell) in sysfs as interface.
Signed-off-by Stefan Wahren <[email protected]>--- drivers/misc/Kconfig | 13 ++ drivers/misc/Makefile | 1 + drivers/misc/fsl_ocotp.c | 332 ++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 346 insertions(+) create mode 100644 drivers/misc/fsl_ocotp.cdrivers/misc/Kconfig +9
-0@@ -515,6 +515,19 @@ config VEXPRESS_SYSCFG bus. System Configuration interface is one of the possible means of generating transactions on this bus. +config FSL_OCOTP + tristate "Freescale MXS On-Chip OTP Memory Support" + depends on ARCH_MXS && SYSFS + help + If you say Y here, you will get support for a readonly + SysFS interface for the One Time Programmable memory pages that + are stored on the Freescale i.MX23/i.MX28 processor. + + To compile this driver as a module, choose M here: the module
Quoted 9 lines
drivers/misc/Kconfig config VEXPRESS_SYSCFG
Quoted 4 lines
drivers/misc/Kconfig +3
-0+ will be called fsl_ocotp. + + If unsure, it is safe to say N.I think this needs to be an MTD driver, not a "misc" driver, and it should use the proper MTD interfaces instead of introducing an incompatible set of interfaces.
Are you sure MTD is the right place? Recently an eFuse driver was merged in drivers/soc/tegra/fuse:
http://lxr.free-electrons.com/source/drivers/soc/tegra/fuse/fuse-tegra.c
Isn't this a similar device?
Signature · 10 lines
Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141028/06ec5899/attachment-0001.sig>
Arnd Bergmann
maintainerRFC PATCH v3 2/3 mxs: add driver for ocotp in i.MX23 and i.MX28
Quoted 41 lines · On Tuesday 28 October 2014 14:17:39 Ezequiel Garcia wrote:
Quoted 30 lines · Arnd Bergmann
Quoted 29 lines · On Saturday 18 October 2014 10:32:51 Stefan Wahren wrote:
This patch brings readonly support for the On Chip OTP cells in the i.MX23 and i.MX28 processor. The driver uses files (one for each cell) in sysfs as interface.
Signed-off-by Stefan Wahren <[email protected]>--- drivers/misc/Kconfig | 13 ++ drivers/misc/Makefile | 1 + drivers/misc/fsl_ocotp.c | 332 ++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 346 insertions(+) create mode 100644 drivers/misc/fsl_ocotp.cdrivers/misc/Kconfig +9
-0@@ -515,6 +515,19 @@ config VEXPRESS_SYSCFG bus. System Configuration interface is one of the possible means of generating transactions on this bus. +config FSL_OCOTP + tristate "Freescale MXS On-Chip OTP Memory Support" + depends on ARCH_MXS && SYSFS + help + If you say Y here, you will get support for a readonly + SysFS interface for the One Time Programmable memory pages that + are stored on the Freescale i.MX23/i.MX28 processor. + + To compile this driver as a module, choose M here: the moduleQuoted 9 lines
drivers/misc/Kconfig config VEXPRESS_SYSCFG
Quoted 4 lines
drivers/misc/Kconfig +3
-0+ will be called fsl_ocotp. + + If unsure, it is safe to say N.I think this needs to be an MTD driver, not a "misc" driver, and it should use the proper MTD interfaces instead of introducing an incompatible set of interfaces.
Quoted 6 lines
Are you sure MTD is the right place? Recently an eFuse driver was merged in
drivers/soc/tegra/fuse:http://lxr.free-electrons.com/source/drivers/soc/tegra/fuse/fuse-tegra.c
Isn't this a similar device?
Hmm, I missed that one.
I came up with MTD just because a grep for OTP showed most hits in there. I have to admit that I didn't check whether those are actually for the same kind of device or for something else that goes by the same name. Having it in MTD doesn't sound too obscure though.
There are a few other references to efuse or otp in the kernel, which means that at some point we probably want to have a common subsystem and user interface for this, either in MTD or standalone.
Between drivers/misc/fsl_ocotp.c, drivers/soc/tegra/fuse and drivers/mfd/ab3100-otp.c, is there any commonality that we could base an abstract API on?
Arnd
RFC PATCH v3 2/3 mxs: add driver for ocotp in i.MX23 and i.MX28
Hi,
Quoted 8 lines
Arnd Bergmann <[email protected]> hat am 28. Oktober 2014 um 20:13 geschrieben:
[...]I came up with MTD just because a grep for OTP showed most hits in there. I have to admit that I didn't check whether those are actually for the same kind of device or for something else that goes by the same name. Having it in MTD doesn't sound too obscure though.
Quoted 7 lines
There are a few other references to efuse or otp in the kernel, which means that at some point we probably want to have a common subsystem and user interface for this, either in MTD or standalone.
Between
drivers/misc/fsl_ocotp.c,drivers/soc/tegra/fuseanddrivers/mfd/ab3100-otp.c, is there any commonality that we could base an abstract API on?
i don't have a answer to this question, but how about changing fsl_ocotp driver to driver/soc/mxs/fuse with a similiar binary interface like the tegra ones.
Does it make sense to you?
Quoted 7 lines
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
BR Stefan
Arnd Bergmann
maintainerRFC PATCH v3 2/3 mxs: add driver for ocotp in i.MX23 and i.MX28
Quoted 14 lines · On Thursday 06 November 2014 20:25:32 Stefan Wahren wrote:
Hi,
Quoted 12 lines
Arnd Bergmann <[email protected]> hat am 28. Oktober 2014 um 20:13 geschrieben:
[...]I came up with MTD just because a grep for OTP showed most hits in there. I have to admit that I didn't check whether those are actually for the same kind of device or for something else that goes by the same name. Having it in MTD doesn't sound too obscure though.
There are a few other references to efuse or otp in the kernel, which means that at some point we probably want to have a common subsystem and user interface for this, either in MTD or standalone.
Quoted 8 lines
Quoted 3 lines
Between
drivers/misc/fsl_ocotp.c,drivers/soc/tegra/fuseanddrivers/mfd/ab3100-otp.c, is there any commonality that we could base an abstract API on?i don't have a answer to this question, but how about changing
fsl_ocotpdriver to driver/soc/mxs/fuse with a similiar binary interface like the tegra ones.Does it make sense to you?
I haven't looked at the drivers, so I don't know if the tegra interface is any better or worse than the others. Changing everyone to have the same interface is definitely a good idea, but of course only if the unified interface is a good one ;-)
Arnd
RFC PATCH v3 2/3 mxs: add driver for ocotp in i.MX23 and i.MX28
Hi Stefan, Arnd,
(I'm trimming the Cc list and adding Thierry and Maxime to the loop):
On 11/06/2014 04:47 PM, Arnd Bergmann wrote:
[..]
Quoted 11 lines
Quoted 5 lines
i don't have a answer to this question, but how about changing
fsl_ocotpdriver to driver/soc/mxs/fuse with a similiar binary interface like the tegra ones.Does it make sense to you?
I haven't looked at the drivers, so I don't know if the tegra interface is any better or worse than the others. Changing everyone to have the same interface is definitely a good idea, but of course only if the unified interface is a good one ;-)
I'm in the process of finding a suitable upstream path for a new eFuse driver for fuses used on Imagination Technologies SoCs.
This was our last proposal, which follows Tegra's work:
http://www.spinics.net/lists/devicetree/msg59246.html
However, Arnd was reluctant to take yet another efuse driver under drivers/soc and proposed instead to try to find a unified API. We've had numerous fuse drivers (tegra, sunxi, imx and img) appearing, so his concern certainly makes sense.
I've talked to Arnd on IRC and we agreed to create a new directory drivers/efuse. As a first step we would just move the tegra driver, and add the new drivers (img on my side, and possibly mxs on Stefan's). Perhaps we would also pull the sunxi_sid driver as well.
Having the drivers together would allow us to come up with a unified API as follow up work.
How does this sound? If you have no objections to this, I can go ahead and try to prepare some RFCs.
Signature · 1 line
Ezequiel
RFC PATCH v3 2/3 mxs: add driver for ocotp in i.MX23 and i.MX28
Hi Ezequiel,
Am 08.01.2015 um 14:59 schrieb Ezequiel Garcia:
Quoted 16 lines
Hi Stefan, Arnd,
(I'm trimming the Cc list and adding Thierry and Maxime to the loop):
I'm in the process of finding a suitable upstream path for a new eFuse driver for fuses used on Imagination Technologies SoCs.
This was our last proposal, which follows Tegra's work:
http://www.spinics.net/lists/devicetree/msg59246.html
However, Arnd was reluctant to take yet another efuse driver under
drivers/socand proposed instead to try to find a unified API. We've had numerous fuse drivers (tegra, sunxi, imx and img) appearing, so his concern certainly makes sense.
Quoted 7 lines
I've talked to Arnd on IRC and we agreed to create a new directory
drivers/efuse. As a first step we would just move the tegra driver, and add the new drivers (img on my side, and possibly mxs on Stefan's). Perhaps we would also pull thesunxi_siddriver as well.Having the drivers together would allow us to come up with a unified API as follow up work.
does this unified API affects userspace interface, internal kernel interface or both?
Quoted 2 lines
How does this sound? If you have no objections to this, I can go ahead and try to prepare some RFCs.
I'm happy about any progress on this. It's not really urgent for me to get the driver into mainline. A helpful and useable userspace interface is more important to me. So i want to send my comments/requirements about the API and post the mxs driver after the definition of the unified API.
Does this answer your question?
Stefan
RFC PATCH v3 2/3 mxs: add driver for ocotp in i.MX23 and i.MX28
In reply to Ezequiel GarciaHi Ezequiel,
Quoted 6 lines
Ezequiel Garcia <[email protected]> hat am 8. Januar 2015 um 14:59 geschrieben:
Hi Stefan, Arnd,
Quoted 8 lines
(I'm trimming the Cc list and adding Thierry and Maxime to the loop):
[...]
I've talked to Arnd on IRC and we agreed to create a new directory
drivers/efuse. As a first step we would just move the tegra driver, and add the new drivers (img on my side, and possibly mxs on Stefan's). Perhaps we would also pull thesunxi_siddriver as well.
AFAIK the binding documentation for the tegra driver is stored in
Documentation/devicetree/bindings/fuse/
so a consistent naming would be better. Beside that i'm okay with the approach.
Stefan
RFC PATCH v3 2/3 mxs: add driver for ocotp in i.MX23 and i.MX28
In reply to Ezequiel GarciaQuoted 35 lines · Ezequiel Garcia
Hi Stefan, Arnd,
(I'm trimming the Cc list and adding Thierry and Maxime to the loop):
On 11/06/2014 04:47 PM, Arnd Bergmann wrote:
[..]Quoted 11 lines
Quoted 5 lines
i don't have a answer to this question, but how about changing
fsl_ocotpdriver to driver/soc/mxs/fuse with a similiar binary interface like the tegra ones.Does it make sense to you?
I haven't looked at the drivers, so I don't know if the tegra interface is any better or worse than the others. Changing everyone to have the same interface is definitely a good idea, but of course only if the unified interface is a good one ;-)
I'm in the process of finding a suitable upstream path for a new eFuse driver for fuses used on Imagination Technologies SoCs.
This was our last proposal, which follows Tegra's work:
http://www.spinics.net/lists/devicetree/msg59246.html
However, Arnd was reluctant to take yet another efuse driver under
drivers/socand proposed instead to try to find a unified API. We've had numerous fuse drivers (tegra, sunxi, imx and img) appearing, so his concern certainly makes sense.I've talked to Arnd on IRC and we agreed to create a new directory
drivers/efuse. As a first step we would just move the tegra driver, and add the new drivers (img on my side, and possibly mxs on Stefan's). Perhaps we would also pull thesunxi_siddriver as well.
Quoted 5 lines
Having the drivers together would allow us to come up with a unified API as follow up work.
How does this sound? If you have no objections to this, I can go ahead and try to prepare some RFCs.
No objections from me. Adding Peter and linux-tegra for visibility.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150109/e448848c/attachment.sig>
RFC PATCH v3 2/3 mxs: add driver for ocotp in i.MX23 and i.MX28
In reply to Ezequiel GarciaQuoted 35 lines · Ezequiel Garcia
Hi Stefan, Arnd,
(I'm trimming the Cc list and adding Thierry and Maxime to the loop):
On 11/06/2014 04:47 PM, Arnd Bergmann wrote:
[..]Quoted 11 lines
Quoted 5 lines
i don't have a answer to this question, but how about changing
fsl_ocotpdriver to driver/soc/mxs/fuse with a similiar binary interface like the tegra ones.Does it make sense to you?
I haven't looked at the drivers, so I don't know if the tegra interface is any better or worse than the others. Changing everyone to have the same interface is definitely a good idea, but of course only if the unified interface is a good one ;-)
I'm in the process of finding a suitable upstream path for a new eFuse driver for fuses used on Imagination Technologies SoCs.
This was our last proposal, which follows Tegra's work:
http://www.spinics.net/lists/devicetree/msg59246.html
However, Arnd was reluctant to take yet another efuse driver under
drivers/socand proposed instead to try to find a unified API. We've had numerous fuse drivers (tegra, sunxi, imx and img) appearing, so his concern certainly makes sense.I've talked to Arnd on IRC and we agreed to create a new directory
drivers/efuse. As a first step we would just move the tegra driver, and add the new drivers (img on my side, and possibly mxs on Stefan's). Perhaps we would also pull thesunxi_siddriver as well.
Quoted 5 lines
Having the drivers together would allow us to come up with a unified API as follow up work.
How does this sound? If you have no objections to this, I can go ahead and try to prepare some RFCs.
It sounds great :)
Could you put me in Cc whenever you send some patches?
Thanks!
Maxime
Signature · 10 lines
Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150112/d70391be/attachment.sig>
RFC PATCH v3 2/3 mxs: add driver for ocotp in i.MX23 and i.MX28
In reply to Stefan WahrenQuoted 14 lines · Stefan Wahren
Hi,
Quoted 12 lines
Arnd Bergmann <[email protected]> hat am 28. Oktober 2014 um 20:13 geschrieben:
[...]I came up with MTD just because a grep for OTP showed most hits in there. I have to admit that I didn't check whether those are actually for the same kind of device or for something else that goes by the same name. Having it in MTD doesn't sound too obscure though.
There are a few other references to efuse or otp in the kernel, which means that at some point we probably want to have a common subsystem and user interface for this, either in MTD or standalone.
Quoted 9 lines
Quoted 3 lines
Between
drivers/misc/fsl_ocotp.c,drivers/soc/tegra/fuseanddrivers/mfd/ab3100-otp.c, is there any commonality that we could base an abstract API on?i don't have a answer to this question, but how about changing
fsl_ocotpdriver to driver/soc/mxs/fuse with a similiar binary interface like the tegra ones.Does it make sense to you?
While you are here, maybe you can check if your API and driver will also be useful to support i.MX6 OCOTP?
I understand that I might be asking too much, and that perhaps i.MX23/28 eFuses are completely different from other another i.MX.
Signature · 2 lines
Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar
RFC PATCH v3 2/3 mxs: add driver for ocotp in i.MX23 and i.MX28
Quoted 7 lines
Ezequiel Garcia <[email protected]> hat am 7. November 2014 um 20:14 geschrieben:
While you are here, maybe you can check if your API and driver will also be useful to support i.MX6 OCOTP?
That's why i named the driver fsl_ocotp and not mxs_ocotp ;-)
Sure the handling would be a little different.
Quoted 3 lines
I understand that I might be asking too much, and that perhaps i.MX23/28 eFuses are completely different from other another i.MX.
I don't believe that, but i didn't doublecheck it.
BR Stefan
Quoted 9 lines
--
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
RFC PATCH v3 2/3 mxs: add driver for ocotp in i.MX23 and i.MX28
In reply to Ezequiel GarciaHi Ezequiel,
Am 28.10.2014 um 18:17 schrieb Ezequiel Garcia:
Quoted 39 lines · Arnd Bergmann
Quoted 21 lines · On Saturday 18 October 2014 10:32:51 Stefan Wahren wrote:
Quoted 20 lines
This patch brings readonly support for the On Chip OTP cells in the i.MX23 and i.MX28 processor. The driver uses files (one for each cell) in sysfs as interface.
Signed-off-by Stefan Wahren <[email protected]>--- drivers/misc/Kconfig | 13 ++ drivers/misc/Makefile | 1 + drivers/misc/fsl_ocotp.c | 332 ++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 346 insertions(+) create mode 100644 drivers/misc/fsl_ocotp.cdrivers/misc/Kconfig +0
-0@@ -515,6 +515,19 @@ config VEXPRESS_SYSCFG bus. System Configuration interface is one of the possible means of generating transactions on this bus.Quoted 17 lines
drivers/misc/Kconfig config VEXPRESS_SYSCFG
Quoted 13 lines
drivers/misc/Kconfig +12
-0+config FSL_OCOTP + tristate "Freescale MXS On-Chip OTP Memory Support" + depends on ARCH_MXS && SYSFS + help + If you say Y here, you will get support for a readonly + SysFS interface for the One Time Programmable memory pages that + are stored on the Freescale i.MX23/i.MX28 processor. + + To compile this driver as a module, choose M here: the module + will be called fsl_ocotp. + + If unsure, it is safe to say N.I think this needs to be an MTD driver, not a "misc" driver, and it should use the proper MTD interfaces instead of introducing an incompatible set of interfaces.
Quoted 6 lines
Are you sure MTD is the right place? Recently an eFuse driver was merged in
drivers/soc/tegra/fuse:http://lxr.free-electrons.com/source/drivers/soc/tegra/fuse/fuse-tegra.c
Isn't this a similar device?
the i.MX28 Reference manual speak also of eFuses and this driver looks more familiar to me.
Quoted 1 line
From my point of view it's important to keep the structure of 40 OTP
register a 32 bits. It doesn't make sense to merge them all together in a blob of 1280 bits and a userspace tool needs to separate it again.
Thanks for the hint.
BR Stefan
RFC PATCH v3 3/3 mxs: enable ocotp for i.MX23 and i.MX28
In reply to Stefan WahrenThis patch enables On Chip OTP support for i.MX23 and i.MX28 SoCs, but keeps the old compatible string.
--- arch/arm/boot/dts/imx23.dtsi | 3 +-- arch/arm/boot/dts/imx28.dtsi | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-)
arch/arm/boot/dts/imx23.dtsi +1 -2
@@ -350,9 +350,8 @@ }; ocotp at 8002c000 { - compatible = "fsl,ocotp"; + compatible = "fsl,imx23-ocotp", "fsl,ocotp"; reg = <0x8002c000 0x2000>; - status = "disabled"; }; axi-ahb at 8002e000 {
arch/arm/boot/dts/imx28.dtsi +1 -2
@@ -923,9 +923,8 @@ }; ocotp: ocotp at 8002c000 { - compatible = "fsl,ocotp"; + compatible = "fsl,imx28-ocotp", "fsl,ocotp"; reg = <0x8002c000 0x2000>; - status = "disabled"; }; axi-ahb at 8002e000 {
Signature · 1 line
1.7.9.5
v3 cover mxs: add ocotp support for i.MX23 and i.MX28
In reply to Stefan WahrenHi Stefan,
I'm very interested in your patches. Anything new about this?
Best regards
J?rg Krause
v3 cover mxs: add ocotp support for i.MX23 and i.MX28
In reply to Stefan WahrenHi Stefan,
sorry, I forgot to subscribe to the mailing list.
Any news about these patches? What's missing?
Best regards
J?rg Krause
v3 cover mxs: add ocotp support for i.MX23 and i.MX28
Hi J?rg,
Am 25.02.2015 um 21:27 schrieb J?rg Krause:
Quoted 5 lines
Hi Stefan,
sorry, I forgot to subscribe to the mailing list.
Any news about these patches? What's missing?
i wait until there is a common infrastructure for OTP / eFuse driver.
Please look at this discussion:
http://marc.info/?l=linux-arm-kernel&m=142486510903415&w=2
After these patches has been applied, i will adapt my patches here:
https://github.com/lategoodbye/fsl_ocotp
Quoted 3 lines
Best regards
J?rg Krause
BR Stefan
v3 cover mxs: add ocotp support for i.MX23 and i.MX28
Hi Stefan,
Quoted 11 lines · Stefan Wahren
Hi J?rg,
Am 25.02.2015 um 21:27 schrieb J?rg Krause:
Quoted 5 lines
Hi Stefan,
sorry, I forgot to subscribe to the mailing list.
Any news about these patches? What's missing?
i wait until there is a common infrastructure for OTP / eFuse driver.
Quoted 7 lines
Please look at this discussion:
http://marc.info/?l=linux-arm-kernel&m=142486510903415&w=2
After these patches has been applied, i will adapt my patches here:
These are good news! Many thanks!
Best regards
J?rg Krause