All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keerthy <j-keerthy@ti.com>
To: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: Sekhar Nori <nsekhar@ti.com>, <linux-rtc@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	Linux OMAP List <linux-omap@vger.kernel.org>
Subject: Re: [PATCH] rtc: omap: Support scratch registers
Date: Wed, 8 Nov 2017 14:01:37 +0530	[thread overview]
Message-ID: <79f52c27-1c6a-c4ec-9635-d05eec635661@ti.com> (raw)
In-Reply-To: <20171108082145.kpd3c45x5skce5wd@piout.net>



On Wednesday 08 November 2017 01:51 PM, Alexandre Belloni wrote:
> On 08/11/2017 at 13:36:15 +0530, Keerthy wrote:
>>
>>
>> On Wednesday 08 November 2017 12:46 PM, Alexandre Belloni wrote:
>>> On 08/11/2017 at 12:38:05 +0530, Keerthy wrote:
>>>>
>>>>
>>>> On Wednesday 08 November 2017 11:57 AM, Alexandre Belloni wrote:
>>>>> Hi,
>>>>>
>>>>> On 08/11/2017 at 11:30:45 +0530, Keerthy wrote:
>>>>>>>>> +static int omap_rtc_scratch_read(void *priv, unsigned int offset, void *_val,
>>>>>>>>> +				 size_t bytes)
>>>>>>>>> +{
>>>>>>>>> +	struct omap_rtc	*rtc = priv;
>>>>>>>>> +	u32 *val = _val;
>>>>>>>>> +	int i;
>>>>>>>>> +
>>>>>>>>> +	for (i = 0; i < bytes / 4; i++)
>>>>>>>>> +		val[i] = rtc_readl(rtc,
>>>>>>>>> +				   OMAP_RTC_SCRATCH0_REG + offset + (i * 4));
>>>>>>
>>>>>> Can the offset be the Scratch register number instead of bytes offset?
>>>>>> More intuitive to me.
>>>>>>
>>>>>> So that one can request using offset as 0, 1, 2 instead of 0, 4, 8?
>>>>>>
>>>>>
>>>>> Well, the offset is coming from the nvmem core, itself getting it from
>>>>> the Linux file API (and it is in bytes). However, you have the guarantee
>>>>> that it will be aligned on a word, see:
>>>>> http://elixir.free-electrons.com/linux/latest/source/drivers/nvmem/core.c#L88
>>>>
>>>> Okay Alexandre. Thanks for clarifying. Looks good to me.
>>>> I have tested on AM437X-GP-EVM.
>>>>
>>>
>>> If needed, you can define nvmem cells (and I guess that is what you
>>> want):
>>> http://elixir.free-electrons.com/linux/latest/source/Documentation/devicetree/bindings/nvmem/nvmem.txt
>>
>> With this patch we cannot still use nvmem_device_write and
>> nvmem_device_read as the nvmem_device is still not registered.
>>
>> How can a driver write to scratch pad registers? Should we be calling
>> nvmem_register in the probe?
> 
> It is not needed, it is registered by rtc_nvmem_register().

Let me go through the chain:

rtc_register_device -> __rtc_register_device --> rtc_nvmem_register ->
rtc_nvram_register

I am seeing that for rtc-omap driver there is rtc_register_device call
and i see that rtc_nvmem_register is not getting called.

Should we add rtc_register_device in probe of rtc-omap?

> 
> nvmem_device_read/write are working because that is what I'm using to
> implement the old sysfs ABI with rtc_nvram_read/write.
> 

WARNING: multiple messages have this Message-ID (diff)
From: Keerthy <j-keerthy@ti.com>
To: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: Sekhar Nori <nsekhar@ti.com>,
	linux-rtc@vger.kernel.org, linux-kernel@vger.kernel.org,
	Linux OMAP List <linux-omap@vger.kernel.org>
Subject: Re: [PATCH] rtc: omap: Support scratch registers
Date: Wed, 8 Nov 2017 14:01:37 +0530	[thread overview]
Message-ID: <79f52c27-1c6a-c4ec-9635-d05eec635661@ti.com> (raw)
In-Reply-To: <20171108082145.kpd3c45x5skce5wd@piout.net>



On Wednesday 08 November 2017 01:51 PM, Alexandre Belloni wrote:
> On 08/11/2017 at 13:36:15 +0530, Keerthy wrote:
>>
>>
>> On Wednesday 08 November 2017 12:46 PM, Alexandre Belloni wrote:
>>> On 08/11/2017 at 12:38:05 +0530, Keerthy wrote:
>>>>
>>>>
>>>> On Wednesday 08 November 2017 11:57 AM, Alexandre Belloni wrote:
>>>>> Hi,
>>>>>
>>>>> On 08/11/2017 at 11:30:45 +0530, Keerthy wrote:
>>>>>>>>> +static int omap_rtc_scratch_read(void *priv, unsigned int offset, void *_val,
>>>>>>>>> +				 size_t bytes)
>>>>>>>>> +{
>>>>>>>>> +	struct omap_rtc	*rtc = priv;
>>>>>>>>> +	u32 *val = _val;
>>>>>>>>> +	int i;
>>>>>>>>> +
>>>>>>>>> +	for (i = 0; i < bytes / 4; i++)
>>>>>>>>> +		val[i] = rtc_readl(rtc,
>>>>>>>>> +				   OMAP_RTC_SCRATCH0_REG + offset + (i * 4));
>>>>>>
>>>>>> Can the offset be the Scratch register number instead of bytes offset?
>>>>>> More intuitive to me.
>>>>>>
>>>>>> So that one can request using offset as 0, 1, 2 instead of 0, 4, 8?
>>>>>>
>>>>>
>>>>> Well, the offset is coming from the nvmem core, itself getting it from
>>>>> the Linux file API (and it is in bytes). However, you have the guarantee
>>>>> that it will be aligned on a word, see:
>>>>> http://elixir.free-electrons.com/linux/latest/source/drivers/nvmem/core.c#L88
>>>>
>>>> Okay Alexandre. Thanks for clarifying. Looks good to me.
>>>> I have tested on AM437X-GP-EVM.
>>>>
>>>
>>> If needed, you can define nvmem cells (and I guess that is what you
>>> want):
>>> http://elixir.free-electrons.com/linux/latest/source/Documentation/devicetree/bindings/nvmem/nvmem.txt
>>
>> With this patch we cannot still use nvmem_device_write and
>> nvmem_device_read as the nvmem_device is still not registered.
>>
>> How can a driver write to scratch pad registers? Should we be calling
>> nvmem_register in the probe?
> 
> It is not needed, it is registered by rtc_nvmem_register().

Let me go through the chain:

rtc_register_device -> __rtc_register_device --> rtc_nvmem_register ->
rtc_nvram_register

I am seeing that for rtc-omap driver there is rtc_register_device call
and i see that rtc_nvmem_register is not getting called.

Should we add rtc_register_device in probe of rtc-omap?

> 
> nvmem_device_read/write are working because that is what I'm using to
> implement the old sysfs ABI with rtc_nvram_read/write.
> 

  reply	other threads:[~2017-11-08  8:32 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-31 16:27 [PATCH] rtc: omap: Support scratch registers Alexandre Belloni
2017-11-06  6:55 ` Sekhar Nori
2017-11-06  6:55   ` Sekhar Nori
2017-11-06  6:59   ` Keerthy
2017-11-06  6:59     ` Keerthy
2017-11-06  7:02     ` Sekhar Nori
2017-11-06  7:02       ` Sekhar Nori
2017-11-08  6:00     ` Keerthy
2017-11-08  6:00       ` Keerthy
2017-11-08  6:27       ` Alexandre Belloni
2017-11-08  7:08         ` Keerthy
2017-11-08  7:08           ` Keerthy
2017-11-08  7:16           ` Alexandre Belloni
2017-11-08  8:06             ` Keerthy
2017-11-08  8:06               ` Keerthy
2017-11-08  8:21               ` Alexandre Belloni
2017-11-08  8:31                 ` Keerthy [this message]
2017-11-08  8:31                   ` Keerthy
2017-11-08  8:32                   ` Keerthy
2017-11-08  8:32                     ` Keerthy
2017-11-08  8:35                     ` Alexandre Belloni
2017-11-08  8:48                       ` Keerthy
2017-11-08  8:48                         ` Keerthy

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=79f52c27-1c6a-c4ec-9635-d05eec635661@ti.com \
    --to=j-keerthy@ti.com \
    --cc=alexandre.belloni@free-electrons.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-rtc@vger.kernel.org \
    --cc=nsekhar@ti.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.