From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Nicolas DET <nd@bplan-gmbh.de>
Cc: linuxppc-dev@ozlabs.org, Sylvain Munaut <tnt@246tNt.com>,
sl@bplan-gmbh.de, linuxppc-embedded@ozlabs.org
Subject: Re: [PATCH/RFC] powerpc: Add MPC5200 Interrupt Controller support.
Date: Thu, 02 Nov 2006 09:12:18 +1100 [thread overview]
Message-ID: <1162419138.25682.453.camel@localhost.localdomain> (raw)
In-Reply-To: <454902F9.20206@bplan-gmbh.de>
My only remaining comment is what I said earlier about the way you
divided the interrupt in levels.
In fact, I've finally dug into the doc and found out that the situation
is even less clear :)
The whole point of this division is to avoid special cases and properly
deal with the separation in different HW registers. We have basically 4
register sets controlling irqs:
- intr->ctrl
- intr->main_mask
- intr->per_mask
- sdma (different device)
Now, your current setup ends up defining a "level" and 5 irq_chips !!!
- intr->ctrl bit 11 has it's own chip
- intr->ctrl other bits or intr->main_mask (2 different chips)
- intr->per_mask a chip
- sdma a chip
which seems to totally gross since the first one is basically "main" irq
0, and has no reason whatsoever to be kept separate from "main". Which
would give us something much more sensible with 4 levels and 4 chips:
- intr->ctrl based interrupts (crit and main, crit being just main 0)
- intr->main_mask
- intr->per_mask
- sdma
In that case, you have a nice 1 level == 1 irq_chip == one register set.
Now, in addition to that, we have another issue I haven't spotted
before, but it might be worth considering:
Do we actually want the sdma interrupts handled there ? Because if you
look closely, the SDMA is basically a cascaded interrupt controller. It
hangs of per interrupt 0 :)
Thus we could simply remove the code for it from that driver and
implement it as as separate controller with a separate interrupt domain.
I know you won't like that idea because it means having a different
interrupt tree but it's worth having the discussion.
Ben.
next prev parent reply other threads:[~2006-11-01 22:12 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-01 20:27 [PATCH/RFC] powerpc: Add MPC5200 Interrupt Controller support Nicolas DET
2006-11-01 22:05 ` Dale Farnsworth
2006-11-01 22:07 ` Sven Luther
2006-11-01 22:21 ` Dale Farnsworth
2006-11-01 22:12 ` Benjamin Herrenschmidt [this message]
2006-11-02 16:27 ` Nicolas DET
2006-11-02 20:47 ` Nicolas DET
2006-11-04 23:35 ` Benjamin Herrenschmidt
2006-11-05 0:27 ` Sylvain Munaut
2006-11-05 1:13 ` Benjamin Herrenschmidt
2006-11-06 6:28 ` Grant Likely
2006-11-06 8:39 ` Sylvain Munaut
2006-11-05 10:17 ` Nicolas DET
2006-11-05 10:37 ` Benjamin Herrenschmidt
2006-11-05 11:30 ` Nicolas DET
2006-11-05 13:02 ` Benjamin Herrenschmidt
2006-11-05 13:16 ` Nicolas DET
2006-11-05 14:32 ` Sylvain Munaut
2006-11-06 6:55 ` Grant Likely
-- strict thread matches above, loose matches on Subject: below --
2006-11-06 10:26 Nicolas DET
2006-11-06 11:03 Nicolas DET
2006-11-06 23:35 ` Sylvain Munaut
2006-11-07 9:22 ` Nicolas DET
2006-11-07 10:40 Nicolas DET
2006-11-07 10:45 ` Sylvain Munaut
2006-11-07 16:30 ` Grant Likely
2006-11-07 20:52 ` Sylvain Munaut
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=1162419138.25682.453.camel@localhost.localdomain \
--to=benh@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=linuxppc-embedded@ozlabs.org \
--cc=nd@bplan-gmbh.de \
--cc=sl@bplan-gmbh.de \
--cc=tnt@246tNt.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).