linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kars de Jong <jongk@linux-m68k.org>
To: fthain@telegraphics.com.au
Cc: geert@linux-m68k.org, philb@gnu.org, schwab@linux-m68k.org,
	arnd@arndb.de, schivers@csc.com.au, tglx@linutronix.de,
	daniel.lezcano@linaro.org, schmitzmic@gmail.com,
	john.stultz@linaro.org, linus.walleij@linaro.org,
	linux-m68k@lists.linux-m68k.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2 09/14] m68k: hp300: Remove hp300_gettimeoffset()
Date: Tue, 20 Nov 2018 10:09:13 +0100	[thread overview]
Message-ID: <CACz-3rh6Qw7YxeFK41KG_ju-bWHRoCaciWvv7JLeURn7wGVAOg@mail.gmail.com> (raw)
In-Reply-To: <eb676d37a8e40b88f6c577b372b6512bc19a3394.1542589838.git.fthain@telegraphics.com.au>

Op ma 19 nov. 2018 om 02:10 schreef Finn Thain <fthain@telegraphics.com.au>:
>
> hp300_gettimeoffset() never checks the timer interrupt flag and will
> fail to notice when the timer counter gets reloaded. That means the
> clock could jump backwards.
>
> Remove this code and leave this platform on the 'jiffies' clocksource.
> Note that this amounts to a regression in clock precision. However,
> adopting the 'jiffies' clocksource does resolve the monotonicity issue.
>
> Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
> ---
> hp300_gettimeoffset() cannot be used in a clocksource conversion
> unless it can be made monotonic. I can't fix this without knowing the
> details of the timer implementation, such as the relationship between
> the timer count and the interrupt flag.

I don't really like this regression...

According to NetBSD sources, there are 3 timers in the chip
(originally an MC6840 PTM). Timer 1 is used as the system timer, timer
3 runs at the same rate and is unused on Linux (on NetBSD it is used
as the statistics/profiling timer), and timer 3 is connected to timer
2 so you can make a 32-bit timer out of the two timers together (also
unused on Linux).

Timers 1 counts down at 25 MHz. The interrupt flag is set when the
counter reaches 0 after which it is automatically reloaded and starts
counting down again.

> ---
>  arch/m68k/hp300/time.c | 19 -------------------
>  1 file changed, 19 deletions(-)

  reply	other threads:[~2018-11-20  9:25 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-19  1:10 [RFC PATCH v2 00/14] m68k: Drop arch_gettimeoffset and adopt clocksource API Finn Thain
2018-11-19  1:10 ` [RFC PATCH v2 09/14] m68k: hp300: Remove hp300_gettimeoffset() Finn Thain
2018-11-20  9:09   ` Kars de Jong [this message]
2018-11-20 23:13     ` Finn Thain
2018-11-21  8:10       ` Geert Uytterhoeven
2018-11-21  8:41         ` Finn Thain
2018-11-21  8:55           ` Geert Uytterhoeven
2018-11-21  9:47             ` Finn Thain
2018-11-21 10:02               ` Geert Uytterhoeven
2018-11-21 11:14                 ` Finn Thain
2018-11-25  1:15                   ` Finn Thain
2018-11-25  2:44                     ` Michael Schmitz
2018-11-25  3:25                       ` Finn Thain
2018-11-21  8:22       ` Kars de Jong
2018-11-19  1:10 ` [RFC PATCH v2 07/14] m68k: atari: Convert to clocksource API Finn Thain
2018-11-19  8:35   ` Michael Schmitz
2018-11-20  8:10   ` Linus Walleij
2018-11-20  8:19     ` Geert Uytterhoeven
2018-11-20  9:30     ` Finn Thain
2018-11-20  9:53       ` Linus Walleij
2018-11-20 10:02     ` Andreas Schwab
2018-11-24  2:03       ` Michael Schmitz
2018-11-24  3:08         ` Finn Thain
2018-11-19  1:10 ` [RFC PATCH v2 08/14] m68k: bvme6000: " Finn Thain
2018-11-19  1:10 ` [RFC PATCH v2 11/14] m68k: mvme147: " Finn Thain
2018-11-19  1:10 ` [RFC PATCH v2 10/14] m68k: mac: " Finn Thain
2018-11-20  8:15   ` Linus Walleij
2018-11-20  9:00     ` Finn Thain
2018-11-20  9:59       ` Linus Walleij
2018-11-19  1:10 ` [RFC PATCH v2 04/14] m68k: apollo, q40, sun3, sun3x: Remove arch_gettimeoffset implementations Finn Thain
2018-11-19  1:10 ` [RFC PATCH v2 01/14] m68k: Call timer_interrupt() with interrupts disabled Finn Thain
2018-11-19  1:10 ` [RFC PATCH v2 03/14] m68k: mac: Clean up unused timer definitions Finn Thain
2018-11-20  1:02   ` Finn Thain
2018-11-19  1:10 ` [RFC PATCH v2 12/14] m68k: mvme147: Handle timer counter overflow Finn Thain
2018-11-19  1:10 ` [RFC PATCH v2 13/14] m68k: mvme16x: Convert to clocksource API Finn Thain
2018-11-19  1:10 ` [RFC PATCH v2 02/14] m68k: mac: Fix VIA timer counter accesses Finn Thain
2018-11-19  1:10 ` [RFC PATCH v2 06/14] m68k: amiga: Convert to clocksource API Finn Thain
2018-11-20  8:04   ` Linus Walleij
2018-11-19  1:10 ` [RFC PATCH v2 05/14] m68k: Drop ARCH_USES_GETTIMEOFFSET Finn Thain
2018-11-19  1:10 ` [RFC PATCH v2 14/14] m68k: mvme16x: Handle timer counter overflow Finn Thain

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=CACz-3rh6Qw7YxeFK41KG_ju-bWHRoCaciWvv7JLeURn7wGVAOg@mail.gmail.com \
    --to=jongk@linux-m68k.org \
    --cc=arnd@arndb.de \
    --cc=daniel.lezcano@linaro.org \
    --cc=fthain@telegraphics.com.au \
    --cc=geert@linux-m68k.org \
    --cc=john.stultz@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=philb@gnu.org \
    --cc=schivers@csc.com.au \
    --cc=schmitzmic@gmail.com \
    --cc=schwab@linux-m68k.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).