ARM: OMAP: irqs: Fix NR_IRQS value to handle PRCM interrupts
Subsystems (2)
PATCH 1/1 ARM: OMAP: irqs: Fix NR_IRQS value to handle PRCM interrupts
The following commit: 2f31b51659c2d8315ea2888ba5b93076febe672b
Author: Tero Kristo <[email protected]>
Date: Fri Dec 16 14:37:00 2011 -0700
ARM: OMAP4: PRM: use PRCM interrupt handler
introduced the PRCM interrupt handler and thus the need for 64 more interrupts. Since SPARSE_IRQ is still not fully functional on OMAP, the NR_IRQS needs to be updated to avoid the failure that happen during irq_alloc_descs call inside the PRCM driver:
[ 0.208221] PRCM: failed to allocate irq descs: -12
Later the mux framework is then unable to request an IRQ from the PRCM interrupt handler.
[ 1.802795] mux: Failed to setup hwmod io irq -22
Fix that by adding 64 more interrupts for OMAP2PLUS config.
---
Tony,
This patch should probably go for the next -rc if possible.
Thanks,
Benoit
arch/arm/plat-omap/include/plat/irqs.h | 10 +++++++++- 1 files changed, 9 insertions(+), 1 deletions(-)
arch/arm/plat-omap/include/plat/irqs.h +9 -1
@@ -428,8 +428,16 @@#define OMAP_GPMC_NR_IRQS 8#define OMAP_GPMC_IRQ_END (OMAP_GPMC_IRQ_BASE + OMAP_GPMC_NR_IRQS) +/* PRCM IRQ handler */ +#ifdef CONFIG_ARCH_OMAP2PLUS +#define OMAP_PRCM_IRQ_BASE (OMAP_GPMC_IRQ_END) +#define OMAP_PRCM_NR_IRQS 64 +#define OMAP_PRCM_IRQ_END (OMAP_PRCM_IRQ_BASE + OMAP_PRCM_NR_IRQS) +#else +#define OMAP_PRCM_IRQ_END OMAP_GPMC_IRQ_END +#endif -#define NR_IRQS OMAP_GPMC_IRQ_END +#define NR_IRQS OMAP_PRCM_IRQ_END#define OMAP_IRQ_BIT (irq) (1 << ((irq) % 32))
Signature · 1 line
1.7.0.4
PATCH 1/1 ARM: OMAP: irqs: Fix NR_IRQS value to handle PRCM interrupts
Quoted 12 lines · Benoit
The following commit:
2f31b51659c2d8315ea2888ba5b93076febe672b
Author: Tero Kristo <[email protected]>
Date: Fri Dec 16 14:37:00 2011 -0700ARM: OMAP4: PRM: use PRCM interrupt handler
introduced the PRCM interrupt handler and thus the need for 64 more interrupts. Since
SPARSE_IRQis still not fully functional on OMAP, theNR_IRQSneeds to be updated to avoid the failure that happen duringirq_alloc_descscall inside the PRCM driver:
Quoted 6 lines
[ 0.208221] PRCM: failed to allocate irq descs: -12Later the mux framework is then unable to request an IRQ from the PRCM interrupt handler.
[ 1.802795] mux: Failed to setup hwmod io irq -22
This is fine for rc, but longer term...
Do any of these have hard-coded interrupt numbers associated with them? If not, just enabling sparse IRQ will sort this out.
As I tried to explain yesterday, there are two modes for IRQ allocation:
1. Without sparse IRQ enabled, irq_alloc_descs(-1, from, num, -1) will allocate IRQs _within_ the existing from..NR_IRQS range, and will fail if there is insufficient IRQs available.
2. With sparse IRQs enabled, irq_alloc_descs(-1, from, num, -1) will allocate IRQs starting at max(from, NR_IRQS) and working upwards.
In either case, irq_alloc_descs(start, 0, num, -1) will allocate 'num' IRQs at 'start' or fail if the range is already in use (and 0..NR_IRQS is defined as 'being in use' when sparse IRQs are enabled.)
So, if the PRCM interrupts aren't statically assigned (the code suggests that they aren't) then it's already sparse-IRQ compliant, and enabling sparse IRQ support will mean that they will be allocated above NR_IRQS.
Therefore, I suggest rather than raising NR_IRQS, you instead enable SPARSE_IRQ now so that anyone using the dynamic IRQ allocation can benefit from sparse IRQ support without having to have a large NR_IRQS.
So, you don't have to wait until everything is converted to use sparse IRQ. You just need to make sure that nothing uses irq_alloc_descs(start, from, num, ...) where start < NR_IRQS, and nothing using that requires statically defined IRQ numbering.
PATCH 1/1 ARM: OMAP: irqs: Fix NR_IRQS value to handle PRCM interrupts
Hi Russell,
Quoted 18 lines · Russell King - ARM Linux
Quoted 17 lines · Benoit
The following commit:
2f31b51659c2d8315ea2888ba5b93076febe672b
Author: Tero Kristo<[email protected]>
Date: Fri Dec 16 14:37:00 2011 -0700ARM: OMAP4: PRM: use PRCM interrupt handler
introduced the PRCM interrupt handler and thus the need for 64 more interrupts. Since
SPARSE_IRQis still not fully functional on OMAP, theNR_IRQSneeds to be updated to avoid the failure that happen duringirq_alloc_descscall inside the PRCM driver:[ 0.208221] PRCM: failed to allocate irq descs: -12Later the mux framework is then unable to request an IRQ from the PRCM interrupt handler.
Quoted 6 lines
Quoted 1 line
[ 1.802795] mux: Failed to setup hwmod io irq -22This is fine for rc, but longer term...
Do any of these have hard-coded interrupt numbers associated with them? If not, just enabling sparse IRQ will sort this out.
You're right, in that case, it does not depend on any hard-coded number.
Quoted 17 lines
As I tried to explain yesterday, there are two modes for IRQ allocation:
1. Without sparse IRQ enabled,
irq_alloc_descs(-1, from, num, -1)will allocate IRQs _within_ the existing from..NR_IRQS range, and will fail if there is insufficient IRQs available.2. With sparse IRQs enabled,
irq_alloc_descs(-1, from, num, -1)will allocate IRQs starting atmax(from, NR_IRQS)and working upwards.In either case,
irq_alloc_descs(start, 0, num, -1)will allocate 'num' IRQs at 'start' or fail if the range is already in use (and 0..NR_IRQS is defined as 'being in use' when sparse IRQs are enabled.)So, if the PRCM interrupts aren't statically assigned (the code suggests that they aren't) then it's already sparse-IRQ compliant, and enabling sparse IRQ support will mean that they will be allocated above
NR_IRQS.
Quoted 8 lines
Therefore, I suggest rather than raising
NR_IRQS, you instead enableSPARSE_IRQnow so that anyone using the dynamic IRQ allocation can benefit from sparse IRQ support without having to have a largeNR_IRQS.So, you don't have to wait until everything is converted to use sparse IRQ. You just need to make sure that nothing uses
irq_alloc_descs(start, from, num, ...)where start<NR_IRQS, and nothing using that requires statically defined IRQ numbering.
Yes, I fully agree, and that's still the plan. That's why I started sending last week a bunch of cleanup for SPARSE_IRQ support. Unfortunately, they might not be ready for 3.4 either, but I'm still working on it.
Meanwhile, we need the current temporary fix.
I can emphasis the temporary duration on that patch in the changelog if needed.
Thanks,
Benoit
PATCH 1/1 ARM: OMAP: irqs: Fix NR_IRQS value to handle PRCM interrupts
Quoted 56 lines · Benoit
Hi Russell,
Quoted 18 lines · Russell King - ARM Linux
Quoted 17 lines · Benoit
The following commit:
2f31b51659c2d8315ea2888ba5b93076febe672b
Author: Tero Kristo<[email protected]>
Date: Fri Dec 16 14:37:00 2011 -0700ARM: OMAP4: PRM: use PRCM interrupt handler
introduced the PRCM interrupt handler and thus the need for 64 more interrupts. Since
SPARSE_IRQis still not fully functional on OMAP, theNR_IRQSneeds to be updated to avoid the failure that happen duringirq_alloc_descscall inside the PRCM driver:[ 0.208221] PRCM: failed to allocate irq descs: -12Later the mux framework is then unable to request an IRQ from the PRCM interrupt handler.
Quoted 6 lines
Quoted 1 line
[ 1.802795] mux: Failed to setup hwmod io irq -22This is fine for rc, but longer term...
Do any of these have hard-coded interrupt numbers associated with them? If not, just enabling sparse IRQ will sort this out.
You're right, in that case, it does not depend on any hard-coded number.
Quoted 17 lines
As I tried to explain yesterday, there are two modes for IRQ allocation:
1. Without sparse IRQ enabled,
irq_alloc_descs(-1, from, num, -1)will allocate IRQs _within_ the existing from..NR_IRQS range, and will fail if there is insufficient IRQs available.2. With sparse IRQs enabled,
irq_alloc_descs(-1, from, num, -1)will allocate IRQs starting atmax(from, NR_IRQS)and working upwards.In either case,
irq_alloc_descs(start, 0, num, -1)will allocate 'num' IRQs at 'start' or fail if the range is already in use (and 0..NR_IRQS is defined as 'being in use' when sparse IRQs are enabled.)So, if the PRCM interrupts aren't statically assigned (the code suggests that they aren't) then it's already sparse-IRQ compliant, and enabling sparse IRQ support will mean that they will be allocated above
NR_IRQS.Quoted 8 lines
Therefore, I suggest rather than raising
NR_IRQS, you instead enableSPARSE_IRQnow so that anyone using the dynamic IRQ allocation can benefit from sparse IRQ support without having to have a largeNR_IRQS.So, you don't have to wait until everything is converted to use sparse IRQ. You just need to make sure that nothing uses
irq_alloc_descs(start, from, num, ...)where start<NR_IRQS, and nothing using that requires statically defined IRQ numbering.
Quoted 4 lines
Yes, I fully agree, and that's still the plan. That's why I started sending last week a bunch of cleanup for
SPARSE_IRQsupport. Unfortunately, they might not be ready for 3.4 either, but I'm still working on it.
One thing I didn't consider is that the GIC has been converted to sparse IRQ support, so enabling it on OMAP will make the irq_alloc_descs() in there to fail if you try and keep it below NR_IRQS.
That rules out a piecemeal conversion, which rather sucks.
PATCH 1/1 ARM: OMAP: irqs: Fix NR_IRQS value to handle PRCM interrupts
In reply to Cousson, BenoitQuoted 19 lines · Cousson, Benoit
The following commit:
2f31b51659c2d8315ea2888ba5b93076febe672b
Author: Tero Kristo <[email protected]>
Date: Fri Dec 16 14:37:00 2011 -0700ARM: OMAP4: PRM: use PRCM interrupt handler
introduced the PRCM interrupt handler and thus the need for 64 more interrupts. Since
SPARSE_IRQis still not fully functional on OMAP, theNR_IRQSneeds to be updated to avoid the failure that happen duringirq_alloc_descscall inside the PRCM driver:[ 0.208221] PRCM: failed to allocate irq descs: -12Later the mux framework is then unable to request an IRQ from the PRCM interrupt handler.
[ 1.802795] mux: Failed to setup hwmod io irq -22
Quoted 8 lines
Fix that by adding 64 more interrupts for OMAP2PLUS config.
Signed-off-by Benoit Cousson <[email protected]>Cc Tero Kristo <[email protected]>---
Tony,This patch should probably go for the next -rc if possible.
Thanks applying into fixes as it seems like the only available fix right now.
Tony