From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932201AbcDTNxO (ORCPT ); Wed, 20 Apr 2016 09:53:14 -0400 Received: from mail-bl2nam02on0061.outbound.protection.outlook.com ([104.47.38.61]:20288 "EHLO NAM02-BL2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751520AbcDTNxI convert rfc822-to-8bit (ORCPT ); Wed, 20 Apr 2016 09:53:08 -0400 Authentication-Results: spf=pass (sender IP is 149.199.60.83) smtp.mailfrom=xilinx.com; vger.kernel.org; dkim=none (message not signed) header.d=none;vger.kernel.org; dmarc=bestguesspass action=none header.from=xilinx.com; From: Anurag Kumar Vulisha To: Alexandre Belloni CC: Alessandro Zummo , Soren Brinkmann , Michal Simek , "rtc-linux@googlegroups.com" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Punnaiah Choudary Kalluri , Anirudha Sarangi , Srikanth Vemula , Srinivas Goud Subject: RE: [PATCH 3/3] RTC: Update seconds time programming logic Thread-Topic: [PATCH 3/3] RTC: Update seconds time programming logic Thread-Index: AQHRlLUSCjpso4UInESpOuGO8Xkd/Z+RZtCAgAENi8D//5C/gIAAoQDQ//+jW4CAAKBUwA== Date: Wed, 20 Apr 2016 13:37:30 +0000 Message-ID: <3802E9A6666DF54886E2B9CBF743BA9825E0B50C@XAP-PVEXMBX01.xlnx.xilinx.com> References: <1460463346-24923-1-git-send-email-anuragku@xilinx.com> <1460463346-24923-3-git-send-email-anuragku@xilinx.com> <20160419223109.GF29844@piout.net> <3802E9A6666DF54886E2B9CBF743BA9825E0B42B@XAP-PVEXMBX01.xlnx.xilinx.com> <20160420075741.GK29844@piout.net> <3802E9A6666DF54886E2B9CBF743BA9825E0B4BE@XAP-PVEXMBX01.xlnx.xilinx.com> <20160420120221.GR29844@piout.net> In-Reply-To: <20160420120221.GR29844@piout.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.23.97.204] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-RCIS-Action: ALLOW X-TM-AS-Product-Ver: IMSS-7.1.0.1224-8.0.0.1202-22272.005 X-TM-AS-User-Approved-Sender: Yes;Yes X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:149.199.60.83;IPV:NLI;CTRY:US;EFV:NLI;SFV:NSPM;SFS:(10009020)(6009001)(2980300002)(438002)(377454003)(199003)(13464003)(189002)(586003)(23726003)(1220700001)(2906002)(3846002)(1096002)(5004730100002)(102836003)(93886004)(33656002)(5003600100002)(11100500001)(92566002)(86362001)(5250100002)(87936001)(47776003)(6116002)(55846006)(15650500001)(2420400007)(4326007)(10710500007)(50466002)(81166005)(50986999)(46406003)(4001430100002)(97756001)(19580405001)(19580395003)(6806005)(5008740100001)(2920100001)(107886002)(110136002)(63266004)(106466001)(54356999)(106116001)(2950100001)(15975445007)(189998001)(76176999)(107986001)(18886065003);DIR:OUT;SFP:1101;SCL:1;SRVR:SN1NAM02HT044;H:xsj-pvapsmtpgw01;FPR:;SPF:Pass;MLV:sfv;A:1;MX:1;LANG:en; X-MS-Office365-Filtering-Correlation-Id: b14ba7c2-0bb9-43c8-0474-08d36920f318 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(8251501002);SRVR:SN1NAM02HT044; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(9101521026)(601004)(2401047)(8121501046)(13018025)(13017025)(5005006)(13024025)(13023025)(13015025)(3002001)(10201501046);SRVR:SN1NAM02HT044;BCL:0;PCL:0;RULEID:;SRVR:SN1NAM02HT044; X-Forefront-PRVS: 0918748D70 X-OriginatorOrg: xilinx.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Apr 2016 13:37:42.4710 (UTC) X-MS-Exchange-CrossTenant-Id: 657af505-d5df-48d0-8300-c31994686c5c X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=657af505-d5df-48d0-8300-c31994686c5c;Ip=[149.199.60.83];Helo=[xsj-pvapsmtpgw01] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT044 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > Cc: Alessandro Zummo ; Soren Brinkmann > ; Michal Simek ; rtc- > linux@googlegroups.com; linux-arm-kernel@lists.infradead.org; linux- > kernel@vger.kernel.org; Punnaiah Choudary Kalluri ; > Anirudha Sarangi ; Srikanth Vemula > ; Srinivas Goud > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Sender: rtc-linux@googlegroups.com Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0072.outbound.protection.outlook.com. [104.47.36.72]) by gmr-mx.google.com with ESMTPS id gg5si478277igb.0.2016.04.20.06.37.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Apr 2016 06:37:44 -0700 (PDT) From: Anurag Kumar Vulisha To: Alexandre Belloni CC: Alessandro Zummo , Soren Brinkmann , Michal Simek , "rtc-linux@googlegroups.com" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Punnaiah Choudary Kalluri , Anirudha Sarangi , Srikanth Vemula , Srinivas Goud Subject: [rtc-linux] RE: [PATCH 3/3] RTC: Update seconds time programming logic Date: Wed, 20 Apr 2016 13:37:30 +0000 Message-ID: <3802E9A6666DF54886E2B9CBF743BA9825E0B50C@XAP-PVEXMBX01.xlnx.xilinx.com> References: <1460463346-24923-1-git-send-email-anuragku@xilinx.com> <1460463346-24923-3-git-send-email-anuragku@xilinx.com> <20160419223109.GF29844@piout.net> <3802E9A6666DF54886E2B9CBF743BA9825E0B42B@XAP-PVEXMBX01.xlnx.xilinx.com> <20160420075741.GK29844@piout.net> <3802E9A6666DF54886E2B9CBF743BA9825E0B4BE@XAP-PVEXMBX01.xlnx.xilinx.com> <20160420120221.GR29844@piout.net> In-Reply-To: <20160420120221.GR29844@piout.net> Content-Type: text/plain; charset=UTF-8 MIME-Version: 1.0 Reply-To: rtc-linux@googlegroups.com List-ID: List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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 > Cc: Alessandro Zummo ; Soren Brinkmann > ; Michal Simek ; rtc- > linux@googlegroups.com; linux-arm-kernel@lists.infradead.org; linux- > kernel@vger.kernel.org; Punnaiah Choudary Kalluri ; > Anirudha Sarangi ; Srikanth Vemula > ; Srinivas Goud > 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: anurag.kumar.vulisha@xilinx.com (Anurag Kumar Vulisha) Date: Wed, 20 Apr 2016 13:37:30 +0000 Subject: [PATCH 3/3] RTC: Update seconds time programming logic In-Reply-To: <20160420120221.GR29844@piout.net> References: <1460463346-24923-1-git-send-email-anuragku@xilinx.com> <1460463346-24923-3-git-send-email-anuragku@xilinx.com> <20160419223109.GF29844@piout.net> <3802E9A6666DF54886E2B9CBF743BA9825E0B42B@XAP-PVEXMBX01.xlnx.xilinx.com> <20160420075741.GK29844@piout.net> <3802E9A6666DF54886E2B9CBF743BA9825E0B4BE@XAP-PVEXMBX01.xlnx.xilinx.com> <20160420120221.GR29844@piout.net> Message-ID: <3802E9A6666DF54886E2B9CBF743BA9825E0B50C@XAP-PVEXMBX01.xlnx.xilinx.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 > Cc: Alessandro Zummo ; Soren Brinkmann > ; Michal Simek ; rtc- > linux at googlegroups.com; linux-arm-kernel at lists.infradead.org; linux- > kernel at vger.kernel.org; Punnaiah Choudary Kalluri ; > Anirudha Sarangi ; Srikanth Vemula > ; Srinivas Goud > 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