Hi Srinivas, Am 24.06.2015 um 12:45 schrieb [email protected]: > Hello Stefan, > > On 15-06-24 11:56:14, Stefan Wahren wrote: >> Hi Sanchayan, >> >> Am 24.06.2015 um 07:19 schrieb [email protected]: >>> On 15-06-23 21:31:41, Stefan Wahren wrote: >>>> Hi Sanchayan, >>>> >>>>> Sanchayan Maity <[email protected]> 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 <[email protected]> >>>>> --- >>>>> 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. > > 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. 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? Stefan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
