From: David Laight <David.Laight@ACULAB.COM>
To: "'Maciej W. Rozycki'" <macro@orcam.me.uk>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: "linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: RE: [PATCH] MIPS: Fix CP0 counter erratum detection for R4k CPUs
Date: Fri, 29 Apr 2022 15:24:48 +0000 [thread overview]
Message-ID: <3582358fb8ae47d7b88f85aa895a7109@AcuMS.aculab.com> (raw)
In-Reply-To: <alpine.DEB.2.21.2204291119040.9383@angie.orcam.me.uk>
> That said reading from the 8254 is messy too and you may need a spinlock
> (you need to write the Counter Latch or Read-Back command to the control
> register and then issue consecutive two reads to the requested timer's
> data register[2]). Which is I guess why support for it has been removed
> from x86 code. For non-SMP it might be good enough.
It is important to 'latch' the counter before reading it.
I tried to optimise some code to avoid the extra accesses.
In principle it ought to have worked, but reading the
unlatched values gave garbage - not just messed up 16bit values.
It was probably returning a value that was being ripple-counted.
The sheer number of IO cycles you need to read the counters
just beggars belief.
So while they can be used to get an accurate timestamp it
really takes too long to be useful.
Even in a modern x86 chipset I think they are still ISA
speed cycles.
(Mind you, we've an fpga based PCIe boards where reads
are ISA speed....)
OTOH I'd have though that for a real 486 (one without a TSC)
that is the only way to get a high res timer count.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2022-04-29 15:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-24 11:46 [PATCH] MIPS: Fix CP0 counter erratum detection for R4k CPUs Maciej W. Rozycki
2022-04-29 10:01 ` Thomas Bogendoerfer
2022-04-29 10:55 ` Maciej W. Rozycki
2022-04-29 15:24 ` David Laight [this message]
2022-04-29 13:04 ` Philippe Mathieu-Daudé
2022-04-29 13:53 ` Thomas Bogendoerfer
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=3582358fb8ae47d7b88f85aa895a7109@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=macro@orcam.me.uk \
--cc=stable@vger.kernel.org \
--cc=tsbogend@alpha.franken.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).