From mboxrd@z Thu Jan 1 00:00:00 1970 From: stefan.wahren@i2se.com (Stefan Wahren) Date: Wed, 24 Jun 2015 13:52:28 +0200 Subject: [RFC PATCH v6 2/2] nvmem: Add Vybrid OCOTP and OCROM support In-Reply-To: <20150624104552.GA32208@Sanchayan-Arch.toradex.int> References: <1037424954.250728.1435087901102.JavaMail.open-xchange@oxbsltgw00.schlund.de> <20150624051903.GA11753@Sanchayan-Arch.toradex.int> <558A7EBE.5030108@i2se.com> <20150624104552.GA32208@Sanchayan-Arch.toradex.int> Message-ID: <558A99FC.2070902@i2se.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Srinivas, Am 24.06.2015 um 12:45 schrieb maitysanchayan at 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 at gmail.com: >>> On 15-06-23 21:31:41, Stefan Wahren wrote: >>>> Hi Sanchayan, >>>> >>>>> Sanchayan Maity 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 >>>>> --- >>>>> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752757AbbFXLxI (ORCPT ); Wed, 24 Jun 2015 07:53:08 -0400 Received: from mout.kundenserver.de ([212.227.126.131]:58953 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752268AbbFXLxD (ORCPT ); Wed, 24 Jun 2015 07:53:03 -0400 Message-ID: <558A99FC.2070902@i2se.com> Date: Wed, 24 Jun 2015 13:52:28 +0200 From: Stefan Wahren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: maitysanchayan@gmail.com CC: srinivas.kandagatla@linaro.org, maxime.ripard@free-electrons.com, linux-arm-kernel@lists.infradead.org, stefan@agner.ch, kernel@pengutronix.de, linux-kernel@vger.kernel.org, shawn.guo@linaro.org, arnd@arndb.de Subject: Re: [RFC PATCH v6 2/2] nvmem: Add Vybrid OCOTP and OCROM support References: <1037424954.250728.1435087901102.JavaMail.open-xchange@oxbsltgw00.schlund.de> <20150624051903.GA11753@Sanchayan-Arch.toradex.int> <558A7EBE.5030108@i2se.com> <20150624104552.GA32208@Sanchayan-Arch.toradex.int> In-Reply-To: <20150624104552.GA32208@Sanchayan-Arch.toradex.int> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:3ZrD5b5dnUvWnmBkJATw+QCPm6Ey3aQAYm7ISmtNmoUWbYH+7xw jk6nowQD+ZJvtrK/8I9pKqUhLvXsDF7PLTFP3zC1E9HawXIqj5datt0XstV9VPOTB+LPme3 6QvtCCaiLkKXVNuoL5AhzpNdZUxXAmd0RrYgJk6eg1KlbtGkB30Atay1jDG037f3bb3KYqc CT0eu4CfS0wHxaxBDFbtw== X-UI-Out-Filterresults: notjunk:1;V01:K0:qR6zSkCLki8=:NHZHuwyB10Ok3J/XdYKeY6 Q73cxY0CRKXFQuaBI1qlAeD4NKzLm5uirOHIWTBVjw+4BUs5OHp3cp0WI/0qbNge1LvY1V0NB KDcPsAUVkO19QbZXcvlCFsMDlSX3Dtgt4w9vkvmmjVQdEIivsiKWJp6yDilBl6eedqMkqgO0Z Pyve42LpET1v35dGSGgSRBrmtnlDax+ImFcKUmF6f22FKBgNVOf4XUb+/nxSRXbZXFmgL4Cbk OVNrnPgOwcodvUFsx5R+t0QnifZ4QN4hZiDcdM72DlVKAC3M3l8xa0wAgloMML+6Yr0onk8Bq K+WsD6QgrT+D1A4FQ5bGrGDRCUjCaNczStoz/NWIrzkiGUv03lP6DhxBcMWPtRjawUqoaiJrP IO9E8p6MTk5gQPFTAE2dCTjx/Y9zo8t4hrG9drmnNE5gL48b3kSj88J9SPMSNhw58Jjqh9Bnq e8IhicozP1pot1y//4eNlvOo7qYpYPo6ndZatzm04eohjz9T/E18DCGTosJyYYmLCUbUIYRF1 N80iorL6gTWk2ZU7S7WE4qAlUr3UIvEgUdzrpMuqSBuql8/TTVD+Hy11vmRF8w/ocF9SL/P1G KYACiOIWs6qLXFYO9esjC2/ktYDGBMZT1ChHlFi5kIfqtcRQK06sToXbi+1R6qi31OlvzamhL CzdvuSXZ21VTj33ety4aso/Fb6rGrZLDOg5KJyY9Zc2sdr53TqiKd25nHVYDhDTy3DpBSnHkr qwxLXzlIHKCkV9Flceat7MmzjybHkDveQc8WnHF6/gUfexTggskVEH4bt9mI02mFF1yQkKB4k aQVAEfD/W5dD7Azhb94ZjQsJLGJxnAHPRJjVDwzDiHIaHHL1QAnWW0+ZQNTjt2aqejqM7Y3 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 >>>>> --- >>>>> 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