linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: John Stultz <jstultz@google.com>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Alessandro Zummo <a.zummo@towertech.it>,
	Benson Leung <bleung@chromium.org>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stephen Boyd <sboyd@kernel.org>,
	linux-rtc@vger.kernel.org, linux-kernel@vger.kernel.org,
	Brian Norris <briannorris@chromium.org>
Subject: Re: [PATCH v2 2/7] rtc: alarmtimer: Use maximum alarm time offset
Date: Thu, 24 Aug 2023 22:46:51 -0700	[thread overview]
Message-ID: <1dfdd796-3ea3-4c7b-b0b6-cf8a50513e87@roeck-us.net> (raw)
In-Reply-To: <CANDhNCqd5VdwGaqHdeFK=Sui+fX_s7SxXnto9jdF_+0c-cuYSw@mail.gmail.com>

On Thu, Aug 24, 2023 at 08:52:44PM -0700, John Stultz wrote:
> On Thu, Aug 17, 2023 at 3:55 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > Some userspace applications use timerfd_create() to request wakeups after
> > a long period of time. For example, a backup application may request a
> > wakeup once per week. This is perfectly fine as long as the system does
> > not try to suspend. However, if the system tries to suspend and the
> > system's RTC does not support the required alarm timeout, the suspend
> > operation will fail with an error such as
> >
> > rtc_cmos 00:01: Alarms can be up to one day in the future
> > PM: dpm_run_callback(): platform_pm_suspend+0x0/0x4a returns -22
> > alarmtimer alarmtimer.4.auto: platform_pm_suspend+0x0/0x4a returned -22 after 117 usecs
> > PM: Device alarmtimer.4.auto failed to suspend: error -22
> >
> > This results in a refusal to suspend the system, causing substantial
> > battery drain on affected systems.
> >
> > To fix the problem, use the maximum alarm time offset as reported by rtc
> > drivers to set the maximum alarm time. While this will result in brief
> > spurious wakeups from suspend, it is still much better than not suspending
> > at all.
> >
> > Cc: Brian Norris <briannorris@chromium.org>
> > Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> > ---
> > v2: Rename range_max_offset -> alarm_offset_max
> >
> >  kernel/time/alarmtimer.c | 13 +++++++++++++
> >  1 file changed, 13 insertions(+)
> >
> > diff --git a/kernel/time/alarmtimer.c b/kernel/time/alarmtimer.c
> > index 8d9f13d847f0..895e3a6d6444 100644
> > --- a/kernel/time/alarmtimer.c
> > +++ b/kernel/time/alarmtimer.c
> > @@ -290,6 +290,19 @@ static int alarmtimer_suspend(struct device *dev)
> >         rtc_timer_cancel(rtc, &rtctimer);
> >         rtc_read_time(rtc, &tm);
> >         now = rtc_tm_to_ktime(tm);
> > +
> > +       /*
> > +        * If the RTC alarm timer only supports a limited time offset, set
> > +        * the alarm time to the maximum supported value.
> > +        * The system will wake up earlier than necessary and is expected
> > +        * to go back to sleep if it has nothing to do.
> > +        * It would be desirable to handle such early wakeups without fully
> > +        * waking up the system, but it is unknown if this is even possible.
> > +        */
> > +       if (rtc->alarm_offset_max &&
> > +           rtc->alarm_offset_max * MSEC_PER_SEC < ktime_to_ms(min))
> > +               min = ms_to_ktime(rtc->alarm_offset_max * MSEC_PER_SEC);
> 
> I don't really have an objection here, but I wonder if this would be
> better abstracted by a rtc_ function?
> 
> ktime_t rtc_bound_ktime_interval(ktime interval)

Probably more like like rtc_bound_alarm_interval(),
but fine with me.

> {
>   if (!rtc->alarm_offset_max)
>       return interval;
>   return ms_to_ktime(min(rtc->alarm_offset_max, ktime_to_ms(interval)));

alarm_offset_max is in seconds, so that would need some tweaking.

Guenter

> }
> 
> (simple enough to throw into rtc.h maybe as an inline function?)
> 
> Then the above would be tweaked to:
> min = rtc_bound_interval(min);
> 
> thanks
> -john

  reply	other threads:[~2023-08-25  5:47 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-17 22:55 [PATCH v2 0/7] rtc: Add support for limited alarm timer offsets Guenter Roeck
2023-08-17 22:55 ` [PATCH v2 1/7] " Guenter Roeck
2023-08-23 16:50   ` Guenter Roeck
2023-08-23 22:51     ` Alexandre Belloni
2023-08-24  3:26       ` Guenter Roeck
2023-08-17 22:55 ` [PATCH v2 2/7] rtc: alarmtimer: Use maximum alarm time offset Guenter Roeck
2023-08-25  3:52   ` John Stultz
2023-08-25  5:46     ` Guenter Roeck [this message]
2023-08-26 11:15     ` Guenter Roeck
2023-08-29 21:50   ` Stephen Boyd
2023-08-30  7:13     ` Guenter Roeck
2023-08-30 21:16       ` Stephen Boyd
2023-08-31  4:23         ` Guenter Roeck
2023-09-06 21:06           ` Stephen Boyd
2023-08-17 22:55 ` [PATCH v2 3/7] rtc: cros-ec: Detect and report supported alarm window size Guenter Roeck
2023-08-17 22:55 ` [PATCH v2 4/7] rtc: cmos: Report supported alarm limit to rtc infrastructure Guenter Roeck
2023-08-17 22:55 ` [PATCH v2 5/7] rtc: tps6586x: Report maximum alarm limit to rtc core Guenter Roeck
2023-08-17 22:55 ` [PATCH v2 6/7] rtc: ds1305: " Guenter Roeck
2023-08-17 22:55 ` [PATCH v2 7/7] rtc: rzn1: " Guenter Roeck
2023-08-18  7:32   ` Miquel Raynal
2023-08-27 21:51 ` (subset) [PATCH v2 0/7] rtc: Add support for limited alarm timer offsets Alexandre Belloni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1dfdd796-3ea3-4c7b-b0b6-cf8a50513e87@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=a.zummo@towertech.it \
    --cc=alexandre.belloni@bootlin.com \
    --cc=bleung@chromium.org \
    --cc=briannorris@chromium.org \
    --cc=jstultz@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rtc@vger.kernel.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=sboyd@kernel.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).