lkml.org 
[lkml]   [2023]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC][PATCH 2/2] time: alarmtimer: Use TASK_FREEZABLE to cleanup freezer handling
Date
On Mon, Feb 27 2023 at 20:06, John Stultz wrote:
> On Mon, Feb 27, 2023 at 4:03 PM John Stultz <jstultz@google.com> wrote:
>> > On Mon, Feb 20 2023 at 19:11, Michael Nazzareno Trimarchi wrote:
>> > +static int alarmtimer_pm_notifier_fn(struct notifier_block *bl, unsigned long state,
>> > + void *unused)
>> > +{
>> > + switch (state) {
>> > + case PM_HIBERNATION_PREPARE:
>> > + case PM_POST_HIBERNATION:
>> > + atomic_set(&alarmtimer_wakeup, 0);
>> > + break;
>> > + }
>> > + return NOTIFY_DONE;
>>
>> But here, we're setting the alarmtimer_wakeup count to zero if we get
>> PM_HIBERNATION_PREPARE or PM_POST_HIBERNATION notifications?
>> And Michael noted we need to add PM_SUSPEND_PREPARE and
>> PM_POST_SUSPEND there for this to seemingly work.

Yup. I missed those when sending out that hack.

> So Thomas's notifier method of zeroing at the begining of suspend and
> tracking any wakeups after that point makes more sense now. It still
> feels a bit messy, but I'm not sure there's something better.

I'm not enthused about it either.

> My only thought is this feels a little bit like its mirroring what the
> pm_wakeup_event() logic is supposed to do. Should we be adding a
> pm_wakeup_event() to alarmtimer_fired() to try to prevent suspend from
> occuring for 500ms or so after an alarmtimer has fired so there is
> enough time for it to be re-armed if needed?

The question is whether this can be called unconditionally and how that
interacts with the suspend logic. Rafael?

Thanks,

tglx

\
 
 \ /
  Last update: 2023-03-27 00:41    [W:0.079 / U:2.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site