On Sun, Dec 11, 2022 at 01:34:39PM +0100, Mark Kettenis wrote: > > Date: Fri, 9 Dec 2022 09:37:11 -0600 > > From: Scott Cheloha <scottchel...@gmail.com> > > > > On Thu, Dec 08, 2022 at 11:35:34AM +0100, Jeremie Courreges-Anglas wrote: > > > On Wed, Dec 07 2022, Scott Cheloha <scottchel...@gmail.com> wrote: > > > > ARMv7 has four interrupt clocks available. I think it'll be easier to > > > > review/test if we do the clockintr switch driver by driver instead of > > > > all at once in a massive single email. When all four driver patches > > > > are confirmed to work, I'll commit them. > > > > > > > > Here's a patch to switch agtimer(4/armv7) to clockintr. > > > > > > > > - Remove agtimer-specific clock interrupt scheduling bits > > > > and randomized statclock bits. > > > > > > > > - Wire up agtimer_intrclock. > > > > > > > > I am looking for a tester to help me get it compiling, > > > > > > Fails to build because of a signature mismatch for agtimer_trigger(), > > > updated diff below. > > > > > > > and then run it > > > > through a kernel-release-upgrade cycle. > > > > > > That's not what you're asking for, but no regression spotted on a cubox > > > machine - which seems to use amptimer(4) according to dmesg. > > > > Thanks miod@/jca@! > > > > So right now are looking for a tester for the attached patch, which > > *does* compile. > > > > An armv7 machine with agtimer(4/armv7). > > A fixed version (I applied your original diff and then fixed it up), > works on a Banana Pi with an Allwinner A20 that uses agtimer(4). > > ok kettenis@
Thanks for testing! To ensure that the patch committed is the one that actually works, please send me your fixed-up patch. Also, did you build a release and upgrade from it? If that's not possible (or it would take weeks) I can proceed as-is... but I would like to avoid breaking snaps and getting yelled at. You have some time, though. I can't commit any of the four arm/armv7 "clockintr switch" patches until they're all confirmed to work.
