Hi, > > > 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; > > > + > > > > I think we should have a comment here, like: > > /* FIXME: Make use of the TICK interrupt once the RTC core supports it */
Is this TICK interrupt suggestion to use the DA9063 TICK interrupt to simulate a second granularity in the AD alarm? If I remember correctly, the original DA9063 patch set which was for AD silicon only, and which was sent to LKML before I took over looking at DA9063, used the DA9063 1-second TICK interrupt to count-down the seconds from the nearest minute in order to simulate second resolution on the RTC alarm for AD. ... yes. Here it is. The original patch was from Krystian Garbaciak and tried to support RTC alarms on the AD silicon to a second resolution by counting down the DA9063 TICK interrupt: https://marc.info/?l=lm-sensors&m=134613501230005&w=2 However, I dropped that patch completely and wrote a new RTC device driver because it didn't work in my tests. The problem was: the TICK interrupt was indistinguishable from the ALARM interrupt for a wake event and when I tested AD silicon to wake up an Android device from suspend or power-off using the RTC IRQ, the device woke up on the ALARM minute (0 seconds), discovered it was not the correct time and immediately went back to sleep. Then it woke-up and returned back to sleep every TICK IRQ second until the correct alarm time was reached (up to 59 times!). At which point it woke up properly. Regards, Steve
