Shared Interrupts Question (2.4)

Shared Interrupts Question (2.4)

[Kent Borg]

I am trying to understand "kinda shared" interrupts.

There are various interrupts in my not-yet-released CPU, and I have
interrupt code that knows how to talk to them.  So far so good.  I
also have an external interrupt controller that groups together 18
external interrupt sources and sends them in one CPU pin.  This
external controller has a register for enabling interrupts, and a
register for status/acknowledge.  Pretty standard.

The CPU code doesn't know about the external controller.  It seems
silly to rewrite the CPU-specific interrput code to accommodate this
board-specific detail (besides then my code won't match Dale's).  So I
figure I tell the kernel I am doing shared interrupts.

So where do I enable, disable, and acknowledge these external bits?
Specifically, I am trying to get a couple of serial ports working.  I
can put conditional code in serial.c startup() to enable these
interrupts, but how do I know which serial port?  Add a conditionally
compiled sub-IRQ number to serial_state structure?

Is there a cleaner way?


Thanks,

-kb


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

Re: Shared Interrupts Question (2.4)

[bhupinder sahran]

Hi

U r saying from the interrupt controller only one
physical line is coming to CPU to interrupt CPU.

SO in the do_irq routine u will have to read the
interrupt controller registers & find out who has
caused the interrupt & then invoke interrupt handler
corressponding to the interrupt number.

U should have a way, from the CPU to read the
interrupt controller registers & find out the
cause.....................


Bhupi
Linux+Hypertransport -->Silicon
www.gdatech.com
Good after beer -- Linux




--- Kent Borg <kentborg@borg.org> wrote:
>
> I am trying to understand "kinda shared" interrupts.
>
> There are various interrupts in my not-yet-released
> CPU, and I have
> interrupt code that knows how to talk to them.  So
> far so good.  I
> also have an external interrupt controller that
> groups together 18
> external interrupt sources and sends them in one CPU
> pin.  This
> external controller has a register for enabling
> interrupts, and a
> register for status/acknowledge.  Pretty standard.
>
> The CPU code doesn't know about the external
> controller.  It seems
> silly to rewrite the CPU-specific interrput code to
> accommodate this
> board-specific detail (besides then my code won't
> match Dale's).  So I
> figure I tell the kernel I am doing shared
> interrupts.
>
> So where do I enable, disable, and acknowledge these
> external bits?
> Specifically, I am trying to get a couple of serial
> ports working.  I
> can put conditional code in serial.c startup() to
> enable these
> interrupts, but how do I know which serial port?
> Add a conditionally
> compiled sub-IRQ number to serial_state structure?
>
> Is there a cleaner way?
>
>
> Thanks,
>
> -kb
>
>
>


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

Re: Shared Interrupts Question (2.4)

[Kent Borg]

On Thu, May 08, 2003 at 01:20:12PM -0700, bhupinder sahran wrote:
> SO in the do_irq routine u will have to read the
> interrupt controller registers & find out who has
> caused the interrupt & then invoke interrupt handler
> corressponding to the interrupt number.

Yes, but how do I enable the interrupt in the first place?  (Disable
too.)  I mean, I know how to set the bit, but where is the best place
to do so?  In the case of a serial port, I figure I could turn it on
in startup() in serial.c.  But then how do I know which of two
possible interrupts it is?  I could do something hacky, like look at
the UART address and infer from there, but that looks nasty...


Thanks,

-kb, the Kent who, if has to muck with existing kernel files, wants to
do so in an acceptable way.

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

Re: Shared Interrupts Question (2.4)

[Dale Farnsworth]

On Thu, May 08, 2003 at 08:08:56PM +0000, Kent Borg wrote:
>
> I am trying to understand "kinda shared" interrupts.
>
> There are various interrupts in my not-yet-released CPU, and I have
> interrupt code that knows how to talk to them.  So far so good.  I
> also have an external interrupt controller that groups together 18
> external interrupt sources and sends them in one CPU pin.  This
> external controller has a register for enabling interrupts, and a
> register for status/acknowledge.  Pretty standard.
>
> The CPU code doesn't know about the external controller.  It seems
> silly to rewrite the CPU-specific interrput code to accommodate this
> board-specific detail (besides then my code won't match Dale's).  So I
> figure I tell the kernel I am doing shared interrupts.
>
> So where do I enable, disable, and acknowledge these external bits?
> Specifically, I am trying to get a couple of serial ports working.  I
> can put conditional code in serial.c startup() to enable these
> interrupts, but how do I know which serial port?  Add a conditionally
> compiled sub-IRQ number to serial_state structure?
>
> Is there a cleaner way?

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.  The board-specific driver
does a request_irq at init time for the one main irq it is multiplexing.

-Dale

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

Re: Shared Interrupts Question (2.4)

[Kent Borg]

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.  The board-specific driver
> does a request_irq at init time for the one main irq it is multiplexing.

Yes!  Flatten the cascaded interrupts to IRQs outside the CPU's, range,
and write a software multiplexer that registers for the one IRQ the CPU
knows. Right?

That's much better than what I had in mind.


Thanks,

-kb

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

Re: Shared Interrupts Question (2.4)

[Kent Borg]

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)

[Dale Farnsworth]

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:
> > 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?

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/