* [PATCH] ARM: OMAP: irqs: Fix NR_IRQS value to handle PRCM interrupts
@ 2012-02-28 13:10 ` Cousson, Benoit
0 siblings, 0 replies; 10+ messages in thread
From: Cousson, Benoit @ 2012-02-28 13:10 UTC (permalink / raw)
To: tony Lindgren
Cc: linux-omap, linux-arm-kernel@lists.infradead.org, Nayak, Rajendra
The following commit: 2f31b51659c2d8315ea2888ba5b93076febe672b
Author: Tero Kristo <t-kristo@ti.com>
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.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
---
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(-)
diff --git a/arch/arm/plat-omap/include/plat/irqs.h b/arch/arm/plat-omap/include/plat/irqs.h
index 2efd645..37bbbbb 100644
--- a/arch/arm/plat-omap/include/plat/irqs.h
+++ b/arch/arm/plat-omap/include/plat/irqs.h
@@ -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))
--
1.7.0.4
^ permalink raw reply related [flat|nested] 10+ messages in thread* [PATCH] ARM: OMAP: irqs: Fix NR_IRQS value to handle PRCM interrupts @ 2012-02-28 13:10 ` Cousson, Benoit 0 siblings, 0 replies; 10+ messages in thread From: Cousson, Benoit @ 2012-02-28 13:10 UTC (permalink / raw) To: linux-arm-kernel The following commit: 2f31b51659c2d8315ea2888ba5b93076febe672b Author: Tero Kristo <t-kristo@ti.com> 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. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Tero Kristo <t-kristo@ti.com> --- 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(-) diff --git a/arch/arm/plat-omap/include/plat/irqs.h b/arch/arm/plat-omap/include/plat/irqs.h index 2efd645..37bbbbb 100644 --- a/arch/arm/plat-omap/include/plat/irqs.h +++ b/arch/arm/plat-omap/include/plat/irqs.h @@ -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)) -- 1.7.0.4 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH] ARM: OMAP: irqs: Fix NR_IRQS value to handle PRCM interrupts 2012-02-28 13:10 ` Cousson, Benoit @ 2012-02-28 14:36 ` Russell King - ARM Linux -1 siblings, 0 replies; 10+ messages in thread From: Russell King - ARM Linux @ 2012-02-28 14:36 UTC (permalink / raw) To: Cousson, Benoit Cc: tony Lindgren, linux-omap, linux-arm-kernel@lists.infradead.org, Nayak, Rajendra On Tue, Feb 28, 2012 at 02:10:09PM +0100, Cousson, Benoit wrote: > The following commit: 2f31b51659c2d8315ea2888ba5b93076febe672b > Author: Tero Kristo <t-kristo@ti.com> > 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 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH] ARM: OMAP: irqs: Fix NR_IRQS value to handle PRCM interrupts @ 2012-02-28 14:36 ` Russell King - ARM Linux 0 siblings, 0 replies; 10+ messages in thread From: Russell King - ARM Linux @ 2012-02-28 14:36 UTC (permalink / raw) To: linux-arm-kernel On Tue, Feb 28, 2012 at 02:10:09PM +0100, Cousson, Benoit wrote: > The following commit: 2f31b51659c2d8315ea2888ba5b93076febe672b > Author: Tero Kristo <t-kristo@ti.com> > 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 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] ARM: OMAP: irqs: Fix NR_IRQS value to handle PRCM interrupts 2012-02-28 14:36 ` Russell King - ARM Linux @ 2012-02-28 20:32 ` Cousson, Benoit -1 siblings, 0 replies; 10+ messages in thread From: Cousson, Benoit @ 2012-02-28 20:32 UTC (permalink / raw) To: Russell King - ARM Linux Cc: tony Lindgren, linux-omap, linux-arm-kernel@lists.infradead.org, Nayak, Rajendra Hi Russell, On 2/28/2012 3:36 PM, Russell King - ARM Linux wrote: > On Tue, Feb 28, 2012 at 02:10:09PM +0100, Cousson, Benoit wrote: >> The following commit: 2f31b51659c2d8315ea2888ba5b93076febe672b >> Author: Tero Kristo<t-kristo@ti.com> >> 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 > > 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. You're right, in that case, it does not depend on any hard-coded number. > 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. 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH] ARM: OMAP: irqs: Fix NR_IRQS value to handle PRCM interrupts @ 2012-02-28 20:32 ` Cousson, Benoit 0 siblings, 0 replies; 10+ messages in thread From: Cousson, Benoit @ 2012-02-28 20:32 UTC (permalink / raw) To: linux-arm-kernel Hi Russell, On 2/28/2012 3:36 PM, Russell King - ARM Linux wrote: > On Tue, Feb 28, 2012 at 02:10:09PM +0100, Cousson, Benoit wrote: >> The following commit: 2f31b51659c2d8315ea2888ba5b93076febe672b >> Author: Tero Kristo<t-kristo@ti.com> >> 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 > > 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. You're right, in that case, it does not depend on any hard-coded number. > 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. 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] ARM: OMAP: irqs: Fix NR_IRQS value to handle PRCM interrupts 2012-02-28 20:32 ` Cousson, Benoit @ 2012-02-28 20:43 ` Russell King - ARM Linux -1 siblings, 0 replies; 10+ messages in thread From: Russell King - ARM Linux @ 2012-02-28 20:43 UTC (permalink / raw) To: Cousson, Benoit Cc: tony Lindgren, linux-omap, linux-arm-kernel@lists.infradead.org, Nayak, Rajendra On Tue, Feb 28, 2012 at 09:32:28PM +0100, Cousson, Benoit wrote: > Hi Russell, > > On 2/28/2012 3:36 PM, Russell King - ARM Linux wrote: >> On Tue, Feb 28, 2012 at 02:10:09PM +0100, Cousson, Benoit wrote: >>> The following commit: 2f31b51659c2d8315ea2888ba5b93076febe672b >>> Author: Tero Kristo<t-kristo@ti.com> >>> 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 >> >> 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. > > You're right, in that case, it does not depend on any hard-coded number. > >> 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. > > 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. 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH] ARM: OMAP: irqs: Fix NR_IRQS value to handle PRCM interrupts @ 2012-02-28 20:43 ` Russell King - ARM Linux 0 siblings, 0 replies; 10+ messages in thread From: Russell King - ARM Linux @ 2012-02-28 20:43 UTC (permalink / raw) To: linux-arm-kernel On Tue, Feb 28, 2012 at 09:32:28PM +0100, Cousson, Benoit wrote: > Hi Russell, > > On 2/28/2012 3:36 PM, Russell King - ARM Linux wrote: >> On Tue, Feb 28, 2012 at 02:10:09PM +0100, Cousson, Benoit wrote: >>> The following commit: 2f31b51659c2d8315ea2888ba5b93076febe672b >>> Author: Tero Kristo<t-kristo@ti.com> >>> 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 >> >> 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. > > You're right, in that case, it does not depend on any hard-coded number. > >> 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. > > 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. 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] ARM: OMAP: irqs: Fix NR_IRQS value to handle PRCM interrupts 2012-02-28 13:10 ` Cousson, Benoit @ 2012-02-28 23:55 ` Tony Lindgren -1 siblings, 0 replies; 10+ messages in thread From: Tony Lindgren @ 2012-02-28 23:55 UTC (permalink / raw) To: Cousson, Benoit Cc: linux-omap, linux-arm-kernel@lists.infradead.org, Nayak, Rajendra * Cousson, Benoit <b-cousson@ti.com> [120228 04:38]: > The following commit: 2f31b51659c2d8315ea2888ba5b93076febe672b > Author: Tero Kristo <t-kristo@ti.com> > 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. > > Signed-off-by: Benoit Cousson <b-cousson@ti.com> > Cc: Tero Kristo <t-kristo@ti.com> > --- > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH] ARM: OMAP: irqs: Fix NR_IRQS value to handle PRCM interrupts @ 2012-02-28 23:55 ` Tony Lindgren 0 siblings, 0 replies; 10+ messages in thread From: Tony Lindgren @ 2012-02-28 23:55 UTC (permalink / raw) To: linux-arm-kernel * Cousson, Benoit <b-cousson@ti.com> [120228 04:38]: > The following commit: 2f31b51659c2d8315ea2888ba5b93076febe672b > Author: Tero Kristo <t-kristo@ti.com> > 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. > > Signed-off-by: Benoit Cousson <b-cousson@ti.com> > Cc: Tero Kristo <t-kristo@ti.com> > --- > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2012-02-28 23:55 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-02-28 13:10 [PATCH] ARM: OMAP: irqs: Fix NR_IRQS value to handle PRCM interrupts Cousson, Benoit 2012-02-28 13:10 ` Cousson, Benoit 2012-02-28 14:36 ` Russell King - ARM Linux 2012-02-28 14:36 ` Russell King - ARM Linux 2012-02-28 20:32 ` Cousson, Benoit 2012-02-28 20:32 ` Cousson, Benoit 2012-02-28 20:43 ` Russell King - ARM Linux 2012-02-28 20:43 ` Russell King - ARM Linux 2012-02-28 23:55 ` Tony Lindgren 2012-02-28 23:55 ` Tony Lindgren
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.