All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Agner <stefan@agner.ch>
To: Stefan Wahren <stefan.wahren@i2se.com>
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
Date: Wed, 24 Jun 2015 13:20:56 +0200	[thread overview]
Message-ID: <1794e55295ed14ea397ca330f3b2b1a3@agner.ch> (raw)
In-Reply-To: <558A7EBE.5030108@i2se.com>

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 <maitysanchayan@gmail.com> 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@gmail.com>
>>>> ---
>>>> 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

WARNING: multiple messages have this Message-ID (diff)
From: stefan@agner.ch (Stefan Agner)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v6 2/2] nvmem: Add Vybrid OCOTP and OCROM support
Date: Wed, 24 Jun 2015 13:20:56 +0200	[thread overview]
Message-ID: <1794e55295ed14ea397ca330f3b2b1a3@agner.ch> (raw)
In-Reply-To: <558A7EBE.5030108@i2se.com>

On 2015-06-24 11:56, 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 <maitysanchayan@gmail.com> 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@gmail.com>
>>>> ---
>>>> 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

  parent reply	other threads:[~2015-06-24 11:23 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-23 13:44 [RFC PATCH v6 0/2] Implement NVMEM/SoC bus support for Vybrid Sanchayan Maity
2015-06-23 13:44 ` Sanchayan Maity
2015-06-23 13:44 ` [RFC PATCH v6 1/2] ARM: dts: vfxxx: Add OCOTP and OCROM nodes Sanchayan Maity
2015-06-23 13:44   ` Sanchayan Maity
2015-06-23 13:44 ` [RFC PATCH v6 2/2] nvmem: Add Vybrid OCOTP and OCROM support Sanchayan Maity
2015-06-23 13:44   ` Sanchayan Maity
2015-06-23 19:03   ` Srinivas Kandagatla
2015-06-23 19:03     ` Srinivas Kandagatla
2015-06-24  5:25     ` maitysanchayan
2015-06-24  5:25       ` maitysanchayan at gmail.com
2015-06-23 19:31   ` Stefan Wahren
2015-06-23 19:31     ` Stefan Wahren
2015-06-24  5:19     ` maitysanchayan
2015-06-24  5:19       ` maitysanchayan at gmail.com
2015-06-24  9:37       ` Srinivas Kandagatla
2015-06-24  9:37         ` Srinivas Kandagatla
2015-06-24  9:44         ` Sanchayan Maity
2015-06-24  9:44           ` Sanchayan Maity
2015-06-24  9:56       ` Stefan Wahren
2015-06-24  9:56         ` Stefan Wahren
2015-06-24 10:45         ` maitysanchayan
2015-06-24 10:45           ` maitysanchayan at gmail.com
2015-06-24 11:52           ` Stefan Wahren
2015-06-24 11:52             ` Stefan Wahren
2015-06-24 12:05             ` maitysanchayan
2015-06-24 12:05               ` maitysanchayan at gmail.com
2015-06-29 11:22             ` [RFC PATCH v6 0/3] Implement NVMEM/SoC bus support for Vybrid Sanchayan Maity
2015-06-29 11:22               ` Sanchayan Maity
2015-06-29 11:22               ` [RFC PATCH v6 1/3] clk: clk-vf610: Add clock for Vybrid OCOTP controller Sanchayan Maity
2015-06-29 11:22                 ` Sanchayan Maity
2015-06-29 11:22               ` [RFC PATCH v6 2/3] ARM: dts: vfxxx: Add OCOTP node Sanchayan Maity
2015-06-29 11:22                 ` Sanchayan Maity
2015-06-29 11:22               ` [RFC PATCH v6 3/3] drivers: nvmem: Add Vybrid OCOTP support Sanchayan Maity
2015-06-29 11:22                 ` Sanchayan Maity
2015-07-06 10:16                 ` Stefan Wahren
2015-07-06 10:16                   ` Stefan Wahren
2015-07-07  5:19                   ` maitysanchayan
2015-07-07  5:19                     ` maitysanchayan at gmail.com
2015-07-07 12:49                     ` Stefan Wahren
2015-07-07 12:49                       ` Stefan Wahren
2015-07-08  5:39                       ` maitysanchayan
2015-07-08  5:39                         ` maitysanchayan at gmail.com
2015-07-08 20:55                         ` Stefan Wahren
2015-07-08 20:55                           ` Stefan Wahren
2015-07-10 18:09                           ` maitysanchayan
2015-07-10 18:09                             ` maitysanchayan at gmail.com
2015-06-24 11:20         ` Stefan Agner [this message]
2015-06-24 11:20           ` [RFC PATCH v6 2/2] nvmem: Add Vybrid OCOTP and OCROM support Stefan Agner
2015-06-24  8:35   ` Maxime Ripard
2015-06-24  8:35     ` Maxime Ripard
2015-06-24  9:34     ` Srinivas Kandagatla
2015-06-24  9:34       ` Srinivas Kandagatla
2015-06-25 17:49       ` Maxime Ripard
2015-06-25 17:49         ` Maxime Ripard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1794e55295ed14ea397ca330f3b2b1a3@agner.ch \
    --to=stefan@agner.ch \
    --cc=arnd@arndb.de \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maitysanchayan@gmail.com \
    --cc=maxime.ripard@free-electrons.com \
    --cc=shawn.guo@linaro.org \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=stefan.wahren@i2se.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.