* PrPMC800 interrupt problem @ 2002-10-24 17:01 Anders Blomdell 2002-10-24 17:26 ` Tom Rini 0 siblings, 1 reply; 11+ messages in thread From: Anders Blomdell @ 2002-10-24 17:01 UTC (permalink / raw) To: linuxppc embedded When trying to use the linuxppc_2_4_devel on a PrPMC800, the system stops responding to external interrupts after the first serial interrupt. Many things works, since the system correctly gets its IP address via DHCP. The system handles a little more than 100 interrupts that gets routed to 'e100intr', then it starts up my shell that does a write to the console. This write triggers an interrupt that gets routed to 'rs_interrupt_single' . After this no more interrupts are received, but 'rs_interrupt_single' is called from the timer task in the serial driver, but the ethernet is totally dead. Anybody that has a good idea what to do about this? Regards Anders Blomdell ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PrPMC800 interrupt problem 2002-10-24 17:01 PrPMC800 interrupt problem Anders Blomdell @ 2002-10-24 17:26 ` Tom Rini 2002-10-25 15:15 ` Anders Blomdell 0 siblings, 1 reply; 11+ messages in thread From: Tom Rini @ 2002-10-24 17:26 UTC (permalink / raw) To: Anders Blomdell; +Cc: linuxppc embedded On Thu, Oct 24, 2002 at 07:01:19PM +0200, Anders Blomdell wrote: > > When trying to use the linuxppc_2_4_devel on a PrPMC800, the system stops > responding to external interrupts after the first serial interrupt. Many > things works, since the system correctly gets its IP address via DHCP. > > The system handles a little more than 100 interrupts that gets routed to > 'e100intr', then it starts up my shell that does a write to the console. > This write triggers an interrupt that gets routed to 'rs_interrupt_single' > . After this no more interrupts are received, but 'rs_interrupt_single' is > called from the timer task in the serial driver, but the ethernet is > totally dead. Anybody that has a good idea what to do about this? Did you update the prpmc800_openpic_initsenses[] table and related? (Look at how the lopec or sandpoint work now). -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PrPMC800 interrupt problem 2002-10-24 17:26 ` Tom Rini @ 2002-10-25 15:15 ` Anders Blomdell 2002-10-25 15:40 ` Tom Rini 2002-10-25 15:44 ` Anders Blomdell 0 siblings, 2 replies; 11+ messages in thread From: Anders Blomdell @ 2002-10-25 15:15 UTC (permalink / raw) To: Tom Rini; +Cc: linuxppc embedded The problem seems to be that the UART generates an Harrier internal interrupt. This should be handled as any other MPIC interrupt, but it isn' t. This lack of an appropriate handler (irq_desc[16].handler == 0) makes the Harrier chip wait forever for an EOI. A very hacky solution to this is to modify 'prpmc800_init_IRQ' to: static void __init prpmc800_init_IRQ(void) { openpic_init(0); // Handle UART interrupts as all other openpic interrupts, this is a // gross hack. openpic_set_sources(16, 1, OpenPIC_Addr + 0x10200); irq_desc[16].handler = irq_desc[15].handler; #define PRIORITY 15 #define VECTOR 16 #define PROCESSOR 0 /* initialize the harrier's internal interrupt priority 15, irq 1 */ out_be32((u32 *)HARRIER_IFEVP_REG, (PRIORITY<<16) | VECTOR); out_be32((u32 *)HARRIER_IFEDE_REG, (1<<PROCESSOR)); /* enable functional exceptions for uarts and abort */ out_8((u8 *)HARRIER_FEEN_REG, (HARRIER_FE_UA0|HARRIER_FE_UA1)); out_8((u8 *)HARRIER_FEMA_REG, ~(HARRIER_FE_UA0|HARRIER_FE_UA1)); } ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PrPMC800 interrupt problem 2002-10-25 15:15 ` Anders Blomdell @ 2002-10-25 15:40 ` Tom Rini 2002-10-25 15:50 ` Anders Blomdell 2002-10-25 15:44 ` Anders Blomdell 1 sibling, 1 reply; 11+ messages in thread From: Tom Rini @ 2002-10-25 15:40 UTC (permalink / raw) To: Anders Blomdell; +Cc: linuxppc embedded On Fri, Oct 25, 2002 at 05:15:46PM +0200, Anders Blomdell wrote: > The problem seems to be that the UART generates an Harrier internal > interrupt. This should be handled as any other MPIC interrupt, but it isn' > t. This lack of an appropriate handler (irq_desc[16].handler == 0) makes > the Harrier chip wait forever for an EOI. > > A very hacky solution to this is to modify 'prpmc800_init_IRQ' to: Did you update the initsenses table as well? And are you sure you are calling openpic_set_sources() correctly? That only maps OpenPIC source 16 to be Linux interrupt 16, and doesn't catch any of the other sources ('tho I don't have the prpmc800 manual in front of me) -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PrPMC800 interrupt problem 2002-10-25 15:40 ` Tom Rini @ 2002-10-25 15:50 ` Anders Blomdell 2002-10-25 16:04 ` Tom Rini 2002-10-25 16:51 ` Matt Porter 0 siblings, 2 replies; 11+ messages in thread From: Anders Blomdell @ 2002-10-25 15:50 UTC (permalink / raw) To: Tom Rini; +Cc: linuxppc embedded On fredag, oktober 25, 2002, at 05:40 , Tom Rini wrote: > On Fri, Oct 25, 2002 at 05:15:46PM +0200, Anders Blomdell wrote: > >> The problem seems to be that the UART generates an Harrier internal >> interrupt. This should be handled as any other MPIC interrupt, but it isn' >> t. This lack of an appropriate handler (irq_desc[16].handler == 0) makes >> the Harrier chip wait forever for an EOI. >> >> A very hacky solution to this is to modify 'prpmc800_init_IRQ' to: > > Did you update the initsenses table as well? And are you sure you are > calling openpic_set_sources() correctly? That only maps OpenPIC source > 16 to be Linux interrupt 16, and doesn't catch any of the other sources > ('tho I don't have the prpmc800 manual in front of me) The initsenses table was correct already, but open_pic.c relies on the number of interrupt sources returned from the feature reporting register, that excludes the internal sources (in Harrier, Hawk and Raven chips at least). Thus these interrupts are not correctly setup. I posted a possible (==untested) solution a few minutes ago. BTW: Is there any documentation on the OpenPIC controllers, the AMD link seems to have disappeared. Regards Anders Blomdell ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PrPMC800 interrupt problem 2002-10-25 15:50 ` Anders Blomdell @ 2002-10-25 16:04 ` Tom Rini 2002-10-25 16:51 ` Matt Porter 1 sibling, 0 replies; 11+ messages in thread From: Tom Rini @ 2002-10-25 16:04 UTC (permalink / raw) To: Anders Blomdell; +Cc: linuxppc embedded On Fri, Oct 25, 2002 at 05:50:35PM +0200, Anders Blomdell wrote: > > On fredag, oktober 25, 2002, at 05:40 , Tom Rini wrote: > > >On Fri, Oct 25, 2002 at 05:15:46PM +0200, Anders Blomdell wrote: > > > >>The problem seems to be that the UART generates an Harrier internal > >>interrupt. This should be handled as any other MPIC interrupt, but it isn' > >>t. This lack of an appropriate handler (irq_desc[16].handler == 0) makes > >>the Harrier chip wait forever for an EOI. > >> > >>A very hacky solution to this is to modify 'prpmc800_init_IRQ' to: > > > >Did you update the initsenses table as well? And are you sure you are > >calling openpic_set_sources() correctly? That only maps OpenPIC source > >16 to be Linux interrupt 16, and doesn't catch any of the other sources > >('tho I don't have the prpmc800 manual in front of me) > The initsenses table was correct already, but open_pic.c relies on the > number of interrupt sources returned from the feature reporting register, > that excludes the internal sources (in Harrier, Hawk and Raven chips at > least). Thus these interrupts are not correctly setup. I posted a possible > (==untested) solution a few minutes ago. If they are correct, change them from '1' / '0' to IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE. I think the problem is that you are not calling openpic_set_sources(...) correctly, or enough times. openpic_init() can only be called without calling openpic_set_sources() if the default call in openpic_init() will work correctly, as is. > BTW: Is there any documentation on the OpenPIC controllers, the AMD link > seems to have disappeared. The MPC107 manual or the MPC8240 manual, iirc. > > Regards > > Anders Blomdell -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PrPMC800 interrupt problem 2002-10-25 15:50 ` Anders Blomdell 2002-10-25 16:04 ` Tom Rini @ 2002-10-25 16:51 ` Matt Porter 1 sibling, 0 replies; 11+ messages in thread From: Matt Porter @ 2002-10-25 16:51 UTC (permalink / raw) To: Anders Blomdell; +Cc: Tom Rini, linuxppc embedded On Fri, Oct 25, 2002 at 05:50:35PM +0200, Anders Blomdell wrote: > BTW: Is there any documentation on the OpenPIC controllers, the AMD link > seems to have disappeared. The PrPMC800 Programmers Reference and Harrier ASIC Programmers Reference guide has everything you need. Visit your vendor's site. Regards, -- Matt Porter porter@cox.net This is Linux Country. On a quiet night, you can hear Windows reboot. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PrPMC800 interrupt problem 2002-10-25 15:15 ` Anders Blomdell 2002-10-25 15:40 ` Tom Rini @ 2002-10-25 15:44 ` Anders Blomdell 2002-10-25 16:00 ` Tom Rini 1 sibling, 1 reply; 11+ messages in thread From: Anders Blomdell @ 2002-10-25 15:44 UTC (permalink / raw) To: Tom Rini; +Cc: linuxppc embedded > A very hacky solution to this is to modify 'prpmc800_init_IRQ' to: > <snip> A better solution is perhaps to change openpic_init from if (NumSources == 0) openpic_set_sources(0, ((t & OPENPIC_FEATURE_LAST_SOURCE_MASK) >> OPENPIC_FEATURE_LAST_SOURCE_SHIFT) + 1, NULL); to if (NumSources == 0) { int irqs; irqs = ((t & OPENPIC_FEATURE_LAST_SOURCE_MASK) >> OPENPIC_FEATURE_LAST_SOURCE_SHIFT) + 1; if (irqs < OpenPIC_NumInitSenses) { // Some internal interrupt is defined, init it's vector as well irqs = OpenPIC_NumInitSenses; } openpic_set_sources(0, irqs, NULL); } Any insight is welcome! As far as I can see, open_pic.c does not handle timer, ipi, uart or any other internal interrupt sources (as they are not reported in the feature register). ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PrPMC800 interrupt problem 2002-10-25 15:44 ` Anders Blomdell @ 2002-10-25 16:00 ` Tom Rini 2002-10-25 16:42 ` Anders Blomdell 0 siblings, 1 reply; 11+ messages in thread From: Tom Rini @ 2002-10-25 16:00 UTC (permalink / raw) To: Anders Blomdell; +Cc: linuxppc embedded On Fri, Oct 25, 2002 at 05:44:26PM +0200, Anders Blomdell wrote: > >A very hacky solution to this is to modify 'prpmc800_init_IRQ' to: > ><snip> > > A better solution is perhaps to change openpic_init from > > if (NumSources == 0) > openpic_set_sources(0, > ((t & OPENPIC_FEATURE_LAST_SOURCE_MASK) > >> > OPENPIC_FEATURE_LAST_SOURCE_SHIFT) + 1, > NULL); > > to > > if (NumSources == 0) { > int irqs; > irqs = ((t & OPENPIC_FEATURE_LAST_SOURCE_MASK) >> > OPENPIC_FEATURE_LAST_SOURCE_SHIFT) + 1; > if (irqs < OpenPIC_NumInitSenses) { > // Some internal interrupt is defined, init it's vector as well > irqs = OpenPIC_NumInitSenses; > } > openpic_set_sources(0, irqs, NULL); > } > > Any insight is welcome! As far as I can see, open_pic.c does not handle > timer, ipi, uart or any other internal interrupt sources (as they are not > reported in the feature register). What you're suggesting brings back the old hacking behavior. Again I say, look at what lopec_setup.c does for handling interrupts, look at the manual for the prpmc800 (and the MPC107 (OpenPIC/EPIC related bits) or MPC8240 (again, OpenPIC/EPIC)) manuals. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PrPMC800 interrupt problem 2002-10-25 16:00 ` Tom Rini @ 2002-10-25 16:42 ` Anders Blomdell 2002-10-26 1:39 ` Tom Rini 0 siblings, 1 reply; 11+ messages in thread From: Anders Blomdell @ 2002-10-25 16:42 UTC (permalink / raw) To: Tom Rini; +Cc: linuxppc embedded > What you're suggesting brings back the old hacking behavior. Again I > say, look at what lopec_setup.c does for handling interrupts, look at > the manual for the prpmc800 (and the MPC107 (OpenPIC/EPIC related bits) > or MPC8240 (again, OpenPIC/EPIC)) manuals. > OK, hope this is a correct solution then (it works, which is a good thing) . Thanks for your patience, all the levels in the interrupt handling are a bit hairy to understand. Regards Anders Blomdell --- ../2002-10-14/arch/ppc/platforms/prpmc800_setup.c Fri Oct 11 17:58:31 2002 +++ arch/ppc/platforms/prpmc800_setup.c Fri Oct 25 18:33:49 2002 @@ -53,23 +53,23 @@ static u_char prpmc800_openpic_initsenses[] __initdata = { - 1, /* PRPMC800_INT_HOSTINT0 */ - 1, /* PRPMC800_INT_UNUSED */ - 1, /* PRPMC800_INT_DEBUGINT */ - 1, /* PRPMC800_INT_HARRIER_WDT */ - 1, /* PRPMC800_INT_UNUSED */ - 1, /* PRPMC800_INT_UNUSED */ - 1, /* PRPMC800_INT_HOSTINT1 */ - 1, /* PRPMC800_INT_HOSTINT2 */ - 1, /* PRPMC800_INT_HOSTINT3 */ - 1, /* PRPMC800_INT_PMC_INTA */ - 1, /* PRPMC800_INT_PMC_INTB */ - 1, /* PRPMC800_INT_PMC_INTC */ - 1, /* PRPMC800_INT_PMC_INTD */ - 1, /* PRPMC800_INT_UNUSED */ - 1, /* PRPMC800_INT_UNUSED */ - 1, /* PRPMC800_INT_UNUSED */ - 1, /* PRPMC800_INT_HARRIER_INT (UARTS, ABORT, DMA) */ + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* PRPMC800_INT_HOSTINT0 * / + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* PRPMC800_INT_UNUSED */ + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* PRPMC800_INT_DEBUGINT * / + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* PRPMC800_INT_HARRIER_WDT */ + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* PRPMC800_INT_UNUSED */ + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* PRPMC800_INT_UNUSED */ + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* PRPMC800_INT_HOSTINT1 * / + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* PRPMC800_INT_HOSTINT2 * / + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* PRPMC800_INT_HOSTINT3 * / + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* PRPMC800_INT_PMC_INTA * / + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* PRPMC800_INT_PMC_INTB * / + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* PRPMC800_INT_PMC_INTC * / + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* PRPMC800_INT_PMC_INTD * / + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* PRPMC800_INT_UNUSED */ + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* PRPMC800_INT_UNUSED */ + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* PRPMC800_INT_UNUSED */ + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* PRPMC800_INT_HARRIER_INT (UARTS, ABORT, DMA) */ }; static int @@ -105,9 +105,6 @@ conswitchp = &dummy_con; #endif - OpenPIC_InitSenses = prpmc800_openpic_initsenses; - OpenPIC_NumInitSenses = sizeof(prpmc800_openpic_initsenses); - printk("PrPMC800 port (C) 2001 MontaVista Software, Inc. (source@m vista.com)\n"); } @@ -198,14 +195,16 @@ static void __init prpmc800_init_IRQ(void) { - openpic_init(0); + OpenPIC_InitSenses = prpmc800_openpic_initsenses; + OpenPIC_NumInitSenses = sizeof(prpmc800_openpic_initsenses); -#define PRIORITY 15 -#define VECTOR 16 -#define PROCESSOR 0 - /* initialize the harrier's internal interrupt priority 15, irq 1 */ - out_be32((u32 *)HARRIER_IFEVP_REG, (PRIORITY<<16) | VECTOR); - out_be32((u32 *)HARRIER_IFEDE_REG, (1<<PROCESSOR)); + // Setup external interrupt sources + openpic_set_sources(0, 16, OpenPIC_Addr + 0x10000); + // Setup internal UART interrupt source + openpic_set_sources(16, 1, OpenPIC_Addr + 0x10200); + + // Do the MPIC initialization based on the above settings + openpic_init(0); /* enable functional exceptions for uarts and abort */ out_8((u8 *)HARRIER_FEEN_REG, (HARRIER_FE_UA0|HARRIER_FE_UA1)); ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PrPMC800 interrupt problem 2002-10-25 16:42 ` Anders Blomdell @ 2002-10-26 1:39 ` Tom Rini 0 siblings, 0 replies; 11+ messages in thread From: Tom Rini @ 2002-10-26 1:39 UTC (permalink / raw) To: Anders Blomdell; +Cc: linuxppc embedded On Fri, Oct 25, 2002 at 06:42:22PM +0200, Anders Blomdell wrote: > >What you're suggesting brings back the old hacking behavior. Again I > >say, look at what lopec_setup.c does for handling interrupts, look at > >the manual for the prpmc800 (and the MPC107 (OpenPIC/EPIC related bits) > >or MPC8240 (again, OpenPIC/EPIC)) manuals. > > OK, hope this is a correct solution then (it works, which is a good thing) > . Thanks for your patience, all the levels in the interrupt handling are a > bit hairy to understand. This looks much better, I will commit this monday. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2002-10-26 1:39 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2002-10-24 17:01 PrPMC800 interrupt problem Anders Blomdell 2002-10-24 17:26 ` Tom Rini 2002-10-25 15:15 ` Anders Blomdell 2002-10-25 15:40 ` Tom Rini 2002-10-25 15:50 ` Anders Blomdell 2002-10-25 16:04 ` Tom Rini 2002-10-25 16:51 ` Matt Porter 2002-10-25 15:44 ` Anders Blomdell 2002-10-25 16:00 ` Tom Rini 2002-10-25 16:42 ` Anders Blomdell 2002-10-26 1:39 ` Tom Rini
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).