Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <cover.1542589838.git.fthain@telegraphics.com.au>
 <eb676d37a8e40b88f6c577b372b6512bc19a3394.1542589838.git.fthain@telegraphics.com.au>
 <CACz-3rh6Qw7YxeFK41KG_ju-bWHRoCaciWvv7JLeURn7wGVAOg@mail.gmail.com> <alpine.LNX.2.21.1811202034350.258@nippy.intranet>
In-Reply-To: <alpine.LNX.2.21.1811202034350.258@nippy.intranet>
From:   Kars de Jong <jongk@linux-m68k.org>
Date:   Wed, 21 Nov 2018 09:22:31 +0100
Message-ID: <CACz-3riTnjM-mt4TBLWVXFWtMbTvVgcuqjqi1h_bzuZzu-DXmg@mail.gmail.com>
Subject: Re: [RFC PATCH v2 09/14] m68k: hp300: Remove hp300_gettimeoffset()
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
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Op wo 21 nov. 2018 om 00:13 schreef Finn Thain <fthain@telegraphics.com.au>:
>
> On Tue, 20 Nov 2018, Kars de Jong wrote:
>
> > 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...
> >
>
> Me neither...
>
> I'll see if I can write a conversion patch based on the information you've
> provided. Can you test it?

I can try... It's been a while since I booted the machine to Linux
though (NFS support only).
MAME is also starting to support it, but not quite there yet :-)

> > According to NetBSD sources, there are 3 timers in the chip (originally
> > an MC6840 PTM).
>
> Thanks for the tip. I will examine the datasheet for the 6840.
>
> I'll also take another look at the NetBSD code.
>
> > 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.
>
> You mean, 250 kHz, right? The code in mainline programs the timer for 2500
> cycles, hoping to get 10 ms. That is, 250 cycles per ms.

Eh, yes, that makes a lot more sense.

> > The interrupt flag is set when the counter reaches 0 after which it is
> > automatically reloaded and starts counting down again.
> >
>
> Thanks.
>
> On atari, the 68901 counts down to 0x01 and raises an interrupt. On mac,
> the 6522 counts down to 0xFFFF then raises an interrupt. No idea about
> amiga (Geert?) -- this has to be handled correctly to get a monotonic
> clocksource. I'll fix this in v3 (where the information is available).

Cool!

Kars.