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

[Steve Twiss]

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