Ralf Baechle wrote:
On Thu, Jun 07, 2007 at 09:59:53AM +0200, Franck Bui-Huu wrote:
I'm working on getting dyntick and highres timer support working for MIPS.
This unavoidably implies dumping most of the MIPS-private time
infrastructure we've piled up over the past decade. Which really is a
major crapectomy. A first cut of the patches which are tested to
run
That's definitely true. I wrote my own version of clockevent support
yesterday based on your patchset "dyntick-quilt" and I end up rewrite
the whole time.c. The biggest part of the job would be to split this
into several patches to ease the review but I doubt it worth it since
we rewrite it almost from scratch.
I'm actually getting closer and closer to the point where keep things in
a nicely split patchset stops being workable.
Actually I'm wondering if we shouldn't create a new file
"arch/mips/kernel/time2.c" which will be a complete rewrite of the
old one (interrupt handler, function pointers, clocksource,
clockevent). This file would be the future replacement of the old
time.c. This new file would be used only if the board have been
updated accordingly. That may help to migrate...
Another issue I have is to implement clockevent set_mode() method. You
left it empty but I think we need at least to shut down the timer
interrupt when setting the clock event device. Strangely I haven't
found a "generic" way to stop them through cp0. Have I missed
something ?
You can mask the count/compare interrupt in the status register like any
other interrupt. Keep in mind that on many CPUs this interrupt is
shared with the performance counter interrupt so cannot always be
disabled.
Well this interrupt could be shared with other devices too, couldn't it ?
If so only the board code can disable it.
There is no other disable bit for this interrupt than the IE bit in the
status register. So it may just have to be ignored.
That would mean we can't have a tickless system in these cases, wouldn't
it ?
Other issues to solve:
o The R4000/R4400 (others?) allow the use of hwint5 for either the
count/compare interrupt or as a normal hardware interrupt. The switch
happens based on a bootstream setting. There is no config register
bit for this, so we either have to hardcode the knowledge about the
affected machines or construct a probe. Where the count/compare is
not usable we cannot use this as a clockevent device.
o Old revisions of the R4000 have a bug where if the count register is
read in exactly the moment where it matches the compare register the
timer interrupt is lost. This means the system will be interrupt-less
for the next typicall like 86s (at the typical 100MHz clock for the
affected processors). The workaround needs to be implemented.
Both are currently the least of my concerns, there is much bigger fish to
catch ...
I agree a first implementation without these concerns addressed would
be easier. But it's still good to keep them in mind.
BTW any idea when "time-ntp-make-cmos-update-generic.patch" is going
to be merged into mainline ? Note: I think there's a bug in
notify_cmos_timer(). The following test should be negated, shouldn't
it ?
+ if (no_sync_cmos_clock)
+ mod_timer(&sync_cmos_timer, jiffies + 1);
In theory the patch should be in -mm to be merged early just after .22.
Haven't found any trace of it.
--
Franck
