On Wed, Dec 18, 2002 at 05:14:19PM +0100, Maciej W. Rozycki wrote: > On Tue, 17 Dec 2002, Jun Sun wrote: > > > > > No MIPS boards are using do_slow_gettimeoffset(). We really should get > > > > rid of it. > > > > > > I know none does at the moment. But are you sure there is no system that > > > would need it and might be supported one day? > > > > I serisouly don't think so. Moving forward every CPU will have a CPU counter, > > which can be used for timeoffset purpose. Even if it does not have one, > > it will surely have some onboard high resolution timer, which can be used > > to intra-jiffy offset purpose. > > Well, I do hope so, too, but you'll never know until you find out. ;-) > > > > Here is an example (untested) code that I would recommend. It sends > > > explicit ACKs to the i8259As, which has the following advantages: > > > > > <snip> > > > > Cool. This code works for me. > > Excellent. I worked on the code a bit more and removed the spurious IRQ > stuff. It's not really necessary -- mask_and_ack_8259A() will deal with > it anyway (a bit less precisely, but we don't care -- they are very rare > and drivers absolutely have to be able to deal with spurious interrupts) > and we want the low-level IRQ handling to be fast as it's performance > critical. At this point the function became so compact it would be > unreasonable not to make it inline -- the generated code is 24 > instructions on my system. The positive side effect is the code won't be > compiled for systems that don't use it. > > Following is a patch that I consider a candidate for submission. I > changed the interface a bit to permit greater flexibility. I renamed the > function to reflect the new semantic. Unless special handling is needed > you may simply call: > > do_IRQ(poll_8259A_irq(), regs); > I actually don't like the new semantic. The main drawback is that we can't dispatch a 8259A interrupt from assemably code, which is often needed. What is wrong with original way of dispatching? The general interrupt dispatching flow is that you chase the routing path until you find the final source and do a do_IRQ(). That seems fine with i8259A case here. While there is certain urge to create asm/i8259a.h file, if in the end all there is two function declarations (i8259_init() and dispatch_i8259_irq()), it is not really worth it. Jun
