Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752749AbbFXMHr (ORCPT ); Wed, 24 Jun 2015 08:07:47 -0400 Received: from mail-pa0-f51.google.com ([209.85.220.51]:33033 "EHLO mail-pa0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752690AbbFXMHq (ORCPT ); Wed, 24 Jun 2015 08:07:46 -0400 Date: Wed, 24 Jun 2015 17:35:00 +0530 From: maitysanchayan@gmail.com To: Stefan Wahren 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 Message-ID: <20150624120500.GB32208@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> <558A99FC.2070902@i2se.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <558A99FC.2070902@i2se.com> User-Agent: Mutt/1.5.23+89 (0255b37be491) (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4487 Lines: 126 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 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. 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/