On Tue, 13 Nov 2018, Michael Schmitz wrote: > Hi Finn, > > Am 12.11.2018 um 22:06 schrieb Finn Thain: > > On Mon, 12 Nov 2018, Geert Uytterhoeven wrote: > > > > > Hi Finn, > > > > > > Thanks for your patch! > > > > > > On Mon, Nov 12, 2018 at 5:46 AM Finn Thain <fth...@telegraphics.com.au> > > > wrote: > > > > The functions that implement arch_gettimeoffset are re-used by > > > > new clocksource drivers in subsequent patches. > > > > > > Disabling this first affects functionality during bisection, right? > > > > > > > It means that all platforms have to use the 'jiffies' clocksource. > > So all that happens is timer granularity drops to 10ms, then gets restored by > the later patches? >
Yes, that was the plan, but I can't confirm that it worked out as I don't have any physical 68k hardware in front of me right now. If you can confirm this on your Atari Falcon, that would be great. (It appears that a QEMU-emulated Mac does not benefit from having a clocksource that's more accurate than the 'jiffies' clocksource, in spite of "clocksource: Switched to clocksource via1".) The latest patches can be found at https://github.com/fthain/linux/commits/mac68k-queue/ -- > I doubt that would be a large enough regression to matter for bisection, but > the way you reuse the arch_gettimeoffset() code for the new read_clock() > functions makes reordering of this patch to the end of the series impossible. > > Best you can don, under the circumstances. > > Cheers, > > Michael > >
