Re: [PATCH 1/2] rtc: da9063: set range

[Alexandre Belloni]

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:

===