Re: Shared Interrupts Question (2.4)

2 messages, 2 authors, 2003-05-10 · open the first message on its own page

Re: Shared Interrupts Question (2.4)

From: Kent Borg <hidden>
Date: 2003-05-09 17:34:17

On Thu, May 08, 2003 at 02:14:26PM -0700, Dale Farnsworth wrote:
Create and register a board-specific interrupt driver.  Assign it
a range of irqs (non-conflicting with the main interrupt driver).
When called with an irq outside its range, the board-specific driver
routines forward the call to the main driver.
Cool, cool...
The board-specific driver does a request_irq at init time for the
one main irq it is multiplexing.
What does my handler on the main irq do?  Perhaps nothing?

I am figuring I supply my own get_irq call, and it returns one of this
new interrupt range, or if none, calls the previous get_irq.  If I
never let the main irq number come back, my handler on the main irq
never gets called, right?  If so, why am calling request_irq in the
first place?  To keep the system from puking on spurious interrupts?
(But if I answer the get_irq, and if I never answer the main irq
number, how would it know?)


Thanks,

-kb, the Kent who thinks he is getting close.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Shared Interrupts Question (2.4)

From: Dale Farnsworth <hidden>
Date: 2003-05-10 02:00:14

On Fri, May 09, 2003 at 05:34:17PM +0000, Kent Borg wrote:
On Thu, May 08, 2003 at 02:14:26PM -0700, Dale Farnsworth wrote:
quoted
Create and register a board-specific interrupt driver.  Assign it
a range of irqs (non-conflicting with the main interrupt driver).
When called with an irq outside its range, the board-specific driver
routines forward the call to the main driver.
Cool, cool...
quoted
The board-specific driver does a request_irq at init time for the
one main irq it is multiplexing.
What does my handler on the main irq do?  Perhaps nothing?
Nothing.  You make sure that get_irq never returns that irq, so
the handler won't be called.
I am figuring I supply my own get_irq call, and it returns one of this
new interrupt range, or if none, calls the previous get_irq.  If I
never let the main irq number come back, my handler on the main irq
never gets called, right?  If so, why am calling request_irq in the
first place?
To enable (unmask) the main irq.  I think you're right, it's better
to not call request_irq and just enable the irq directly.
To keep the system from puking on spurious interrupts?
(But if I answer the get_irq, and if I never answer the main irq
number, how would it know?)
I'd call the main get_irq before checking for interrupt in my range.

my_get_irq() {
	int irq = main_get_irq();

	if (irq != my_irq)
		return irq;

	/* find which irq in my range cascaded into my_irq */
	irq = find_cascaded_irq();

	return irq;
}

-Dale

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help