All of lore.kernel.org
 help / color / mirror / Atom feed
From: <markus.stockhausen@gmx.de>
To: "'Daniel Lezcano'" <daniel.lezcano@linaro.org>, <tglx@linutronix.de>
Cc: <howels@allthatwemight.be>, <bjorn@mork.no>,
	<linux-kernel@vger.kernel.org>
Subject: AW: AW: [PATCH 1/4] clocksource/drivers/timer-rtl-otto: work around dying timers
Date: Wed, 10 Sep 2025 20:16:22 +0200	[thread overview]
Message-ID: <020f01dc227f$03e40b60$0bac2220$@gmx.de> (raw)
In-Reply-To: <38633f6f-c14c-4a74-b372-cdfdab80619e@linaro.org>

> Von: Daniel Lezcano <daniel.lezcano@linaro.org> 
> Gesendet: Mittwoch, 10. September 2025 18:39
>
> > What I tried:
> > 
> > 1. Read out the current (remaining) timer value: In the error cases
> > this can give any value between 1 (=320ns) and 15 (=4800ns).
> > 
> > 2. Check if IRQ flag is already set and IRQ might trigger next. This was
> > never the case.
>
> It would have been interesting to check if we are in the time bug range 
> to wait with a delay (5us), check the IRQ flag as the current timer 
> should have expired, then set the counter and recheck the IRQ flag.

It's been 2 months that I dived deep into this case. Finding a 
reproducer, adding lightweight logging and try&error a solution 
was really hard. In the end I was happy to have a fix that was 
intensively tested.

For some notes see
https://github.com/openwrt/openwrt/pull/19468#issuecomment-3095570297

From what I remember:

- I started on a multithreading SoC and went over to a single
core SoC to reduce side effects during analysis. 

- The timer never died when it was reprogrammed from
an interrupt of a just finished timer. The reason was always
a reprogramming from outside the interrupt->reprogram
call sequence.

- Reprogramming always worked fine. A timer with <5us left, was 
restarted with a timer >5us. The new timer started to count.
No interrupt flag seemed to be magically toggled during this 
process. There was no active IRQ notification directly after the
reprogramming. That was how I expected it.

- But in rare cases the new timer did not trigger the subsequent
interrupt. I was totally confused that the future interrupt of 
a newly started timer did not work.

Graphically:

- timer run ---+-------------------->|
               | issue stop & start 
               | timer run ------------------>|
                                              | no IRQ here

Conclusion was for me: If we "kill" a running timer and restart 
it and it will not fire an interrupt after the newly set time, 
then something must be somehow broken. The ending timer and 
the stop/start sequence (that consists of two register writes) 
have some interference. Whatever it might be.

Markus


  reply	other threads:[~2025-09-10 18:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-04  8:03 [PATCH 0/4] clocksource/drivers/timer-rtl-otto: enhancements Markus Stockhausen
2025-08-04  8:03 ` [PATCH 1/4] clocksource/drivers/timer-rtl-otto: work around dying timers Markus Stockhausen
2025-09-10  9:02   ` Daniel Lezcano
2025-09-10 10:16     ` AW: " markus.stockhausen
2025-09-10 16:39       ` Daniel Lezcano
2025-09-10 18:16         ` markus.stockhausen [this message]
2025-09-10 20:53           ` AW: " Daniel Lezcano
2025-08-04  8:03 ` [PATCH 2/4] clocksource/drivers/timer-rtl-otto: drop set_counter function Markus Stockhausen
2025-08-04  8:03 ` [PATCH 3/4] clocksource/drivers/timer-rtl-otto: do not interfere with interrupts Markus Stockhausen
2025-08-04  8:03 ` [PATCH 4/4] clocksource/drivers/timer-rtl-otto: simplify documentation Markus Stockhausen
2025-09-10 20:54 ` [PATCH 0/4] clocksource/drivers/timer-rtl-otto: enhancements Daniel Lezcano
2025-09-10 21:15   ` AW: " markus.stockhausen

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='020f01dc227f$03e40b60$0bac2220$@gmx.de' \
    --to=markus.stockhausen@gmx.de \
    --cc=bjorn@mork.no \
    --cc=daniel.lezcano@linaro.org \
    --cc=howels@allthatwemight.be \
    --cc=linux-kernel@vger.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 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.