i.MX28 - driver for OTP eFuses

[ChristophG_Baum]

Hello Forum,

using a vanilla 3.7 Linux kernel for the i.MX28 EVK I started porting some drivers from the Freescale SDK based on 2.6.35.

The OTP driver allows reading the OTP cells via the sysfs but fails to write. I tracked the problem to a call to clk_get(). The name of the required clock seems to have changed from "hclk" to "hbus", but fixing that didn't help. sysfs shows a clock named "hbus". So what else could go wrong?

Regards

Christoph

[dimitarboevski]

Hey, i got it working. Both reading and writing.

I'm using the clk_get_sys("hbus", NULL) function to get the clock. It should work after registering it like you do (as i saw it in your patch - it helped me a lot!) in the clk-imx28.c file.

The other thing that has changed is some regulator's name (the name is already set in the device tree). You should change it in the board file mach-mxs.c to "vddio-sd0":

static struct fsl_otp_data otp_data = {
  .fuse_name = (char **)bank_reg_desc,
  .regulator_name = "vddio-sd0",
  .fuse_num = BANKS * BANK_ITEMS,
};

Now i get a warning when the driver creates the sysfs entries if the kernel is compiled with CONFIG_DEBUG_LOCK_ALLOC set. It seems to be a problem with the kernel itself because the sysfs driver is doing things to "make lockdep happy"... but anyway, the OTP driver works.

[ChristophG_Baum]

I uploaded a new patch that includes the fixes for clock and regulator. It now conforms to the checkpatch.pl script in the current mainline kernel (appart from the missing "signed off by").

[dimitarboevski]

Ahh, we just have to call sysfs_attr_init() to "make lockdep happy". here's a mini patch:

diff --git a/drivers/char/fsl_otp.c b/drivers/char/fsl_otp.c
index ce99bf8e..c3cc1c6 100644
--- a/drivers/char/fsl_otp.c
+++ b/drivers/char/fsl_otp.c
@@ -158,6 +158,8 @@ static int alloc_otp_attr(void)
  kattr[i].store = otp_store;

  attrs[i] = &kattr[i].attr;
+ sysfs_attr_init( attrs[i] );
+
  }
  memset(&attr_group, 0, sizeof(attr_group));
  attr_group.attrs = attrs;

[fabio_estevam]

Do you guys plan to send this patch upstream?

[lategoodbye]

Hi,

took Christoph's last version and made a V3. This version is without write support because this would have a negative impact on the whole system:

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/295228.html

Please send me testing feedback for i.MX23 and i.MX28.

BR Stefan

[ChristophG_Baum]

I would like to, but currently I haven't got the time. And as I'm a nobody on LAKML it is likely to be ignored, as was the DCP patch.

[dimitarboevski]

Good work.

Do you get the following warning at kernel loading:

WARNING: at kernel/lockdep.c:2986 sysfs_add_file_mode+0x80/0xe8()

( stacktrace )

BUG: key c7620028 not in .data!

.....

It's only shown when the kernel is compiled with the CONFIG_DEBUG_LOCK_ALLOC option. If you don't get the warning could you check if that option is turned off for you? I would rather not turn it off so i'm trying to get rid of those ugly 20 lines of "BUG".

[ChristophG_Baum]

Yes, I see warnings like this. I will try your patch below.

[ChristophG_Baum]

Yes, it works for me too!

Now I have some deadbeef in my i.MX28 :-)

[fabio_estevam]

Christoph,

It would help if you post your patch to the Linux ARM kernel mailing list, so that people could review what you did.

Regards,

Fabio Estevam

[ChristophG_Baum]

My (still not entirely working) patch can be found at http://www.sgoc.de/Downloads/fsl-otp.patch.

Christoph

[fabio_estevam]

Hi Christoph,

What does "not entirely working" mean? What is missing?

I saw your post in the linux-arm-kernel list. It would be really nice if you could post it as patch (via git send-email, preferably) so that people could review it and possibly accept it to the kernel.

Let me know if you need help with the submission process.

Also, how did you test it?

Thanks,

Fabio Estevam

[ChristophG_Baum]

Hi Fabio,

What does "not entirely working" mean? What is missing?

reading works, but writing OTP cells fails because clk_get() fails to get the handle for the CLK associated with "hclk", "hbus" or whatever. As far as I understood the code in 3.7 the name of the clock is "hbus" and it seems to get registered. A clock of this name can also be seen via /sys/kernel/debug. But clk_get() still fails. Could it be that the clock has also to be named in the device tree?

I saw your post in the linux-arm-kernel list. It would be really nice if you could post it as patch (via git send-email, preferably) so that people could review it and possibly accept it to the kernel.

Currently I'm waiting to see how the DCP patch is going.

Regards,

Christoph

[ChristophG_Baum]

Hi Fabio,

well, you may be right that the Linux ARM kernel mailing list is a better place for this question. But I didn't dare as the driver doesn't work so far.

Regards,

Christoph