Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752434AbbFXLXe (ORCPT ); Wed, 24 Jun 2015 07:23:34 -0400 Received: from mail.kmu-office.ch ([178.209.48.109]:58294 "EHLO mail.kmu-office.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751024AbbFXLX0 (ORCPT ); Wed, 24 Jun 2015 07:23:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Date: Wed, 24 Jun 2015 13:20:56 +0200 From: Stefan Agner To: Stefan Wahren Cc: maitysanchayan@gmail.com, srinivas.kandagatla@linaro.org, maxime.ripard@free-electrons.com, linux-arm-kernel@lists.infradead.org, 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 In-Reply-To: <558A7EBE.5030108@i2se.com> References: <1037424954.250728.1435087901102.JavaMail.open-xchange@oxbsltgw00.schlund.de> <20150624051903.GA11753@Sanchayan-Arch.toradex.int> <558A7EBE.5030108@i2se.com> Message-ID: <1794e55295ed14ea397ca330f3b2b1a3@agner.ch> User-Agent: Roundcube Webmail/1.1.2 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2746 Lines: 78 On 2015-06-24 11:56, 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. > > It possible that it works in your case. But in the case the lock bits > are set the driver won't work correctly. The OCOTP represents fuses, starting from 0x400A5400 one can access the shadowed registers containing the fuses values. The reference manual also says: "All shadow registers are always readable through the APB bus except some secret key" The driver does not need write access. I guess it is fine to use only reads through regmap...? -- Stefan -- 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/