From: "Grant Likely" <grant.likely@secretlab.ca>
To: "Matt Sealey" <matt@genesi-usa.com>,
linuxppc-dev <linuxppc-dev@ozlabs.org>
Subject: Fwd: [PATCH] powerpc/mpc52xx: Properly update irq_desc when set_type() is called.
Date: Tue, 13 Jan 2009 23:03:58 -0700 [thread overview]
Message-ID: <fa686aa40901132203u3074a2c1h3eeb5ae49b938090@mail.gmail.com> (raw)
In-Reply-To: <fa686aa40901132203p71bbd6eem2b8173dc8a4e5fc8@mail.gmail.com>
On Tue, Jan 13, 2009 at 6:00 AM, Matt Sealey <matt@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.
prev parent reply other threads:[~2009-01-14 6:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-07 19:25 [PATCH] powerpc/mpc52xx: Properly update irq_desc when set_type() is called Grant Likely
2009-01-08 3:51 ` Matt Sealey
2009-01-08 4:53 ` Grant Likely
2009-01-08 14:40 ` Matt Sealey
2009-01-09 21:02 ` Grant Likely
2009-01-10 17:19 ` Matt Sealey
[not found] ` <fa686aa40901101425y5ff97f9fgabaa8aa6f0e974c7@mail.gmail.com>
[not found] ` <496AB287.5050508@genesi-usa.com>
[not found] ` <fa686aa40901112156i69611682icf9ef3a7702fd862@mail.gmail.com>
[not found] ` <496C907B.2060609@genesi-usa.com>
[not found] ` <fa686aa40901132203p71bbd6eem2b8173dc8a4e5fc8@mail.gmail.com>
2009-01-14 6:03 ` Grant Likely [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fa686aa40901132203u3074a2c1h3eeb5ae49b938090@mail.gmail.com \
--to=grant.likely@secretlab.ca \
--cc=linuxppc-dev@ozlabs.org \
--cc=matt@genesi-usa.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).