linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: stefan.wahren@i2se.com (Stefan Wahren)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v6 3/3] drivers: nvmem: Add Vybrid OCOTP support
Date: Wed, 8 Jul 2015 22:55:23 +0200 (CEST)	[thread overview]
Message-ID: <24856127.49152.1436388923583.JavaMail.open-xchange@oxbsltgw04.schlund.de> (raw)
In-Reply-To: <20150708053920.GA4089@Sanchayan-Arch.toradex.int>

Hi Sanchayan,

> maitysanchayan at gmail.com hat am 8. Juli 2015 um 07:39 geschrieben:
>
>
> [...]
> > > >
> > > > Looking at valid_fuse_addr shows me 0x3F as last valid register. So the
> > > > rest
> > > > of the buffer ( 0xD00 - sizeof(valid_fuse_addr) ) in case of raw access
> > > > could be
> > > > uninitializied.
> > >
> > > Sorry I did not exactly get you here. The intention behind using the
> > > valid_fuse_addr
> > > is to allow reading only from valid fuse addresses and avoid reading from
> > > all
> > > other
> > > locations as per the Fuse map address table 35-1.
> >
> > Yes, i got your intention. But from my unterstand the read function should
> > fill
> > up
> > the complete buffer with defined values. My MXS OCOTP driver have the same
> > problem
> > and fill up the invalid registers with zero.
>
> I must admit I had not thought of that. Thats a valid point. I dont know at
> the
> moment however what would be the correct approach here. Perhaps filling
> locations
> other than the valid fuse addresses as per the fuse map table with 0xBADABADA
> is
> the right thing? Anyways that's what is going to be returned if we were to
> read
> a location which is read locked or reserved.

since we are operating in userspace the behavior shouldn't be specific to the
device.
It would be good when all drivers behave the same. But i think it would be much
better
as the nvmem framework take care of it and preinit the buffer with a defined
value.

>
> However since the fuse address and base address mapping is not exactly linear,
> this would require some additional logic than the simple thing I did. 

I defined a regmap_access_table for valid read registers in my case. But i think
in your case
an implementation of the readable_reg callback in the regmap_config would be
more elegant.

You can validate your implementation under /sys/kernel/debug/regmap/

Sorry, i'm a newbie to regmap.

Stefan

> Also OCOTP requires the fuse address to be written. May be using the nvmem
> consumer DT property
> gets something?! Not sure atm.
>
> - Sanchayan.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2015-07-08 20:55 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-23 13:44 [RFC PATCH v6 0/2] Implement NVMEM/SoC bus support for Vybrid Sanchayan Maity
2015-06-23 13:44 ` [RFC PATCH v6 1/2] ARM: dts: vfxxx: Add OCOTP and OCROM nodes Sanchayan Maity
2015-06-23 13:44 ` [RFC PATCH v6 2/2] nvmem: Add Vybrid OCOTP and OCROM support Sanchayan Maity
2015-06-23 19:03   ` Srinivas Kandagatla
2015-06-24  5:25     ` maitysanchayan at gmail.com
2015-06-23 19:31   ` Stefan Wahren
2015-06-24  5:19     ` maitysanchayan at gmail.com
2015-06-24  9:37       ` Srinivas Kandagatla
2015-06-24  9:44         ` Sanchayan Maity
2015-06-24  9:56       ` Stefan Wahren
2015-06-24 10:45         ` maitysanchayan at gmail.com
2015-06-24 11:52           ` Stefan Wahren
2015-06-24 12:05             ` maitysanchayan at gmail.com
2015-06-29 11:22             ` [RFC PATCH v6 0/3] Implement NVMEM/SoC bus support for Vybrid Sanchayan Maity
2015-06-29 11:22               ` [RFC PATCH v6 1/3] clk: clk-vf610: Add clock for Vybrid OCOTP controller Sanchayan Maity
2015-06-29 11:22               ` [RFC PATCH v6 2/3] ARM: dts: vfxxx: Add OCOTP node Sanchayan Maity
2015-06-29 11:22               ` [RFC PATCH v6 3/3] drivers: nvmem: Add Vybrid OCOTP support Sanchayan Maity
2015-07-06 10:16                 ` Stefan Wahren
2015-07-07  5:19                   ` maitysanchayan at gmail.com
2015-07-07 12:49                     ` Stefan Wahren
2015-07-08  5:39                       ` maitysanchayan at gmail.com
2015-07-08 20:55                         ` Stefan Wahren [this message]
2015-07-10 18:09                           ` maitysanchayan at gmail.com
2015-06-24 11:20         ` [RFC PATCH v6 2/2] nvmem: Add Vybrid OCOTP and OCROM support Stefan Agner
2015-06-24  8:35   ` Maxime Ripard
2015-06-24  9:34     ` Srinivas Kandagatla
2015-06-25 17:49       ` Maxime Ripard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=24856127.49152.1436388923583.JavaMail.open-xchange@oxbsltgw04.schlund.de \
    --to=stefan.wahren@i2se.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).