- From: Calin A. Culianu <calin_at_ajvar.org>
- Date: Tue, 24 Jan 2006 21:08:05 -0500 (EST)
I guess you are exposing my lapses in PC hardware knowledge. I should know this but I don't.. and actually I was concerned about this when I was writing an RT driver for a sound board and I was worried about interrupt sharing (my solution was just to make sure the board was in a slot such that it gets its own dedicated interrupt). So basically, when a board asserts an interrupt, it will keep the line high (since PCI interrupts are level-triggered) until the board is satisfied (most probably by the ISR for the board setting some bits in a register to acknowledge the interrupt)? Since the line is always high, it will continue to generate interrupts as far as the interrupt controller is concerned whenever that interrupt is masked on? Or am I misunderstanding the scheme? I guess I could google around for it... I somehow thought the interrupt controller is involved in forcing the interrupt line low again... so that other boards can issue interrupts on the same line as quickly as possible -- even if the original interrupt is not fully serviced.. but I guess that was wishful thinking on my part. It actually makes little sense for the interrupt controller to do this since in most general purpose OS's, each driver's ISR should know how to tell the board to shut up, basically. So you are basically describing it as: A pended (to Linux) interrupt will be masked out until it is serviced by linux (otherwise you get infinite calls to the rt handler)... thus priority inverting the RT ISR you actually want to run...? -Calin On Tue, 24 Jan 2006, Frank Mori Hess wrote: > On Tuesday 24 January 2006 12:21 am, Calin A. Culianu wrote: >> Well regular RT tasks run with interrupts enabled anyway. They just >> pend linux interrupts until the RT system is idle. The small RTLinux >> and real-time ISRs always get to run, even in RTLinux, RTAi, etc. Not >> sure I agree with that design but that's the way it works. At least >> that's my understanding. Am I wrong? > > My point is: > > non rt device has interrupt-> > > shared pci interrupt asserted-> > > rt handler runs (does nothing)-> > > interrupt still asserted-> > > rt handler disabled until non rt device handler is run and interrupt line > is no longer asserted > > The only way I can see they could still guarantee any bound on latency is > if they run the rt handler in a polling mode every N microseconds off of > timer interrupts while the shared interrupt remains asserted. > > -- > Frank > >
Received on 2006-01-25Z02:08:05