OMAP2+: PM/serial: hold console semaphore while OMAP UARTs are disabled

OMAP2+: PM/serial: hold console semaphore while OMAP UARTs are disabled

[Paul Walmsley]

The console semaphore must be held while the OMAP UART devices are
disabled, lest a console write cause an ARM abort (and a kernel crash)
when the underlying console device is inaccessible.  These crashes
only occur when the console is on one of the OMAP internal serial
ports.

While this problem has been latent in the PM idle loop for some time,
the crash was not triggerable with an unmodified kernel until commit
6f251e9db1093c187addc309b5f2f7fe3efd2995 ("OMAP: UART: omap_device
conversions, remove implicit 8520 assumptions").  After this patch, a
console write often occurs after the console UART has been disabled in
the idle loop, crashing the system.  Several users have encountered
this bug:

    http://www.mail-archive.com/linux-omap at vger.kernel.org/msg38396.html

    http://www.mail-archive.com/linux-omap at vger.kernel.org/msg36602.html

The same commit also introduced new code that disabled the UARTs
during init, in omap_serial_init_port().  The kernel will also crash
in this code when earlyconsole and extra debugging is enabled:

    http://www.mail-archive.com/linux-omap at vger.kernel.org/msg36411.html

The minimal fix for the -rc series is to hold the console semaphore
while the OMAP UARTs are disabled.  This is a somewhat overbroad fix,
since the console may not be located on an OMAP UART, as is the case
with the GPMC UART on Zoom3.  While it is technically possible to
determine which devices the console or earlyconsole is actually
running on, it is not a trivial problem to solve, and the code to do
so is not really appropriate for the -rc series.

The right long-term fix is to ensure that no code outside of the OMAP
serial driver can disable an OMAP UART.  As I understand it, code to
implement this is under development by TI.

This patch is a collaboration between Paul Walmsley <paul@pwsan.com>
and Tony Lindgren <tony@atomide.com>.  Thanks to Ming Lei
<tom.leiming@gmail.com> and Pramod <pramod.gurav@ti.com> for their
feedback on earlier versions of this patch.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Ming Lei <tom.leiming@gmail.com>
Cc: Pramod <pramod.gurav@ti.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Jean Pihet <jean.pihet@newoldbits.com>
Cc: Govindraj.R <govindraj.raja@ti.com>
---
 arch/arm/mach-omap2/pm24xx.c |    7 +++++++
 arch/arm/mach-omap2/pm34xx.c |   10 ++++++++++
 arch/arm/mach-omap2/serial.c |    5 +++++
 3 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index a40457d..c85923e5 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -30,6 +30,7 @@
 #include <linux/irq.h>
 #include <linux/time.h>
 #include <linux/gpio.h>
+#include <linux/console.h>
 
 #include <asm/mach/time.h>
 #include <asm/mach/irq.h>
@@ -118,6 +119,10 @@ static void omap2_enter_full_retention(void)
 	if (omap_irq_pending())
 		goto no_sleep;
 
+	/* Block console output in case it is on one of the OMAP UARTs */
+	if (try_acquire_console_sem())
+		goto no_sleep;
+
 	omap_uart_prepare_idle(0);
 	omap_uart_prepare_idle(1);
 	omap_uart_prepare_idle(2);
@@ -131,6 +136,8 @@ static void omap2_enter_full_retention(void)
 	omap_uart_resume_idle(1);
 	omap_uart_resume_idle(0);
 
+	release_console_sem();
+
 no_sleep:
 	if (omap2_pm_debug) {
 		unsigned long long tmp;
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 75c0cd1..0ec8a04 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -28,6 +28,7 @@
 #include <linux/clk.h>
 #include <linux/delay.h>
 #include <linux/slab.h>
+#include <linux/console.h>
 
 #include <plat/sram.h>
 #include <plat/clockdomain.h>
@@ -385,6 +386,12 @@ void omap_sram_idle(void)
 		omap3_enable_io_chain();
 	}
 
+	/* Block console output in case it is on one of the OMAP UARTs */
+	if (per_next_state < PWRDM_POWER_ON ||
+	    core_next_state < PWRDM_POWER_ON)
+		if (try_acquire_console_sem())
+			goto console_still_active;
+
 	/* PER */
 	if (per_next_state < PWRDM_POWER_ON) {
 		omap_uart_prepare_idle(2);
@@ -463,6 +470,9 @@ void omap_sram_idle(void)
 		omap_uart_resume_idle(3);
 	}
 
+	release_console_sem();
+
+console_still_active:
 	/* Disable IO-PAD and IO-CHAIN wakeup */
 	if (omap3_has_io_wakeup() &&
 	    (per_next_state < PWRDM_POWER_ON ||
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index edd7c99..18935ea 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -27,6 +27,7 @@
 #include <linux/slab.h>
 #include <linux/serial_8250.h>
 #include <linux/pm_runtime.h>
+#include <linux/console.h>
 
 #ifdef CONFIG_SERIAL_OMAP
 #include <plat/omap-serial.h>
@@ -810,6 +811,8 @@ void __init omap_serial_init_port(int port)
 
 	oh->dev_attr = uart;
 
+	acquire_console_sem(); /* in case the earlycon is on the UART */
+
 	/*
 	 * Because of early UART probing, UART did not get idled
 	 * on init.  Now that omap_device is ready, ensure full idle
@@ -834,6 +837,8 @@ void __init omap_serial_init_port(int port)
 	omap_uart_block_sleep(uart);
 	uart->timeout = DEFAULT_TIMEOUT;
 
+	release_console_sem();
+
 	if ((cpu_is_omap34xx() && uart->padconf) ||
 	    (uart->wk_en && uart->wk_mask)) {
 		device_init_wakeup(&od->pdev.dev, true);
-- 
1.7.2.3

OMAP2+: PM/serial: hold console semaphore while OMAP UARTs are disabled

[Kevin Hilman]

Paul Walmsley <paul@pwsan.com> writes:

> The console semaphore must be held while the OMAP UART devices are
> disabled, lest a console write cause an ARM abort (and a kernel crash)
> when the underlying console device is inaccessible.  These crashes
> only occur when the console is on one of the OMAP internal serial
> ports.
>
> While this problem has been latent in the PM idle loop for some time,
> the crash was not triggerable with an unmodified kernel until commit
> 6f251e9db1093c187addc309b5f2f7fe3efd2995 ("OMAP: UART: omap_device
> conversions, remove implicit 8520 assumptions").  After this patch, a
> console write often occurs after the console UART has been disabled in
> the idle loop, crashing the system.  Several users have encountered
> this bug:
>
>     http://www.mail-archive.com/linux-omap at vger.kernel.org/msg38396.html
>
>     http://www.mail-archive.com/linux-omap at vger.kernel.org/msg36602.html
>
> The same commit also introduced new code that disabled the UARTs
> during init, in omap_serial_init_port().  The kernel will also crash
> in this code when earlyconsole and extra debugging is enabled:
>
>     http://www.mail-archive.com/linux-omap at vger.kernel.org/msg36411.html
>
> The minimal fix for the -rc series is to hold the console semaphore
> while the OMAP UARTs are disabled.  This is a somewhat overbroad fix,
> since the console may not be located on an OMAP UART, as is the case
> with the GPMC UART on Zoom3.  While it is technically possible to
> determine which devices the console or earlyconsole is actually
> running on, it is not a trivial problem to solve, and the code to do
> so is not really appropriate for the -rc series.
>
> The right long-term fix is to ensure that no code outside of the OMAP
> serial driver can disable an OMAP UART.  As I understand it, code to
> implement this is under development by TI.

Yes, what is underway is a conversion of the omap-serial driver to use
runtime PM so we can finally rid ourselves of the hackery in
mach-omap2/serial.c.  The PM stuff there is a real mess to understand
and maintain, and rather fragile, obviously.  Once the serial driver
itself is in charge of when to disable the UARTs, this becomes a much
easier problem to manage.

> This patch is a collaboration between Paul Walmsley <paul@pwsan.com>
> and Tony Lindgren <tony@atomide.com>.  Thanks to Ming Lei
> <tom.leiming@gmail.com> and Pramod <pramod.gurav@ti.com> for their
> feedback on earlier versions of this patch.

> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> Cc: Kevin Hilman <khilman@deeprootsystems.com>
> Cc: Ming Lei <tom.leiming@gmail.com>
> Cc: Pramod <pramod.gurav@ti.com>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Jean Pihet <jean.pihet@newoldbits.com>
> Cc: Govindraj.R <govindraj.raja@ti.com>

Acked-by: Kevin Hilman <khilman@deeprootsystems.com>

Very nice.  I've been exploring various solutions to this problem as
well, but this one is much cleaner.  Also, I hadn't discovered the 'try'
version of the console semaphore, so was running into recursive locking.

Anyways, tested on omap35xx: omap3evm (uart1/core console) and beagle
(uart3/per console) and omap34xx/n900 (uart3/per console) using both
retention-idle and off-idle.

Kevin

OMAP2+: PM/serial: hold console semaphore while OMAP UARTs are disabled

[Tony Lindgren]

* Kevin Hilman <khilman@deeprootsystems.com> [101124 16:32]:
> Paul Walmsley <paul@pwsan.com> writes:

<snip>

> Acked-by: Kevin Hilman <khilman@deeprootsystems.com>
> 
> Very nice.  I've been exploring various solutions to this problem as
> well, but this one is much cleaner.  Also, I hadn't discovered the 'try'
> version of the console semaphore, so was running into recursive locking.
> 
> Anyways, tested on omap35xx: omap3evm (uart1/core console) and beagle
> (uart3/per console) and omap34xx/n900 (uart3/per console) using both
> retention-idle and off-idle.

Thanks, queuing this as fix for the -rc cycle.

Tony

OMAP2+: PM/serial: hold console semaphore while OMAP UARTs are disabled

[Jean Pihet]

Hi,

On Thu, Nov 25, 2010 at 12:49 AM, Paul Walmsley <paul@pwsan.com> wrote:
>
> The console semaphore must be held while the OMAP UART devices are
> disabled, lest a console write cause an ARM abort (and a kernel crash)
> when the underlying console device is inaccessible. ?These crashes
> only occur when the console is on one of the OMAP internal serial
> ports.
This does not fix the issue for me on Beagle (console on ttyO2).

Doing:
  / # echo 5 > /sys/devices/platform/omap/omap-hsuart.0/sleep_timeout
  / # echo 5 > /sys/devices/platform/omap/omap-hsuart.1/sleep_timeout
  / # echo 5 > /sys/devices/platform/omap/omap-hsuart.2/sleep_timeout
and waiting 5 seconds hangs the console.

However enabling sleep_while_idle before configuring the UART2 timeout
makes it work ok:
  / # echo 5 > /sys/devices/platform/omap/omap-hsuart.0/sleep_timeout
  / # echo 5 > /sys/devices/platform/omap/omap-hsuart.1/sleep_timeout
  / # echo 1 > /debug/pm_debug/sleep_while_idle
  / # echo 5 > /sys/devices/platform/omap/omap-hsuart.2/sleep_timeout

This result is similar to what I tested on a recent l-o master w/o the fix.
Am I missing something?

One more remark. With OFF mode enabled I noticed that PER can go OFF
without CORE going OFF, which could trigger the errata i582. I think
this is another latent problem.

/ # cat /debug/pm_debug/count
usbhost_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
per_pwrdm (ON),OFF:3797,RET:2382,INA:0,ON:6180,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
dss_pwrdm (OFF),OFF:1,RET:1,INA:1,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
cam_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
core_pwrdm (ON),OFF:778,RET:3019,INA:0,ON:3798,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
neon_pwrdm (ON),OFF:4367,RET:1806,INA:6,ON:6180,RET-LOGIC-OFF:0
mpu_pwrdm (ON),OFF:4367,RET:1806,INA:6,ON:6180,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
iva2_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0
...

Any thoughts?
Jean

OMAP2+: PM/serial: hold console semaphore while OMAP UARTs are disabled

[Paul Walmsley]

Hello Jean

On Thu, 25 Nov 2010, Jean Pihet wrote:

> On Thu, Nov 25, 2010 at 12:49 AM, Paul Walmsley <paul@pwsan.com> wrote:
> >
> > The console semaphore must be held while the OMAP UART devices are
> > disabled, lest a console write cause an ARM abort (and a kernel crash)
> > when the underlying console device is inaccessible. ?These crashes
> > only occur when the console is on one of the OMAP internal serial
> > ports.
> This does not fix the issue for me on Beagle (console on ttyO2).
> 
> Doing:
>   / # echo 5 > /sys/devices/platform/omap/omap-hsuart.0/sleep_timeout
>   / # echo 5 > /sys/devices/platform/omap/omap-hsuart.1/sleep_timeout
>   / # echo 5 > /sys/devices/platform/omap/omap-hsuart.2/sleep_timeout
> and waiting 5 seconds hangs the console.

If this is without sleep_while_idle enabled, then you're seeing an 
unrelated bug that is not related to this patch.  That's because, when 
/debug/pm_debug/sleep_while_idle is 0, the pm34xx.c code that this patch 
touches won't be reached.

By the way, you write that the above situation "hangs the console."  Is it 
just the case that the console dies and the rest of the system is still 
alive, or does the whole system crash?

> However enabling sleep_while_idle before configuring the UART2 timeout
> makes it work ok:
>   / # echo 5 > /sys/devices/platform/omap/omap-hsuart.0/sleep_timeout
>   / # echo 5 > /sys/devices/platform/omap/omap-hsuart.1/sleep_timeout
>   / # echo 1 > /debug/pm_debug/sleep_while_idle
>   / # echo 5 > /sys/devices/platform/omap/omap-hsuart.2/sleep_timeout
> 
> This result is similar to what I tested on a recent l-o master w/o the fix.
> Am I missing something?

It may depend on your loglevel settings.  If warning messages aren't 
emitted to the console, then you won't see this crash.

Whether the system crashes also depends on whether you happen to get a new 
worst-case deactivation latency from your console serial port during PM 
idle.  If not, and there are no other console writes after the UART is 
disabled, then this patch won't affect anything.

Just FYI, without this patch, Tony's N810 crashed reliably upon entering 
dynamic idle. 

> One more remark. With OFF mode enabled I noticed that PER can go OFF
> without CORE going OFF, which could trigger the errata i582. I think
> this is another latent problem.

This appears to be unrelated to the patch under discussion.  Maybe you 
should start a separate list thread on this issue?  We do not appear to 
have the suggested workaround sequence in the TRM in the current code.  
This workaround is quite complex.  Someone from TI should definitely put 
together some patches to implement it.


- Paul

OMAP2+: PM/serial: hold console semaphore while OMAP UARTs are disabled

[Paul Walmsley]

Hi

On Thu, 25 Nov 2010, Jean Pihet wrote:

> On Thu, Nov 25, 2010 at 12:49 AM, Paul Walmsley <paul@pwsan.com> wrote:
> >
> > The console semaphore must be held while the OMAP UART devices are
> > disabled, lest a console write cause an ARM abort (and a kernel crash)
> > when the underlying console device is inaccessible. ?These crashes
> > only occur when the console is on one of the OMAP internal serial
> > ports.
> This does not fix the issue for me on Beagle (console on ttyO2).
> 
> Doing:
>   / # echo 5 > /sys/devices/platform/omap/omap-hsuart.0/sleep_timeout
>   / # echo 5 > /sys/devices/platform/omap/omap-hsuart.1/sleep_timeout
>   / # echo 5 > /sys/devices/platform/omap/omap-hsuart.2/sleep_timeout
> and waiting 5 seconds hangs the console.

By the way, I just tried this on a Beagle 35xx rev C2, with Tony's commit 
063d907edaf3fbf9776c189c3e02f2c7a129d18c, and did not see any hang.   Are 
you using a linux-omap kernel?


- Paul

OMAP2+: PM/serial: hold console semaphore while OMAP UARTs are disabled

[Jean Pihet]

On Thu, Nov 25, 2010 at 6:35 PM, Paul Walmsley <paul@pwsan.com> wrote:
> Hello Jean
>
> On Thu, 25 Nov 2010, Jean Pihet wrote:
>
>> On Thu, Nov 25, 2010 at 12:49 AM, Paul Walmsley <paul@pwsan.com> wrote:
>> >
>> > The console semaphore must be held while the OMAP UART devices are
>> > disabled, lest a console write cause an ARM abort (and a kernel crash)
>> > when the underlying console device is inaccessible. ?These crashes
>> > only occur when the console is on one of the OMAP internal serial
>> > ports.
>> This does not fix the issue for me on Beagle (console on ttyO2).
>>
>> Doing:
>> ? / # echo 5 > /sys/devices/platform/omap/omap-hsuart.0/sleep_timeout
>> ? / # echo 5 > /sys/devices/platform/omap/omap-hsuart.1/sleep_timeout
>> ? / # echo 5 > /sys/devices/platform/omap/omap-hsuart.2/sleep_timeout
>> and waiting 5 seconds hangs the console.
>
> If this is without sleep_while_idle enabled, then you're seeing an
> unrelated bug that is not related to this patch. ?That's because, when
> /debug/pm_debug/sleep_while_idle is 0, the pm34xx.c code that this patch
> touches won't be reached.
Ok so we still have a problem. I understood the correct fix is to
migrate the UART code to hwmod.

> By the way, you write that the above situation "hangs the console." ?Is it
> just the case that the console dies and the rest of the system is still
> alive, or does the whole system crash?
The console hangs, the rest of the system still runs.

>> However enabling sleep_while_idle before configuring the UART2 timeout
>> makes it work ok:
>> ? / # echo 5 > /sys/devices/platform/omap/omap-hsuart.0/sleep_timeout
>> ? / # echo 5 > /sys/devices/platform/omap/omap-hsuart.1/sleep_timeout
>> ? / # echo 1 > /debug/pm_debug/sleep_while_idle
>> ? / # echo 5 > /sys/devices/platform/omap/omap-hsuart.2/sleep_timeout
>>
>> This result is similar to what I tested on a recent l-o master w/o the fix.
>> Am I missing something?
>
> It may depend on your loglevel settings. ?If warning messages aren't
> emitted to the console, then you won't see this crash.
>
> Whether the system crashes also depends on whether you happen to get a new
> worst-case deactivation latency from your console serial port during PM
> idle. ?If not, and there are no other console writes after the UART is
> disabled, then this patch won't affect anything.
>
> Just FYI, without this patch, Tony's N810 crashed reliably upon entering
> dynamic idle.
'crashed reliably' ;p

>
>> One more remark. With OFF mode enabled I noticed that PER can go OFF
>> without CORE going OFF, which could trigger the errata i582. I think
>> this is another latent problem.
>
> This appears to be unrelated to the patch under discussion. ?Maybe you
> should start a separate list thread on this issue? ?We do not appear to
> have the suggested workaround sequence in the TRM in the current code.
> This workaround is quite complex. ?Someone from TI should definitely put
> together some patches to implement it.
Yes this is unrelated, let's discuss this separately.

>
>
> - Paul

Thanks,
Jean

OMAP2+: PM/serial: hold console semaphore while OMAP UARTs are disabled

[Jean Pihet]

Paul,

On Thu, Nov 25, 2010 at 7:15 PM, Paul Walmsley <paul@pwsan.com> wrote:
> Hi
>
> On Thu, 25 Nov 2010, Jean Pihet wrote:
>
>> On Thu, Nov 25, 2010 at 12:49 AM, Paul Walmsley <paul@pwsan.com> wrote:
>> >
>> > The console semaphore must be held while the OMAP UART devices are
>> > disabled, lest a console write cause an ARM abort (and a kernel crash)
>> > when the underlying console device is inaccessible. ?These crashes
>> > only occur when the console is on one of the OMAP internal serial
>> > ports.
>> This does not fix the issue for me on Beagle (console on ttyO2).
>>
>> Doing:
>> ? / # echo 5 > /sys/devices/platform/omap/omap-hsuart.0/sleep_timeout
>> ? / # echo 5 > /sys/devices/platform/omap/omap-hsuart.1/sleep_timeout
>> ? / # echo 5 > /sys/devices/platform/omap/omap-hsuart.2/sleep_timeout
>> and waiting 5 seconds hangs the console.
>
> By the way, I just tried this on a Beagle 35xx rev C2, with Tony's commit
> 063d907edaf3fbf9776c189c3e02f2c7a129d18c, and did not see any hang. ? Are
> you using a linux-omap kernel?
Yes this is using l-o master on Beagle B5.

>
>
> - Paul

Jean

OMAP2+: PM/serial: hold console semaphore while OMAP UARTs are disabled

[Paul Walmsley]

Hello Jean

On Thu, 25 Nov 2010, Jean Pihet wrote:

> On Thu, Nov 25, 2010 at 6:35 PM, Paul Walmsley <paul@pwsan.com> wrote:
> > On Thu, 25 Nov 2010, Jean Pihet wrote:
> >> On Thu, Nov 25, 2010 at 12:49 AM, Paul Walmsley <paul@pwsan.com> wrote:
> >> >
> >> > The console semaphore must be held while the OMAP UART devices are
> >> > disabled, lest a console write cause an ARM abort (and a kernel crash)
> >> > when the underlying console device is inaccessible. ?These crashes
> >> > only occur when the console is on one of the OMAP internal serial
> >> > ports.
> >> This does not fix the issue for me on Beagle (console on ttyO2).
> >>
> >> Doing:
> >> ? / # echo 5 > /sys/devices/platform/omap/omap-hsuart.0/sleep_timeout
> >> ? / # echo 5 > /sys/devices/platform/omap/omap-hsuart.1/sleep_timeout
> >> ? / # echo 5 > /sys/devices/platform/omap/omap-hsuart.2/sleep_timeout
> >> and waiting 5 seconds hangs the console.
> >
> > By the way, you write that the above situation "hangs the console." ?Is it
> > just the case that the console dies and the rest of the system is still
> > alive, or does the whole system crash?
> The console hangs, the rest of the system still runs.

Just out of curiosity, if you send a few breaks to the OMAP over serial, 
does that cause the console to pay attention again?  CTRL-A F in minicom.


- Paul

OMAP2+: PM/serial: hold console semaphore while OMAP UARTs are disabled

[Jean Pihet]

Hello Paul,

On Thu, Dec 2, 2010 at 8:23 AM, Paul Walmsley <paul@pwsan.com> wrote:
> Hello Jean
>
> On Thu, 25 Nov 2010, Jean Pihet wrote:
>
>> On Thu, Nov 25, 2010 at 6:35 PM, Paul Walmsley <paul@pwsan.com> wrote:
>> > On Thu, 25 Nov 2010, Jean Pihet wrote:
>> >> On Thu, Nov 25, 2010 at 12:49 AM, Paul Walmsley <paul@pwsan.com> wrote:
>> >> >
>> >> > The console semaphore must be held while the OMAP UART devices are
>> >> > disabled, lest a console write cause an ARM abort (and a kernel crash)
>> >> > when the underlying console device is inaccessible. ?These crashes
>> >> > only occur when the console is on one of the OMAP internal serial
>> >> > ports.
>> >> This does not fix the issue for me on Beagle (console on ttyO2).
>> >>
>> >> Doing:
>> >> ? / # echo 5 > /sys/devices/platform/omap/omap-hsuart.0/sleep_timeout
>> >> ? / # echo 5 > /sys/devices/platform/omap/omap-hsuart.1/sleep_timeout
>> >> ? / # echo 5 > /sys/devices/platform/omap/omap-hsuart.2/sleep_timeout
>> >> and waiting 5 seconds hangs the console.
>> >
>> > By the way, you write that the above situation "hangs the console." ?Is it
>> > just the case that the console dies and the rest of the system is still
>> > alive, or does the whole system crash?
>> The console hangs, the rest of the system still runs.
>
> Just out of curiosity, if you send a few breaks to the OMAP over serial,
> does that cause the console to pay attention again? ?CTRL-A F in minicom.
Yes it helps. In most cases sending 2-3 breaks resumes the UART console.

>
> - Paul

Jean

OMAP2+: PM/serial: hold console semaphore while OMAP UARTs are disabled

[Paul Walmsley]

Salut Jean

On Thu, 2 Dec 2010, Jean Pihet wrote:

> On Thu, Dec 2, 2010 at 8:23 AM, Paul Walmsley <paul@pwsan.com> wrote:
> > On Thu, 25 Nov 2010, Jean Pihet wrote:
> >> On Thu, Nov 25, 2010 at 6:35 PM, Paul Walmsley <paul@pwsan.com> wrote:
> >> > On Thu, 25 Nov 2010, Jean Pihet wrote:
> >> >> On Thu, Nov 25, 2010 at 12:49 AM, Paul Walmsley <paul@pwsan.com> wrote:
> >> >> >
> >> >> > The console semaphore must be held while the OMAP UART devices are
> >> >> > disabled, lest a console write cause an ARM abort (and a kernel crash)
> >> >> > when the underlying console device is inaccessible. ?These crashes
> >> >> > only occur when the console is on one of the OMAP internal serial
> >> >> > ports.
> >> >> This does not fix the issue for me on Beagle (console on ttyO2).
> >> >>
> >> >> Doing:
> >> >> ? / # echo 5 > /sys/devices/platform/omap/omap-hsuart.0/sleep_timeout
> >> >> ? / # echo 5 > /sys/devices/platform/omap/omap-hsuart.1/sleep_timeout
> >> >> ? / # echo 5 > /sys/devices/platform/omap/omap-hsuart.2/sleep_timeout
> >> >> and waiting 5 seconds hangs the console.
> >> >
> >> > By the way, you write that the above situation "hangs the console." ?Is it
> >> > just the case that the console dies and the rest of the system is still
> >> > alive, or does the whole system crash?
> >> The console hangs, the rest of the system still runs.
> >
> > Just out of curiosity, if you send a few breaks to the OMAP over serial,
> > does that cause the console to pay attention again? ?CTRL-A F in minicom.
> Yes it helps. In most cases sending 2-3 breaks resumes the UART console.

Could you try enabling DSS in your .config?  I applied the following to my 
omap2plus_defconfig after make oldnoconfig, and the console is now working 
again for me.

Hopefully adding DSS hwmod stuff will fix this...


- Paul

--- .config	2010-12-03 18:05:31.661889255 -0700
+++ .config.sleep.working	2010-12-03 18:03:57.733918058 -0700
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
 # Linux/arm 2.6.37-rc4 Kernel Configuration
-# Fri Dec  3 18:05:31 2010
+# Fri Dec  3 18:00:21 2010
 #
 CONFIG_ARM=y
 CONFIG_SYS_SUPPORTS_APM_EMULATION=y
@@ -1465,9 +1465,28 @@
 # CONFIG_FB_METRONOME is not set
 # CONFIG_FB_MB862XX is not set
 # CONFIG_FB_BROADSHEET is not set
-# CONFIG_FB_OMAP is not set
 CONFIG_FB_OMAP_LCD_VGA=y
-# CONFIG_OMAP2_DSS is not set
+CONFIG_OMAP2_DSS=y
+CONFIG_OMAP2_VRAM_SIZE=0
+CONFIG_OMAP2_DSS_DEBUG_SUPPORT=y
+# CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS is not set
+CONFIG_OMAP2_DSS_DPI=y
+# CONFIG_OMAP2_DSS_RFBI is not set
+CONFIG_OMAP2_DSS_VENC=y
+# CONFIG_OMAP2_DSS_SDI is not set
+# CONFIG_OMAP2_DSS_DSI is not set
+# CONFIG_OMAP2_DSS_FAKE_VSYNC is not set
+CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=0
+# CONFIG_FB_OMAP2 is not set
+
+#
+# OMAP2/3 Display Device Drivers
+#
+# CONFIG_PANEL_GENERIC is not set
+# CONFIG_PANEL_SHARP_LS037V7DW01 is not set
+# CONFIG_PANEL_SHARP_LQ043T1DG01 is not set
+# CONFIG_PANEL_TOPPOLY_TDO35S is not set
+# CONFIG_PANEL_TPO_TD043MTEA1 is not set
 CONFIG_BACKLIGHT_LCD_SUPPORT=y
 CONFIG_LCD_CLASS_DEVICE=y
 # CONFIG_LCD_L4F00242T03 is not set

OMAP2+: PM/serial: hold console semaphore while OMAP UARTs are disabled

[Kevin Hilman]

Tony Lindgren <tony@atomide.com> writes:

> * Kevin Hilman <khilman@deeprootsystems.com> [101124 16:32]:
>> Paul Walmsley <paul@pwsan.com> writes:
>
> <snip>
>
>> Acked-by: Kevin Hilman <khilman@deeprootsystems.com>
>> 
>> Very nice.  I've been exploring various solutions to this problem as
>> well, but this one is much cleaner.  Also, I hadn't discovered the 'try'
>> version of the console semaphore, so was running into recursive locking.
>> 
>> Anyways, tested on omap35xx: omap3evm (uart1/core console) and beagle
>> (uart3/per console) and omap34xx/n900 (uart3/per console) using both
>> retention-idle and off-idle.
>
> Thanks, queuing this as fix for the -rc cycle.

FYI.. just found a regression caused by this patch.  It prevented
suspend from ever happening since the console semaphore is already held
during suspend.

Just posted a fix for this:

Date: Tue, 7 Dec 2010 12:24:13 -0800
Subject: [PATCH] OMAP2+: PM/serial: fix console semaphore acquire during suspend


Kevin