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.
> 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.
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.
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 ...
> 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.
> The other patch named "time-move-to_tm-to-lib.patch" create a new file
> in arch/mips/lib directory. This new file is called
> "to_tm.c". Shouldn't we call it something less specific like "time.c" ?
I actually may drop that one for now. Two problems with it:
o to_tm() is being used in modules but having the function in a lib means
it may not be linked into the kernel so the modules might fail.
o arch/mips/lib is not the right place anyway. There are several nearly
identical copies of the function around under arch/ so they should be
unified.
Ralf
