Re: [rtc-linux] [PATCH 1/3] rtc: omap: Unlock and Lock rtc registers before and after register writes

2015-04-02 Thread Lokesh Vutla
Hi,

On Wednesday 01 April 2015 09:22 PM, Alexandre Belloni wrote:
 Hi,
 
 On 01/04/2015 at 11:24:56 +0530, Lokesh Vutla wrote :
 RTC module contains a kicker mechanism to prevent any spurious writes
 from changing the register values. This mechanism requires two MMR
 writes to the KICK0 and KICK1 registers with exact data values
 before the kicker lock mechanism is released.

 Currently the driver release the lock in the probe and leaves it enabled
 until the rtc driver removal. This eliminates the idea of preventing
 spurious writes when RTC driver is loaded.
 So implement rtc lock and unlock functions before and after register writes.

 Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
 ---
 - This is as advised by Paul to implement lock and unlock functions in
   the driver and not to unlock and leave it in probe.
   The same discussion can be seen here:
   http://www.mail-archive.com/linux-omap%40vger.kernel.org/msg111588.html

  drivers/rtc/rtc-omap.c | 46 ++
  1 file changed, 38 insertions(+), 8 deletions(-)

 diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
 index 8e5851a..96cc613 100644
 --- a/drivers/rtc/rtc-omap.c
 +++ b/drivers/rtc/rtc-omap.c
 @@ -156,6 +156,22 @@ static inline void rtc_writel(struct omap_rtc *rtc, 
 unsigned int reg, u32 val)
  writel(val, rtc-base + reg);
  }
  
 +static void rtc_unlock(struct omap_rtc *rtc)
 +{
 +if (rtc-type-has_kicker) {
 
 Instead of testing for has_kicker each time, I would add .lock and
 .unlock to omap_rtc_device_type and directly use rtc-type-lock and
 rtc-type-unlock.
Makes sense. I have posted v2 of my series updating this.

Thanks and regards,
Lokesh
 
 +rtc_writel(rtc, OMAP_RTC_KICK0_REG, KICK0_VALUE);
 +rtc_writel(rtc, OMAP_RTC_KICK1_REG, KICK1_VALUE);
 +}
 +}
 +

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [rtc-linux] [PATCH 1/3] rtc: omap: Unlock and Lock rtc registers before and after register writes

2015-04-01 Thread Alexandre Belloni
Hi,

On 01/04/2015 at 11:24:56 +0530, Lokesh Vutla wrote :
 RTC module contains a kicker mechanism to prevent any spurious writes
 from changing the register values. This mechanism requires two MMR
 writes to the KICK0 and KICK1 registers with exact data values
 before the kicker lock mechanism is released.
 
 Currently the driver release the lock in the probe and leaves it enabled
 until the rtc driver removal. This eliminates the idea of preventing
 spurious writes when RTC driver is loaded.
 So implement rtc lock and unlock functions before and after register writes.
 
 Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
 ---
 - This is as advised by Paul to implement lock and unlock functions in
   the driver and not to unlock and leave it in probe.
   The same discussion can be seen here:
   http://www.mail-archive.com/linux-omap%40vger.kernel.org/msg111588.html
 
  drivers/rtc/rtc-omap.c | 46 ++
  1 file changed, 38 insertions(+), 8 deletions(-)
 
 diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
 index 8e5851a..96cc613 100644
 --- a/drivers/rtc/rtc-omap.c
 +++ b/drivers/rtc/rtc-omap.c
 @@ -156,6 +156,22 @@ static inline void rtc_writel(struct omap_rtc *rtc, 
 unsigned int reg, u32 val)
   writel(val, rtc-base + reg);
  }
  
 +static void rtc_unlock(struct omap_rtc *rtc)
 +{
 + if (rtc-type-has_kicker) {

Instead of testing for has_kicker each time, I would add .lock and
.unlock to omap_rtc_device_type and directly use rtc-type-lock and
rtc-type-unlock.

 + rtc_writel(rtc, OMAP_RTC_KICK0_REG, KICK0_VALUE);
 + rtc_writel(rtc, OMAP_RTC_KICK1_REG, KICK1_VALUE);
 + }
 +}
 +
-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html