Re: [RFC PATCH v6 2/2] nvmem: Add Vybrid OCOTP and OCROM support

[maitysanchayan]

Hello Stefan,

On 15-06-24 11:56:14, Stefan Wahren wrote:
> Hi Sanchayan,
> 
> Am 24.06.2015 um 07:19 schrieb maitysanchayan@xxxxxxxxx:
> > On 15-06-23 21:31:41, Stefan Wahren wrote:
> >> Hi Sanchayan,
> >>
> >>> Sanchayan Maity <maitysanchayan@xxxxxxxxx> 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@xxxxxxxxx>
> >>> ---
> >>> 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?

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?

> 
> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/