From: Michael Ellerman <mpe@ellerman.id.au>
To: "Nicholas Piggin" <npiggin@gmail.com>,
"Michal Suchánek" <msuchanek@suse.de>
Cc: miguel.ojeda.sandonis@gmail.com, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] powerpc/time: Always set decrementer in timer_interrupt()
Date: Fri, 29 Apr 2022 22:42:45 +1000 [thread overview]
Message-ID: <878rro9i2i.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <1651119254.5iw3tsme9w.astroid@bobo.none>
Nicholas Piggin <npiggin@gmail.com> writes:
> Excerpts from Nicholas Piggin's message of April 21, 2022 12:07 pm:
>> Excerpts from Michal Suchánek's message of April 21, 2022 12:28 am:
>>> Hello,
>>>
>>> On Thu, Apr 21, 2022 at 12:16:57AM +1000, Michael Ellerman wrote:
>>>> This is a partial revert of commit 0faf20a1ad16 ("powerpc/64s/interrupt:
>>>> Don't enable MSR[EE] in irq handlers unless perf is in use").
>>>>
>>>> Prior to that commit, we always set the decrementer in
>>>> timer_interrupt(), to clear the timer interrupt. Otherwise we could end
>>>> up continuously taking timer interrupts.
>>>>
>>>> When high res timers are enabled there is no problem seen with leaving
>>>> the decrementer untouched in timer_interrupt(), because it will be
>>>> programmed via hrtimer_interrupt() -> tick_program_event() ->
>>>> clockevents_program_event() -> decrementer_set_next_event().
>>>>
>>>> However with CONFIG_HIGH_RES_TIMERS=n or booting with highres=off, we
>>>
>>> How difficult is it to detect this condition?
>>>
>>> Maybe detecting this could be just added?
>>
>> Possibly not too difficult but I'd like to see if we can get this to work
>> in core timer code -
>>
>> https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-April/242212.html
>>
>> I'll resend as a patch and see what flamage I get...
>
> tglx merged it into his tree, so we could try again after its
> upstream.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=timers/core&id=62c1256d544747b38e77ca9b5bfe3a26f9592576
>
> I'm kind of worried the patch will explode some strange clock event
> device in an obscure way so we may wait for a release or two first.
Hah yep, :face-with-cold-sweat:
I created an issue so hopefully we don't forget:
https://github.com/linuxppc/issues/issues/408
cheers
next prev parent reply other threads:[~2022-04-29 12:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-20 14:16 [PATCH] powerpc/time: Always set decrementer in timer_interrupt() Michael Ellerman
2022-04-20 14:28 ` Michal Suchánek
2022-04-21 2:07 ` Nicholas Piggin
2022-04-28 4:18 ` Nicholas Piggin
2022-04-29 12:42 ` Michael Ellerman [this message]
2022-04-21 6:42 ` Michael Ellerman
2022-04-21 2:04 ` Nicholas Piggin
2022-04-24 12:15 ` Michael Ellerman
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=878rro9i2i.fsf@mpe.ellerman.id.au \
--to=mpe@ellerman.id.au \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=msuchanek@suse.de \
--cc=npiggin@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.