All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anurag Kumar Vulisha <anurag.kumar.vulisha@xilinx.com>
To: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>,
	Soren Brinkmann <sorenb@xilinx.com>,
	Michal Simek <michals@xilinx.com>,
	"rtc-linux@googlegroups.com" <rtc-linux@googlegroups.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Punnaiah Choudary Kalluri <punnaia@xilinx.com>,
	Anirudha Sarangi <anirudh@xilinx.com>,
	Srikanth Vemula <svemula@xilinx.com>,
	Srinivas Goud <sgoud@xilinx.com>
Subject: RE: [PATCH 3/3] RTC: Update seconds time programming logic
Date: Wed, 20 Apr 2016 13:37:30 +0000	[thread overview]
Message-ID: <3802E9A6666DF54886E2B9CBF743BA9825E0B50C@XAP-PVEXMBX01.xlnx.xilinx.com> (raw)
In-Reply-To: <20160420120221.GR29844@piout.net>

Hi Alexandre,

Thanks for reviewing the patch, I will sent v2 with the changes updated.

Thanks,
Anurag Kumar V

> -----Original Message-----
> From: Alexandre Belloni [mailto:alexandre.belloni@free-electrons.com]
> Sent: Wednesday, April 20, 2016 5:32 PM
> To: Anurag Kumar Vulisha <anuragku@xilinx.com>
> Cc: Alessandro Zummo <a.zummo@towertech.it>; Soren Brinkmann
> <sorenb@xilinx.com>; Michal Simek <michals@xilinx.com>; rtc-
> linux@googlegroups.com; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; Punnaiah Choudary Kalluri <punnaia@xilinx.com>;
> Anirudha Sarangi <anirudh@xilinx.com>; Srikanth Vemula
> <svemula@xilinx.com>; Srinivas Goud <sgoud@xilinx.com>
> Subject: Re: [PATCH 3/3] RTC: Update seconds time programming logic
> 
> On 20/04/2016 at 10:31:06 +0000, Anurag Kumar Vulisha wrote :
> > > Yeas, I understood that. But my question was whether the interrupt
> > > handling was necessary at all.
> > > Instead of waiting for an interrupt to set time_updated, can't you
> > > simply read RTC_INT_STS and check for the RTC_INT_SEC bit in
> > > xlnx_rtc_read_time() ?
> > >
> > > Something like:
> > >
> > > status = readl(xrtcdev->reg_base + RTC_INT_STS) if (status &
> RTC_INT_SEC)
> > >       rtc_time64_to_tm(readl(xrtcdev->reg_base + RTC_CUR_TM), tm);
> > > else
> > >       rtc_time64_to_tm(readl(xrtcdev->reg_base + RTC_SET_TM_RD) - 1,
> > > tm);
> > >
> > > It all depends on whether the RTC_INT_SEC bit in RTC_INT_STS is
> > > being updated even when it is not enabled as an interrupt.
> > >
> >
> > The above said logic will work if we doesn't clear the RTC_INT_STS
> > register after the RTC_INT_SEC bit is set, this happens only if
> > interrupts are not enabled. If interrupts are enabled we will be clearing the
> RTC_INT_STS every time in the interrupt handler.
> > And moreover we need to return time from RTC_SET_TM_RD only if time is
> > requested within 1 sec span after programming the time only , so this is
> required only for one time.
> > Since we are clearing the RTC_INT_STS in our interrupt handler, we
> > might end up in giving the wrong time to the user when requested.So I
> think this logic might not work.
> > Please correct me if am wrong.
> >
> 
> Simply stop clearing RTC_INT_SEC from RTC_INT_STS in the interrupt
> handler.
> 
> You can also remove
> 	if (status & RTC_INT_SEC)
> 		rtc_update_irq(xrtcdev->rtc, 1, RTC_IRQF | RTC_UF);
> 
> as it will not be used. Update interrupts are handled by the core using timers
> anyway. And as you can see, there was no code enabling RTC_INT_SEC in
> RTC_INT_EN before your patch.
> 
> --
> Alexandre Belloni, Free Electrons
> Embedded Linux, Kernel and Android engineering http://free-electrons.com

WARNING: multiple messages have this Message-ID (diff)
From: Anurag Kumar Vulisha <anurag.kumar.vulisha@xilinx.com>
To: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>,
	Soren Brinkmann <sorenb@xilinx.com>,
	Michal Simek <michals@xilinx.com>,
	"rtc-linux@googlegroups.com" <rtc-linux@googlegroups.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Punnaiah Choudary Kalluri <punnaia@xilinx.com>,
	Anirudha Sarangi <anirudh@xilinx.com>,
	Srikanth Vemula <svemula@xilinx.com>,
	Srinivas Goud <sgoud@xilinx.com>
Subject: [rtc-linux] RE: [PATCH 3/3] RTC: Update seconds time programming logic
Date: Wed, 20 Apr 2016 13:37:30 +0000	[thread overview]
Message-ID: <3802E9A6666DF54886E2B9CBF743BA9825E0B50C@XAP-PVEXMBX01.xlnx.xilinx.com> (raw)
In-Reply-To: <20160420120221.GR29844@piout.net>

Hi Alexandre,

Thanks for reviewing the patch, I will sent v2 with the changes updated.

Thanks,
Anurag Kumar V

> -----Original Message-----
> From: Alexandre Belloni [mailto:alexandre.belloni@free-electrons.com]
> Sent: Wednesday, April 20, 2016 5:32 PM
> To: Anurag Kumar Vulisha <anuragku@xilinx.com>
> Cc: Alessandro Zummo <a.zummo@towertech.it>; Soren Brinkmann
> <sorenb@xilinx.com>; Michal Simek <michals@xilinx.com>; rtc-
> linux@googlegroups.com; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; Punnaiah Choudary Kalluri <punnaia@xilinx.com>;
> Anirudha Sarangi <anirudh@xilinx.com>; Srikanth Vemula
> <svemula@xilinx.com>; Srinivas Goud <sgoud@xilinx.com>
> Subject: Re: [PATCH 3/3] RTC: Update seconds time programming logic
> 
> On 20/04/2016 at 10:31:06 +0000, Anurag Kumar Vulisha wrote :
> > > Yeas, I understood that. But my question was whether the interrupt
> > > handling was necessary at all.
> > > Instead of waiting for an interrupt to set time_updated, can't you
> > > simply read RTC_INT_STS and check for the RTC_INT_SEC bit in
> > > xlnx_rtc_read_time() ?
> > >
> > > Something like:
> > >
> > > status = readl(xrtcdev->reg_base + RTC_INT_STS) if (status &
> RTC_INT_SEC)
> > >       rtc_time64_to_tm(readl(xrtcdev->reg_base + RTC_CUR_TM), tm);
> > > else
> > >       rtc_time64_to_tm(readl(xrtcdev->reg_base + RTC_SET_TM_RD) - 1,
> > > tm);
> > >
> > > It all depends on whether the RTC_INT_SEC bit in RTC_INT_STS is
> > > being updated even when it is not enabled as an interrupt.
> > >
> >
> > The above said logic will work if we doesn't clear the RTC_INT_STS
> > register after the RTC_INT_SEC bit is set, this happens only if
> > interrupts are not enabled. If interrupts are enabled we will be clearing the
> RTC_INT_STS every time in the interrupt handler.
> > And moreover we need to return time from RTC_SET_TM_RD only if time is
> > requested within 1 sec span after programming the time only , so this is
> required only for one time.
> > Since we are clearing the RTC_INT_STS in our interrupt handler, we
> > might end up in giving the wrong time to the user when requested.So I
> think this logic might not work.
> > Please correct me if am wrong.
> >
> 
> Simply stop clearing RTC_INT_SEC from RTC_INT_STS in the interrupt
> handler.
> 
> You can also remove
> 	if (status & RTC_INT_SEC)
> 		rtc_update_irq(xrtcdev->rtc, 1, RTC_IRQF | RTC_UF);
> 
> as it will not be used. Update interrupts are handled by the core using timers
> anyway. And as you can see, there was no code enabling RTC_INT_SEC in
> RTC_INT_EN before your patch.
> 
> --
> Alexandre Belloni, Free Electrons
> Embedded Linux, Kernel and Android engineering http://free-electrons.com

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

WARNING: multiple messages have this Message-ID (diff)
From: anurag.kumar.vulisha@xilinx.com (Anurag Kumar Vulisha)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/3] RTC: Update seconds time programming logic
Date: Wed, 20 Apr 2016 13:37:30 +0000	[thread overview]
Message-ID: <3802E9A6666DF54886E2B9CBF743BA9825E0B50C@XAP-PVEXMBX01.xlnx.xilinx.com> (raw)
In-Reply-To: <20160420120221.GR29844@piout.net>

Hi Alexandre,

Thanks for reviewing the patch, I will sent v2 with the changes updated.

Thanks,
Anurag Kumar V

> -----Original Message-----
> From: Alexandre Belloni [mailto:alexandre.belloni at free-electrons.com]
> Sent: Wednesday, April 20, 2016 5:32 PM
> To: Anurag Kumar Vulisha <anuragku@xilinx.com>
> Cc: Alessandro Zummo <a.zummo@towertech.it>; Soren Brinkmann
> <sorenb@xilinx.com>; Michal Simek <michals@xilinx.com>; rtc-
> linux at googlegroups.com; linux-arm-kernel at lists.infradead.org; linux-
> kernel at vger.kernel.org; Punnaiah Choudary Kalluri <punnaia@xilinx.com>;
> Anirudha Sarangi <anirudh@xilinx.com>; Srikanth Vemula
> <svemula@xilinx.com>; Srinivas Goud <sgoud@xilinx.com>
> Subject: Re: [PATCH 3/3] RTC: Update seconds time programming logic
> 
> On 20/04/2016 at 10:31:06 +0000, Anurag Kumar Vulisha wrote :
> > > Yeas, I understood that. But my question was whether the interrupt
> > > handling was necessary at all.
> > > Instead of waiting for an interrupt to set time_updated, can't you
> > > simply read RTC_INT_STS and check for the RTC_INT_SEC bit in
> > > xlnx_rtc_read_time() ?
> > >
> > > Something like:
> > >
> > > status = readl(xrtcdev->reg_base + RTC_INT_STS) if (status &
> RTC_INT_SEC)
> > >       rtc_time64_to_tm(readl(xrtcdev->reg_base + RTC_CUR_TM), tm);
> > > else
> > >       rtc_time64_to_tm(readl(xrtcdev->reg_base + RTC_SET_TM_RD) - 1,
> > > tm);
> > >
> > > It all depends on whether the RTC_INT_SEC bit in RTC_INT_STS is
> > > being updated even when it is not enabled as an interrupt.
> > >
> >
> > The above said logic will work if we doesn't clear the RTC_INT_STS
> > register after the RTC_INT_SEC bit is set, this happens only if
> > interrupts are not enabled. If interrupts are enabled we will be clearing the
> RTC_INT_STS every time in the interrupt handler.
> > And moreover we need to return time from RTC_SET_TM_RD only if time is
> > requested within 1 sec span after programming the time only , so this is
> required only for one time.
> > Since we are clearing the RTC_INT_STS in our interrupt handler, we
> > might end up in giving the wrong time to the user when requested.So I
> think this logic might not work.
> > Please correct me if am wrong.
> >
> 
> Simply stop clearing RTC_INT_SEC from RTC_INT_STS in the interrupt
> handler.
> 
> You can also remove
> 	if (status & RTC_INT_SEC)
> 		rtc_update_irq(xrtcdev->rtc, 1, RTC_IRQF | RTC_UF);
> 
> as it will not be used. Update interrupts are handled by the core using timers
> anyway. And as you can see, there was no code enabling RTC_INT_SEC in
> RTC_INT_EN before your patch.
> 
> --
> Alexandre Belloni, Free Electrons
> Embedded Linux, Kernel and Android engineering http://free-electrons.com

  reply	other threads:[~2016-04-20 13:53 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-12 12:15 [PATCH 1/3] RTC: Enable RTC switching to battery power when VCC_PSAUX is N/A Anurag Kumar Vulisha
2016-04-12 12:15 ` Anurag Kumar Vulisha
2016-04-12 12:15 ` [rtc-linux] " Anurag Kumar Vulisha
2016-04-12 12:15 ` [PATCH 2/3] RTC: Write Calibration value before set time Anurag Kumar Vulisha
2016-04-12 12:15   ` Anurag Kumar Vulisha
2016-04-12 12:15   ` [rtc-linux] " Anurag Kumar Vulisha
2016-04-19 22:39   ` Alexandre Belloni
2016-04-19 22:39     ` Alexandre Belloni
2016-04-19 22:39     ` [rtc-linux] " Alexandre Belloni
2016-04-12 12:15 ` [PATCH 3/3] RTC: Update seconds time programming logic Anurag Kumar Vulisha
2016-04-12 12:15   ` Anurag Kumar Vulisha
2016-04-12 12:15   ` [rtc-linux] " Anurag Kumar Vulisha
2016-04-19 22:31   ` Alexandre Belloni
2016-04-19 22:31     ` Alexandre Belloni
2016-04-19 22:31     ` [rtc-linux] " Alexandre Belloni
2016-04-20  7:10     ` Anurag Kumar Vulisha
2016-04-20  7:10       ` Anurag Kumar Vulisha
2016-04-20  7:10       ` [rtc-linux] " Anurag Kumar Vulisha
2016-04-20  7:57       ` Alexandre Belloni
2016-04-20  7:57         ` Alexandre Belloni
2016-04-20  7:57         ` [rtc-linux] " Alexandre Belloni
2016-04-20 10:31         ` Anurag Kumar Vulisha
2016-04-20 10:31           ` Anurag Kumar Vulisha
2016-04-20 10:31           ` [rtc-linux] " Anurag Kumar Vulisha
2016-04-20 12:02           ` Alexandre Belloni
2016-04-20 12:02             ` Alexandre Belloni
2016-04-20 12:02             ` [rtc-linux] " Alexandre Belloni
2016-04-20 13:37             ` Anurag Kumar Vulisha [this message]
2016-04-20 13:37               ` Anurag Kumar Vulisha
2016-04-20 13:37               ` [rtc-linux] " Anurag Kumar Vulisha
2016-04-19 22:37 ` [PATCH 1/3] RTC: Enable RTC switching to battery power when VCC_PSAUX is N/A Alexandre Belloni
2016-04-19 22:37   ` Alexandre Belloni
2016-04-19 22:37   ` [rtc-linux] " Alexandre Belloni

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=3802E9A6666DF54886E2B9CBF743BA9825E0B50C@XAP-PVEXMBX01.xlnx.xilinx.com \
    --to=anurag.kumar.vulisha@xilinx.com \
    --cc=a.zummo@towertech.it \
    --cc=alexandre.belloni@free-electrons.com \
    --cc=anirudh@xilinx.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michals@xilinx.com \
    --cc=punnaia@xilinx.com \
    --cc=rtc-linux@googlegroups.com \
    --cc=sgoud@xilinx.com \
    --cc=sorenb@xilinx.com \
    --cc=svemula@xilinx.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.