Message ID | 1327700179-17454-1-git-send-email-grant.likely@secretlab.ca (mailing list archive) |
---|---|
State | Not Applicable |
Headers | show |
On 01/27/2012 03:35 PM, Grant Likely wrote: > Hey everyone, > > This patch series is ready for much wider consumption now. I'd like > to get it into linux-next ASAP because there will be ARM board support > depending on it. I'll wait a few days before I ask Stephen to pull > this in. > > Stephen/Milton/Ben, any testing you can help with here would be > appreciated since you've got access to a wider variety of Power > machines than I do. > > Thomas, I think it makes sense to maintain this in a separate branch > from other irq changes until the next merge window. If you prefer, > I'm happy to maintain this branch until then. > I picked up your irqdomain/next branch and it doesn't compile: CC kernel/irq/irqdomain.o kernel/irq/irqdomain.c: In function ‘irq_create_mapping’: kernel/irq/irqdomain.c:403:47: error: ‘irq’ undeclared (first use in this function) kernel/irq/irqdomain.c:403:47: note: each undeclared identifier is reported only once for each function it app Rob > Cheers, > g. > > The following changes since commit dcd6c92267155e70a94b3927bce681ce74b80d1f: > > Linux 3.3-rc1 (2012-01-19 15:04:48 -0800) > > are available in the git repository at: > git://git.secretlab.ca/git/linux-2.6 irqdomain/next > > Grant Likely (24): > irq_domain: add documentation and MAINTAINERS entry. > dt: Make irqdomain less verbose > irq_domain: Make irq_domain structure match powerpc's irq_host > irq_domain: convert microblaze from irq_host to irq_domain > irq_domain/powerpc: Use common irq_domain structure instead of irq_host > irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead > irq_domain/powerpc: Eliminate virq_is_host() > irq_domain: Move irq_domain code from powerpc to kernel/irq > irqdomain: remove NO_IRQ from irq domain code > irq_domain: Remove references to old irq_host names > irq_domain: Replace irq_alloc_host() with revmap-specific initializers > irq_domain: Add support for base irq and hwirq in legacy mappings > irq_domain: Remove 'new' irq_domain in favour of the ppc one > irq_domain: Remove irq_domain_add_simple() > irq_domain: Create common xlate functions that device drivers can use > irq_domain: constify irq_domain_ops > irq_domain/c6x: constify irq_domain structures > irq_domain/c6x: Use library of xlate functions > irq_domain/powerpc: constify irq_domain_ops > irqdomain/powerpc: Replace custom xlate functions with library functions > irq_domain/x86: Convert x86 (embedded) to use common irq_domain > irq_domain: Include hwirq number in /proc/interrupts > irq_domain: remove "hint" when allocating irq numbers > irq_domain: mostly eliminate slow-path revmap lookups > > Mark Salter (1): > irq_domain/c6x: Convert c6x to use generic irq_domain support. > > Documentation/IRQ-domain.txt | 113 +++ > MAINTAINERS | 9 + > arch/arm/common/gic.c | 95 ++-- > arch/arm/common/vic.c | 16 +- > arch/arm/include/asm/hardware/gic.h | 4 +- > arch/arm/include/asm/hardware/vic.h | 2 + > arch/arm/mach-exynos/common.c | 2 +- > arch/arm/mach-imx/mach-imx6q.c | 3 +- > arch/arm/mach-msm/board-msm8x60.c | 8 +- > arch/arm/mach-mx5/imx51-dt.c | 4 +- > arch/arm/mach-mx5/imx53-dt.c | 4 +- > arch/arm/mach-omap2/board-generic.c | 2 +- > arch/arm/mach-prima2/irq.c | 2 +- > arch/arm/mach-versatile/core.c | 5 +- > arch/c6x/Kconfig | 1 + > arch/c6x/include/asm/irq.h | 245 +------- > arch/c6x/kernel/irq.c | 612 +---------------- > arch/c6x/platforms/megamod-pic.c | 25 +- > arch/microblaze/include/asm/irq.h | 4 +- > arch/microblaze/kernel/irq.c | 2 +- > arch/microblaze/kernel/setup.c | 2 - > arch/powerpc/Kconfig | 1 + > arch/powerpc/include/asm/ehv_pic.h | 2 +- > arch/powerpc/include/asm/i8259.h | 2 +- > arch/powerpc/include/asm/irq.h | 247 +------- > arch/powerpc/include/asm/mpic.h | 2 +- > arch/powerpc/include/asm/xics.h | 2 +- > arch/powerpc/kernel/irq.c | 617 +---------------- > arch/powerpc/platforms/512x/mpc5121_ads_cpld.c | 12 +- > arch/powerpc/platforms/52xx/media5200.c | 15 +- > arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 16 +- > arch/powerpc/platforms/52xx/mpc52xx_pic.c | 12 +- > arch/powerpc/platforms/82xx/pq2ads-pci-pic.c | 14 +- > arch/powerpc/platforms/85xx/socrates_fpga_pic.c | 15 +- > arch/powerpc/platforms/86xx/gef_pic.c | 15 +- > arch/powerpc/platforms/cell/axon_msi.c | 29 +- > arch/powerpc/platforms/cell/beat_interrupt.c | 16 +- > arch/powerpc/platforms/cell/interrupt.c | 16 +- > arch/powerpc/platforms/cell/spider-pic.c | 14 +- > arch/powerpc/platforms/embedded6xx/flipper-pic.c | 30 +- > arch/powerpc/platforms/embedded6xx/hlwd-pic.c | 35 +- > arch/powerpc/platforms/iseries/irq.c | 11 +- > arch/powerpc/platforms/powermac/pic.c | 26 +- > arch/powerpc/platforms/powermac/smp.c | 9 +- > arch/powerpc/platforms/ps3/interrupt.c | 11 +- > arch/powerpc/platforms/wsp/opb_pic.c | 26 +- > arch/powerpc/sysdev/cpm1.c | 9 +- > arch/powerpc/sysdev/cpm2_pic.c | 23 +- > arch/powerpc/sysdev/ehv_pic.c | 14 +- > arch/powerpc/sysdev/fsl_msi.c | 10 +- > arch/powerpc/sysdev/fsl_msi.h | 2 +- > arch/powerpc/sysdev/i8259.c | 15 +- > arch/powerpc/sysdev/ipic.c | 31 +- > arch/powerpc/sysdev/ipic.h | 2 +- > arch/powerpc/sysdev/mpc8xx_pic.c | 11 +- > arch/powerpc/sysdev/mpic.c | 17 +- > arch/powerpc/sysdev/mpic_msi.c | 2 +- > arch/powerpc/sysdev/mv64x60_pic.c | 11 +- > arch/powerpc/sysdev/qe_lib/qe_ic.c | 26 +- > arch/powerpc/sysdev/qe_lib/qe_ic.h | 2 +- > arch/powerpc/sysdev/tsi108_pci.c | 22 +- > arch/powerpc/sysdev/uic.c | 26 +- > arch/powerpc/sysdev/xics/xics-common.c | 28 +- > arch/powerpc/sysdev/xilinx_intc.c | 19 +- > arch/x86/Kconfig | 2 + > arch/x86/include/asm/irq_controller.h | 12 - > arch/x86/include/asm/prom.h | 10 - > arch/x86/kernel/devicetree.c | 101 +-- > drivers/gpio/gpio-mpc8xxx.c | 30 +- > drivers/mfd/twl-core.c | 12 +- > drivers/net/phy/mdio-gpio.c | 4 +- > include/linux/irqdomain.h | 190 ++++-- > kernel/irq/irqdomain.c | 816 +++++++++++++++++++--- > kernel/irq/proc.c | 3 + > 74 files changed, 1334 insertions(+), 2471 deletions(-) > create mode 100644 Documentation/IRQ-domain.txt > delete mode 100644 arch/x86/include/asm/irq_controller.h > > _______________________________________________ > devicetree-discuss mailing list > devicetree-discuss@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss
On Jan 28, 2012 11:38 AM, "Rob Herring" <robherring2@gmail.com> wrote: > > On 01/27/2012 03:35 PM, Grant Likely wrote: > > Hey everyone, > > > > This patch series is ready for much wider consumption now. I'd like > > to get it into linux-next ASAP because there will be ARM board support > > depending on it. I'll wait a few days before I ask Stephen to pull > > this in. > > > > Stephen/Milton/Ben, any testing you can help with here would be > > appreciated since you've got access to a wider variety of Power > > machines than I do. > > > > Thomas, I think it makes sense to maintain this in a separate branch > > from other irq changes until the next merge window. If you prefer, > > I'm happy to maintain this branch until then. > > > > I picked up your irqdomain/next branch and it doesn't compile: > > CC kernel/irq/irqdomain.o > kernel/irq/irqdomain.c: In function ‘irq_create_mapping’: > kernel/irq/irqdomain.c:403:47: error: ‘irq’ undeclared (first use in > this function) > kernel/irq/irqdomain.c:403:47: note: each undeclared identifier is > reported only once for each function it app Oops, I had fixed that but didn't refresh the patch. Change the references in that function from irq to virq, or pop off the top patch to fix. I'll push out a fixed tree when I get home. g. > > Rob > > > Cheers, > > g. > > > > The following changes since commit dcd6c92267155e70a94b3927bce681ce74b80d1f: > > > > Linux 3.3-rc1 (2012-01-19 15:04:48 -0800) > > > > are available in the git repository at: > > git://git.secretlab.ca/git/linux-2.6 irqdomain/next > > > > Grant Likely (24): > > irq_domain: add documentation and MAINTAINERS entry. > > dt: Make irqdomain less verbose > > irq_domain: Make irq_domain structure match powerpc's irq_host > > irq_domain: convert microblaze from irq_host to irq_domain > > irq_domain/powerpc: Use common irq_domain structure instead of irq_host > > irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead > > irq_domain/powerpc: Eliminate virq_is_host() > > irq_domain: Move irq_domain code from powerpc to kernel/irq > > irqdomain: remove NO_IRQ from irq domain code > > irq_domain: Remove references to old irq_host names > > irq_domain: Replace irq_alloc_host() with revmap-specific initializers > > irq_domain: Add support for base irq and hwirq in legacy mappings > > irq_domain: Remove 'new' irq_domain in favour of the ppc one > > irq_domain: Remove irq_domain_add_simple() > > irq_domain: Create common xlate functions that device drivers can use > > irq_domain: constify irq_domain_ops > > irq_domain/c6x: constify irq_domain structures > > irq_domain/c6x: Use library of xlate functions > > irq_domain/powerpc: constify irq_domain_ops > > irqdomain/powerpc: Replace custom xlate functions with library functions > > irq_domain/x86: Convert x86 (embedded) to use common irq_domain > > irq_domain: Include hwirq number in /proc/interrupts > > irq_domain: remove "hint" when allocating irq numbers > > irq_domain: mostly eliminate slow-path revmap lookups > > > > Mark Salter (1): > > irq_domain/c6x: Convert c6x to use generic irq_domain support. > > > > Documentation/IRQ-domain.txt | 113 +++ > > MAINTAINERS | 9 + > > arch/arm/common/gic.c | 95 ++-- > > arch/arm/common/vic.c | 16 +- > > arch/arm/include/asm/hardware/gic.h | 4 +- > > arch/arm/include/asm/hardware/vic.h | 2 + > > arch/arm/mach-exynos/common.c | 2 +- > > arch/arm/mach-imx/mach-imx6q.c | 3 +- > > arch/arm/mach-msm/board-msm8x60.c | 8 +- > > arch/arm/mach-mx5/imx51-dt.c | 4 +- > > arch/arm/mach-mx5/imx53-dt.c | 4 +- > > arch/arm/mach-omap2/board-generic.c | 2 +- > > arch/arm/mach-prima2/irq.c | 2 +- > > arch/arm/mach-versatile/core.c | 5 +- > > arch/c6x/Kconfig | 1 + > > arch/c6x/include/asm/irq.h | 245 +------- > > arch/c6x/kernel/irq.c | 612 +---------------- > > arch/c6x/platforms/megamod-pic.c | 25 +- > > arch/microblaze/include/asm/irq.h | 4 +- > > arch/microblaze/kernel/irq.c | 2 +- > > arch/microblaze/kernel/setup.c | 2 - > > arch/powerpc/Kconfig | 1 + > > arch/powerpc/include/asm/ehv_pic.h | 2 +- > > arch/powerpc/include/asm/i8259.h | 2 +- > > arch/powerpc/include/asm/irq.h | 247 +------- > > arch/powerpc/include/asm/mpic.h | 2 +- > > arch/powerpc/include/asm/xics.h | 2 +- > > arch/powerpc/kernel/irq.c | 617 +---------------- > > arch/powerpc/platforms/512x/mpc5121_ads_cpld.c | 12 +- > > arch/powerpc/platforms/52xx/media5200.c | 15 +- > > arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 16 +- > > arch/powerpc/platforms/52xx/mpc52xx_pic.c | 12 +- > > arch/powerpc/platforms/82xx/pq2ads-pci-pic.c | 14 +- > > arch/powerpc/platforms/85xx/socrates_fpga_pic.c | 15 +- > > arch/powerpc/platforms/86xx/gef_pic.c | 15 +- > > arch/powerpc/platforms/cell/axon_msi.c | 29 +- > > arch/powerpc/platforms/cell/beat_interrupt.c | 16 +- > > arch/powerpc/platforms/cell/interrupt.c | 16 +- > > arch/powerpc/platforms/cell/spider-pic.c | 14 +- > > arch/powerpc/platforms/embedded6xx/flipper-pic.c | 30 +- > > arch/powerpc/platforms/embedded6xx/hlwd-pic.c | 35 +- > > arch/powerpc/platforms/iseries/irq.c | 11 +- > > arch/powerpc/platforms/powermac/pic.c | 26 +- > > arch/powerpc/platforms/powermac/smp.c | 9 +- > > arch/powerpc/platforms/ps3/interrupt.c | 11 +- > > arch/powerpc/platforms/wsp/opb_pic.c | 26 +- > > arch/powerpc/sysdev/cpm1.c | 9 +- > > arch/powerpc/sysdev/cpm2_pic.c | 23 +- > > arch/powerpc/sysdev/ehv_pic.c | 14 +- > > arch/powerpc/sysdev/fsl_msi.c | 10 +- > > arch/powerpc/sysdev/fsl_msi.h | 2 +- > > arch/powerpc/sysdev/i8259.c | 15 +- > > arch/powerpc/sysdev/ipic.c | 31 +- > > arch/powerpc/sysdev/ipic.h | 2 +- > > arch/powerpc/sysdev/mpc8xx_pic.c | 11 +- > > arch/powerpc/sysdev/mpic.c | 17 +- > > arch/powerpc/sysdev/mpic_msi.c | 2 +- > > arch/powerpc/sysdev/mv64x60_pic.c | 11 +- > > arch/powerpc/sysdev/qe_lib/qe_ic.c | 26 +- > > arch/powerpc/sysdev/qe_lib/qe_ic.h | 2 +- > > arch/powerpc/sysdev/tsi108_pci.c | 22 +- > > arch/powerpc/sysdev/uic.c | 26 +- > > arch/powerpc/sysdev/xics/xics-common.c | 28 +- > > arch/powerpc/sysdev/xilinx_intc.c | 19 +- > > arch/x86/Kconfig | 2 + > > arch/x86/include/asm/irq_controller.h | 12 - > > arch/x86/include/asm/prom.h | 10 - > > arch/x86/kernel/devicetree.c | 101 +-- > > drivers/gpio/gpio-mpc8xxx.c | 30 +- > > drivers/mfd/twl-core.c | 12 +- > > drivers/net/phy/mdio-gpio.c | 4 +- > > include/linux/irqdomain.h | 190 ++++-- > > kernel/irq/irqdomain.c | 816 +++++++++++++++++++--- > > kernel/irq/proc.c | 3 + > > 74 files changed, 1334 insertions(+), 2471 deletions(-) > > create mode 100644 Documentation/IRQ-domain.txt > > delete mode 100644 arch/x86/include/asm/irq_controller.h > > > > _______________________________________________ > > devicetree-discuss mailing list > > devicetree-discuss@lists.ozlabs.org > > https://lists.ozlabs.org/listinfo/devicetree-discuss >
On Fri, Jan 27, 2012 at 02:35:54PM -0700, Grant Likely wrote: > Hey everyone, > > This patch series is ready for much wider consumption now. I'd like > to get it into linux-next ASAP because there will be ARM board support > depending on it. I'll wait a few days before I ask Stephen to pull > this in. > > Stephen/Milton/Ben, any testing you can help with here would be > appreciated since you've got access to a wider variety of Power > machines than I do. This series has been: Tested-by: Olof Johansson <olof@lixom.net> On powerpc/pasemi (it's the only one I still have easy access to). -Olof
On Mon, Jan 30, 2012 at 08:53:44PM -0800, Olof Johansson wrote: > On Fri, Jan 27, 2012 at 02:35:54PM -0700, Grant Likely wrote: > > Hey everyone, > > > > This patch series is ready for much wider consumption now. I'd like > > to get it into linux-next ASAP because there will be ARM board support > > depending on it. I'll wait a few days before I ask Stephen to pull > > this in. > > > > Stephen/Milton/Ben, any testing you can help with here would be > > appreciated since you've got access to a wider variety of Power > > machines than I do. > > This series has been: > > Tested-by: Olof Johansson <olof@lixom.net> > > On powerpc/pasemi (it's the only one I still have easy access to). Excellent, thanks Olof! g.
On Fri, Jan 27, 2012 at 02:35:54PM -0700, Grant Likely wrote: > Hey everyone, > > This patch series is ready for much wider consumption now. I'd like > to get it into linux-next ASAP because there will be ARM board support > depending on it. I'll wait a few days before I ask Stephen to pull > this in. Grant, Can you answer me this: does this irqdomain support require DT? The question comes up because OMAP has converted some of their support to require irq domain support for their PMICs, and it seems irq domain support requires DT. This seems to have made the whole of OMAP essentially become a DT-only platform. Removing the dependency on IRQ_DOMAIN brings up these build errors in the twl-core code (that being the PMIC for OMAP CPUs): drivers/mfd/twl-core.c: In function 'twl_probe': drivers/mfd/twl-core.c:1229: error: invalid use of undefined type 'struct irq_domain' drivers/mfd/twl-core.c:1230: error: invalid use of undefined type 'struct irq_domain' drivers/mfd/twl-core.c:1235: error: implicit declaration of function 'irq_domain_add' That's a bit of a problem, because afaik there aren't the DT descriptions for the boards I have yet, so it's causing me to see regressions when building and booting kernels with CONFIG_OF=n. The more core-code we end up with which requires DT, the worse this problem is going to become - and obviously saying "everyone must now convert to DT" is, even today, a mammoth task. Now, here's the thing: I believe that IRQ domains - at least as far as the hwirq stuff - should be available irrespective of whether we have the rest of the IRQ domain support code in place, so that IRQ support code doesn't have to keep playing games to decode from the global space to the per-controller number space. I believe that would certainly help the current OMAP problems, where the current lack of CONFIG_IRQ_DOMAIN basically makes the kernel oops on boot. How we fix this regression for 3.4 I've no idea at present, I'm trying to work out what the real dependencies are for OMAP on this stuff. Finally, do we need asm/irq.h in our asm/prom.h ? That's causing fragility between DT and non-DT builds, because people are finding that their DT builds work without their mach/irqs.h includes but fail when built with non-DT. The only thing which DT might need - at the most - is NR_IRQS, but I'd hope with things like irq domains it doesn't actually require it.
On Sat, 2012-02-04 at 22:17 +0000, Russell King - ARM Linux wrote: > On Fri, Jan 27, 2012 at 02:35:54PM -0700, Grant Likely wrote: > > Hey everyone, > > > > This patch series is ready for much wider consumption now. I'd like > > to get it into linux-next ASAP because there will be ARM board support > > depending on it. I'll wait a few days before I ask Stephen to pull > > this in. > > Grant, > > Can you answer me this: does this irqdomain support require DT? The original powerpc code this is based on didn't require it. It was an explicit design decision and I remember insisting that Grant follows it, but I haven't yet reviewed his last batch. DT is orthogonal. You have "helpers" that use the DT to resolve the domain of an interrupt source and do the mapping for you, but I made sure that you call always still create domains and map interrupts using explicit domain pointers & hw numbers. (And I need them to deal with ancient broken device-tree's on some platforms such as oldworld PowerMacs). > The question comes up because OMAP has converted some of their support > to require irq domain support for their PMICs, and it seems irq domain > support requires DT. This seems to have made the whole of OMAP > essentially become a DT-only platform. .../... > Now, here's the thing: I believe that IRQ domains - at least as far as > the hwirq stuff - should be available irrespective of whether we have > the rest of the IRQ domain support code in place, so that IRQ support > code doesn't have to keep playing games to decode from the global > space to the per-controller number space. > > I believe that would certainly help the current OMAP problems, where > the current lack of CONFIG_IRQ_DOMAIN basically makes the kernel oops > on boot. > > How we fix this regression for 3.4 I've no idea at present, I'm trying > to work out what the real dependencies are for OMAP on this stuff. > > Finally, do we need asm/irq.h in our asm/prom.h ? That's causing > fragility between DT and non-DT builds, because people are finding > that their DT builds work without their mach/irqs.h includes but > fail when built with non-DT. The only thing which DT might need - > at the most - is NR_IRQS, but I'd hope with things like irq domains > it doesn't actually require it. Cheers, Ben.
Russell, On 02/04/2012 04:17 PM, Russell King - ARM Linux wrote: > On Fri, Jan 27, 2012 at 02:35:54PM -0700, Grant Likely wrote: >> Hey everyone, >> >> This patch series is ready for much wider consumption now. I'd like >> to get it into linux-next ASAP because there will be ARM board support >> depending on it. I'll wait a few days before I ask Stephen to pull >> this in. > > Grant, > > Can you answer me this: does this irqdomain support require DT? > No. It's the other way around, DT requires irqdomain. The GIC and VIC code for example can be built with or w/o DT enabled, but both select IRQ_DOMAIN. FYI, I just submitted a patch that selects IRQ_DOMAIN for all of ARM: http://www.gossamer-threads.com/lists/linux/kernel/1487231?page=last Either we do that or we select IRQ_DOMAIN one irq_chip at a time. With the "new" irq_domain code, we could probably do better to shrink the code needed in the non-DT case. > The question comes up because OMAP has converted some of their support > to require irq domain support for their PMICs, and it seems irq domain > support requires DT. This seems to have made the whole of OMAP > essentially become a DT-only platform. I think we should select DT or not at the sub-arch level. Trying to support both builds is a needless headache. > > Removing the dependency on IRQ_DOMAIN brings up these build errors > in the twl-core code (that being the PMIC for OMAP CPUs): > > drivers/mfd/twl-core.c: In function 'twl_probe': > drivers/mfd/twl-core.c:1229: error: invalid use of undefined type 'struct irq_domain' > drivers/mfd/twl-core.c:1230: error: invalid use of undefined type 'struct irq_domain' > drivers/mfd/twl-core.c:1235: error: implicit declaration of function 'irq_domain_add' > > That's a bit of a problem, because afaik there aren't the DT descriptions > for the boards I have yet, so it's causing me to see regressions when > building and booting kernels with CONFIG_OF=n. > > The more core-code we end up with which requires DT, the worse this > problem is going to become - and obviously saying "everyone must now > convert to DT" is, even today, a mammoth task. > > Now, here's the thing: I believe that IRQ domains - at least as far as > the hwirq stuff - should be available irrespective of whether we have > the rest of the IRQ domain support code in place, so that IRQ support > code doesn't have to keep playing games to decode from the global > space to the per-controller number space. > > I believe that would certainly help the current OMAP problems, where > the current lack of CONFIG_IRQ_DOMAIN basically makes the kernel oops > on boot. > > How we fix this regression for 3.4 I've no idea at present, I'm trying > to work out what the real dependencies are for OMAP on this stuff. > > Finally, do we need asm/irq.h in our asm/prom.h ? That's causing > fragility between DT and non-DT builds, because people are finding > that their DT builds work without their mach/irqs.h includes but > fail when built with non-DT. The only thing which DT might need - > at the most - is NR_IRQS, but I'd hope with things like irq domains > it doesn't actually require it. Doesn't look like it is needed. Rob > _______________________________________________ > devicetree-discuss mailing list > devicetree-discuss@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss
On Sat, Feb 04, 2012 at 10:17:48PM +0000, Russell King - ARM Linux wrote: > On Fri, Jan 27, 2012 at 02:35:54PM -0700, Grant Likely wrote: > > Hey everyone, > > > > This patch series is ready for much wider consumption now. I'd like > > to get it into linux-next ASAP because there will be ARM board support > > depending on it. I'll wait a few days before I ask Stephen to pull > > this in. > > Grant, > > Can you answer me this: does this irqdomain support require DT? No, it should not. Any situation where it does is a bug. > Now, here's the thing: I believe that IRQ domains - at least as far as > the hwirq stuff - should be available irrespective of whether we have > the rest of the IRQ domain support code in place, so that IRQ support > code doesn't have to keep playing games to decode from the global > space to the per-controller number space. Correct. That's the intent. My new series flushes out irq_domain quite a bit better and gets all architectures doing the same thing if they use irq_domains. I've done some testing on both CONFIG_OF and !CONFIG_OF builds, but I'm going to do some more to make sure I've not missed anything. > I believe that would certainly help the current OMAP problems, where > the current lack of CONFIG_IRQ_DOMAIN basically makes the kernel oops > on boot. > > How we fix this regression for 3.4 I've no idea at present, I'm trying > to work out what the real dependencies are for OMAP on this stuff. > > Finally, do we need asm/irq.h in our asm/prom.h ? That's causing > fragility between DT and non-DT builds, because people are finding > that their DT builds work without their mach/irqs.h includes but > fail when built with non-DT. The only thing which DT might need - > at the most - is NR_IRQS, but I'd hope with things like irq domains > it doesn't actually require it. I don't think so. There may be a file or two that break because they're not including everything they need, but I don't think anything in the header requires it. The irq_domain code is well isolated. The header file doesn't need to be including it. g.