On 01/04/2019 21:34:25+0200, Wolfram Sang wrote: > > > Well, seeing the code, I actually remembered that this test is still > > there to ensure the core will properly block. If you remove that test, > > the other ones should all timeout. > > Thanks for your assistance! What I did just now was to make use of the > 'uie_unsupported' flag. This is the outcome: > > > [==========] Running 7 tests from 2 test cases. > [ RUN ] rtc.date_read > rtctest.c:49:rtc.date_read:Current RTC date/time is 01/01/2000 00:13:23. > [ OK ] rtc.date_read > [ RUN ] rtc.uie_read > [ OK ] rtc.uie_read > [ RUN ] rtc.uie_select > [ OK ] rtc.uie_select > [ RUN ] rtc.alarm_alm_set > rtctest.c:137:rtc.alarm_alm_set:Alarm time now set to 00:13:32. > rtctest.c:148:rtc.alarm_alm_set:Expected 0 (0) != rc (0) > rtc.alarm_alm_set: Test terminated by assertion > [ FAIL ] rtc.alarm_alm_set > [ RUN ] rtc.alarm_wkalm_set > rtctest.c:195:rtc.alarm_wkalm_set:Alarm time now set to 01/01/2000 > 00:13:37. > rtctest.c:202:rtc.alarm_wkalm_set:Expected 0 (0) != rc (0) > rtc.alarm_wkalm_set: Test terminated by assertion > [ FAIL ] rtc.alarm_wkalm_set > [ RUN ] rtc.alarm_alm_set_minute > rtctest.c:239:rtc.alarm_alm_set_minute:Alarm time now set to 00:14:00. > rtctest.c:258:rtc.alarm_alm_set_minute:data: 1a0 > [ OK ] rtc.alarm_alm_set_minute > [ RUN ] rtc.alarm_wkalm_set_minute > rtctest.c:297:rtc.alarm_wkalm_set_minute:Alarm time now set to > 01/01/2000 00:15:00. > [ OK ] rtc.alarm_wkalm_set_minute > [==========] 5 / 7 tests passed. > [ FAILED ] > > I wonder why the_set_minute tests pass, but the other ones fail. I also > wonder why I need the uie_unsupported flag? It's been a while since I > dug into the RTC subsystem, I may be missing something. But I see the > UIE code finally calling into set_alarm for some codepath. We have that > for DA9063, but it is not executed for the UIE test of rtctest. However, > it seems the driver doesn't support this in an optimal way, because > there is a currently unused update interrupt which should be used for > UIE, or? I also wonder why all this works fine for Steve. > I had a look at the driver and I guess you have a 9063AD while Steve uses another model. That explains why you need the uie_unsupported flag. The 9063AD can only do alarms on a minute boundary. Since the move to hr_timer, the uie are done using the classic alarm or they are emulated by the core. This improved the situation for many RTCs that don't have a separate UIE but this made it worse for a few (and this is an example). I have plan to work on this but didn't have the time yet. I suggest the following patch: === >From 37b2ab7d537e76e42bde64cf4b57701b0ed8e8cd Mon Sep 17 00:00:00 2001 From: Alexandre Belloni <alexandre.belloni@xxxxxxxxxxx> Date: Tue, 2 Apr 2019 10:06:46 +0200 Subject: [PATCH] rtc: da9063: set uie_unsupported when relevant The DA9063AD doesn't support alarms on any seconds and its granularity is the minute. Set uie_unsupported in that case. Reported-by: Wolfram Sang <wsa@xxxxxxxxxxxxx> Reported-by: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> Signed-off-by: Alexandre Belloni <alexandre.belloni@xxxxxxxxxxx> --- drivers/rtc/rtc-da9063.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/rtc/rtc-da9063.c b/drivers/rtc/rtc-da9063.c index 1b792bcea3c7..53e690b0f3a2 100644 --- a/drivers/rtc/rtc-da9063.c +++ b/drivers/rtc/rtc-da9063.c @@ -475,6 +475,9 @@ static int da9063_rtc_probe(struct platform_device *pdev) da9063_data_to_tm(data, &rtc->alarm_time, rtc); rtc->rtc_sync = false; + if (config->rtc_data_start != RTC_SEC) + rtc->rtc_dev->uie_unsupported = 1; + irq_alarm = platform_get_irq_byname(pdev, "ALARM"); ret = devm_request_threaded_irq(&pdev->dev, irq_alarm, NULL, da9063_alarm_event, -- 2.20.1 -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
