• G
    parisc: fix "delay!" timer handling · 84be31be
    Grant Grundler 提交于
    Rewrote timer_interrupt() to properly handle the "delayed!" case.
    
    If we used floating point math to compute the number of ticks that had
    elapsed since the last timer interrupt, it could take up to 12K cycles
    (emperical!) to handle the interrupt. Existing code assumed it would
    never take more than 8k cycles. We end up programming Interval Timer
    to a value less than "current" cycle counter.  Thus have to wait until
    Interval Timer "wrapped" and would then get the "delayed!" printk that
    I moved below.
    
    Since we don't really know what the upper limit is, I prefer to read
    CR16 again after we've programmed it to make sure we won't have to
    wait for CR16 to wrap.
    
    Further, the printk was between reading CR16 (cycle couner) and writing CR16
    (the interval timer). This would cause us to continue to set the interval
    timer to a value that was "behind" the cycle counter. Rinse and repeat.
    So no printk's between reading CR16 and setting next interval timer.
    
    Tested on A500 (550 Mhz PA8600).
    Signed-off-by: NGrant Grundler <grundler@parisc-linux.org>
    Tested-by: NKyle McMartin <kyle@mcmartin.ca>
    Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>
    
    ----
    Kyle, Helge, and other parisc's,
    Please test on 32-bit before committing.
    I think I have it right but recognize I might not.
    
    TODO: I wanted to use "do_div()" in order to get both remainder
    and value back with one division op. That should help with the
    latency alot but can be applied seperately from this patch.
    
    thanks,
    grant
    84be31be
time.c 7.8 KB