Re: Ingo's realtime_preempt patch causes kernel oops

[Steven Rostedt <rostedt@goodmis.org>]

On Wed, 2006-05-24 at 18:03 +0200, Thomas Gleixner wrote:
> On Wed, 2006-05-24 at 11:52 -0400, Steven Rostedt wrote:
> > > > As I said yesterday. You need a demultiplexer for such cases.
> > > > 
> > > 
> > > Would IRQs stay masked until the thread has finished running?
> > 
> > I would say yes.  But the system is basically broken if you have the
> > same interrupt line that needs both to be threaded and NODELAY.
> > 
> > Basically, the best I can think to have for such a case, is all
> > interrupt threads that have a shared NODELAY run at MAX_PRIO (99).  So
> > that they act like a NODELAY interrupt, in that they run over everything
> > else, but they can still schedule.
> 
> Err. That's why you use demultiplexers. The demux handler is always
> NODELAY.
> 
> shared IRQ
> -> demux_handler
> 	disable shared irq
> 	identify interrupt sources
> 	for all sources:
> 		calculate the interrupt number
> 		irq_desc[number]->handle_irq(.....)
> 			disable/ack a particular source
> 			if NODELAY 
> 				call handler and reenable if appropriate
> 			else 
> 				wakeup thread
> 	enable shared irq
> 
> That's the way you really want to do it. Granted, that this is not
> possible with the current implementation of PCI cards, but for the SoC
> peripherals this is usually simple to do.
> 
> The ARM tree has tons of examples which do exactly this.
> 

OK I haven't worked on arm much at all. Only had to port one board
before, and didn't need to get too involved.

Can't two devices share the same interrupt line? Not talking about a
cascading interrupt controller, but two actual devices that can trigger
a single interrupt line.  So, if this is the case, how do you disable a
particular source without going to the driver itself?

If this is not the case, and the interrupt line that is shared has
another controller that the devices are separated on, then this is
trivial.  But I don't know the setup in question.

-- Steve