Re: [PATCH V1] drivers/rtc: da9052: ALARM causes interrupt storm
On Wed, 2 Apr 2014 12:45:38 +0100 "Opensource [Anthony Olech]"
wrote:
> Setting the alarm to a time not on a minute boundary results in repeated
> interrupts being generated by the DA9052/3 PMIC device until the kernel
> RTC core sees that the alarm has rung. Sometimes the number and frequency
> of interrupts can cause the kernel to disable the IRQ line used by the
> DA9052/3 PMIC with disasterous consequences. This patch fixes the problem.
>
> Even though the DA9052/3 PMIC is capable generating periodic interrupts,
> ie TICKS, the method used to distinguish RTC_AF from RTC_PF events was
> flawed and can not work in conjunction with the regmap_irq kernel core.
> Thus that flawed detection has also been removed by the DA9052/3 PMIC RTC
> driver's irq handler, so that it no longer reports the wrong type of event
> to the kernel RTC core.
>
> The internal static functions within the DA9052/3 PMIC RTC driver have
> been changed to pass the 'da9052_rtc' structure instead of the 'da9052'
> because there is no backwards pointer from the 'da9052' structure.
>
> Signed-off-by: Anthony Olech
> ---
>
> This patch is relative to linux-next repository tag next-20140402
>
> This patch fixes the three issues described above. The first is serious
> because usiing the RTC alarm set to a non minute boundary will eventually
> cause all component drivers that depend on the interrupt line to fail. The
> solution adopted is to round up to alarm time to the next highest minute.
>
> The second bug, reporting a RTC_PF event instead of an RTC_AF event turns
> out to not matter with the current implementation of the kernel RTC core
> as it seems to ignore the event type. However, should that change in the
> future it is better to fix the issue now and not have 'problems waiting to
> happen'
>
> The third set of changes are to make the da9052_rtc structure available
> to all the local internal functions in the driver. This was done during
> testing so that diagnostic data could be stored there. Should the solution
> to the first issue be found not acceptable, then the alternative of using
> the TICKS interrupt at the fixed one second interval in order to step to
> the exact second of the requested alarm requires an extra (alarm time)
> piece of data to be stored. In devices that use the alarm function to wake
> up from sleep, accuracy to the second will result in the device being
> awake for up to nearly a minute longer than expected.
The above three paragraphs contained important info which is
appropriate to the formal patch changelog.
>
> ...
>
> @@ -261,7 +271,7 @@ static struct platform_driver da9052_rtc_driver = {
>
> module_platform_driver(da9052_rtc_driver);
>
> -MODULE_AUTHOR("David Dajun Chen ");
> +MODULE_AUTHOR("Anthony Olech ");
> MODULE_DESCRIPTION("RTC driver for Dialog DA9052 PMIC");
> MODULE_LICENSE("GPL");
> MODULE_ALIAS("platform:da9052-rtc");
What's this?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V1] drivers/rtc: da9052: ALARM causes interrupt storm
On Wed, 2 Apr 2014 12:45:38 +0100 Opensource [Anthony Olech]
anthony.olech.opensou...@diasemi.com wrote:
Setting the alarm to a time not on a minute boundary results in repeated
interrupts being generated by the DA9052/3 PMIC device until the kernel
RTC core sees that the alarm has rung. Sometimes the number and frequency
of interrupts can cause the kernel to disable the IRQ line used by the
DA9052/3 PMIC with disasterous consequences. This patch fixes the problem.
Even though the DA9052/3 PMIC is capable generating periodic interrupts,
ie TICKS, the method used to distinguish RTC_AF from RTC_PF events was
flawed and can not work in conjunction with the regmap_irq kernel core.
Thus that flawed detection has also been removed by the DA9052/3 PMIC RTC
driver's irq handler, so that it no longer reports the wrong type of event
to the kernel RTC core.
The internal static functions within the DA9052/3 PMIC RTC driver have
been changed to pass the 'da9052_rtc' structure instead of the 'da9052'
because there is no backwards pointer from the 'da9052' structure.
Signed-off-by: Anthony Olech anthony.olech.opensou...@diasemi.com
---
This patch is relative to linux-next repository tag next-20140402
This patch fixes the three issues described above. The first is serious
because usiing the RTC alarm set to a non minute boundary will eventually
cause all component drivers that depend on the interrupt line to fail. The
solution adopted is to round up to alarm time to the next highest minute.
The second bug, reporting a RTC_PF event instead of an RTC_AF event turns
out to not matter with the current implementation of the kernel RTC core
as it seems to ignore the event type. However, should that change in the
future it is better to fix the issue now and not have 'problems waiting to
happen'
The third set of changes are to make the da9052_rtc structure available
to all the local internal functions in the driver. This was done during
testing so that diagnostic data could be stored there. Should the solution
to the first issue be found not acceptable, then the alternative of using
the TICKS interrupt at the fixed one second interval in order to step to
the exact second of the requested alarm requires an extra (alarm time)
piece of data to be stored. In devices that use the alarm function to wake
up from sleep, accuracy to the second will result in the device being
awake for up to nearly a minute longer than expected.
The above three paragraphs contained important info which is
appropriate to the formal patch changelog.
...
@@ -261,7 +271,7 @@ static struct platform_driver da9052_rtc_driver = {
module_platform_driver(da9052_rtc_driver);
-MODULE_AUTHOR(David Dajun Chen dc...@diasemi.com);
+MODULE_AUTHOR(Anthony Olech anthony.ol...@diasemi.com);
MODULE_DESCRIPTION(RTC driver for Dialog DA9052 PMIC);
MODULE_LICENSE(GPL);
MODULE_ALIAS(platform:da9052-rtc);
What's this?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH V1] drivers/rtc: da9052: ALARM causes interrupt storm
Hi Alessandro,
you did not reply to my patch submission.
Why not?
Tony Olech
Dialog Semiconductor
> -Original Message-
> From: Opensource [Anthony Olech]
> [mailto:anthony.olech.opensou...@diasemi.com]
> Sent: 02 April 2014 12:46
> To: Alessandro Zummo; Support Opensource
> Cc: linux-kernel@vger.kernel.org; rtc-li...@googlegroups.com; David Dajun
> Chen
> Subject: [PATCH V1] drivers/rtc: da9052: ALARM causes interrupt storm
>
> Setting the alarm to a time not on a minute boundary results in repeated
> interrupts being generated by the DA9052/3 PMIC device until the kernel RTC
> core sees that the alarm has rung. Sometimes the number and frequency of
> interrupts can cause the kernel to disable the IRQ line used by the
> DA9052/3 PMIC with disasterous consequences. This patch fixes the
> problem.
>
> Even though the DA9052/3 PMIC is capable generating periodic interrupts, ie
> TICKS, the method used to distinguish RTC_AF from RTC_PF events was
> flawed and can not work in conjunction with the regmap_irq kernel core.
> Thus that flawed detection has also been removed by the DA9052/3 PMIC
> RTC driver's irq handler, so that it no longer reports the wrong type of event
> to the kernel RTC core.
>
> The internal static functions within the DA9052/3 PMIC RTC driver have been
> changed to pass the 'da9052_rtc' structure instead of the 'da9052'
> because there is no backwards pointer from the 'da9052' structure.
>
> Signed-off-by: Anthony Olech
> ---
>
> This patch is relative to linux-next repository tag next-20140402
>
> This patch fixes the three issues described above. The first is serious
> because
> usiing the RTC alarm set to a non minute boundary will eventually cause all
> component drivers that depend on the interrupt line to fail. The solution
> adopted is to round up to alarm time to the next highest minute.
>
> The second bug, reporting a RTC_PF event instead of an RTC_AF event turns
> out to not matter with the current implementation of the kernel RTC core as
> it seems to ignore the event type. However, should that change in the future
> it is better to fix the issue now and not have 'problems waiting to happen'
>
> The third set of changes are to make the da9052_rtc structure available to all
> the local internal functions in the driver. This was done during testing so
> that
> diagnostic data could be stored there. Should the solution to the first issue
> be found not acceptable, then the alternative of using the TICKS interrupt at
> the fixed one second interval in order to step to the exact second of the
> requested alarm requires an extra (alarm time) piece of data to be stored. In
> devices that use the alarm function to wake up from sleep, accuracy to the
> second will result in the device being awake for up to nearly a minute longer
> than expected.
>
> drivers/rtc/rtc-da9052.c | 122 +-
>
> 1 file changed, 66 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/rtc/rtc-da9052.c b/drivers/rtc/rtc-da9052.c index
> a1cbf64..e5c9486 100644
> --- a/drivers/rtc/rtc-da9052.c
> +++ b/drivers/rtc/rtc-da9052.c
> @@ -20,28 +20,28 @@
> #include
> #include
>
> -#define rtc_err(da9052, fmt, ...) \
> - dev_err(da9052->dev, "%s: " fmt, __func__,
> ##__VA_ARGS__)
> +#define rtc_err(rtc, fmt, ...) \
> + dev_err(rtc->da9052->dev, "%s: " fmt, __func__,
> ##__VA_ARGS__)
>
> struct da9052_rtc {
> struct rtc_device *rtc;
> struct da9052 *da9052;
> };
>
> -static int da9052_rtc_enable_alarm(struct da9052 *da9052, bool enable)
> +static int da9052_rtc_enable_alarm(struct da9052_rtc *rtc, bool enable)
> {
> int ret;
> if (enable) {
> - ret = da9052_reg_update(da9052, DA9052_ALARM_Y_REG,
> - DA9052_ALARM_Y_ALARM_ON,
> - DA9052_ALARM_Y_ALARM_ON);
> + ret = da9052_reg_update(rtc->da9052,
> DA9052_ALARM_Y_REG,
> +
> DA9052_ALARM_Y_ALARM_ON|DA9052_ALARM_Y_TICK_ON,
> + DA9052_ALARM_Y_ALARM_ON);
> if (ret != 0)
> - rtc_err(da9052, "Failed to enable ALM: %d\n", ret);
> + rtc_err(rtc, "Failed to enable ALM: %d\n", ret);
> } else {
> - ret = da9052_reg_update(da9052, DA9052_ALARM_Y_REG,
> - DA9052_ALARM_Y_ALARM_ON, 0);
> + ret = da9052_reg_update(rtc->da9052,
> DA9052_ALARM_Y_REG,
> +
> DA9052_ALARM_Y_ALARM_ON|DA9052_ALARM_Y_TICK_ON, 0);
> if (ret != 0)
> -
RE: [PATCH V1] drivers/rtc: da9052: ALARM causes interrupt storm
Hi Alessandro,
you did not reply to my patch submission.
Why not?
Tony Olech
Dialog Semiconductor
-Original Message-
From: Opensource [Anthony Olech]
[mailto:anthony.olech.opensou...@diasemi.com]
Sent: 02 April 2014 12:46
To: Alessandro Zummo; Support Opensource
Cc: linux-kernel@vger.kernel.org; rtc-li...@googlegroups.com; David Dajun
Chen
Subject: [PATCH V1] drivers/rtc: da9052: ALARM causes interrupt storm
Setting the alarm to a time not on a minute boundary results in repeated
interrupts being generated by the DA9052/3 PMIC device until the kernel RTC
core sees that the alarm has rung. Sometimes the number and frequency of
interrupts can cause the kernel to disable the IRQ line used by the
DA9052/3 PMIC with disasterous consequences. This patch fixes the
problem.
Even though the DA9052/3 PMIC is capable generating periodic interrupts, ie
TICKS, the method used to distinguish RTC_AF from RTC_PF events was
flawed and can not work in conjunction with the regmap_irq kernel core.
Thus that flawed detection has also been removed by the DA9052/3 PMIC
RTC driver's irq handler, so that it no longer reports the wrong type of event
to the kernel RTC core.
The internal static functions within the DA9052/3 PMIC RTC driver have been
changed to pass the 'da9052_rtc' structure instead of the 'da9052'
because there is no backwards pointer from the 'da9052' structure.
Signed-off-by: Anthony Olech anthony.olech.opensou...@diasemi.com
---
This patch is relative to linux-next repository tag next-20140402
This patch fixes the three issues described above. The first is serious
because
usiing the RTC alarm set to a non minute boundary will eventually cause all
component drivers that depend on the interrupt line to fail. The solution
adopted is to round up to alarm time to the next highest minute.
The second bug, reporting a RTC_PF event instead of an RTC_AF event turns
out to not matter with the current implementation of the kernel RTC core as
it seems to ignore the event type. However, should that change in the future
it is better to fix the issue now and not have 'problems waiting to happen'
The third set of changes are to make the da9052_rtc structure available to all
the local internal functions in the driver. This was done during testing so
that
diagnostic data could be stored there. Should the solution to the first issue
be found not acceptable, then the alternative of using the TICKS interrupt at
the fixed one second interval in order to step to the exact second of the
requested alarm requires an extra (alarm time) piece of data to be stored. In
devices that use the alarm function to wake up from sleep, accuracy to the
second will result in the device being awake for up to nearly a minute longer
than expected.
drivers/rtc/rtc-da9052.c | 122 +-
1 file changed, 66 insertions(+), 56 deletions(-)
diff --git a/drivers/rtc/rtc-da9052.c b/drivers/rtc/rtc-da9052.c index
a1cbf64..e5c9486 100644
--- a/drivers/rtc/rtc-da9052.c
+++ b/drivers/rtc/rtc-da9052.c
@@ -20,28 +20,28 @@
#include linux/mfd/da9052/da9052.h
#include linux/mfd/da9052/reg.h
-#define rtc_err(da9052, fmt, ...) \
- dev_err(da9052-dev, %s: fmt, __func__,
##__VA_ARGS__)
+#define rtc_err(rtc, fmt, ...) \
+ dev_err(rtc-da9052-dev, %s: fmt, __func__,
##__VA_ARGS__)
struct da9052_rtc {
struct rtc_device *rtc;
struct da9052 *da9052;
};
-static int da9052_rtc_enable_alarm(struct da9052 *da9052, bool enable)
+static int da9052_rtc_enable_alarm(struct da9052_rtc *rtc, bool enable)
{
int ret;
if (enable) {
- ret = da9052_reg_update(da9052, DA9052_ALARM_Y_REG,
- DA9052_ALARM_Y_ALARM_ON,
- DA9052_ALARM_Y_ALARM_ON);
+ ret = da9052_reg_update(rtc-da9052,
DA9052_ALARM_Y_REG,
+
DA9052_ALARM_Y_ALARM_ON|DA9052_ALARM_Y_TICK_ON,
+ DA9052_ALARM_Y_ALARM_ON);
if (ret != 0)
- rtc_err(da9052, Failed to enable ALM: %d\n, ret);
+ rtc_err(rtc, Failed to enable ALM: %d\n, ret);
} else {
- ret = da9052_reg_update(da9052, DA9052_ALARM_Y_REG,
- DA9052_ALARM_Y_ALARM_ON, 0);
+ ret = da9052_reg_update(rtc-da9052,
DA9052_ALARM_Y_REG,
+
DA9052_ALARM_Y_ALARM_ON|DA9052_ALARM_Y_TICK_ON, 0);
if (ret != 0)
- rtc_err(da9052, Write error: %d\n, ret);
+ rtc_err(rtc, Write error: %d\n, ret);
}
return ret;
}
@@ -49,31 +49,20 @@ static int da9052_rtc_enable_alarm(struct da9052
*da9052, bool enable) static irqreturn_t da9052_rtc_irq(int irq, void *data)
{
struct da9052_rtc *rtc = data;
- int ret;
- ret = da9052_reg_read(rtc-da9052
[PATCH V1] drivers/rtc: da9052: ALARM causes interrupt storm
Setting the alarm to a time not on a minute boundary results in repeated
interrupts being generated by the DA9052/3 PMIC device until the kernel
RTC core sees that the alarm has rung. Sometimes the number and frequency
of interrupts can cause the kernel to disable the IRQ line used by the
DA9052/3 PMIC with disasterous consequences. This patch fixes the problem.
Even though the DA9052/3 PMIC is capable generating periodic interrupts,
ie TICKS, the method used to distinguish RTC_AF from RTC_PF events was
flawed and can not work in conjunction with the regmap_irq kernel core.
Thus that flawed detection has also been removed by the DA9052/3 PMIC RTC
driver's irq handler, so that it no longer reports the wrong type of event
to the kernel RTC core.
The internal static functions within the DA9052/3 PMIC RTC driver have
been changed to pass the 'da9052_rtc' structure instead of the 'da9052'
because there is no backwards pointer from the 'da9052' structure.
Signed-off-by: Anthony Olech
---
This patch is relative to linux-next repository tag next-20140402
This patch fixes the three issues described above. The first is serious
because usiing the RTC alarm set to a non minute boundary will eventually
cause all component drivers that depend on the interrupt line to fail. The
solution adopted is to round up to alarm time to the next highest minute.
The second bug, reporting a RTC_PF event instead of an RTC_AF event turns
out to not matter with the current implementation of the kernel RTC core
as it seems to ignore the event type. However, should that change in the
future it is better to fix the issue now and not have 'problems waiting to
happen'
The third set of changes are to make the da9052_rtc structure available
to all the local internal functions in the driver. This was done during
testing so that diagnostic data could be stored there. Should the solution
to the first issue be found not acceptable, then the alternative of using
the TICKS interrupt at the fixed one second interval in order to step to
the exact second of the requested alarm requires an extra (alarm time)
piece of data to be stored. In devices that use the alarm function to wake
up from sleep, accuracy to the second will result in the device being
awake for up to nearly a minute longer than expected.
drivers/rtc/rtc-da9052.c | 122 +-
1 file changed, 66 insertions(+), 56 deletions(-)
diff --git a/drivers/rtc/rtc-da9052.c b/drivers/rtc/rtc-da9052.c
index a1cbf64..e5c9486 100644
--- a/drivers/rtc/rtc-da9052.c
+++ b/drivers/rtc/rtc-da9052.c
@@ -20,28 +20,28 @@
#include
#include
-#define rtc_err(da9052, fmt, ...) \
- dev_err(da9052->dev, "%s: " fmt, __func__, ##__VA_ARGS__)
+#define rtc_err(rtc, fmt, ...) \
+ dev_err(rtc->da9052->dev, "%s: " fmt, __func__, ##__VA_ARGS__)
struct da9052_rtc {
struct rtc_device *rtc;
struct da9052 *da9052;
};
-static int da9052_rtc_enable_alarm(struct da9052 *da9052, bool enable)
+static int da9052_rtc_enable_alarm(struct da9052_rtc *rtc, bool enable)
{
int ret;
if (enable) {
- ret = da9052_reg_update(da9052, DA9052_ALARM_Y_REG,
- DA9052_ALARM_Y_ALARM_ON,
- DA9052_ALARM_Y_ALARM_ON);
+ ret = da9052_reg_update(rtc->da9052, DA9052_ALARM_Y_REG,
+ DA9052_ALARM_Y_ALARM_ON|DA9052_ALARM_Y_TICK_ON,
+ DA9052_ALARM_Y_ALARM_ON);
if (ret != 0)
- rtc_err(da9052, "Failed to enable ALM: %d\n", ret);
+ rtc_err(rtc, "Failed to enable ALM: %d\n", ret);
} else {
- ret = da9052_reg_update(da9052, DA9052_ALARM_Y_REG,
- DA9052_ALARM_Y_ALARM_ON, 0);
+ ret = da9052_reg_update(rtc->da9052, DA9052_ALARM_Y_REG,
+ DA9052_ALARM_Y_ALARM_ON|DA9052_ALARM_Y_TICK_ON, 0);
if (ret != 0)
- rtc_err(da9052, "Write error: %d\n", ret);
+ rtc_err(rtc, "Write error: %d\n", ret);
}
return ret;
}
@@ -49,31 +49,20 @@ static int da9052_rtc_enable_alarm(struct da9052 *da9052,
bool enable)
static irqreturn_t da9052_rtc_irq(int irq, void *data)
{
struct da9052_rtc *rtc = data;
- int ret;
- ret = da9052_reg_read(rtc->da9052, DA9052_ALARM_MI_REG);
- if (ret < 0) {
- rtc_err(rtc->da9052, "Read error: %d\n", ret);
- return IRQ_NONE;
- }
-
- if (ret & DA9052_ALARMMI_ALARMTYPE) {
- da9052_rtc_enable_alarm(rtc->da9052, 0);
- rtc_update_irq(rtc->rtc, 1, RTC_IRQF | RTC_AF);
- } else
- rtc_update_irq(rtc->rtc, 1, RTC_IRQF | RTC_PF);
+ rtc_update_irq(rtc->rtc, 1, RTC_IRQF | RTC_AF);
return IRQ_HANDLED;
}
-static int
[PATCH V1] drivers/rtc: da9052: ALARM causes interrupt storm
Setting the alarm to a time not on a minute boundary results in repeated
interrupts being generated by the DA9052/3 PMIC device until the kernel
RTC core sees that the alarm has rung. Sometimes the number and frequency
of interrupts can cause the kernel to disable the IRQ line used by the
DA9052/3 PMIC with disasterous consequences. This patch fixes the problem.
Even though the DA9052/3 PMIC is capable generating periodic interrupts,
ie TICKS, the method used to distinguish RTC_AF from RTC_PF events was
flawed and can not work in conjunction with the regmap_irq kernel core.
Thus that flawed detection has also been removed by the DA9052/3 PMIC RTC
driver's irq handler, so that it no longer reports the wrong type of event
to the kernel RTC core.
The internal static functions within the DA9052/3 PMIC RTC driver have
been changed to pass the 'da9052_rtc' structure instead of the 'da9052'
because there is no backwards pointer from the 'da9052' structure.
Signed-off-by: Anthony Olech anthony.olech.opensou...@diasemi.com
---
This patch is relative to linux-next repository tag next-20140402
This patch fixes the three issues described above. The first is serious
because usiing the RTC alarm set to a non minute boundary will eventually
cause all component drivers that depend on the interrupt line to fail. The
solution adopted is to round up to alarm time to the next highest minute.
The second bug, reporting a RTC_PF event instead of an RTC_AF event turns
out to not matter with the current implementation of the kernel RTC core
as it seems to ignore the event type. However, should that change in the
future it is better to fix the issue now and not have 'problems waiting to
happen'
The third set of changes are to make the da9052_rtc structure available
to all the local internal functions in the driver. This was done during
testing so that diagnostic data could be stored there. Should the solution
to the first issue be found not acceptable, then the alternative of using
the TICKS interrupt at the fixed one second interval in order to step to
the exact second of the requested alarm requires an extra (alarm time)
piece of data to be stored. In devices that use the alarm function to wake
up from sleep, accuracy to the second will result in the device being
awake for up to nearly a minute longer than expected.
drivers/rtc/rtc-da9052.c | 122 +-
1 file changed, 66 insertions(+), 56 deletions(-)
diff --git a/drivers/rtc/rtc-da9052.c b/drivers/rtc/rtc-da9052.c
index a1cbf64..e5c9486 100644
--- a/drivers/rtc/rtc-da9052.c
+++ b/drivers/rtc/rtc-da9052.c
@@ -20,28 +20,28 @@
#include linux/mfd/da9052/da9052.h
#include linux/mfd/da9052/reg.h
-#define rtc_err(da9052, fmt, ...) \
- dev_err(da9052-dev, %s: fmt, __func__, ##__VA_ARGS__)
+#define rtc_err(rtc, fmt, ...) \
+ dev_err(rtc-da9052-dev, %s: fmt, __func__, ##__VA_ARGS__)
struct da9052_rtc {
struct rtc_device *rtc;
struct da9052 *da9052;
};
-static int da9052_rtc_enable_alarm(struct da9052 *da9052, bool enable)
+static int da9052_rtc_enable_alarm(struct da9052_rtc *rtc, bool enable)
{
int ret;
if (enable) {
- ret = da9052_reg_update(da9052, DA9052_ALARM_Y_REG,
- DA9052_ALARM_Y_ALARM_ON,
- DA9052_ALARM_Y_ALARM_ON);
+ ret = da9052_reg_update(rtc-da9052, DA9052_ALARM_Y_REG,
+ DA9052_ALARM_Y_ALARM_ON|DA9052_ALARM_Y_TICK_ON,
+ DA9052_ALARM_Y_ALARM_ON);
if (ret != 0)
- rtc_err(da9052, Failed to enable ALM: %d\n, ret);
+ rtc_err(rtc, Failed to enable ALM: %d\n, ret);
} else {
- ret = da9052_reg_update(da9052, DA9052_ALARM_Y_REG,
- DA9052_ALARM_Y_ALARM_ON, 0);
+ ret = da9052_reg_update(rtc-da9052, DA9052_ALARM_Y_REG,
+ DA9052_ALARM_Y_ALARM_ON|DA9052_ALARM_Y_TICK_ON, 0);
if (ret != 0)
- rtc_err(da9052, Write error: %d\n, ret);
+ rtc_err(rtc, Write error: %d\n, ret);
}
return ret;
}
@@ -49,31 +49,20 @@ static int da9052_rtc_enable_alarm(struct da9052 *da9052,
bool enable)
static irqreturn_t da9052_rtc_irq(int irq, void *data)
{
struct da9052_rtc *rtc = data;
- int ret;
- ret = da9052_reg_read(rtc-da9052, DA9052_ALARM_MI_REG);
- if (ret 0) {
- rtc_err(rtc-da9052, Read error: %d\n, ret);
- return IRQ_NONE;
- }
-
- if (ret DA9052_ALARMMI_ALARMTYPE) {
- da9052_rtc_enable_alarm(rtc-da9052, 0);
- rtc_update_irq(rtc-rtc, 1, RTC_IRQF | RTC_AF);
- } else
- rtc_update_irq(rtc-rtc, 1, RTC_IRQF | RTC_PF);
+ rtc_update_irq(rtc-rtc, 1, RTC_IRQF | RTC_AF);
