On Fri, 2024-08-02 at 12:49 +0200, Thomas Gleixner wrote:
> On Fri, Aug 02 2024 at 09:07, David Woodhouse wrote:
> > On Thu, 2024-08-01 at 20:57 +0200, Thomas Gleixner wrote:
> > > It's not counting right out of reset. But once it started counting it's
> > > tedious to stop :)
> > 
> > My reading of the data sheet definitely suggests that it *shouldn't*
> > be.
> > 
> > Mode 0 says: "The output will be initially low after the mode set
> > operation. After the count is loaded into the selected count
> > register... the counter will count."
> 
> Hmm. Indeed. That does not stop the counter, but it prevents the
> interrupt from firing over and over.
> 
> So fine, we can go with the patch from Li, but the changelog needs a
> rewrite and the code want's a big fat comment.

Nah, it wants to be MODE, COUNT, COUNT, MODE to handle all known
implementations.

Already posted as [PATCH 2/1] (with big fat comments and a version of
your test) at

https://lore.kernel.org/kvm/3bc237678ade809cc685fedb8c1a3d435e590639.ca...@infradead.org/

Although I just realised that I edited the first patch (to *remove* the
now-bogus comments about the stop sequence) before posting that one, so
they don't follow cleanly from one another; there's a trivial conflict.
I also forgot to remove the pre-1999 typedefs from the test program,
despite fixing it to use <stdint.h> like it's the 21st century :)

Top two commits of
https://git.infradead.org/users/dwmw2/linux.git/shortlog/refs/heads/clocks

I'll repost properly if you're happy with them?

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to