From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Michal Simek <monstr@monstr.eu>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
x86@kernel.org, linux-kernel@vger.kernel.org,
Ralf Baechle <ralf@linux-mips.org>,
hpa@zytor.com, Dirk Brandewie <dirk.brandewie@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
linuxppc-dev@lists.ozlabs.org,
devicetree-discuss@lists.ozlabs.org
Subject: Re: [PATCH 0/6] General device tree irq domain infrastructure
Date: Tue, 03 May 2011 11:43:19 +1000 [thread overview]
Message-ID: <1304386999.2513.293.camel@pasglop> (raw)
In-Reply-To: <20110428192227.8979.49181.stgit@ponder>
On Thu, 2011-04-28 at 14:01 -0600, Grant Likely wrote:
> A lot of this series ends up being fixups to powerpc code; but the 4th
> patch is of importance to every architecture using CONFIG_OF (except
> SPARC, which has its own solution).
>
> This series (finally!) factors out device tree irq domain decoding
> from arch/powerpc and makes it generic for all architectures. The
> infrastructure is quite simple. Any interrupt controller can embed
> the of_irq_domain structure and register it with the core code. After
> that, device nodes referencing interrupts on that device tree node
> will trigger a call to the domain's map function.
This leads to an immediate reaction from me : why "of_irq_domain" ?
The concept of interrupt domains is completely orthogonal to "OF" and
whether you use the device-tree or not.
Having a remapping mechanism allowing to deal with multiple interrupt
domains without playing stupid numbering tricks is generally useful for
architectures, regardless of their adoption of the device-tree.
The irq domain has one and -only one- op that is related to OF which
allows to map a device node to a domain, but that's 'optional' and only
use if you use the OF resolving process. The whole mechanism can be (and
is under some circumstances on ppc) without a device-tree relationship.
We instanciate IRQs within domains manually in some cases, either
because we lack proper DT informations or bcs the IRQs come from the
firmware or as "created" out of the blue (device-tree). A domain pointer
(or NULL for the default domain) is all is needed.
Thus I object to tying this infrastructure generically to "OF" even if
it's just a mater of naming of the domain structure and location of the
code in the kernel tree.
It should basically all go into kernel/irq/domains.c or something like
that.
Cheers,
Ben.
> PowerPC and x86 have been converted to use of_irq_domain. MIPS and
> Microblaze have it enabled, but nothing actually registers domains
> yet, so a workaround is in place to preserve the current behaviour
> until it is fixed.
>
> I'd really like to get patches 1-4 merged into 2.6.40. Please test.
> I'm also running through build testing here, and when it's complete
> I'll push it out to a 'devicetree/irq-domain' branch on
> git://git.secretlab.ca/git/linux-2.6
>
> It needs testing. I've booted it on a powerpc board here without any
> apparent regressions, but that isn't a very big sample. I've also
> build tested on everything I think is affected.
>
> I'd also like to get it into linux-next. Ben, if things checkout okay
> over the next few days, would you be okay with me adding it to
> linux-next, say around Wednesday next week? As for merging, I think
> this should probably go via your powerpc tree since the that's where
> the bulk of the changes are, but I'm open to other suggestions).
>
> Patches 5 & 6 are follow-on cleanup work to powerpc, but patch 6 is
> RFC only since there is a locking problem that I haven't fixed yet.
>
> Cheers,
> g.
>
> ---
>
> Grant Likely (6):
> powerpc: stop exporting irq_map
> powerpc: make irq_{alloc,free}_virt private and remove count argument
> powerpc: Make struct irq_host semi-private by moving into irqhost.h
> dt: generalize of_irq_parse_and_map()
> powerpc: move irq_alloc_descs_at() call into irq_alloc_virt()
> powerpc: use irq_alloc_desc() to manage irq allocations
>
>
> arch/microblaze/kernel/irq.c | 7 -
> arch/microblaze/kernel/setup.c | 2
> arch/mips/kernel/prom.c | 14 -
> arch/powerpc/include/asm/irq.h | 88 +------
> arch/powerpc/include/asm/irqhost.h | 27 ++
> arch/powerpc/kernel/irq.c | 260 ++++++++++++----------
> arch/powerpc/platforms/512x/mpc5121_ads_cpld.c | 5
> arch/powerpc/platforms/52xx/media5200.c | 5
> arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 1
> arch/powerpc/platforms/52xx/mpc52xx_pic.c | 80 +------
> arch/powerpc/platforms/82xx/pq2ads-pci-pic.c | 5
> arch/powerpc/platforms/85xx/socrates_fpga_pic.c | 26 +-
> arch/powerpc/platforms/86xx/gef_pic.c | 10 -
> arch/powerpc/platforms/8xx/m8xx_setup.c | 2
> arch/powerpc/platforms/cell/axon_msi.c | 15 +
> arch/powerpc/platforms/cell/spider-pic.c | 19 +-
> arch/powerpc/platforms/embedded6xx/flipper-pic.c | 9 -
> arch/powerpc/platforms/embedded6xx/hlwd-pic.c | 9 -
> arch/powerpc/platforms/embedded6xx/wii.c | 6 -
> arch/powerpc/platforms/iseries/irq.c | 10 -
> arch/powerpc/platforms/powermac/pic.c | 12 +
> arch/powerpc/platforms/pseries/ras.c | 4
> arch/powerpc/platforms/pseries/xics.c | 14 +
> arch/powerpc/sysdev/cpm1.c | 8 -
> arch/powerpc/sysdev/cpm2_pic.c | 10 -
> arch/powerpc/sysdev/fsl_msi.c | 3
> arch/powerpc/sysdev/i8259.c | 3
> arch/powerpc/sysdev/ipic.c | 19 +-
> arch/powerpc/sysdev/mpc8xx_pic.c | 10 -
> arch/powerpc/sysdev/mpc8xxx_gpio.c | 13 +
> arch/powerpc/sysdev/mpic.c | 33 +--
> arch/powerpc/sysdev/mpic_msi.c | 3
> arch/powerpc/sysdev/mpic_pasemi_msi.c | 5
> arch/powerpc/sysdev/mv64x60_pic.c | 14 +
> arch/powerpc/sysdev/qe_lib/qe_ic.c | 9 -
> arch/powerpc/sysdev/uic.c | 13 +
> arch/powerpc/sysdev/xilinx_intc.c | 9 -
> arch/x86/include/asm/irq_controller.h | 12 -
> arch/x86/include/asm/prom.h | 1
> arch/x86/kernel/devicetree.c | 77 +------
> drivers/of/irq.c | 118 ++++++++++
> include/linux/of_irq.h | 31 +++
> 42 files changed, 504 insertions(+), 517 deletions(-)
> create mode 100644 arch/powerpc/include/asm/irqhost.h
> delete mode 100644 arch/x86/include/asm/irq_controller.h
next prev parent reply other threads:[~2011-05-03 1:43 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-28 20:01 [PATCH 0/6] General device tree irq domain infrastructure Grant Likely
2011-04-28 20:01 ` [PATCH 1/6] powerpc: stop exporting irq_map Grant Likely
2011-05-03 1:44 ` Benjamin Herrenschmidt
2011-04-28 20:01 ` [PATCH 2/6] powerpc: make irq_{alloc, free}_virt private and remove count argument Grant Likely
2011-05-03 1:47 ` Benjamin Herrenschmidt
2011-05-04 15:59 ` Grant Likely
2011-05-05 0:39 ` Benjamin Herrenschmidt
2011-04-28 20:01 ` [PATCH 3/6] powerpc: Make struct irq_host semi-private by moving into irqhost.h Grant Likely
2011-05-03 1:48 ` Benjamin Herrenschmidt
2011-04-28 20:02 ` [PATCH 4/6] dt: generalize irq_of_create_mapping() Grant Likely
2011-05-03 1:50 ` Benjamin Herrenschmidt
2011-05-04 16:05 ` Grant Likely
2011-05-05 0:43 ` Benjamin Herrenschmidt
2011-04-28 20:02 ` [PATCH 5/6] powerpc: move irq_alloc_descs_at() call into irq_alloc_virt() Grant Likely
2011-04-28 20:02 ` [PATCH 6/6] powerpc: use irq_alloc_desc() to manage irq allocations Grant Likely
2011-04-29 16:16 ` [PATCH 0/6] General device tree irq domain infrastructure Sebastian Andrzej Siewior
2011-04-29 17:43 ` Grant Likely
2011-05-03 1:43 ` Benjamin Herrenschmidt [this message]
2011-05-04 15:52 ` Grant Likely
2011-05-05 0:39 ` Benjamin Herrenschmidt
2011-05-05 8:37 ` Thomas Gleixner
2011-05-05 14:07 ` Grant Likely
2011-05-05 14:14 ` Sebastian Andrzej Siewior
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=1304386999.2513.293.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=bigeasy@linutronix.de \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=dirk.brandewie@gmail.com \
--cc=grant.likely@secretlab.ca \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=monstr@monstr.eu \
--cc=ralf@linux-mips.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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).