Fwd: [PATCH] powerpc/mpc52xx: Properly update irq_desc when set_type() is called.

Grant Likely grant.likely at secretlab.ca
Wed Jan 14 17:03:58 EST 2009


On Tue, Jan 13, 2009 at 6:00 AM, Matt Sealey <matt at genesi-usa.com> wrote:
> Grant Likely wrote:
>>
>>
>> Theoretically it could call IRQ handlers to be called too often.  It
>> might possibly be the cause of too many 'BAD' irqs being recorded....
>
> That might explain a few USB explosions, where high bandwidth transfers
> (restoring partimage disks) would make the host controller die (a freeze,
> then it comes back with 'nobody cared about irq 134' etc.) and perhaps a
> lockup we saw with openSUSE 11.0 installer..
>
>> Now that I think of it, I should probably also change all the internal
>> IRQs to be LEVEL instead of EDGE.
>
> And what does that really affect? I wouldn't think the internal stuff would
> make any difference what it senses on?

It took me most of the morning, but I traced through all the code and
figured out how it is supposed to work.  In this case the type field
in status is indeed cosmetic.  The only time I can see that it really
comes into play is when edge IRQs are enabled after being disabled for
replaying IRQs.  It might be the source of some of the BAD irq count
on the mpc5200, but it is unlikely.

The real logic behind handling an IRQ is defined by the handler
registered with set_irq_chip_and_handler() which the current mpc5200
PIC driver seems to be doing correctly.  However, for external IRQs,
the handler is not changed when the IRQ switches from the default edge
sensitivity to level sensitivity.  Using the wrong handler doesn't
seem to actively break things, but I'm still investigating to find out
if it affects performance or results in BAD irq counts.

Regardless, I'm looking at a number of cleanups to the PIC code and
I'll be posting a patch soon with the intent of getting it into .30.

Cheers,
g.

--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.



More information about the Linuxppc-dev mailing list