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. >
next prev parent 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: linkBe 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.