All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Grygorii.Strashko@linaro.org" <grygorii.strashko@linaro.org>
To: Nishanth Menon <nm@ti.com>,
	Alexandre Belloni <alexandre.belloni@free-electrons.com>,
	Alessandro Zummo <a.zummo@towertech.it>
Cc: linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org,
	rtc-linux@googlegroups.com
Subject: Re: [PATCH V2] drivers/rtc/rtc-ds1307.c: Enable the mcp794xx alarm after programming time
Date: Wed, 22 Apr 2015 16:26:01 +0300	[thread overview]
Message-ID: <5537A169.206@linaro.org> (raw)
In-Reply-To: <1429577494-15087-1-git-send-email-nm@ti.com>

Hi,

On 04/21/2015 03:51 AM, Nishanth Menon wrote:
> Alarm interrupt enable register is at offset 0x7, while the time
> registers for the alarm follow that. When we program Alarm interrupt
> enable prior to programming the time, it is possible that previous
> time value could be close or match at the time of alarm enable
> resulting in interrupt trigger which is unexpected (and does not match
> the time we expect it to trigger).
> 
> To prevent this scenario from occuring, program the ALM0_EN bit only
> after the alarm time is appropriately programmed.
> 
> Ofcourse, I2C programming is non-atomic, so there are loopholes where
> the interrupt wont trigger if the time requested is in the past at
> the time of programming the ALM0_EN bit. However, we will not have
> unexpected interrupts while the time is programmed after the interrupt
> are enabled.

I think it will be nice if you will mention that you going to follow
vendor recommendations - AN1491 Configuring the MCP794XX RTCC Family
http://ww1.microchip.com/downloads/en/AppNotes/01491A.pdf
;)
"Also, it is recommended that the alarm registers be loaded
before the alarm is enabled."

> 
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> Changes in v2:
> 	- minor typo fix in comments
> 	- merged up code that I missed committing in
> 
> V1: https://patchwork.kernel.org/patch/6245041/
> 
>   drivers/rtc/rtc-ds1307.c |   12 ++++++------
>   1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
> index 4ffabb322a9a..3cd4783375a5 100644
> --- a/drivers/rtc/rtc-ds1307.c
> +++ b/drivers/rtc/rtc-ds1307.c
> @@ -742,17 +742,17 @@ static int mcp794xx_set_alarm(struct device *dev, struct rtc_wkalrm *t)
>   	regs[6] &= ~MCP794XX_BIT_ALMX_IF;
>   	/* Set alarm match: second, minute, hour, day, date, month. */
>   	regs[6] |= MCP794XX_MSK_ALMX_MATCH;
> -
> -	if (t->enabled)
> -		regs[0] |= MCP794XX_BIT_ALM0_EN;
> -	else
> -		regs[0] &= ~MCP794XX_BIT_ALM0_EN;
> +	/* Disable interrupt. We will not enable until completely programmed */
> +	regs[0] &= ~MCP794XX_BIT_ALM0_EN;
>   
>   	ret = ds1307->write_block_data(client, MCP794XX_REG_CONTROL, 10, regs);
>   	if (ret < 0)
>   		return ret;
>   
> -	return 0;
> +	if (!t->enabled)
> +		return 0;
> +	regs[0] |= MCP794XX_BIT_ALM0_EN;
> +	return i2c_smbus_write_byte_data(client, MCP794XX_REG_CONTROL, regs[0]);

So, It seems, that right sequence should be:
- disable alarmX
- read alarmX regs
- configure alarmX regs
- load alarmX regs
- enable alarmX

More over, looks like, alarm/alarm IRQ should be enabled/disabled separately from set_alarm/RTC_ALM_SET
by RTC_AIE_ON, RTC_AIE_OFF. Should it?

>   }
>   
>   static int mcp794xx_alarm_irq_enable(struct device *dev, unsigned int enabled)
> 


-- 
regards,
-grygorii

WARNING: multiple messages have this Message-ID (diff)
From: "Grygorii.Strashko@linaro.org" <grygorii.strashko@linaro.org>
To: Nishanth Menon <nm@ti.com>,
	Alexandre Belloni <alexandre.belloni@free-electrons.com>,
	Alessandro Zummo <a.zummo@towertech.it>
Cc: linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org,
	rtc-linux@googlegroups.com
Subject: [rtc-linux] Re: [PATCH V2] drivers/rtc/rtc-ds1307.c: Enable the mcp794xx alarm after programming time
Date: Wed, 22 Apr 2015 16:26:01 +0300	[thread overview]
Message-ID: <5537A169.206@linaro.org> (raw)
In-Reply-To: <1429577494-15087-1-git-send-email-nm@ti.com>

Hi,

On 04/21/2015 03:51 AM, Nishanth Menon wrote:
> Alarm interrupt enable register is at offset 0x7, while the time
> registers for the alarm follow that. When we program Alarm interrupt
> enable prior to programming the time, it is possible that previous
> time value could be close or match at the time of alarm enable
> resulting in interrupt trigger which is unexpected (and does not match
> the time we expect it to trigger).
> 
> To prevent this scenario from occuring, program the ALM0_EN bit only
> after the alarm time is appropriately programmed.
> 
> Ofcourse, I2C programming is non-atomic, so there are loopholes where
> the interrupt wont trigger if the time requested is in the past at
> the time of programming the ALM0_EN bit. However, we will not have
> unexpected interrupts while the time is programmed after the interrupt
> are enabled.

I think it will be nice if you will mention that you going to follow
vendor recommendations - AN1491 Configuring the MCP794XX RTCC Family
http://ww1.microchip.com/downloads/en/AppNotes/01491A.pdf
;)
"Also, it is recommended that the alarm registers be loaded
before the alarm is enabled."

> 
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> Changes in v2:
> 	- minor typo fix in comments
> 	- merged up code that I missed committing in
> 
> V1: https://patchwork.kernel.org/patch/6245041/
> 
>   drivers/rtc/rtc-ds1307.c |   12 ++++++------
>   1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
> index 4ffabb322a9a..3cd4783375a5 100644
> --- a/drivers/rtc/rtc-ds1307.c
> +++ b/drivers/rtc/rtc-ds1307.c
> @@ -742,17 +742,17 @@ static int mcp794xx_set_alarm(struct device *dev, struct rtc_wkalrm *t)
>   	regs[6] &= ~MCP794XX_BIT_ALMX_IF;
>   	/* Set alarm match: second, minute, hour, day, date, month. */
>   	regs[6] |= MCP794XX_MSK_ALMX_MATCH;
> -
> -	if (t->enabled)
> -		regs[0] |= MCP794XX_BIT_ALM0_EN;
> -	else
> -		regs[0] &= ~MCP794XX_BIT_ALM0_EN;
> +	/* Disable interrupt. We will not enable until completely programmed */
> +	regs[0] &= ~MCP794XX_BIT_ALM0_EN;
>   
>   	ret = ds1307->write_block_data(client, MCP794XX_REG_CONTROL, 10, regs);
>   	if (ret < 0)
>   		return ret;
>   
> -	return 0;
> +	if (!t->enabled)
> +		return 0;
> +	regs[0] |= MCP794XX_BIT_ALM0_EN;
> +	return i2c_smbus_write_byte_data(client, MCP794XX_REG_CONTROL, regs[0]);

So, It seems, that right sequence should be:
- disable alarmX
- read alarmX regs
- configure alarmX regs
- load alarmX regs
- enable alarmX

More over, looks like, alarm/alarm IRQ should be enabled/disabled separately from set_alarm/RTC_ALM_SET
by RTC_AIE_ON, RTC_AIE_OFF. Should it?

>   }
>   
>   static int mcp794xx_alarm_irq_enable(struct device *dev, unsigned int enabled)
> 


-- 
regards,
-grygorii

-- 
-- 
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.

  parent reply	other threads:[~2015-04-22 13:26 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-21  0:51 [PATCH V2] drivers/rtc/rtc-ds1307.c: Enable the mcp794xx alarm after programming time Nishanth Menon
2015-04-21  0:51 ` Nishanth Menon
2015-04-21  0:51 ` [rtc-linux] " Nishanth Menon
2015-04-21 23:41 ` Alexandre Belloni
2015-04-21 23:41   ` [rtc-linux] " Alexandre Belloni
2015-04-21 23:58   ` Nishanth Menon
2015-04-21 23:58     ` Nishanth Menon
2015-04-21 23:58     ` [rtc-linux] " Nishanth Menon
2015-04-22  1:09     ` Alexandre Belloni
2015-04-22  1:09       ` [rtc-linux] " Alexandre Belloni
2015-04-22  1:59       ` Nishanth Menon
2015-04-22  1:59         ` Nishanth Menon
2015-04-22  1:59         ` [rtc-linux] " Nishanth Menon
2015-04-22 11:30         ` Alexandre Belloni
2015-04-22 11:30           ` [rtc-linux] " Alexandre Belloni
2015-04-23  0:04           ` Nishanth Menon
2015-04-23  0:04             ` Nishanth Menon
2015-04-23  0:04             ` [rtc-linux] " Nishanth Menon
2015-04-24  9:41             ` Alexandre Belloni
2015-04-24  9:41               ` [rtc-linux] " Alexandre Belloni
2015-04-22 13:26 ` Grygorii.Strashko@linaro.org [this message]
2015-04-22 13:26   ` Grygorii.Strashko@linaro.org
2015-04-23  0:00   ` Nishanth Menon
2015-04-23  0:00     ` Nishanth Menon
2015-04-23  0:00     ` [rtc-linux] " Nishanth Menon
2015-04-23 10:17     ` Grygorii.Strashko@linaro.org
2015-04-23 10:17       ` Grygorii.Strashko@linaro.org
2015-04-23 10:17       ` [rtc-linux] " Grygorii.Strashko@linaro.org
2015-04-23 13:11       ` Nishanth Menon
2015-04-23 13:11         ` Nishanth Menon
2015-04-23 13:11         ` [rtc-linux] " Nishanth Menon
2015-04-23 15:29         ` Grygorii.Strashko@linaro.org
2015-04-23 15:29           ` [rtc-linux] " Grygorii.Strashko@linaro.org

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=5537A169.206@linaro.org \
    --to=grygorii.strashko@linaro.org \
    --cc=a.zummo@towertech.it \
    --cc=alexandre.belloni@free-electrons.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=nm@ti.com \
    --cc=rtc-linux@googlegroups.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.