Re: PrPMC800 interrupt problem

On Fri, Oct 25, 2002 at 05:50:35PM +0200, Anders Blomdell wrote:

On fredag, oktober 25, 2002, at 05:40 , Tom Rini wrote:

quoted

On Fri, Oct 25, 2002 at 05:15:46PM +0200, Anders Blomdell wrote:

quoted

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/