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.camel@xxxxxxxxxxxxx/ 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
