Re: OMAP3EVM not booting on l-o master
Hi Kevin, On Wed, 2 May 2012, Kevin Hilman wrote: From 22726db6fc514cc5110db43fdf05d5afda8e4a59 Mon Sep 17 00:00:00 2001 From: Kevin Hilman khil...@ti.com Date: Tue, 1 May 2012 07:06:42 -0700 Subject: [PATCH] ARM: OMAP3: PM: leave PRCM interrupts disabled until explicitly enabled. By default, request_irq() will auto-enable the requested IRQ. For PRCM interrupts, we may want to avoid that until the PM core code is fully ready to handle the interrupts. This is particularily true for IO pad interrupts on OMAP3, which are shared between the hwmod core and the PRM core. In order to avoid PRCM IO-chain interrupts until the PM core is ready to handle them, ready, set the IRQ_NOAUTOEN flag for the PRCM IO-chain interrupt, which means it will remain disabled after request_irq(). Then, explicitly enable the PRCM interrupts after the request_irq() in the PM core (but not in the hwmod core.) Special thanks to Tero Kristo for suggesting to isolate the fix to only the IO-chain interrupt on OMAP3 instead of all PRCM interrupts. Tested-by: Afzal Mohammed af...@ti.com Acked-by: Tero Kristo t-kri...@ti.com Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Kevin Hilman khil...@ti.com Acked-by: Paul Walmsley p...@pwsan.com If for some reason it doesn't get in for 3.5, let me know and I'll queue with the other IO chain patches for 3.6 as we discussed. - Paul -- 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: OMAP3EVM not booting on l-o master
Paul Walmsley p...@pwsan.com writes:
Hi Kevin,
Afzal, care to give this one a test as well? It should have the same
result but is a more targetted fix. With and ack from Tero and a
Tested-by from you, I'll post this to the list and and queue it up for
v3.5.
just checking on this one to discuss how we should handle the
io_chain_devel_3.5 branch on my git tree, which would depend on this
patch... this is a tricky series since it touches PM, PRM, and hwmod
code...
Right, you should probably take this patch along with the
io_chain_devel_3.5 branch. Below is a version that applies on top of
io_chain_devel_3.5 with an ack from Tero and Tested-by from Mohammed.
Kevin
From 22726db6fc514cc5110db43fdf05d5afda8e4a59 Mon Sep 17 00:00:00 2001
From: Kevin Hilman khil...@ti.com
Date: Tue, 1 May 2012 07:06:42 -0700
Subject: [PATCH] ARM: OMAP3: PM: leave PRCM interrupts disabled until
explicitly enabled.
By default, request_irq() will auto-enable the requested IRQ.
For PRCM interrupts, we may want to avoid that until the PM core code
is fully ready to handle the interrupts. This is particularily true
for IO pad interrupts on OMAP3, which are shared between the hwmod
core and the PRM core.
In order to avoid PRCM IO-chain interrupts until the PM core is ready
to handle them, ready, set the IRQ_NOAUTOEN flag for the PRCM IO-chain
interrupt, which means it will remain disabled after request_irq().
Then, explicitly enable the PRCM interrupts after the request_irq() in
the PM core (but not in the hwmod core.)
Special thanks to Tero Kristo for suggesting to isolate the fix to
only the IO-chain interrupt on OMAP3 instead of all PRCM interrupts.
Tested-by: Afzal Mohammed af...@ti.com
Acked-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |1 +
arch/arm/mach-omap2/prm2xxx_3xxx.c | 11 +--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 3e6b564..745a151 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -685,6 +685,7 @@ static int __init omap3_pm_init(void)
ret = request_irq(omap_prcm_event_to_irq(io),
_prcm_int_handle_io, IRQF_SHARED | IRQF_NO_SUSPEND, pm_io,
omap3_pm_init);
+ enable_irq(omap_prcm_event_to_irq(io));
if (ret) {
pr_err(pm: Failed to request pm_io irq\n);
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c
b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index 1471a33..a0309de 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -15,6 +15,7 @@
#include linux/errno.h
#include linux/err.h
#include linux/io.h
+#include linux/irq.h
#include common.h
#include plat/cpu.h
@@ -350,10 +351,16 @@ static void __init omap3xxx_prm_enable_io_wakeup(void)
static int __init omap3xxx_prcm_init(void)
{
+ int ret = 0;
+
if (cpu_is_omap34xx()) {
omap3xxx_prm_enable_io_wakeup();
- return omap_prcm_register_chain_handler(omap3_prcm_irq_setup);
+ ret = omap_prcm_register_chain_handler(omap3_prcm_irq_setup);
+ if (!ret)
+ irq_set_status_flags(omap_prcm_event_to_irq(io),
+IRQ_NOAUTOEN);
}
- return 0;
+
+ return ret;
}
subsys_initcall(omap3xxx_prcm_init);
--
1.7.9.2
--
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: OMAP3EVM not booting on l-o master
On Wed, 2012-05-02 at 07:48 +0200, Mohammed, Afzal wrote: Hi Kevin, On Tue, May 01, 2012 at 19:38:00, Hilman, Kevin wrote: Afzal, care to give this one a test as well? It should have the same result but is a more targetted fix. With and ack from Tero and a Tested-by from you, I'll post this to the list and and queue it up for v3.5. With an additional diff [1], your patch makes omap3evm boot Without [1], compiler error Regards Afzal [1] diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c b/arch/arm/mach-omap2/prm2xxx_3xxx.c index a8c6bd8..a0309de 100644 --- a/arch/arm/mach-omap2/prm2xxx_3xxx.c +++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c @@ -15,6 +15,7 @@ #include linux/errno.h #include linux/err.h #include linux/io.h +#include linux/irq.h #include common.h #include plat/cpu.h With this addition Kevin's patch looks good to me, so acked. -Tero -- 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: OMAP3EVM not booting on l-o master
Hi Kevin, Afzal, care to give this one a test as well? It should have the same result but is a more targetted fix. With and ack from Tero and a Tested-by from you, I'll post this to the list and and queue it up for v3.5. just checking on this one to discuss how we should handle the io_chain_devel_3.5 branch on my git tree, which would depend on this patch... this is a tricky series since it touches PM, PRM, and hwmod code... - Paul -- 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: OMAP3EVM not booting on l-o master
Hi Kevin, On Tue, May 01, 2012 at 02:10:28, Hilman, Kevin wrote: Afzal, care to give this one a test as well? It should have the same result but is a more targetted fix. With and ack from Tero and a Tested-by from you, I'll post this to the list and and queue it up for v3.5. Over what commit id, should this patch be applied ?, unable to apply it over 297624c ARM: OMAP3: PM: Remove IO Daisychain control from cpuidle, the one that I tested your previous patch. Regards Afzal From 274ded7fbe573bbbe45db80bdc1989272077c011 Mon Sep 17 00:00:00 2001 From: Kevin Hilman khil...@ti.com Date: Fri, 27 Apr 2012 16:05:51 -0700 Subject: [PATCH] ARM: OMAP3: PM: leave PRCM interrupts disabled until explicitly enabled. -- 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: OMAP3EVM not booting on l-o master
Mohammed, Afzal af...@ti.com writes:
Hi Kevin,
On Tue, May 01, 2012 at 02:10:28, Hilman, Kevin wrote:
Afzal, care to give this one a test as well? It should have the same
result but is a more targetted fix. With and ack from Tero and a
Tested-by from you, I'll post this to the list and and queue it up for
v3.5.
Over what commit id, should this patch be applied ?, unable to apply it over
297624c ARM: OMAP3: PM: Remove IO Daisychain control from cpuidle, the
one that I tested your previous patch.
Oops, my fault.
Below is a version that applies on top of the IO chain branch currently
in Paul's tree[1].
Kevin
[1] git://git.pwsan.com/linux-2.6 io_chain_devel_3.5
From d94f04eea40686cd9db8e9dbd8dbf3c02edca07f Mon Sep 17 00:00:00 2001
From: Kevin Hilman khil...@ti.com
Date: Tue, 1 May 2012 07:06:42 -0700
Subject: [PATCH] ARM: OMAP3: PM: leave PRCM interrupts disabled until
explicitly enabled.
By default, request_irq() will auto-enable the requested IRQ.
For PRCM interrupts, we may want to avoid that until the PM core code
is fully ready to handle the interrupts. This is particularily true
for IO pad interrupts on OMAP3, which are shared between the hwmod
core and the PRM core.
In order to avoid PRCM IO-chain interrupts until the PM core is ready
to handle them, ready, set the IRQ_NOAUTOEN flag for the PRCM IO-chain
interrupt, which means it will remain disabled after request_irq().
Then, explicitly enable the PRCM interrupts after the request_irq() in
the PM core (but not in the hwmod core.)
Special thanks to Tero Kristo for suggesting to isolate the fix to
only the IO-chain interrupt on OMAP3 instead of all PRCM interrupts.
Cc: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |1 +
arch/arm/mach-omap2/prm2xxx_3xxx.c | 10 --
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 3e6b564..745a151 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -685,6 +685,7 @@ static int __init omap3_pm_init(void)
ret = request_irq(omap_prcm_event_to_irq(io),
_prcm_int_handle_io, IRQF_SHARED | IRQF_NO_SUSPEND, pm_io,
omap3_pm_init);
+ enable_irq(omap_prcm_event_to_irq(io));
if (ret) {
pr_err(pm: Failed to request pm_io irq\n);
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c
b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index 1471a33..a8c6bd8 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -350,10 +350,16 @@ static void __init omap3xxx_prm_enable_io_wakeup(void)
static int __init omap3xxx_prcm_init(void)
{
+ int ret = 0;
+
if (cpu_is_omap34xx()) {
omap3xxx_prm_enable_io_wakeup();
- return omap_prcm_register_chain_handler(omap3_prcm_irq_setup);
+ ret = omap_prcm_register_chain_handler(omap3_prcm_irq_setup);
+ if (!ret)
+ irq_set_status_flags(omap_prcm_event_to_irq(io),
+IRQ_NOAUTOEN);
}
- return 0;
+
+ return ret;
}
subsys_initcall(omap3xxx_prcm_init);
--
1.7.9.2
--
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: OMAP3EVM not booting on l-o master
Hi Kevin, On Tue, May 01, 2012 at 19:38:00, Hilman, Kevin wrote: Afzal, care to give this one a test as well? It should have the same result but is a more targetted fix. With and ack from Tero and a Tested-by from you, I'll post this to the list and and queue it up for v3.5. With an additional diff [1], your patch makes omap3evm boot Without [1], compiler error Regards Afzal [1] diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c b/arch/arm/mach-omap2/prm2xxx_3xxx.c index a8c6bd8..a0309de 100644 --- a/arch/arm/mach-omap2/prm2xxx_3xxx.c +++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c @@ -15,6 +15,7 @@ #include linux/errno.h #include linux/err.h #include linux/io.h +#include linux/irq.h #include common.h #include plat/cpu.h -- 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: OMAP3EVM not booting on l-o master
On Fri, 2012-04-27 at 16:15 -0700, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
On Tue, 2012-04-24 at 10:07 -0700, Kevin Hilman wrote:
[...]
From 26733dd988ccc9e72355a39e01b2d6e9215a892d Mon Sep 17 00:00:00 2001
From: Tero Kristo t-kri...@ti.com
Date: Mon, 23 Apr 2012 12:14:46 +0300
Subject: [PATCH] ARM: OMAP3: PM: move wakeup event ack to hwmod_io
handler
PRCM IO interrupts are handled with a shared interrupt handler logic.
Currently hwmod_io is processing the actual event, but the acking
of the IO wakeups is done from the PM code with a separate handler.
If a wakeup event is detected during init before the PM code is in
place, the interrupt handler can hang in an infinite loop. Fix this
by removing the pm_io handler, and calling its functionality from
within the hwmod_io handler. This fix applies only to OMAP3, as
OMAP4 does not have similar wakeup handling logic.
Signed-off-by: Tero Kristo t-kri...@ti.com
Doesn't this mean that even on a !PM kernel that IO events might still
be firing for nothing?
I actually disabled the IO handler in !PM kernel, as I thought this
would be a problem there.
OK
Seems like it would be better to ensure that these interrupts are just
disabled until the PM core initializes and can enable them.
I thought about this but I couldn't figure out a clean way to do this.
If I do irq_request, it automatically enables the interrupt, and if
there is an interrupt pending it will fire immediately and get stuck.
hmm, I thought there was a flag for disabling the auto-enable feature...
/me looks
Yup, from linux/irq.h
* IRQ_NOAUTOEN - Interrupt is not automatically
enabled in
* request/setup_irq()
With that, we can just set all the PRCM IRQs to be disabled until
explicitly enabled using enable_irq(). The following patch (only boot
tested on OMAP3530/Overo and OMAP4430/Panda) should take care of it.
Do you think that should solve this problem?
Yea that works. However your patch implements the disable for all PRCM
interrupts, and this is only needed for the IO event on OMAP3. How about
something like this:
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -691,6 +691,8 @@ static int __init omap3_pm_init(void)
goto err2;
}
+ enable_irq(omap_prcm_event_to_irq(io));
+
ret = pwrdm_for_each(pwrdms_setup, NULL);
if (ret) {
pr_err(Failed to setup powerdomains\n);
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c
b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index b8962fe..2b12bb9 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -15,6 +15,7 @@
#include linux/errno.h
#include linux/err.h
#include linux/io.h
+#include linux/irq.h
#include common.h
#include plat/cpu.h
@@ -339,9 +340,13 @@ static void __init omap3_enable_io_wakeup(void)
static int __init omap3xxx_prcm_init(void)
{
+ int ret = 0;
+
if (cpu_is_omap34xx()) {
omap3_enable_io_wakeup();
- return
omap_prcm_register_chain_handler(omap3_prcm_irq_setup);
+ ret =
omap_prcm_register_chain_handler(omap3_prcm_irq_setup);
+ irq_set_status_flags(omap_prcm_event_to_irq(io),
+ IRQ_NOAUTOEN);
}
- return 0;
+ return ret;
}
--
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: OMAP3EVM not booting on l-o master
Tero Kristo t-kri...@ti.com writes:
On Fri, 2012-04-27 at 16:15 -0700, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
On Tue, 2012-04-24 at 10:07 -0700, Kevin Hilman wrote:
[...]
From 26733dd988ccc9e72355a39e01b2d6e9215a892d Mon Sep 17 00:00:00 2001
From: Tero Kristo t-kri...@ti.com
Date: Mon, 23 Apr 2012 12:14:46 +0300
Subject: [PATCH] ARM: OMAP3: PM: move wakeup event ack to hwmod_io
handler
PRCM IO interrupts are handled with a shared interrupt handler logic.
Currently hwmod_io is processing the actual event, but the acking
of the IO wakeups is done from the PM code with a separate handler.
If a wakeup event is detected during init before the PM code is in
place, the interrupt handler can hang in an infinite loop. Fix this
by removing the pm_io handler, and calling its functionality from
within the hwmod_io handler. This fix applies only to OMAP3, as
OMAP4 does not have similar wakeup handling logic.
Signed-off-by: Tero Kristo t-kri...@ti.com
Doesn't this mean that even on a !PM kernel that IO events might still
be firing for nothing?
I actually disabled the IO handler in !PM kernel, as I thought this
would be a problem there.
OK
Seems like it would be better to ensure that these interrupts are just
disabled until the PM core initializes and can enable them.
I thought about this but I couldn't figure out a clean way to do this.
If I do irq_request, it automatically enables the interrupt, and if
there is an interrupt pending it will fire immediately and get stuck.
hmm, I thought there was a flag for disabling the auto-enable feature...
/me looks
Yup, from linux/irq.h
* IRQ_NOAUTOEN - Interrupt is not automatically
enabled in
* request/setup_irq()
With that, we can just set all the PRCM IRQs to be disabled until
explicitly enabled using enable_irq(). The following patch (only boot
tested on OMAP3530/Overo and OMAP4430/Panda) should take care of it.
Do you think that should solve this problem?
Yea that works. However your patch implements the disable for all PRCM
interrupts, and this is only needed for the IO event on OMAP3.
How about something like this:
Your patch seems to have been mangled, but I think I get the idea, and
that looks right.
I've updated my patch to use (what I understood to be) your idea and
updated the changelog to reflect that it's a targetted fix for just the
IO interrupt on OMAP3.
Afzal, care to give this one a test as well? It should have the same
result but is a more targetted fix. With and ack from Tero and a
Tested-by from you, I'll post this to the list and and queue it up for
v3.5.
Thanks,
Kevin
From 274ded7fbe573bbbe45db80bdc1989272077c011 Mon Sep 17 00:00:00 2001
From: Kevin Hilman khil...@ti.com
Date: Fri, 27 Apr 2012 16:05:51 -0700
Subject: [PATCH] ARM: OMAP3: PM: leave PRCM interrupts disabled until
explicitly enabled.
By default, request_irq() will auto-enable the requested IRQ.
For PRCM interrupts, we may want to avoid that until the PM core code
is fully ready to handle the interrupts. This is particularily true
for IO pad interrupts on OMAP3, which are shared between the hwmod
core and the PRM core.
In order to avoid PRCM IO-chain interrupts until the PM core is ready
to handle them, ready, set the IRQ_NOAUTOEN flag for the PRCM IO-chain
interrupt, which means it will remain disabled after request_irq().
Then, explicitly enable the PRCM interrupts after the request_irq() in
the PM core (but not in the hwmod core.)
Special thanks to Tero Kristo for suggesting to isolate the fix to
only the IO-chain interrupt on OMAP3 instead of all PRCM interrupts.
Cc: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |1 +
arch/arm/mach-omap2/prm2xxx_3xxx.c | 14 +++---
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 66ff828..b40de27 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -732,6 +732,7 @@ static int __init omap3_pm_init(void)
ret = request_irq(omap_prcm_event_to_irq(io),
_prcm_int_handle_io, IRQF_SHARED | IRQF_NO_SUSPEND, pm_io,
omap3_pm_init);
+ enable_irq(omap_prcm_event_to_irq(io));
if (ret) {
pr_err(pm: Failed to request pm_io irq\n);
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c
b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index 9ce7654..21cb740 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -15,6 +15,7 @@
#include linux/errno.h
#include linux/err.h
#include linux/io.h
+#include linux/irq.h
#include common.h
#include plat/cpu.h
@@ -303,8 +304,15 @@ void omap3xxx_prm_restore_irqen(u32 *saved_mask)
static int __init
RE: OMAP3EVM not booting on l-o master
Hi Kevin, On Sat, Apr 28, 2012 at 04:45:21, Hilman, Kevin wrote: Afzal, care to test the patch below to see if it fixes your boot problem on OMAP3EVM with the IO chain series? Your patch fixes the boot problem Regards Afzal -- 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: OMAP3EVM not booting on l-o master
On Tue, 2012-04-24 at 10:07 -0700, Kevin Hilman wrote: Hi Tero, Tero Kristo t-kri...@ti.com writes: On Fri, 2012-04-06 at 07:52 +, Mohammed, Afzal wrote: Hi Paul, On Fri, Apr 06, 2012 at 12:43:06, Paul Walmsley wrote: Perhaps you might be willing to add some debugging to omap_mux_late_init() to find out what part of that function is causing it to hang? It is getting hung as interrupt handler omap_hwmod_mux_handle_irq is being repeatedly called. Hi Afzal, can you try the attached patch with this branch and omap3evm board? I don't have the board myself so I can't test it myself (I tested this with omap3beagle and it works with that one.) Thanks for digging into this problem and coming up with a proposed solution. Some questions below... -Tero From 26733dd988ccc9e72355a39e01b2d6e9215a892d Mon Sep 17 00:00:00 2001 From: Tero Kristo t-kri...@ti.com Date: Mon, 23 Apr 2012 12:14:46 +0300 Subject: [PATCH] ARM: OMAP3: PM: move wakeup event ack to hwmod_io handler PRCM IO interrupts are handled with a shared interrupt handler logic. Currently hwmod_io is processing the actual event, but the acking of the IO wakeups is done from the PM code with a separate handler. If a wakeup event is detected during init before the PM code is in place, the interrupt handler can hang in an infinite loop. Fix this by removing the pm_io handler, and calling its functionality from within the hwmod_io handler. This fix applies only to OMAP3, as OMAP4 does not have similar wakeup handling logic. Signed-off-by: Tero Kristo t-kri...@ti.com Doesn't this mean that even on a !PM kernel that IO events might still be firing for nothing? I actually disabled the IO handler in !PM kernel, as I thought this would be a problem there. Seems like it would be better to ensure that these interrupts are just disabled until the PM core initializes and can enable them. I thought about this but I couldn't figure out a clean way to do this. If I do irq_request, it automatically enables the interrupt, and if there is an interrupt pending it will fire immediately and get stuck. I can of course do some really nasty hackery for disabling all interrupts when requesting it and then manually disabling it before enabling interrupts again... but this does not look too nice imo. -Tero -- 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: OMAP3EVM not booting on l-o master
Tero Kristo t-kri...@ti.com writes:
On Tue, 2012-04-24 at 10:07 -0700, Kevin Hilman wrote:
[...]
From 26733dd988ccc9e72355a39e01b2d6e9215a892d Mon Sep 17 00:00:00 2001
From: Tero Kristo t-kri...@ti.com
Date: Mon, 23 Apr 2012 12:14:46 +0300
Subject: [PATCH] ARM: OMAP3: PM: move wakeup event ack to hwmod_io handler
PRCM IO interrupts are handled with a shared interrupt handler logic.
Currently hwmod_io is processing the actual event, but the acking
of the IO wakeups is done from the PM code with a separate handler.
If a wakeup event is detected during init before the PM code is in
place, the interrupt handler can hang in an infinite loop. Fix this
by removing the pm_io handler, and calling its functionality from
within the hwmod_io handler. This fix applies only to OMAP3, as
OMAP4 does not have similar wakeup handling logic.
Signed-off-by: Tero Kristo t-kri...@ti.com
Doesn't this mean that even on a !PM kernel that IO events might still
be firing for nothing?
I actually disabled the IO handler in !PM kernel, as I thought this
would be a problem there.
OK
Seems like it would be better to ensure that these interrupts are just
disabled until the PM core initializes and can enable them.
I thought about this but I couldn't figure out a clean way to do this.
If I do irq_request, it automatically enables the interrupt, and if
there is an interrupt pending it will fire immediately and get stuck.
hmm, I thought there was a flag for disabling the auto-enable feature...
/me looks
Yup, from linux/irq.h
* IRQ_NOAUTOEN - Interrupt is not automatically enabled in
*request/setup_irq()
With that, we can just set all the PRCM IRQs to be disabled until
explicitly enabled using enable_irq(). The following patch (only boot
tested on OMAP3530/Overo and OMAP4430/Panda) should take care of it.
Do you think that should solve this problem?
Afzal, care to test the patch below to see if it fixes your boot problem
on OMAP3EVM with the IO chain series?
Thanks,
Kevin
From: Kevin Hilman khil...@ti.com
Date: Fri, 27 Apr 2012 16:05:51 -0700
Subject: [PATCH] ARM: OMAP2+: PM: leave PRCM interrupts disabled until
explicitly enabled.
By default, request_irq() will auto-enable the requested IRQ.
For PRCM interrupts, we want to avoid that until the PM core code is
fully ready to handle the interrupts. This is particularily true for
IO pad interrupts, which are shared between the hwmod core and the PRM
core. This is also important for !PM kernels where we don't need
any PRCM interrupts firing at all.
In order to avoid PRCM interrupts until ready, set the IRQ_NOAUTOEN
flag for the PRCM chained handler which means PRCM interrupts will
remain disabled after request_irq().
Then, explicitly enable the PRCM interrupts after the request_irq() in
the PM core (but not in the hwmod core.)
Cc: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |2 ++
arch/arm/mach-omap2/prm_common.c |3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 66ff828..ba17813 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -722,6 +722,7 @@ static int __init omap3_pm_init(void)
ret = request_irq(omap_prcm_event_to_irq(wkup),
_prcm_int_handle_wakeup, IRQF_NO_SUSPEND, pm_wkup, NULL);
+ enable_irq(omap_prcm_event_to_irq(wkup));
if (ret) {
pr_err(pm: Failed to request pm_wkup irq\n);
@@ -732,6 +733,7 @@ static int __init omap3_pm_init(void)
ret = request_irq(omap_prcm_event_to_irq(io),
_prcm_int_handle_io, IRQF_SHARED | IRQF_NO_SUSPEND, pm_io,
omap3_pm_init);
+ enable_irq(omap_prcm_event_to_irq(io));
if (ret) {
pr_err(pm: Failed to request pm_io irq\n);
diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
index d28f848..c805775 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -307,7 +307,8 @@ int omap_prcm_register_chain_handler(struct
omap_prcm_irq_setup *irq_setup)
ct-regs.ack = irq_setup-ack + i * 4;
ct-regs.mask = irq_setup-mask + i * 4;
- irq_setup_generic_chip(gc, mask[i], 0, IRQ_NOREQUEST, 0);
+ irq_setup_generic_chip(gc, mask[i], 0, IRQ_NOREQUEST,
+ IRQ_NOAUTOEN);
prcm_irq_chips[i] = gc;
}
--
1.7.9.2
--
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: OMAP3EVM not booting on l-o master
Hi Tero, On Mon, Apr 23, 2012 at 17:29:48, Kristo, Tero wrote: Okay thats good (although I wonder why the attachment got corrupted.) Did you check if the device suspends / resumes properly also? Can you check what do you have in the /proc/interrupts for the hwmod_io interrupt just after boot / after one suspend? Device suspends resumes properly. At boot 2, after one suspend-resume 3 Regards Afzal
RE: OMAP3EVM not booting on l-o master
On Tue, 2012-04-24 at 14:00 +0200, Mohammed, Afzal wrote: Hi Tero, On Mon, Apr 23, 2012 at 17:29:48, Kristo, Tero wrote: Okay thats good (although I wonder why the attachment got corrupted.) Did you check if the device suspends / resumes properly also? Can you check what do you have in the /proc/interrupts for the hwmod_io interrupt just after boot / after one suspend? Device suspends resumes properly. At boot 2, after one suspend-resume 3 Okay that looks normal to me, you just get some prcm interrupts during boot which was causing the device to hang earlier. Thanks for testing out. Paul, how should we take this forward? -Tero -- 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: OMAP3EVM not booting on l-o master
Hi Tero, Tero Kristo t-kri...@ti.com writes: On Fri, 2012-04-06 at 07:52 +, Mohammed, Afzal wrote: Hi Paul, On Fri, Apr 06, 2012 at 12:43:06, Paul Walmsley wrote: Perhaps you might be willing to add some debugging to omap_mux_late_init() to find out what part of that function is causing it to hang? It is getting hung as interrupt handler omap_hwmod_mux_handle_irq is being repeatedly called. Hi Afzal, can you try the attached patch with this branch and omap3evm board? I don't have the board myself so I can't test it myself (I tested this with omap3beagle and it works with that one.) Thanks for digging into this problem and coming up with a proposed solution. Some questions below... -Tero From 26733dd988ccc9e72355a39e01b2d6e9215a892d Mon Sep 17 00:00:00 2001 From: Tero Kristo t-kri...@ti.com Date: Mon, 23 Apr 2012 12:14:46 +0300 Subject: [PATCH] ARM: OMAP3: PM: move wakeup event ack to hwmod_io handler PRCM IO interrupts are handled with a shared interrupt handler logic. Currently hwmod_io is processing the actual event, but the acking of the IO wakeups is done from the PM code with a separate handler. If a wakeup event is detected during init before the PM code is in place, the interrupt handler can hang in an infinite loop. Fix this by removing the pm_io handler, and calling its functionality from within the hwmod_io handler. This fix applies only to OMAP3, as OMAP4 does not have similar wakeup handling logic. Signed-off-by: Tero Kristo t-kri...@ti.com Doesn't this mean that even on a !PM kernel that IO events might still be firing for nothing? Seems like it would be better to ensure that these interrupts are just disabled until the PM core initializes and can enable them. Kevin -- 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: OMAP3EVM not booting on l-o master
On Fri, 2012-04-06 at 07:52 +, Mohammed, Afzal wrote:
Hi Paul,
On Fri, Apr 06, 2012 at 12:43:06, Paul Walmsley wrote:
Perhaps you might be willing to add some debugging to omap_mux_late_init()
to find out what part of that function is causing it to hang?
It is getting hung as interrupt handler omap_hwmod_mux_handle_irq
is being repeatedly called.
Hi Afzal,
can you try the attached patch with this branch and omap3evm board? I
don't have the board myself so I can't test it myself (I tested this
with omap3beagle and it works with that one.)
-Tero
From 26733dd988ccc9e72355a39e01b2d6e9215a892d Mon Sep 17 00:00:00 2001
From: Tero Kristo t-kri...@ti.com
Date: Mon, 23 Apr 2012 12:14:46 +0300
Subject: [PATCH] ARM: OMAP3: PM: move wakeup event ack to hwmod_io handler
PRCM IO interrupts are handled with a shared interrupt handler logic.
Currently hwmod_io is processing the actual event, but the acking
of the IO wakeups is done from the PM code with a separate handler.
If a wakeup event is detected during init before the PM code is in
place, the interrupt handler can hang in an infinite loop. Fix this
by removing the pm_io handler, and calling its functionality from
within the hwmod_io handler. This fix applies only to OMAP3, as
OMAP4 does not have similar wakeup handling logic.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/mux.c| 18 +-
arch/arm/mach-omap2/pm.h |1 +
arch/arm/mach-omap2/pm34xx.c | 18 ++
3 files changed, 20 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 65c3391..17349e3 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -41,6 +41,7 @@
#include control.h
#include mux.h
#include prm.h
+#include pm.h
#define OMAP_MUX_BASE_OFFSET 0x30 /* Offset from CTRL_BASE */
#define OMAP_MUX_BASE_SZ 0x5ca
@@ -427,6 +428,13 @@ static irqreturn_t omap_hwmod_mux_handle_irq(int irq, void *unused)
return IRQ_HANDLED;
}
+static irqreturn_t omap34xx_hwmod_mux_handle_irq(int irq, void *unused)
+{
+ omap_hwmod_for_each(_omap_hwmod_mux_handle_irq, NULL);
+ prcm_int_ack_io();
+ return IRQ_HANDLED;
+}
+
/* Assumes the calling function takes care of locking */
void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state)
{
@@ -792,6 +800,7 @@ static int __init omap_mux_late_init(void)
{
struct omap_mux_partition *partition;
int ret;
+ irq_handler_t irq_handler;
list_for_each_entry(partition, mux_partitions, node) {
struct omap_mux_entry *e, *tmp;
@@ -812,12 +821,19 @@ static int __init omap_mux_late_init(void)
}
}
+#ifdef CONFIG_PM
+ if (cpu_is_omap34xx())
+ irq_handler = omap34xx_hwmod_mux_handle_irq;
+ else
+ irq_handler = omap_hwmod_mux_handle_irq;
+
ret = request_irq(omap_prcm_event_to_irq(io),
- omap_hwmod_mux_handle_irq, IRQF_SHARED | IRQF_NO_SUSPEND,
+ irq_handler, IRQF_SHARED | IRQF_NO_SUSPEND,
hwmod_io, omap_mux_late_init);
if (ret)
pr_warning(mux: Failed to setup hwmod io irq %d\n, ret);
+#endif
omap_mux_dbg_init();
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 36fa90b..09ba9e7 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -20,6 +20,7 @@ extern void omap3_pm_off_mode_enable(int);
extern void omap_sram_idle(void);
extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
extern int omap3_idle_init(void);
+extern void prcm_int_ack_io(void);
extern int omap4_idle_init(void);
extern int omap_pm_clkdms_setup(struct clockdomain *clkdm, void *unused);
extern int (*omap_pm_suspend)(void);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index afe3dda..cea4408 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -182,14 +182,10 @@ static int prcm_clear_mod_irqs(s16 module, u8 regs, u32 ignore_bits)
return c;
}
-static irqreturn_t _prcm_int_handle_io(int irq, void *unused)
+void prcm_int_ack_io(void)
{
- int c;
-
- c = prcm_clear_mod_irqs(WKUP_MOD, 1,
+ prcm_clear_mod_irqs(WKUP_MOD, 1,
~(OMAP3430_ST_IO_MASK | OMAP3430_ST_IO_CHAIN_MASK));
-
- return c ? IRQ_HANDLED : IRQ_NONE;
}
static irqreturn_t _prcm_int_handle_wakeup(int irq, void *unused)
@@ -683,16 +679,6 @@ static int __init omap3_pm_init(void)
goto err1;
}
- /* IO interrupt is shared with mux code */
- ret = request_irq(omap_prcm_event_to_irq(io),
- _prcm_int_handle_io, IRQF_SHARED | IRQF_NO_SUSPEND, pm_io,
- omap3_pm_init);
-
- if (ret) {
- pr_err(pm: Failed to request pm_io irq\n);
- goto err1;
- }
-
ret = pwrdm_for_each(pwrdms_setup, NULL);
if (ret) {
printk(KERN_ERR Failed to setup powerdomains\n);
--
1.7.4.1
RE: OMAP3EVM not booting on l-o master
Hi Tero, With this branch you meant, HEAD @ 297624c ARM: OMAP3: PM: Remove IO Daisychain control from cpuidle, right ? (the one Paul suggested to try) Regards Afzal On Mon, Apr 23, 2012 at 14:54:04, Kristo, Tero wrote: On Fri, 2012-04-06 at 07:52 +, Mohammed, Afzal wrote: Hi Paul, On Fri, Apr 06, 2012 at 12:43:06, Paul Walmsley wrote: Perhaps you might be willing to add some debugging to omap_mux_late_init() to find out what part of that function is causing it to hang? It is getting hung as interrupt handler omap_hwmod_mux_handle_irq is being repeatedly called. Hi Afzal, can you try the attached patch with this branch and omap3evm board? I don't have the board myself so I can't test it myself (I tested this with omap3beagle and it works with that one.) -Tero
RE: OMAP3EVM not booting on l-o master
On Mon, 2012-04-23 at 12:07 +0200, Mohammed, Afzal wrote: Hi Tero, With this branch you meant, HEAD @ 297624c ARM: OMAP3: PM: Remove IO Daisychain control from cpuidle, right ? (the one Paul suggested to try) Yeah, thats right. My patch applies right on top of it. -Tero Regards Afzal On Mon, Apr 23, 2012 at 14:54:04, Kristo, Tero wrote: On Fri, 2012-04-06 at 07:52 +, Mohammed, Afzal wrote: Hi Paul, On Fri, Apr 06, 2012 at 12:43:06, Paul Walmsley wrote: Perhaps you might be willing to add some debugging to omap_mux_late_init() to find out what part of that function is causing it to hang? It is getting hung as interrupt handler omap_hwmod_mux_handle_irq is being repeatedly called. Hi Afzal, can you try the attached patch with this branch and omap3evm board? I don't have the board myself so I can't test it myself (I tested this with omap3beagle and it works with that one.) -Tero -- 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: OMAP3EVM not booting on l-o master
Hi Tero,
On Mon, Apr 23, 2012 at 15:43:22, Kristo, Tero wrote:
can you try the attached patch with this branch and omap3evm board? I
don't have the board myself so I can't test it myself (I tested this
with omap3beagle and it works with that one.)
With your patch, OMAP3EVM boots normally.
Tested by creating same changes as in your patch as below (patch could not
be applied, seems it was corrupted)
Regards
Afzal
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 65c3391..17349e3 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -41,6 +41,7 @@
#include control.h
#include mux.h
#include prm.h
+#include pm.h
#define OMAP_MUX_BASE_OFFSET 0x30/* Offset from CTRL_BASE */
#define OMAP_MUX_BASE_SZ 0x5ca
@@ -427,6 +428,13 @@ static irqreturn_t omap_hwmod_mux_handle_irq(int irq, void
*unused)
return IRQ_HANDLED;
}
+static irqreturn_t omap34xx_hwmod_mux_handle_irq(int irq, void *unused)
+{
+ omap_hwmod_for_each(_omap_hwmod_mux_handle_irq, NULL);
+ prcm_int_ack_io();
+ return IRQ_HANDLED;
+}
+
/* Assumes the calling function takes care of locking */
void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state)
{
@@ -792,6 +800,7 @@ static int __init omap_mux_late_init(void)
{
struct omap_mux_partition *partition;
int ret;
+ irq_handler_t irq_handler;
list_for_each_entry(partition, mux_partitions, node) {
struct omap_mux_entry *e, *tmp;
@@ -812,12 +821,19 @@ static int __init omap_mux_late_init(void)
}
}
+#ifdef CONFIG_PM
+ if (cpu_is_omap34xx())
+ irq_handler = omap34xx_hwmod_mux_handle_irq;
+ else
+ irq_handler = omap_hwmod_mux_handle_irq;
+
ret = request_irq(omap_prcm_event_to_irq(io),
- omap_hwmod_mux_handle_irq, IRQF_SHARED | IRQF_NO_SUSPEND,
+ irq_handler, IRQF_SHARED | IRQF_NO_SUSPEND,
hwmod_io, omap_mux_late_init);
if (ret)
pr_warning(mux: Failed to setup hwmod io irq %d\n, ret);
+#endif
omap_mux_dbg_init();
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 36fa90b..09ba9e7 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -20,6 +20,7 @@ extern void omap3_pm_off_mode_enable(int);
extern void omap_sram_idle(void);
extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
extern int omap3_idle_init(void);
+extern void prcm_int_ack_io(void);
extern int omap4_idle_init(void);
extern int omap_pm_clkdms_setup(struct clockdomain *clkdm, void *unused);
extern int (*omap_pm_suspend)(void);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index afe3dda..cea4408 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -182,14 +182,10 @@ static int prcm_clear_mod_irqs(s16 module, u8 regs, u32
ignore_bits)
return c;
}
-static irqreturn_t _prcm_int_handle_io(int irq, void *unused)
+void prcm_int_ack_io(void)
{
- int c;
-
- c = prcm_clear_mod_irqs(WKUP_MOD, 1,
+ prcm_clear_mod_irqs(WKUP_MOD, 1,
~(OMAP3430_ST_IO_MASK | OMAP3430_ST_IO_CHAIN_MASK));
-
- return c ? IRQ_HANDLED : IRQ_NONE;
}
static irqreturn_t _prcm_int_handle_wakeup(int irq, void *unused)
@@ -683,16 +679,6 @@ static int __init omap3_pm_init(void)
goto err1;
}
- /* IO interrupt is shared with mux code */
- ret = request_irq(omap_prcm_event_to_irq(io),
- _prcm_int_handle_io, IRQF_SHARED | IRQF_NO_SUSPEND, pm_io,
- omap3_pm_init);
-
- if (ret) {
- pr_err(pm: Failed to request pm_io irq\n);
- goto err1;
- }
-
ret = pwrdm_for_each(pwrdms_setup, NULL);
if (ret) {
printk(KERN_ERR Failed to setup powerdomains\n);
RE: OMAP3EVM not booting on l-o master
On Mon, 2012-04-23 at 12:43 +0200, Mohammed, Afzal wrote:
Hi Tero,
On Mon, Apr 23, 2012 at 15:43:22, Kristo, Tero wrote:
can you try the attached patch with this branch and omap3evm board? I
don't have the board myself so I can't test it myself (I tested this
with omap3beagle and it works with that one.)
With your patch, OMAP3EVM boots normally.
Tested by creating same changes as in your patch as below (patch could not
be applied, seems it was corrupted)
Okay thats good (although I wonder why the attachment got corrupted.)
Did you check if the device suspends / resumes properly also? Can you
check what do you have in the /proc/interrupts for the hwmod_io
interrupt just after boot / after one suspend?
-Tero
Regards
Afzal
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 65c3391..17349e3 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -41,6 +41,7 @@
#include control.h
#include mux.h
#include prm.h
+#include pm.h
#define OMAP_MUX_BASE_OFFSET 0x30/* Offset from CTRL_BASE */
#define OMAP_MUX_BASE_SZ 0x5ca
@@ -427,6 +428,13 @@ static irqreturn_t omap_hwmod_mux_handle_irq(int irq,
void *unused)
return IRQ_HANDLED;
}
+static irqreturn_t omap34xx_hwmod_mux_handle_irq(int irq, void *unused)
+{
+ omap_hwmod_for_each(_omap_hwmod_mux_handle_irq, NULL);
+ prcm_int_ack_io();
+ return IRQ_HANDLED;
+}
+
/* Assumes the calling function takes care of locking */
void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state)
{
@@ -792,6 +800,7 @@ static int __init omap_mux_late_init(void)
{
struct omap_mux_partition *partition;
int ret;
+ irq_handler_t irq_handler;
list_for_each_entry(partition, mux_partitions, node) {
struct omap_mux_entry *e, *tmp;
@@ -812,12 +821,19 @@ static int __init omap_mux_late_init(void)
}
}
+#ifdef CONFIG_PM
+ if (cpu_is_omap34xx())
+ irq_handler = omap34xx_hwmod_mux_handle_irq;
+ else
+ irq_handler = omap_hwmod_mux_handle_irq;
+
ret = request_irq(omap_prcm_event_to_irq(io),
- omap_hwmod_mux_handle_irq, IRQF_SHARED | IRQF_NO_SUSPEND,
+ irq_handler, IRQF_SHARED | IRQF_NO_SUSPEND,
hwmod_io, omap_mux_late_init);
if (ret)
pr_warning(mux: Failed to setup hwmod io irq %d\n, ret);
+#endif
omap_mux_dbg_init();
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 36fa90b..09ba9e7 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -20,6 +20,7 @@ extern void omap3_pm_off_mode_enable(int);
extern void omap_sram_idle(void);
extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
extern int omap3_idle_init(void);
+extern void prcm_int_ack_io(void);
extern int omap4_idle_init(void);
extern int omap_pm_clkdms_setup(struct clockdomain *clkdm, void *unused);
extern int (*omap_pm_suspend)(void);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index afe3dda..cea4408 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -182,14 +182,10 @@ static int prcm_clear_mod_irqs(s16 module, u8 regs, u32
ignore_bits)
return c;
}
-static irqreturn_t _prcm_int_handle_io(int irq, void *unused)
+void prcm_int_ack_io(void)
{
- int c;
-
- c = prcm_clear_mod_irqs(WKUP_MOD, 1,
+ prcm_clear_mod_irqs(WKUP_MOD, 1,
~(OMAP3430_ST_IO_MASK | OMAP3430_ST_IO_CHAIN_MASK));
-
- return c ? IRQ_HANDLED : IRQ_NONE;
}
static irqreturn_t _prcm_int_handle_wakeup(int irq, void *unused)
@@ -683,16 +679,6 @@ static int __init omap3_pm_init(void)
goto err1;
}
- /* IO interrupt is shared with mux code */
- ret = request_irq(omap_prcm_event_to_irq(io),
- _prcm_int_handle_io, IRQF_SHARED | IRQF_NO_SUSPEND, pm_io,
- omap3_pm_init);
-
- if (ret) {
- pr_err(pm: Failed to request pm_io irq\n);
- goto err1;
- }
-
ret = pwrdm_for_each(pwrdms_setup, NULL);
if (ret) {
printk(KERN_ERR Failed to setup powerdomains\n);
--
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: OMAP3EVM not booting on l-o master
On Fri, 6 Apr 2012, Mohammed, Afzal wrote: On Fri, Apr 06, 2012 at 01:22:20, Paul Walmsley wrote: http://git.kernel.org/?p=linux/kernel/git/pjw/omap-devel.git;a=summary If you open it in your web browser, it shows http and https URLs for the tree that you should be able to pull from. You'll want the io_chain_devel_3.5 branch. OMAP3EVM does not boot with this branch, hung at the same point. Okay, thanks for the test. Based on your other message, it indeed sounds like a mux problem. Perhaps you might be willing to add some debugging to omap_mux_late_init() to find out what part of that function is causing it to hang? - Paul -- 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: OMAP3EVM not booting on l-o master
Hi Paul, On Fri, Apr 06, 2012 at 12:43:06, Paul Walmsley wrote: Perhaps you might be willing to add some debugging to omap_mux_late_init() to find out what part of that function is causing it to hang? It is getting hung as interrupt handler omap_hwmod_mux_handle_irq is being repeatedly called. Regards Afzal -- 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: OMAP3EVM not booting on l-o master
* Mohammed, Afzal af...@ti.com [120405 21:57]: Hi Tony, On Thu, Apr 05, 2012 at 22:46:53, Tony Lindgren wrote: What happens if you disable CONFIG_OMAP_MUX? Then it boots properly. OK, so that's because then the mux interrupts won't get enabled like you noticed elsewhere in the thread. So something in Paul's series is changing the interrupt behaviour somehow? Tony -- 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: OMAP3EVM not booting on l-o master
cc Kevin On Fri, 6 Apr 2012, Tony Lindgren wrote: So something in Paul's series is changing the interrupt behaviour somehow? Am wondering if this might be due to the kernel not clearing some bootloader mux settings? Perhaps the bootloader is configuring the mux hardware for I/O wakeups on a pad, but the kernel is missing an mux IRQ handler or mapping for it. Or maybe one of the kernel mux entries is missing the OMAP_WAKEUP_EN or OMAP_DEVICE_PAD_WAKEUP flags for a pad that the bootloader is configuring - I seem to recall that Kevin found some problems here with the mach-omap2/serial.c mux code. Anyway, will create a patch to add some debugging here for Afzal to try. Also,it seems to me that when the mux layer starts, the code should probably clear out all of the I/O wakeup configuration in the hardware that the bootloader set up. - Paul -- 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: OMAP3EVM not booting on l-o master
* Paul Walmsley p...@pwsan.com [120406 11:11]: cc Kevin On Fri, 6 Apr 2012, Tony Lindgren wrote: So something in Paul's series is changing the interrupt behaviour somehow? Am wondering if this might be due to the kernel not clearing some bootloader mux settings? Perhaps the bootloader is configuring the mux hardware for I/O wakeups on a pad, but the kernel is missing an mux IRQ handler or mapping for it. Or maybe one of the kernel mux entries is missing the OMAP_WAKEUP_EN or OMAP_DEVICE_PAD_WAKEUP flags for a pad that the bootloader is configuring - I seem to recall that Kevin found some problems here with the mach-omap2/serial.c mux code. Anyway, will create a patch to add some debugging here for Afzal to try. That's easy to check from dumping out the mux status from /sys/kernel/debug/omap_mux/* entries after booting with a working kernel. Also,it seems to me that when the mux layer starts, the code should probably clear out all of the I/O wakeup configuration in the hardware that the bootloader set up. Yes that sounds right. Regards, Tony -- 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: OMAP3EVM not booting on l-o master
On Thu, 5 Apr 2012, Paul Walmsley wrote: I just rebased this series on top of v3.4-rc1 and built each patch in it successfully, so it sounds like there's some bisection-specific build problem? Okay, a quick update. Just tried with a different .config, and can reproduce the following build problem with patch 2 of the IO wakeup series, in code that is later removed by patch 6: arch/arm/mach-omap2/pm34xx.c: In function 'omap_sram_idle': arch/arm/mach-omap2/pm34xx.c:281:4: error: implicit declaration of function 'omap3_reconfigure_io_chain' That's my mistake and I will correct it here and send a new pull request, once we figure out what's going on with your boot hang. As far as the crashes go, I don't think I have an OMAP3EVM, but I'll take a look here on the OMAP35xx boards that I do have. I just booted the 'io_chain_devel_3.5' branch from git://git.pwsan.com/linux-2.6 on a 35xx ES3.0 BeagleBoard with no problems. Could you please try booting this branch on your OMAP3EVM? - Paul Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0 [0.00] Linux version 3.4.0-rc1-6-g297624c (paul@dusk) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #404 SMP T2 [0.00] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [0.00] Machine: OMAP3 Beagle Board [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] OMAP3430/3530 ES3.0 (l2cache iva sgx neon isp ) [0.00] Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz [0.00] PERCPU: Embedded 8 pages/cpu @c0e53000 s11456 r8192 d13120 u32768 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 [0.00] Kernel command line: console=ttyO2,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 mem=256M rootwait earlyprintk [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes) [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Memory: 255MB = 255MB total [0.00] Memory: 246220k/246220k available, 15924k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xd080 - 0xff00 ( 744 MB) [0.00] lowmem : 0xc000 - 0xd000 ( 256 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .text : 0xc0008000 - 0xc0619ee8 (6216 kB) [0.00] .init : 0xc061a000 - 0xc0667cc0 ( 312 kB) [0.00] .data : 0xc0668000 - 0xc06f9c98 ( 584 kB) [0.00].bss : 0xc06f9cbc - 0xc0c4df60 (5457 kB) [0.00] Hierarchical RCU implementation. [0.00] NR_IRQS:474 [0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts [0.00] Total of 96 interrupts on 1 active controller [0.00] OMAP clockevent source: GPTIMER12 at 32768 Hz [0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [0.00] Console: colour dummy device 80x30 [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.00] ... MAX_LOCK_DEPTH: 48 [0.00] ... MAX_LOCKDEP_KEYS:8191 [0.00] ... CLASSHASH_SIZE: 4096 [0.00] ... MAX_LOCKDEP_ENTRIES: 16384 [0.00] ... MAX_LOCKDEP_CHAINS: 32768 [0.00] ... CHAINHASH_SIZE: 16384 [0.00] memory used by lock dependency info: 3695 kB [0.00] per task-struct memory footprint: 1152 bytes [0.001129] Calibrating delay loop... 471.61 BogoMIPS (lpj=1843200) [0.081909] pid_max: default: 32768 minimum: 301 [0.082916] Security Framework initialized [0.083282] Mount-cache hash table entries: 512 [0.089874] CPU: Testing write buffer coherency: ok [0.091033] CPU0: thread -1, cpu 0, socket -1, mpidr 0 [0.091186] Setting up static identity map for 0x80472300 - 0x80472370 [0.093597] Brought up 1 CPUs [0.093627] SMP: Total of 1 processors activated (471.61 BogoMIPS). [0.110290] omap_hwmod: usbtll_fck: missing clockdomain for usbtll_fck. [0.120819] dummy: [0.123565] NET: Registered protocol family 16 [0.125244] GPMC revision 5.0 [0.139343] gpiochip_add: registered GPIOs 0 to 31 on device: gpio [0.140014] OMAP GPIO hardware version 2.5 [0.141448] gpiochip_add: registered GPIOs 32 to 63 on device: gpio [0.143920] gpiochip_add: registered GPIOs 64 to 95 on device: gpio [0.145812] gpiochip_add: registered GPIOs 96 to 127 on device: gpio [0.147735] gpiochip_add: registered GPIOs 128 to 159 on device: gpio [
RE: OMAP3EVM not booting on l-o master
Hi Paul, On Thu, Apr 05, 2012 at 15:03:36, Paul Walmsley wrote: Could you try booting with initcall_debug and posting the boot log? Logs as follows, Regards Afzal Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0 [0.00] Linux version 3.4.0-rc1-11705-g33fc21e (af...@linux-psp-server.india.ext.ti.com) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #5 SMP Thu Apr 5 15:19:27 IST 2012 [0.00] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [0.00] Machine: OMAP3 EVM [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] On node 0 totalpages: 32512 [0.00] free_area_init_node: node 0, pgdat c06b3cc0, node_mem_map c0c0a000 [0.00] Normal zone: 256 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 32256 pages, LIFO batch:7 [0.00] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp ) [0.00] Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz [0.00] PERCPU: Embedded 8 pages/cpu @c0d0e000 s11456 r8192 d13120 u32768 [0.00] pcpu-alloc: s11456 r8192 d13120 u32768 alloc=8*4096 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32256 [0.00] Kernel command line: console=ttyO0,115200n8 root/dev/ram rw earlyprintk mem=128M initrd=0x81338000,0x1f6c2f initcall_debug debug [0.00] PID hash table entries: 512 (order: -1, 2048 bytes) [0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) [0.00] Memory: 127MB = 127MB total [0.00] Memory: 114536k/114536k available, 16536k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xc880 - 0xff00 ( 872 MB) [0.00] lowmem : 0xc000 - 0xc800 ( 128 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .text : 0xc0008000 - 0xc05d2e34 (5932 kB) [0.00] .init : 0xc05d3000 - 0xc0621cc0 ( 316 kB) [0.00] .data : 0xc0622000 - 0xc06b5958 ( 591 kB) [0.00].bss : 0xc06b597c - 0xc0c09be0 (5457 kB) [0.00] Hierarchical RCU implementation. [0.00] NR_IRQS:474 [0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts [0.00] Total of 96 interrupts on 1 active controller [0.00] OMAP clockevent source: GPTIMER1 at 32768 Hz [0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [0.00] Console: colour dummy device 80x30 [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.00] ... MAX_LOCK_DEPTH: 48 [0.00] ... MAX_LOCKDEP_KEYS:8191 [0.00] ... CLASSHASH_SIZE: 4096 [0.00] ... MAX_LOCKDEP_ENTRIES: 16384 [0.00] ... MAX_LOCKDEP_CHAINS: 32768 [0.00] ... CHAINHASH_SIZE: 16384 [0.00] memory used by lock dependency info: 3695 kB [0.00] per task-struct memory footprint: 1152 bytes [0.001129] Calibrating delay loop... 497.82 BogoMIPS (lpj=1941504) [0.085906] pid_max: default: 32768 minimum: 301 [0.086883] Security Framework initialized [0.087219] Mount-cache hash table entries: 512 [0.093780] CPU: Testing write buffer coherency: ok [0.094970] CPU0: thread -1, cpu 0, socket -1, mpidr 0 [0.095001] calling init_static_idmap+0x0/0xe0 @ 1 [0.095123] Setting up static identity map for 0x804278b8 - 0x80427928 [0.095153] initcall init_static_idmap+0x0/0xe0 returned 0 after 0 usecs [0.095184] calling omap4_sar_ram_init+0x0/0x60 @ 1 [0.095214] initcall omap4_sar_ram_init+0x0/0x60 returned -12 after 0 usecs [0.095245] initcall omap4_sar_ram_init+0x0/0x60 returned with error code -12 [0.095275] calling omap_l2_cache_init+0x0/0xec @ 1 [0.095306] initcall omap_l2_cache_init+0x0/0xec returned -19 after 0 usecs [0.095336] calling spawn_ksoftirqd+0x0/0x54 @ 1 [0.095825] initcall spawn_ksoftirqd+0x0/0x54 returned 0 after 0 usecs [0.095855] calling init_workqueues+0x0/0x3c8 @ 1 [0.097015] initcall init_workqueues+0x0/0x3c8 returned 0 after 0 usecs [0.097045] calling migration_init+0x0/0x78 @ 1 [0.097106] initcall migration_init+0x0/0x78 returned 0 after 0 usecs [0.097137] calling cpu_stop_init+0x0/0xd8 @ 1 [0.097473] initcall cpu_stop_init+0x0/0xd8 returned 0 after 0 usecs [0.097503] calling rcu_scheduler_really_started+0x0/0x18 @ 1 [0.097534] initcall
RE: OMAP3EVM not booting on l-o master
cc Tony Hi, On Thu, 5 Apr 2012, Mohammed, Afzal wrote: On Thu, Apr 05, 2012 at 15:03:36, Paul Walmsley wrote: Could you try booting with initcall_debug and posting the boot log? Logs as follows, thanks. ... [6.065307] calling omap_mux_late_init+0x0/0x1a0 @ 1 Looks like a mux-related problem. Tony recently found some mux-related bugs that got merged with the v3.3 mach-omap2/serial.c - I wonder if they might be affecting your board too? - Paul -- 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: OMAP3EVM not booting on l-o master
Hi Afzal, On Thu, Apr 5, 2012 at 3:47 PM, Paul Walmsley p...@pwsan.com wrote: cc Tony Hi, On Thu, 5 Apr 2012, Mohammed, Afzal wrote: On Thu, Apr 05, 2012 at 15:03:36, Paul Walmsley wrote: Could you try booting with initcall_debug and posting the boot log? Logs as follows, thanks. ... [ 6.065307] calling omap_mux_late_init+0x0/0x1a0 @ 1 Looks like a mux-related problem. Tony recently found some mux-related bugs that got merged with the v3.3 mach-omap2/serial.c - I wonder if they might be affecting your board too? Can you try this patch [1], Just to confirm its serial mux issue however still the patch is not aligned on how to fix it. -- Thanks, Govindraj.R [1]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg65347.html -- 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: OMAP3EVM not booting on l-o master
Hi Govindraj, On Thu, Apr 05, 2012 at 15:53:25, R, Govindraj wrote: Can you try this patch [1], Just to confirm its serial mux issue however still the patch is not aligned on how to fix it. With that patch too, Kernel does not boot. Regards Afzal -- 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: OMAP3EVM not booting on l-o master
Hi Paul, On Thu, Apr 05, 2012 at 15:37:42, Paul Walmsley wrote: I just booted the 'io_chain_devel_3.5' branch from git://git.pwsan.com/linux-2.6 on a 35xx ES3.0 BeagleBoard with no problems. Could you please try booting this branch on your OMAP3EVM? I am unable to fetch using git protocol, hence tried, http://git.pwsan.com/linux-2.6 http://git.pwsan.com/linux-2.6.git but giving error, fatal: http://git.pwsan.com/linux-2.6/info/refs not found: did you run git update-server-info on the server? Any other to try ? Regards Afzal -- 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: OMAP3EVM not booting on l-o master
* Mohammed, Afzal af...@ti.com [120405 09:22]: Hi Govindraj, On Thu, Apr 05, 2012 at 15:53:25, R, Govindraj wrote: Can you try this patch [1], Just to confirm its serial mux issue however still the patch is not aligned on how to fix it. With that patch too, Kernel does not boot. What happens if you disable CONFIG_OMAP_MUX? Regards, Tony -- 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: OMAP3EVM not booting on l-o master
On Thu, 5 Apr 2012, Mohammed, Afzal wrote: On Thu, Apr 05, 2012 at 15:37:42, Paul Walmsley wrote: I just booted the 'io_chain_devel_3.5' branch from git://git.pwsan.com/linux-2.6 on a 35xx ES3.0 BeagleBoard with no problems. Could you please try booting this branch on your OMAP3EVM? I am unable to fetch using git protocol, hence tried, http://git.pwsan.com/linux-2.6 http://git.pwsan.com/linux-2.6.git but giving error, fatal: http://git.pwsan.com/linux-2.6/info/refs not found: did you run git update-server-info on the server? The git trees on that server aren't exported by the HTTP server, so git protocol is the only access method on git.pwsan.com right now. Anyway, I've just posted that branch on git.kernel.org. Here's the gitweb URL: http://git.kernel.org/?p=linux/kernel/git/pjw/omap-devel.git;a=summary If you open it in your web browser, it shows http and https URLs for the tree that you should be able to pull from. You'll want the io_chain_devel_3.5 branch. - Paul -- 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: OMAP3EVM not booting on l-o master
Paul Walmsley p...@pwsan.com writes: On Thu, 5 Apr 2012, Paul Walmsley wrote: I just rebased this series on top of v3.4-rc1 and built each patch in it successfully, so it sounds like there's some bisection-specific build problem? Okay, a quick update. Just tried with a different .config, and can reproduce the following build problem with patch 2 of the IO wakeup series, in code that is later removed by patch 6: arch/arm/mach-omap2/pm34xx.c: In function 'omap_sram_idle': arch/arm/mach-omap2/pm34xx.c:281:4: error: implicit declaration of function 'omap3_reconfigure_io_chain' That's my mistake and I will correct it here and send a new pull request, once we figure out what's going on with your boot hang. I notcied this problem too when building an OMAP4-only .config and just sent a patch: [PATCH] ARM: OMAP2+: PRM: fix compile for OMAP4-only build Kevin -- 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: OMAP3EVM not booting on l-o master
Hi Tony, On Thu, Apr 05, 2012 at 22:46:53, Tony Lindgren wrote: What happens if you disable CONFIG_OMAP_MUX? Then it boots properly. Regards Afzal -- 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: OMAP3EVM not booting on l-o master
Hi Paul, On Fri, Apr 06, 2012 at 01:22:20, Paul Walmsley wrote: http://git.kernel.org/?p=linux/kernel/git/pjw/omap-devel.git;a=summary If you open it in your web browser, it shows http and https URLs for the tree that you should be able to pull from. You'll want the io_chain_devel_3.5 branch. OMAP3EVM does not boot with this branch, hung at the same point. Regards Afzal -- 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: OMAP3EVM not booting on l-o master
Hi, On Wed, Apr 04, 2012 at 11:06:39, Mohammed, Afzal wrote: OMAP3EVM is not booting on l-o master, with default configuration, HEAD @33fc21e Linux-omap rebuilt: Updated to v3.4-rc1, merged in most of pending branches. Reverting merge commit 58adb29 Merge branch 'io_chain_devel_3.4' of git://git.pwsan.com/linux-2.6 into prm makes OMAP3EVM boot. Bisecting into this merge could not be done as build was breaking for most of the individual commits in the merge (except when HEAD is the last commit of the merge, as below). Assuming broken builds to be good for bisect, it could get built for, cca6430 ARM: OMAP3: PM: Remove IO Daisychain control from cpuidle but with it OMAP3EVM does not boot. Regards Afzal -- 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
