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 <fthain@xxxxxxxxxxxxxxxxxxx>
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
