From: Thomas Gleixner <tglx@linutronix.de>
To: "dbasehore ." <dbasehore@chromium.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Peter Zijlstra <peterz@infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@redhat.com>,
Rajneesh Bhardwaj <rajneesh.bhardwaj@intel.com>,
the arch/x86 maintainers <x86@kernel.org>,
Platform Driver <platform-driver-x86@vger.kernel.org>,
Len Brown <len.brown@intel.com>,
Linux PM <linux-pm@vger.kernel.org>
Subject: Re: [PATCH v5 2/5] tick: Add freeze timer events
Date: Wed, 19 Jul 2017 00:22:23 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.20.1707190019500.2425@nanos> (raw)
In-Reply-To: <CAGAzgsoqjwK1HPK7jPKhC+YhH7EbVLjbYm+p-UARGmK_hvB=+A@mail.gmail.com>
On Tue, 18 Jul 2017, dbasehore . wrote:
> On Tue, Jul 18, 2017 at 2:53 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > On Tue, 18 Jul 2017, dbasehore . wrote:
> >> On Mon, Jul 17, 2017 at 11:40 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> >> > On Mon, 17 Jul 2017, dbasehore . wrote:
> >> >> On Mon, Jul 17, 2017 at 6:33 PM, Rafael J. Wysocki <rafael@kernel.org> wrote:
> >> >> I could make a patch to try it out. I would probably add a flag to rtc
> >> >> timers to indicate whether it wakes the system (default true). We
> >> >> would have to add a sync with the rtc irq and the rtc irqwork. I would
> >> >> probably add a rtc_timer_sync function that would flush the rtc irq
> >> >> and flush the irqwork. I would call this after the freeze_ops sync
> >> >> function since the sci irq needs to finish before syncing with the rtc
> >> >> irq. Also, pm_wakeup_irq seems racy with the current implementation of
> >> >> s2idle_loop since the RTC irq could be mistakenly set as pm_wakeup_irq
> >> >> when something else actually triggered the full wakeup. Fortunately, I
> >> >> don't think pm_wakeup_irq is used for anything except debugging, but
> >> >> we might change that.
> >> >
> >> > There is another option which you might consider. We can reserve one of the
> >> > HPET comparators for that purpose and have a special interrupt handler for
> >> > it. Checking the HPET for expiry from the low level code should be trivial.
> >> >
> >> Does that handle setting up new timers properly or does the timer sync
> >> code still need to be written?
> >
> > Sorry, I don't understand the question. What is timer sync code?
> >
>
> Does the comparator allow you to have a completely separate alarm set
> in the hardware? If there's another timer setup (say some user
> specified wake alarm), we need to program that alarm after the current
> one goes off if we aren't able to program multiple alarms at the same
> time.
The HPET consists of several independent comparator units. The kernel uses
only a limited set of them. We can reserve one or more for that purpose, so
it does not require any multiplexing or whatever. How many of them do you
need?
Thanks,
tglx
next prev parent reply other threads:[~2017-07-18 22:22 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-08 0:02 [PATCH v5 1/5] x86: stub out pmc function Derek Basehore
2017-07-08 0:03 ` [PATCH v5 2/5] tick: Add freeze timer events Derek Basehore
2017-07-08 16:05 ` Andy Shevchenko
2017-07-10 21:11 ` dbasehore .
2017-07-10 12:53 ` Rafael J. Wysocki
2017-07-12 21:25 ` Thomas Gleixner
2017-07-13 1:18 ` dbasehore .
2017-07-13 4:54 ` Thomas Gleixner
2017-07-13 7:32 ` Peter Zijlstra
2017-07-13 15:09 ` Rafael J. Wysocki
2017-07-13 22:58 ` dbasehore .
2017-07-15 12:39 ` Rafael J. Wysocki
2017-07-18 0:30 ` dbasehore .
2017-07-18 1:33 ` Rafael J. Wysocki
2017-07-18 3:52 ` dbasehore .
2017-07-18 6:40 ` Thomas Gleixner
2017-07-18 20:09 ` dbasehore .
2017-07-18 21:53 ` Thomas Gleixner
2017-07-18 22:03 ` dbasehore .
2017-07-18 22:22 ` Thomas Gleixner [this message]
2017-07-18 22:37 ` dbasehore .
2017-07-18 22:39 ` Thomas Gleixner
2017-07-08 0:03 ` [PATCH v5 3/5] x86, apic: Add freeze event support Derek Basehore
2017-07-13 5:13 ` Thomas Gleixner
2017-07-08 0:03 ` [PATCH v5 4/5] freeze: Add error reporting Derek Basehore
2017-07-08 0:03 ` [PATCH v5 5/5] intel_idle: Add S0ix validation Derek Basehore
2017-07-09 7:13 ` kbuild test robot
2017-07-10 13:33 ` Rafael J. Wysocki
2017-07-10 21:57 ` dbasehore .
2017-07-10 22:09 ` Rafael J. Wysocki
2017-07-10 22:24 ` dbasehore .
2017-07-11 14:57 ` Rafael J. Wysocki
2017-07-11 15:43 ` Len Brown
2017-07-12 22:16 ` Thomas Gleixner
2017-07-12 23:14 ` dbasehore .
2017-07-13 5:11 ` Thomas Gleixner
2017-07-13 22:49 ` dbasehore .
2017-07-13 1:06 ` dbasehore .
2017-07-08 16:00 ` [PATCH v5 1/5] x86: stub out pmc function Andy Shevchenko
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=alpine.DEB.2.20.1707190019500.2425@nanos \
--to=tglx@linutronix.de \
--cc=dbasehore@chromium.org \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=rajneesh.bhardwaj@intel.com \
--cc=rjw@rjwysocki.net \
--cc=x86@kernel.org \
/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