Re: [PATCH v2 00/21] irqchip: gic: killing gic_arch_extn and co, slowly
On 12/01/15 14:14, Rob Herring wrote:
> On Wed, Jan 7, 2015 at 11:42 AM, Marc Zyngier wrote:
>> The gic_arch_extn hack that a number of platform use has been nagging
>> me for too long. It is only there for the benefit of a few platform,
>> and yet it impacts all GIC users. Moreover, it gives people the wrong
>> idea ("let's use it to put some new custom hack in there"...).
>>
>> But now that stacked irq domains have landed in -next, the time has
>> come for gic_arch_extn to meet the Big Bit Bucket.
>
> [...]
>
>> - This actively *breaks* existing setups. Once you boot a new kernel
>> with an old DT, suspend/resume *will* be broken. Old kernels on a
>> new DT won't even boot! You've been warned. This really outline the
>> necessity of actually describing the HW in device trees...
>
> Just to be clear, you need some agreement from the maintainers of
> those platforms before doing this. It doesn't appear there is
> disagreement, but I don't see any explicit agreement either.
I'm not trying to go behind anyone's back, if that's your concern. I
fully intend to obtain every maintainer's explicit acknowledgement
before removing any feature from the kernel. The warning above is there
to get the maintainers attention on the disrupting effect of this series.
> This seems to model the interrupts as chained, but at least for some
> cases aren't these auxiliary controllers in parallel to the GIC? In
>From looking at the various TRMs, they all look to be chained interrupt
controllers (at least Tegra, OMAP and IMX6 show this). I have not been
able to find a publicly available TRM for any of the Samsung platforms,
so this one could be different (but I really doubt it somehow).
> other words, do the they require configuration for interrupts to work
> for the normal non-wakeup use? I'm not sure that the h/w is being
> modeled any more accurately if that is the case. However, we don't
> really have a way to describe an interrupt line is connected to 2
> interrupt parents in DT, so I'm not sure what else you could do here.
The main problem is that they are not general-purpose interrupt
controllers. They all come first on the interrupt path, and somehow feed
two signals into the GIC: the actual interrupt, and the bypass signal.
None of that is representable in DT. I'm willing to take any idea though.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/21] irqchip: gic: killing gic_arch_extn and co, slowly
On Wed, Jan 7, 2015 at 11:42 AM, Marc Zyngier wrote:
> The gic_arch_extn hack that a number of platform use has been nagging
> me for too long. It is only there for the benefit of a few platform,
> and yet it impacts all GIC users. Moreover, it gives people the wrong
> idea ("let's use it to put some new custom hack in there"...).
>
> But now that stacked irq domains have landed in -next, the time has
> come for gic_arch_extn to meet the Big Bit Bucket.
[...]
> - This actively *breaks* existing setups. Once you boot a new kernel
> with an old DT, suspend/resume *will* be broken. Old kernels on a
> new DT won't even boot! You've been warned. This really outline the
> necessity of actually describing the HW in device trees...
Just to be clear, you need some agreement from the maintainers of
those platforms before doing this. It doesn't appear there is
disagreement, but I don't see any explicit agreement either.
This seems to model the interrupts as chained, but at least for some
cases aren't these auxiliary controllers in parallel to the GIC? In
other words, do the they require configuration for interrupts to work
for the normal non-wakeup use? I'm not sure that the h/w is being
modeled any more accurately if that is the case. However, we don't
really have a way to describe an interrupt line is connected to 2
interrupt parents in DT, so I'm not sure what else you could do here.
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/21] irqchip: gic: killing gic_arch_extn and co, slowly
On 2015-01-07 17:42, Marc Zyngier wrote:
The gic_arch_extn hack that a number of platform use has been nagging
me for too long. It is only there for the benefit of a few platform,
and yet it impacts all GIC users. Moreover, it gives people the wrong
idea ("let's use it to put some new custom hack in there"...).
But now that stacked irq domains have landed in -next, the time has
come for gic_arch_extn to meet the Big Bit Bucket.
This patch series takes several steps towards the elimination of
gic_arch_extn:
- moves Tegra's legacy interrupt controller support to
drivers/irqchip, implementing a stacked domain on top of the
standard GIC.
- OMAP, imx6 and exynos are also converted to stacked domains, but
their implementation is left in place (the code is far too
intricately mixed with other details of the platform for me to even
try to move it). Some OMAP variants get a special treatment as we
also kill the crossbar horror (more on that below).
- shmobile, ux500 and zynq are only slightly modified.
- The GIC itself is cleaned up, and some other bits and bobs are
adjusted for a good measure.
About the TI crossbar:
- The allocation of interrupts in this domain is fairly similar to
what we do for MSI (see the GICv2m driver), and stacked domains
have
proved to be a fitting solution.
- The current description in DT is currently entierely inaccurate,
and
as we already broke it for the OMAP WUGEN block, we might as well
do
it again for the TI crossbar.
- The way crossbar, WUGEN and GIC interract is quite complex (this is
effectively a stack of three interrupt controllers with interesting
exceptions and braindead routing), and stacked domains are the
right
abstraction for that.
- Other platforms (Freescale Vybrid) are starting to come up with the
same type of things, and it'd be good to avoid them following the
same broken model.
- It removes a few lines from the code base so it can't completely be
a bad idea!
So this patch series does exactly that: make the crossbar a stacked
interrupt controller that only takes care of setting up the routing,
fix the DTs to represent the actual HW, and remove a bit of the
craziness from the GIC code.
It is worth realizing that:
- I haven't been able to test this as much as I would have wanted to
(it's only been tested on tegra2 and omap5).
- I've created DT bindings when needed, updated existing ones, but I
haven't created a binding for platforms that already used an
undocumented one (imx6, I'm looking at you).
- I've relaxed quite a bit of the locking in the GIC code. I believe
this is safe, but someone else should give it a long hard look.
- This actively *breaks* existing setups. Once you boot a new kernel
with an old DT, suspend/resume *will* be broken. Old kernels on a
new DT won't even boot! You've been warned. This really outline the
necessity of actually describing the HW in device trees...
As for the patches, they are on top of 3.19-rc3.
I've pushed the code to:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
irq/die-gic-arch-extn-die-die-die
I've updated this branch with the changes requested in this review
cycle. I'll give it a test run on Monday with the platforms I have
around (mainly Tegra20 and OMAP4/5).
Unless anything major comes up, I'll post v3 with a view of getting
this into 3.20.
Thanks,
M.
--
Fast, cheap, reliable. Pick two.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/21] irqchip: gic: killing gic_arch_extn and co, slowly
On 17:42-20150107, Marc Zyngier wrote: > As for the patches, they are on top of 3.19-rc3. Applied the 21 patches and gave a quick dry run on various boards BASE = v3.19-rc3 + 1 uImage+dtb patch for IRQ = v3.19-rc3 + irq series NOTE: I am yet to dig in deeper to figure out which platform may have valid regressions etc. will do that tomorrow. meanwhile, some raw test results below: +++v3.19-rc3 - BOOT TEST+++ boot 1: am335x-evm: BOOT: PASS: http://slexy.org/raw/s2IOPX99Ty 2: am335x-sk: BOOT: FAIL: http://slexy.org/raw/s2dzt0lTF7 3: am3517-evm: BOOT: PASS: http://slexy.org/raw/s23yAMKuRx 4: am37x-evm: BOOT: PASS: http://slexy.org/raw/s20vsYwsYQ 5: am437x-sk: BOOT: PASS: http://slexy.org/raw/s2QgujFs6l 6:am43xx-epos: BOOT: PASS: http://slexy.org/raw/s2QHVg9XcB 7: am43xx-gpevm: BOOT: PASS: http://slexy.org/raw/s2Ep5DEQuk 8:BeagleBoard-X15(am57xx-evm): BOOT: PASS: http://slexy.org/raw/s20STBNTs9 9: BeagleBoard-XM: BOOT: PASS: http://slexy.org/raw/s2UhG6u7yM 10:beagleboard-vanilla: BOOT: PASS: http://slexy.org/raw/s2QB7ECFKw 11: beaglebone-black: BOOT: PASS: http://slexy.org/raw/s20iAe7yTa 12: beaglebone: BOOT: PASS: http://slexy.org/raw/s20Uui1gkn 13: craneboard: BOOT: PASS: http://slexy.org/raw/s21DcY6gn4 14: dra72x-evm: BOOT: PASS: http://slexy.org/raw/s2qj7IvmaV 15: dra7xx-evm: BOOT: PASS: http://slexy.org/raw/s20lLxN8bR 16: OMAP3430-Labrador(LDP): BOOT: PASS: http://slexy.org/raw/s20GmT9ASX 17: n900: BOOT: FAIL: http://slexy.org/raw/s2riSEzfea 18: omap5-evm: BOOT: PASS: http://slexy.org/raw/s21adCD3Js 19: pandaboard-es: BOOT: PASS: http://slexy.org/raw/s21Am3vEzM 20: pandaboard-vanilla: BOOT: PASS: http://slexy.org/raw/s2XLmW2ONB 21:sdp2430: BOOT: PASS: http://slexy.org/raw/s21ehzlzyv 22:sdp3430: BOOT: PASS: http://slexy.org/raw/s24gh1VUnl 23:sdp4430: BOOT: PASS: http://slexy.org/raw/s2HfgkFfOx TOTAL = 23 boards, Booted Boards = 21, No Boot boards = 2 +++ IRQ - BOOT TEST+++ boot 1: am335x-evm: BOOT: PASS: http://slexy.org/raw/s21411sejg 2: am335x-sk: BOOT: PASS: http://slexy.org/raw/s209N4Tu4E 3: am3517-evm: BOOT: PASS: http://slexy.org/raw/s2Shbhciy8 4: am37x-evm: BOOT: PASS: http://slexy.org/raw/s20wfqH0Wo 5: am437x-sk: BOOT: PASS: http://slexy.org/raw/s21uAXcB12 6:am43xx-epos: BOOT: PASS: http://slexy.org/raw/s26MGCZz0i 7: am43xx-gpevm: BOOT: PASS: http://slexy.org/raw/s2c8IGmWfB 8:BeagleBoard-X15(am57xx-evm): BOOT: FAIL: http://slexy.org/raw/s2u1yV4hHK 9: BeagleBoard-XM: BOOT: PASS: http://slexy.org/raw/s20zzOBKWJ 10:beagleboard-vanilla: BOOT: PASS: http://slexy.org/raw/s2wffxWVGa 11: beaglebone-black: BOOT: PASS: http://slexy.org/raw/s2Yshc0Vkw 12: beaglebone: BOOT: PASS: http://slexy.org/raw/s2Ki0ohBVf 13: craneboard: BOOT: PASS: http://slexy.org/raw/s2GVlDWkzP 14: dra72x-evm: BOOT: PASS: http://slexy.org/raw/s2dfZIVZ42 15: dra7xx-evm: BOOT: PASS: http://slexy.org/raw/s25UqvqVna 16: OMAP3430-Labrador(LDP): BOOT: PASS: http://slexy.org/raw/s20plEBPRB 17: n900: BOOT: FAIL: http://slexy.org/raw/s20zeM6YUP 18: omap5-evm: BOOT: PASS: http://slexy.org/raw/s2JOb4VEGJ 19: pandaboard-es: BOOT: PASS: http://slexy.org/raw/s20jCqY4OV 20: pandaboard-vanilla: BOOT: PASS: http://slexy.org/raw/s21TuquMeN 21:sdp2430: BOOT: PASS: http://slexy.org/raw/s20z1S6w1a 22:sdp3430: BOOT: PASS: http://slexy.org/raw/s20SJo6BqV 23:sdp4430: BOOT: PASS: http://slexy.org/raw/s204Bn9azX TOTAL = 23 boards, Booted Boards = 21, No Boot boards = 2 +++v3.19-rc3 - POWER TEST+++ power 1: am335x-evm: BOOT: PASS: err=10 warn=24, CPUFreq: PASS, CPUIdle: N/A: http://slexy.org/raw/s20t02tklu 2: am335x-sk: BOOT: FAIL: http://slexy.org/raw/s2HX7WisAk 3: am3517-evm: BOOT: FAIL: http://slexy.org/raw/s2mdCPTUBw 4: am37x-evm: BOOT: FAIL: http://slexy.org/raw/s2beWlmPMy 5: am437x-sk: BOOT: PASS: crit=2 err=12 warn=25, CPUFreq: N/A, CPUIdle: N/A: http://slexy.org/raw/s2Z0QTrATC 6:am43xx-epos: BOOT: PASS: crit=2 err=15 warn=26, CPUFreq: N/A, CPUIdle: N/A: http://slexy.org/raw/s21VqMaKE5 7: am43xx-gpevm: BOOT: PASS: crit=2 err=12 warn=25, CPUFreq: N/A, CPUIdl
Re: [PATCH v2 00/21] irqchip: gic: killing gic_arch_extn and co, slowly
Marc,
On 1/7/2015 9:42 AM, Marc Zyngier wrote:
The gic_arch_extn hack that a number of platform use has been nagging
me for too long. It is only there for the benefit of a few platform,
and yet it impacts all GIC users. Moreover, it gives people the wrong
idea ("let's use it to put some new custom hack in there"...).
But now that stacked irq domains have landed in -next, the time has
come for gic_arch_extn to meet the Big Bit Bucket.
This patch series takes several steps towards the elimination of
gic_arch_extn:
- moves Tegra's legacy interrupt controller support to
drivers/irqchip, implementing a stacked domain on top of the
standard GIC.
- OMAP, imx6 and exynos are also converted to stacked domains, but
their implementation is left in place (the code is far too
intricately mixed with other details of the platform for me to even
try to move it). Some OMAP variants get a special treatment as we
also kill the crossbar horror (more on that below).
- shmobile, ux500 and zynq are only slightly modified.
- The GIC itself is cleaned up, and some other bits and bobs are
adjusted for a good measure.
About the TI crossbar:
- The allocation of interrupts in this domain is fairly similar to
what we do for MSI (see the GICv2m driver), and stacked domains have
proved to be a fitting solution.
- The current description in DT is currently entierely inaccurate, and
as we already broke it for the OMAP WUGEN block, we might as well do
it again for the TI crossbar.
- The way crossbar, WUGEN and GIC interract is quite complex (this is
effectively a stack of three interrupt controllers with interesting
exceptions and braindead routing), and stacked domains are the right
abstraction for that.
- Other platforms (Freescale Vybrid) are starting to come up with the
same type of things, and it'd be good to avoid them following the
same broken model.
- It removes a few lines from the code base so it can't completely be
a bad idea!
So this patch series does exactly that: make the crossbar a stacked
interrupt controller that only takes care of setting up the routing,
fix the DTs to represent the actual HW, and remove a bit of the
craziness from the GIC code.
It is worth realizing that:
- I haven't been able to test this as much as I would have wanted to
(it's only been tested on tegra2 and omap5).
- I've created DT bindings when needed, updated existing ones, but I
haven't created a binding for platforms that already used an
undocumented one (imx6, I'm looking at you).
- I've relaxed quite a bit of the locking in the GIC code. I believe
this is safe, but someone else should give it a long hard look.
- This actively *breaks* existing setups. Once you boot a new kernel
with an old DT, suspend/resume *will* be broken. Old kernels on a
new DT won't even boot! You've been warned. This really outline the
necessity of actually describing the HW in device trees...
As for the patches, they are on top of 3.19-rc3.
I've pushed the code to:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
irq/die-gic-arch-extn-die-die-die
Comments welcome,
M.
Marc Zyngier (21):
ARM: tegra: irq: nuke leftovers from non-DT support
irqchip: tegra: add DT-based support for legacy interrupt controller
ARM: tegra: skip gic_arch_extn setup if DT has a LIC node
ARM: tegra: update DTs to expose legacy interrupt controller
DT: tegra: add binding for the legacy interrupt controller
ARM: tegra: remove old LIC support
genirq: Add irqchip_set_wake_parent
irqchip: crossbar: convert dra7 crossbar to stacked domains
DT: update ti,irq-crossbar binding
irqchip: GIC: get rid of routable domain
DT: arm,gic: kill arm,routable-irqs
ARM: omap: convert wakeupgen to stacked domains
DT: omap4/5: add binding for the wake-up generator
ARM: imx6: convert GPC to stacked domains
ARM: exynos4/5: convert pmu wakeup to stacked domains
DT: exynos: update PMU binding
irqchip: gic: add an entry point to set up irqchip flags
ARM: shmobile: remove use of gic_arch_extn.irq_set_wake
ARM: ux500: switch from gic_arch_extn to gic_set_irqchip_flags
ARM: zynq: switch from gic_arch_extn to gic_set_irqchip_flags
irqchip: gic: Drop support for gic_arch_extn
Thanks a lot for killing those gic_arch_extn and cross-bar with
newly added stacked domains. It cleans up the GIC code for better.
Feel free to add my ack if you need one.
Acked-by: Santosh Shilimkar
Regards,
Snatosh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 00/21] irqchip: gic: killing gic_arch_extn and co, slowly
The gic_arch_extn hack that a number of platform use has been nagging
me for too long. It is only there for the benefit of a few platform,
and yet it impacts all GIC users. Moreover, it gives people the wrong
idea ("let's use it to put some new custom hack in there"...).
But now that stacked irq domains have landed in -next, the time has
come for gic_arch_extn to meet the Big Bit Bucket.
This patch series takes several steps towards the elimination of
gic_arch_extn:
- moves Tegra's legacy interrupt controller support to
drivers/irqchip, implementing a stacked domain on top of the
standard GIC.
- OMAP, imx6 and exynos are also converted to stacked domains, but
their implementation is left in place (the code is far too
intricately mixed with other details of the platform for me to even
try to move it). Some OMAP variants get a special treatment as we
also kill the crossbar horror (more on that below).
- shmobile, ux500 and zynq are only slightly modified.
- The GIC itself is cleaned up, and some other bits and bobs are
adjusted for a good measure.
About the TI crossbar:
- The allocation of interrupts in this domain is fairly similar to
what we do for MSI (see the GICv2m driver), and stacked domains have
proved to be a fitting solution.
- The current description in DT is currently entierely inaccurate, and
as we already broke it for the OMAP WUGEN block, we might as well do
it again for the TI crossbar.
- The way crossbar, WUGEN and GIC interract is quite complex (this is
effectively a stack of three interrupt controllers with interesting
exceptions and braindead routing), and stacked domains are the right
abstraction for that.
- Other platforms (Freescale Vybrid) are starting to come up with the
same type of things, and it'd be good to avoid them following the
same broken model.
- It removes a few lines from the code base so it can't completely be
a bad idea!
So this patch series does exactly that: make the crossbar a stacked
interrupt controller that only takes care of setting up the routing,
fix the DTs to represent the actual HW, and remove a bit of the
craziness from the GIC code.
It is worth realizing that:
- I haven't been able to test this as much as I would have wanted to
(it's only been tested on tegra2 and omap5).
- I've created DT bindings when needed, updated existing ones, but I
haven't created a binding for platforms that already used an
undocumented one (imx6, I'm looking at you).
- I've relaxed quite a bit of the locking in the GIC code. I believe
this is safe, but someone else should give it a long hard look.
- This actively *breaks* existing setups. Once you boot a new kernel
with an old DT, suspend/resume *will* be broken. Old kernels on a
new DT won't even boot! You've been warned. This really outline the
necessity of actually describing the HW in device trees...
As for the patches, they are on top of 3.19-rc3.
I've pushed the code to:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
irq/die-gic-arch-extn-die-die-die
Comments welcome,
M.
Marc Zyngier (21):
ARM: tegra: irq: nuke leftovers from non-DT support
irqchip: tegra: add DT-based support for legacy interrupt controller
ARM: tegra: skip gic_arch_extn setup if DT has a LIC node
ARM: tegra: update DTs to expose legacy interrupt controller
DT: tegra: add binding for the legacy interrupt controller
ARM: tegra: remove old LIC support
genirq: Add irqchip_set_wake_parent
irqchip: crossbar: convert dra7 crossbar to stacked domains
DT: update ti,irq-crossbar binding
irqchip: GIC: get rid of routable domain
DT: arm,gic: kill arm,routable-irqs
ARM: omap: convert wakeupgen to stacked domains
DT: omap4/5: add binding for the wake-up generator
ARM: imx6: convert GPC to stacked domains
ARM: exynos4/5: convert pmu wakeup to stacked domains
DT: exynos: update PMU binding
irqchip: gic: add an entry point to set up irqchip flags
ARM: shmobile: remove use of gic_arch_extn.irq_set_wake
ARM: ux500: switch from gic_arch_extn to gic_set_irqchip_flags
ARM: zynq: switch from gic_arch_extn to gic_set_irqchip_flags
irqchip: gic: Drop support for gic_arch_extn
Documentation/devicetree/bindings/arm/gic.txt | 6 -
.../devicetree/bindings/arm/omap/crossbar.txt | 18 +-
.../devicetree/bindings/arm/samsung/pmu.txt| 13 +
.../interrupt-controller/nvidia,tegra-ictlr.txt| 39 +++
.../interrupt-controller/ti,omap4-wugen-mpu| 32 ++
arch/arm/boot/dts/am4372.dtsi | 11 +-
arch/arm/boot/dts/dra7-evm.dts | 2 +-
arch/arm/boot/dts/dra7.dtsi| 43 ++-
arch/arm/boot/dts/dra72-evm.dts| 1 -
arch/arm/boot/dts/dra72x.dtsi | 3 +-
arch/arm/boot/dts/dra74x.dtsi | 5 +-
arch/arm/boot/dts/exynos4.dtsi | 3 +
arch/arm/boot/dts/exynos5250.dtsi
