Shared Interrupts Question (2.4)
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/
Shared Interrupts Question (2.4)
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/
Shared Interrupts Question (2.4)
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 at 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/
Shared Interrupts Question (2.4)
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/
Shared Interrupts Question (2.4)
On Thu, May 08, 2003 at 08:08:56PM +, 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/
