Do not return error if irq-type setting is requested for
controlloer which does not support this. This is how
regmap-irq has previously handled the undupported type
settings and existing drivers seem to be upset if failure
is now reported.
Fixes: 1c2928e3e321 ("regmap: regmap-irq/gpio-max77620: add level-irq support")
Signed-off-by: Matti Vaittinen <[email protected]>
---
Geert reported that 1c2928e3e321 breaks da9063-rtc on the Renesas
Koelsch board:
https://lore.kernel.org/lkml/[email protected]/T/#m194616cc88d7b4c2a78f7ce07907608fdb64a092
Geert, do you know if anyone vould to test this?
drivers/base/regmap/regmap-irq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/regmap/regmap-irq.c b/drivers/base/regmap/regmap-irq.c
index 1bd1145ad8b5..d2d0014b0d23 100644
--- a/drivers/base/regmap/regmap-irq.c
+++ b/drivers/base/regmap/regmap-irq.c
@@ -258,7 +258,7 @@ static int regmap_irq_set_type(struct irq_data *data, unsigned int type)
const struct regmap_irq_type *t = &irq_data->type;
if ((t->types_supported & type) != type)
- return -ENOTSUPP;
+ return 0;
reg = t->type_reg_offset / map->reg_stride;
--
2.14.3
--
Matti Vaittinen
ROHM Semiconductors
~~~ "I don't think so," said Rene Descartes. Just then, he vanished ~~~
Hi Matti,
On Thu, Dec 27, 2018 at 9:44 AM Matti Vaittinen
<[email protected]> wrote:
> Do not return error if irq-type setting is requested for
> controlloer which does not support this. This is how
> regmap-irq has previously handled the undupported type
> settings and existing drivers seem to be upset if failure
> is now reported.
>
> Fixes: 1c2928e3e321 ("regmap: regmap-irq/gpio-max77620: add level-irq support")
> Signed-off-by: Matti Vaittinen <[email protected]>
Reported-by: Geert Uytterhoeven <[email protected]>
> ---
>
> Geert reported that 1c2928e3e321 breaks da9063-rtc on the Renesas
> Koelsch board:
>
> https://lore.kernel.org/lkml/[email protected]/T/#m194616cc88d7b4c2a78f7ce07907608fdb64a092
>
> Geert, do you know if anyone vould to test this?
Thanks, that seems to fix the issue with da9063-rtc.
I don't know how to trigger an actual interrupt, though.
> --- a/drivers/base/regmap/regmap-irq.c
> +++ b/drivers/base/regmap/regmap-irq.c
> @@ -258,7 +258,7 @@ static int regmap_irq_set_type(struct irq_data *data, unsigned int type)
> const struct regmap_irq_type *t = &irq_data->type;
>
> if ((t->types_supported & type) != type)
> - return -ENOTSUPP;
> + return 0;
>
> reg = t->type_reg_offset / map->reg_stride;
>
> --
> 2.14.3
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Sat, Dec 29, 2018 at 12:13:32PM +0100, Geert Uytterhoeven wrote:
> > Geert, do you know if anyone vould to test this?
> Thanks, that seems to fix the issue with da9063-rtc.
> I don't know how to trigger an actual interrupt, though.
If it's a RTC does it have an alarm you can set?
Hi Mark,
On Mon, Dec 31, 2018 at 8:14 PM Mark Brown <[email protected]> wrote:
> On Sat, Dec 29, 2018 at 12:13:32PM +0100, Geert Uytterhoeven wrote:
> > > Geert, do you know if anyone vould to test this?
>
> > Thanks, that seems to fix the issue with da9063-rtc.
>
> > I don't know how to trigger an actual interrupt, though.
>
> If it's a RTC does it have an alarm you can set?
That's what I had expected, too, but there is no alarm file under
/sys/class/rtc/.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Hi Geert,
On 01 January 2019 @17:36, Geert Uytterhoeven wrote:
> Subject: Re: [PATCH] regmap: regmap-irq: silently ignore unsupported type settings
> On Mon, Dec 31, 2018 at 8:14 PM Mark Brown <[email protected]> wrote:
> > On Sat, Dec 29, 2018 at 12:13:32PM +0100, Geert Uytterhoeven wrote:
> > > > Geert, do you know if anyone vould to test this?
> >
> > > Thanks, that seems to fix the issue with da9063-rtc.
> >
> > > I don't know how to trigger an actual interrupt, though.
> >
> > If it's a RTC does it have an alarm you can set?
>
> That's what I had expected, too, but there is no alarm file under
> /sys/class/rtc/.
>
> Gr{oetje,eeting}s,
>
> Geert
To communicate with the DA9063 RTC I am use ioctl function calls
- RTC_SET_TIME
- RTC_RD_TIME
- RTC_ALM_SET
- RTC_ALM_READ
- RTC_AIE_ON
- RTC_AIE_OFF
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/rtc.txt
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/rtc
Although I don't use the test programs found in Linux, the ioctl calls I
make are shown in the Linux selftests. I believe that Alexandre Belloni
updated the RTC tests recently -- but I am not up to date with the latest.
git show d8da8665e8e34c14f9b20fe3f21dff29b24cbf02:tools/testing/selftests/rtc/rtctest.c
Regards,
Steve
On Thu, Dec 27, 2018 at 10:44:43AM +0200, Matti Vaittinen wrote:
> Do not return error if irq-type setting is requested for
> controlloer which does not support this. This is how
> regmap-irq has previously handled the undupported type
> settings and existing drivers seem to be upset if failure
> is now reported.
>
> Fixes: 1c2928e3e321 ("regmap: regmap-irq/gpio-max77620: add level-irq support")
> Signed-off-by: Matti Vaittinen <[email protected]>
> ---
>
> Geert reported that 1c2928e3e321 breaks da9063-rtc on the Renesas
> Koelsch board:
>
> https://lore.kernel.org/lkml/[email protected]/T/#m194616cc88d7b4c2a78f7ce07907608fdb64a092
>
> Geert, do you know if anyone vould to test this?
>
Bit late since its already been applied but this patch fixes the
issues I had.
Thanks,
Charles
()Hi Steve,
On Wed, Jan 2, 2019 at 4:31 PM Steve Twiss
<[email protected]> wrote:
> On 01 January 2019 @17:36, Geert Uytterhoeven wrote:
> > Subject: Re: [PATCH] regmap: regmap-irq: silently ignore unsupported type settings
> > On Mon, Dec 31, 2018 at 8:14 PM Mark Brown <[email protected]> wrote:
> > > On Sat, Dec 29, 2018 at 12:13:32PM +0100, Geert Uytterhoeven wrote:
> > > > > Geert, do you know if anyone vould to test this?
> > >
> > > > Thanks, that seems to fix the issue with da9063-rtc.
> > >
> > > > I don't know how to trigger an actual interrupt, though.
> > >
> > > If it's a RTC does it have an alarm you can set?
> >
> > That's what I had expected, too, but there is no alarm file under
> > /sys/class/rtc/.
> >
> > Gr{oetje,eeting}s,
> >
> > Geert
>
> To communicate with the DA9063 RTC I am use ioctl function calls
>
> - RTC_SET_TIME
> - RTC_RD_TIME
> - RTC_ALM_SET
> - RTC_ALM_READ
> - RTC_AIE_ON
> - RTC_AIE_OFF
>
> - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/rtc.txt
> - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/rtc
>
> Although I don't use the test programs found in Linux, the ioctl calls I
> make are shown in the Linux selftests. I believe that Alexandre Belloni
> updated the RTC tests recently -- but I am not up to date with the latest.
>
> git show d8da8665e8e34c14f9b20fe3f21dff29b24cbf02:tools/testing/selftests/rtc/rtctest.c
root@koelsch:~# tools/testing/selftests/rtc/rtctest
[==========] Running 5 tests from 2 test cases.
[ RUN ] rtc.date_read
rtctest.c:49:rtc.date_read:Current RTC date/time is 04/01/2019 14:44:25.
[ OK ] rtc.date_read
[ RUN ] rtc.uie_read
[ OK ] rtc.uie_read
[ RUN ] rtc.uie_select
rtctest.c:98:rtc.uie_select:Expected 0 (0) != rc (0)
rtc.uie_select: Test terminated by assertion
[ FAIL ] rtc.uie_select
[ RUN ] rtc.alarm_alm_set
rtctest.c:137:rtc.alarm_alm_set:Alarm time now set to 14:47:23.
rtctest.c:148:rtc.alarm_alm_set:Expected 0 (0) != rc (0)
rtc.alarm_alm_set: Test failed at step #5
[ FAIL ] rtc.alarm_alm_set
[ RUN ] rtc.alarm_wkalm_set
rtctest.c:198:rtc.alarm_wkalm_set:Alarm time now set to 04/01/2019 14:47:28.
rtctest.c:205:rtc.alarm_wkalm_set:Expected 0 (0) != rc (0)
rtctest.c:214:rtc.alarm_wkalm_set:Expected new (1546613934) == secs (1546613248)
rtc.alarm_wkalm_set: Test terminated by assertion
[ FAIL ] rtc.alarm_wkalm_set
[==========] 2 / 5 tests passed.
[ FAILED ]
root@koelsch:~#
No interrupt fired, as witnessed by /proc/interrupts, and the pr_info()
I had added to da9063_alarm_event().
Note that rtctest behaves the same before the regmap irq breakage,
so this is not a recent regression...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Hi Geert,
On 04 January 2019 at 15:48, Geert Uytterhoeven wrote:
> To: Steve Twiss <[email protected]>
> Subject: Re: [PATCH] regmap: regmap-irq: silently ignore unsupported type settings
>
> ()Hi Steve,
>
> On Wed, Jan 2, 2019 at 4:31 PM Steve Twiss
> <[email protected]> wrote:
> > On 01 January 2019 @17:36, Geert Uytterhoeven wrote:
> > > Subject: Re: [PATCH] regmap: regmap-irq: silently ignore unsupported type settings
> > > On Mon, Dec 31, 2018 at 8:14 PM Mark Brown <[email protected]> wrote:
> > > > On Sat, Dec 29, 2018 at 12:13:32PM +0100, Geert Uytterhoeven wrote:
> > > > > > Geert, do you know if anyone vould to test this?
> > > > > Thanks, that seems to fix the issue with da9063-rtc.
> > > > > I don't know how to trigger an actual interrupt, though.
> > > > If it's a RTC does it have an alarm you can set?
> > > That's what I had expected, too, but there is no alarm file under
> > > /sys/class/rtc/.
> >
> > To communicate with the DA9063 RTC I am use ioctl function calls
> >
> > - RTC_SET_TIME
> > - RTC_RD_TIME
> > - RTC_ALM_SET
> > - RTC_ALM_READ
> > - RTC_AIE_ON
> > - RTC_AIE_OFF
> >
> > - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/rtc.txt
> > - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/rtc
> >
> > Although I don't use the test programs found in Linux, the ioctl calls I
> > make are shown in the Linux selftests. I believe that Alexandre Belloni
> > updated the RTC tests recently -- but I am not up to date with the latest.
> >
> > git show
> d8da8665e8e34c14f9b20fe3f21dff29b24cbf02:tools/testing/selftests/rtc/rtctest.c
Okay. So, I've got my own RTC tests which I wrote using the ioctl()
commands. I've not used the rtctest from the kernel before.
Also, I would need to look more closely to give you a better reply
for your results.
> root@koelsch:~# tools/testing/selftests/rtc/rtctest
> [==========] Running 5 tests from 2 test cases.
> [ RUN ] rtc.date_read
> rtctest.c:49:rtc.date_read:Current RTC date/time is 04/01/2019 14:44:25.
> [ OK ] rtc.date_read
> [ RUN ] rtc.uie_read
> [ OK ] rtc.uie_read
> [ RUN ] rtc.uie_select
> rtctest.c:98:rtc.uie_select:Expected 0 (0) != rc (0)
> rtc.uie_select: Test terminated by assertion
> [ FAIL ] rtc.uie_select
> [ RUN ] rtc.alarm_alm_set
> rtctest.c:137:rtc.alarm_alm_set:Alarm time now set to 14:47:23.
> rtctest.c:148:rtc.alarm_alm_set:Expected 0 (0) != rc (0)
> rtc.alarm_alm_set: Test failed at step #5
> [ FAIL ] rtc.alarm_alm_set
> [ RUN ] rtc.alarm_wkalm_set
> rtctest.c:198:rtc.alarm_wkalm_set:Alarm time now set to 04/01/2019 14:47:28.
> rtctest.c:205:rtc.alarm_wkalm_set:Expected 0 (0) != rc (0)
> rtctest.c:214:rtc.alarm_wkalm_set:Expected new (1546613934) == secs
> (1546613248)
> rtc.alarm_wkalm_set: Test terminated by assertion
> [ FAIL ] rtc.alarm_wkalm_set
> [==========] 2 / 5 tests passed.
> [ FAILED ]
> root@koelsch:~#
>
> No interrupt fired, as witnessed by /proc/interrupts, and the pr_info()
> I had added to da9063_alarm_event().
>
> Note that rtctest behaves the same before the regmap irq breakage,
> so this is not a recent regression...
I've just incrementally rebased from v4.18 through to v4.20 and I see the
IRQ working for the DA9063 alarm on my test system. I've not applied any extra
patches and the results below are for the following vanilla kernels: v4.18,
v4.19, v4.20.
The next results are only for regressions in the RTC alarm for the DA9063. I
only ran one simple "TEST" to create an output for you (although I did it twice
to produce two IRQs):
--- 8< ---
v4.18
-----
> cat *.res
[PASS] Set RTC alarms functional test for TEST with DA9063-TEST
[PASS] Setting test type to use RTC alarm functional test for TEST with DA9063-TEST
[PASS] Running set alarm tests for RTC { 1 }
[PASS] Running test for test_rtc_prog_set_simple_alarm_seconds()
[PASS] Setting the current date and time from the da9063-rtc as 2000-01-01 00:00:00
[PASS] Setting the alarm date and time from the da9063-rtc as 2000-01-01 00:00:05 (+5 secs into the future)
[PASS] Setting the listener on da9063-rtc then waiting for elapsed timeout of 15 seconds...
[PASS] The alarm was triggered on da9063-rtc within the expected time and the alarm happened at 2000-01-01 00:00:05
[PASS] Running test for test_rtc_prog_set_simple_alarm_seconds()
[PASS] Setting the current date and time from the da9063-rtc as 2000-01-01 00:00:00
[PASS] Setting the alarm date and time from the da9063-rtc as 2000-01-01 00:00:15 (+15 secs into the future)
[PASS] Setting the listener on da9063-rtc then waiting for elapsed timeout of 25 seconds...
[PASS] The alarm was triggered on da9063-rtc within the expected time and the alarm happened at 2000-01-01 00:00:15
[PASS] Finished running DA9063 set alarm tests for RTC { 1 } on TEST
> cat /proc/interrupts | grep da9063
249: 2 0 0 0 gpio-mxc 11 Level da9063-irq
302: 0 0 0 0 da9063-irq 0 Level ONKEY
303: 0 0 2 0 da9063-irq 1 Level ALARM
310: 0 0 0 0 da9063-irq 8 Level LDO_LIM
> uname -a
Linux test 4.18.0 #1 SMP Mon Jan 7 16:25:37 GMT 2019 armv7l GNU/Linux
v4.19
-----
> cat *.res
[PASS] Set RTC alarms functional test for TEST with DA9063-TEST
[PASS] Setting test type to use RTC alarm functional test for TEST with DA9063-TEST
[PASS] Running set alarm tests for RTC { 1 }
[PASS] Running test for test_rtc_prog_set_simple_alarm_seconds()
[PASS] Setting the current date and time from the da9063-rtc as 2000-01-01 00:00:00
[PASS] Setting the alarm date and time from the da9063-rtc as 2000-01-01 00:00:05 (+5 secs into the future)
[PASS] Setting the listener on da9063-rtc then waiting for elapsed timeout of 15 seconds...
[PASS] The alarm was triggered on da9063-rtc within the expected time and the alarm happened at 2000-01-01 00:00:05
[PASS] Running test for test_rtc_prog_set_simple_alarm_seconds()
[PASS] Setting the current date and time from the da9063-rtc as 2000-01-01 00:00:00
[PASS] Setting the alarm date and time from the da9063-rtc as 2000-01-01 00:00:15 (+15 secs into the future)
[PASS] Setting the listener on da9063-rtc then waiting for elapsed timeout of 25 seconds...
[PASS] The alarm was triggered on da9063-rtc within the expected time and the alarm happened at 2000-01-01 00:00:15
[PASS] Finished running DA9063 set alarm tests for RTC { 1 } on TEST
> cat /proc/interrupts | grep da9063
249: 2 0 0 0 gpio-mxc 11 Level da9063-irq
302: 0 0 0 0 da9063-irq 0 Level ONKEY
303: 0 0 0 2 da9063-irq 1 Level ALARM
310: 0 0 0 0 da9063-irq 8 Level LDO_LIM
> uname -a
Linux test 4.19.0 #1 SMP Mon Jan 7 17:34:43 GMT 2019 armv7l GNU/Linux
v4.20
-----
> cat *.res
[PASS] Set RTC alarms functional test for TEST with DA9063-TEST
[PASS] Setting test type to use RTC alarm functional test for TEST with DA9063-TEST
[PASS] Running set alarm tests for RTC { 1 }
[PASS] Running test for test_rtc_prog_set_simple_alarm_seconds()
[PASS] Setting the current date and time from the da9063-rtc as 2000-01-01 00:00:00
[PASS] Setting the alarm date and time from the da9063-rtc as 2000-01-01 00:00:05 (+5 secs into the future)
[PASS] Setting the listener on da9063-rtc then waiting for elapsed timeout of 15 seconds...
[PASS] The alarm was triggered on da9063-rtc within the expected time and the alarm happened at 2000-01-01 00:00:05
[PASS] Running test for test_rtc_prog_set_simple_alarm_seconds()
[PASS] Setting the current date and time from the da9063-rtc as 2000-01-01 00:00:00
[PASS] Setting the alarm date and time from the da9063-rtc as 2000-01-01 00:00:15 (+15 secs into the future)
[PASS] Setting the listener on da9063-rtc then waiting for elapsed timeout of 25 seconds...
[PASS] The alarm was triggered on da9063-rtc within the expected time and the alarm happened at 2000-01-01 00:00:15
[PASS] Finished running DA9063 set alarm tests for RTC { 1 } on TEST
> cat /proc/interrupts | grep da9063
249: 2 0 0 0 gpio-mxc 11 Level da9063-irq
302: 0 0 0 0 da9063-irq 0 Level ONKEY
303: 0 0 2 0 da9063-irq 1 Level ALARM
310: 0 0 0 0 da9063-irq 8 Level LDO_LIM
> uname -a
Linux test 4.20.0 #1 SMP Mon Jan 7 17:46:59 GMT 2019 armv7l GNU/Linux
--- 8< ---
So, with these results, I don't think this is a regression going back very far.
But when I get to vanilla v5.0-rc1, there are lots of IRQ failures, so I can't
test because nothing gets loaded. All of the IRQs in each of the DA9063
MFD cells are failing, not just for the RTC. I get the following from the
console logs for v5.0-rc1 ...
da9063 1-0058: Device detected (chip-ID: 0x61, var-ID: 0x60)
genirq: Setting trigger mode 8 for irq 310 failed (regmap_irq_set_type+0x0/0x164)
da9063-regulators da9063-regulators: Failed to request LDO_LIM IRQ.
da9063-regulators: probe of da9063-regulators failed with error -524
[...]
da9063-onkey da9063-onkey: DMA mask not set
genirq: Setting trigger mode 8 for irq 302 failed (regmap_irq_set_type+0x0/0x164)
da9063-onkey da9063-onkey: Failed to request IRQ 302: -524
da9063-onkey: probe of da9063-onkey failed with error -524
da9063-rtc da9063-rtc: DMA mask not set
da9063-rtc da9063-rtc: registered as rtc0
genirq: Setting trigger mode 8 for irq 303 failed (regmap_irq_set_type+0x0/0x164)
da9063-rtc da9063-rtc: Failed to request ALARM IRQ 303: -524
da9063-rtc: probe of da9063-rtc failed with error -524
[...]
da9063-watchdog da9063-watchdog: DMA mask not set
I'll test the proposed fix tomorrow.
Regards,
Steve
Hi Geert,
On 29 December 2018 11:14 Geert Uytterhoeven wrote:
> To: Matti Vaittinen <[email protected]>
> Cc: [email protected]; Mark Brown <[email protected]>; Greg KH
> <[email protected]>; Rafael J. Wysocki <[email protected]>; Linux
> Kernel Mailing List <[email protected]>; Support Opensource
> <[email protected]>
> Subject: Re: [PATCH] regmap: regmap-irq: silently ignore unsupported type
> settings
>
> Hi Matti,
>
> On Thu, Dec 27, 2018 at 9:44 AM Matti Vaittinen
> <[email protected]> wrote:
> > Do not return error if irq-type setting is requested for
> > controlloer which does not support this. This is how
> > regmap-irq has previously handled the undupported type
> > settings and existing drivers seem to be upset if failure
> > is now reported.
> >
> > Fixes: 1c2928e3e321 ("regmap: regmap-irq/gpio-max77620: add level-irq support")
> > Signed-off-by: Matti Vaittinen <[email protected]>
>
> Reported-by: Geert Uytterhoeven <[email protected]>
>
> > ---
> >
> > Geert reported that 1c2928e3e321 breaks da9063-rtc on the Renesas
> > Koelsch board:
> >
> >
> https://lore.kernel.org/lkml/[email protected]/T/#
> m194616cc88d7b4c2a78f7ce07907608fdb64a092
> >
> > Geert, do you know if anyone vould to test this?
>
> Thanks, that seems to fix the issue with da9063-rtc.
>
> I don't know how to trigger an actual interrupt, though.
>
> > --- a/drivers/base/regmap/regmap-irq.c
> > +++ b/drivers/base/regmap/regmap-irq.c
> > @@ -258,7 +258,7 @@ static int regmap_irq_set_type(struct irq_data *data,
> unsigned int type)
> > const struct regmap_irq_type *t = &irq_data->type;
> >
> > if ((t->types_supported & type) != type)
> > - return -ENOTSUPP;
> > + return 0;
> >
> > reg = t->type_reg_offset / map->reg_stride;
> >
> > --
> > 2.14.3
>
I've run this patch on the DA9063 set-up I have here. And this fixes the
problem.
Acked-by: Steve Twiss <[email protected]>
Tested-by: Steve Twiss <[email protected]>
Regards,
Steve
My previous report using the unmodified v5.0-rc1 Linux kernel is here:
https://lore.kernel.org/lkml/6ED8E3B22081A4459DAC7699F3695FB7022179F018@SW-EX-MBX02.diasemi.com
This v5.0-rc1 Linux kernel failed to allow IRQs for the MFD cells in the
DA9063. But, altering the v5.0-rc1 kernel with the patch given above (to
return 0 instead of -ENOTSUPP in regmap-irq.c), fixes the problem.
A cut-down console output for this result is given below.
--- 8< ---
[...]
da9063 1-0058: Device detected (chip-ID: 0x61, var-ID: 0x60)
[...]
da9063-onkey da9063-onkey: DMA mask not set
input: da9063-onkey as /devices/soc0/soc/2100000.aips-bus/21a4000.i2c/i2c-1/1-0058/da9063-onkey/input/input2
da9063-rtc da9063-rtc: DMA mask not set
da9063-rtc da9063-rtc: registered as rtc0
[...]
da9063-watchdog da9063-watchdog: DMA mask not set
[...]
da9063-rtc da9063-rtc: setting system clock to 2000-01-01T00:00:00 UTC (946684800)
[...]
--- 8< ---
and the results of setting an RTC alarm and waiting for the interrupt outputs
the following:
--- 8< ---
> cat *.res
[PASS] Set RTC alarms functional test for TEST with DA9063-TEST
[PASS] Setting test type to use BB RTC alarm functional test for TEST with DA9063-TEST
[PASS] Running set alarm tests for RTC { 1 }
[PASS] Running test for test_rtc_prog_set_simple_alarm_seconds()
[PASS] Setting the current date and time from the da9063-rtc as 2000-01-01 00:00:00
[PASS] Setting the alarm date and time from the da9063-rtc as 2000-01-01 00:00:05 (+5 secs into the future)
[PASS] Setting the listener on da9063-rtc then waiting for elapsed timeout of 15 seconds...
[PASS] The alarm was triggered on da9063-rtc within the expected time and the alarm happened at 2000-01-01 00:00:05
[PASS] Running test for test_rtc_prog_set_simple_alarm_seconds()
[PASS] Setting the current date and time from the da9063-rtc as 2000-01-01 00:00:00
[PASS] Setting the alarm date and time from the da9063-rtc as 2000-01-01 00:00:15 (+15 secs into the future)
[PASS] Setting the listener on da9063-rtc then waiting for elapsed timeout of 25 seconds...
[PASS] The alarm was triggered on da9063-rtc within the expected time and the alarm happened at 2000-01-01 00:00:15
[PASS] Finished running DA9063 set alarm tests for RTC { 1 } on TEST
> cat /proc/interrupts | grep da9063
249: 2 0 0 0 gpio-mxc 11 Level da9063-irq
302: 0 0 0 0 da9063-irq 0 Level ONKEY
303: 0 0 0 2 da9063-irq 1 Level ALARM
310: 0 0 0 0 da9063-irq 8 Level LDO_LIM
> uname -a
Linux test 5.0.0-rc1 #1 SMP Tue Jan 8 09:39:30 GMT 2019 armv7l GNU/Linux
--- 8< ---