Messages in this thread | | | Date | Wed, 24 Jun 2015 17:35:00 +0530 | From | maitysanchayan@gmail ... | Subject | Re: [RFC PATCH v6 2/2] nvmem: Add Vybrid OCOTP and OCROM support |
| |
Hello Stefan,
On 15-06-24 13:52:28, Stefan Wahren wrote: > Hi Srinivas, > > Am 24.06.2015 um 12:45 schrieb maitysanchayan@gmail.com: > > Hello Stefan, > > > > On 15-06-24 11:56:14, Stefan Wahren wrote: > >> Hi Sanchayan, > >> > >> Am 24.06.2015 um 07:19 schrieb maitysanchayan@gmail.com: > >>> On 15-06-23 21:31:41, Stefan Wahren wrote: > >>>> Hi Sanchayan, > >>>> > >>>>> Sanchayan Maity <maitysanchayan@gmail.com> hat am 23. Juni 2015 um 15:44 > >>>>> geschrieben: > >>>>> > >>>>> > >>>>> The patch adds support for the On Chip One Time Programmable Peripheral > >>>>> (OCOTP) and On Chip ROM (OCROM) support. > >>>>> > >>>>> On Vybrid OCOTP contain data like SoC ID, MAC address and OCROM has the > >>>>> revision ID. > >>>>> > >>>>> Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com> > >>>>> --- > >>>>> drivers/nvmem/Kconfig | 11 +++++++++ > >>>>> drivers/nvmem/Makefile | 2 ++ > >>>>> drivers/nvmem/vf610-ocotp.c | 60 +++++++++++++++++++++++++++++++++++++++++++++ > >>>>> 3 files changed, 73 insertions(+) > >>>>> create mode 100644 drivers/nvmem/vf610-ocotp.c > >>>>> > >>>>> diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig > >>>>> index 17f1a57..557c1e0 100644 > >>>>> --- a/drivers/nvmem/Kconfig > >>>>> +++ b/drivers/nvmem/Kconfig > >>>>> @@ -33,4 +33,15 @@ config NVMEM_SUNXI_SID > >>>>> This driver can also be built as a module. If so, the module > >>>>> will be called eeprom-sunxi-sid. > >>>>> > >>>>> +config NVMEM_VF610_OCOTP > >>>>> + tristate "VF610 SoCs OCOTP support" > >>>>> + depends on SOC_VF610 > >>>>> + select REGMAP_MMIO > >>>> how do you come to the conclusion that Vybrid On-Chip OTP is accessable via > >>>> MMIO? > >>> Frankly speaking I just changed the naming conventions and followed the qfrom > >>> and sunxi sid examples in Srinivas's patches. > >>> > >>> I just tested it without the "select REGMAP_MMIO" and it works just fine. > >>> > >>> - Sanchayan. > >> sorry for the confusion. My question refers to the whole driver > >> implementation not only to the REGMAP_MMIO. > >> > >> According to > >> > >> Vybrid Reference Manual F-Series > >> Document Number: VYBRIDRM > >> Rev 7, 06/2014 > >> > >> 35.5 OCOTP memory map/register definition > >> > >> the memory region is organized in control and shadow registers. I'm very > >> sceptical that using REGMAP_MMIO is the right way for accessing the OCOTP. > > Sorry I am not well versed with the regmap stuff. Can you please tell me why > > REGMAP_MMIO is not the right way for accessing the OCOTP? > > i think the implementation of OCOTP driver should be more like this: > > https://git.linaro.org/people/srinivas.kandagatla/linux.git/commit/b4c3ad253747767511233687436f20144e850d67 > > It uses REGMAP with a specialized read function.
Thank you very much for the link.
> > > > > If this is not the right way, I assume you are referring to the procedures > > in section 35.3.1.5 and 35.3.1.6 for reading and writing from these areas? > > Yes. I think writing isn't needed. But the read function should check > at least for OCOTP_CTRL[BUSY] and OCOTP_CTRL[ERROR]. If one of the > bits is set, the read function should return with an error.
Understood. Will incoporate this in the v6 patch.
> > This is the same behavior of my OCOTP driver for MXS platform. > > Unfortunately i haven't push the driver to my github account. > > >> It possible that it works in your case. But in the case the lock bits > >> are set the driver won't work correctly. > > As such the previous implementations were very different. > > > > Currently I only expect to provide a way for users to read the SoC ID from > > the OCOTP block. My understanding was even if the lock bits are set, reading > > from the registers will return 0xBADABADA. > > > > For example, currently for three locations I see this from ocotp block > > > > * > > 0000080 bada bada bada bada bada bada bada bada > > * > > 0000500 bada bada bada bada bada bada bada bada > > * > > 0000c80 bada bada bada bada bada bada bada bada > > * > > > > - Sanchayan. > > Until somebody comes to the idea to fetch the MAC address from the OCOTP > block ... > > How about doing it right at this point, instead of fixing it later?
Of course. Thanks for the feedback Stefan.
- Sanchayan.
| |