Re: beagle hangs in uart3 disabling clocks
Paul Walmsley writes: > On Tue, 5 Oct 2010, Pramod wrote: > >> On Tuesday 05 October 2010 03:33 PM, Paul Walmsley wrote: >> > >> > Looks to me like it boots fine. If you had hwmod debugging enabled, your >> > kernel should have crashed after >> > >> > omap-hsuart.0: ttyO0 at MMIO 0x4806a000 (irq = 72) is a OMAP UART0 >> > omap-hsuart.1: ttyO1 at MMIO 0x4806c000 (irq = 73) is a OMAP UART1 >> > omap-hsuart.2: ttyO2 at MMIO 0x4902 (irq = 74) is a OMAP UART2 >> > >> > ... but it didn't crash there. I'm not seeing any hwmod debug messages >> > though, so you probably don't have DEBUG defined in omap_hwmod.c. >> > >> > So, I suspect whatever problem you're seeing is unrelated to the problem >> > that the patch was intended to solve. >> > >> > >> > - Paul >> >> The hwmod debug messages will be seen when I enable them on the go with: >> echo -n 'file omap_hwmod.c +p' > /debug/dynamic_debug/control >> >> This will show lots of logs as below ending with UART3 clock disabling and a >> hang. >> >> omap_hwmod:omap_hwmod: uart1: idling >> omap_hwmod:omap_hwmod: uart1: disabling clocks >> omap_hwmod:omap_hwmod: uart2: idling >> omap_hwmod:omap_hwmod: uart2: disabling clocks >> omap_hwmod:omap_hwmod: uart1: enabling >> omap_hwmod:omap_hwmod: uart1: enabling clocks >> omap_hwmod:omap_hwmod: uart2: enabling >> omap_hwmod:omap_hwmod: uart2: enabling clocks >> omap_hwmod:omap_hwmod: uart3: idling >> omap_hwmod:omap_hwmod: uart3: disabling clock > > OK, the problem here is probably with the real serial console generating > messages while the hwmod is idle, not earlyconsole/bootconsole. The patch > could be extended to fix that, but it doesn't address that right now. Why > don't you take a shot at doing that? > > In this context, the real serial console is only part of the problem. > For a complete fix, I suspect that one would have to tinker with the OMAP > UART driver or serial core, since other drivers beyond the real console > may be using the serial port (e.g. Bluetooth). > > Also, thinking about this issue further, there needs to be an additional > fix at least in omap_serial_init_port() to ensure that the UART TX FIFO is > completely drained before it starts messing around with the underlying > hwmod. Similarly, whenever the PM runtime conversion is done for > drivers/serial/omap-serial.c, it will need to ensure that the TX FIFO has > drained before going to idle. Now that the base omap-serial driver is queued for mainline, the next step is to move all the PM hackery from mach-omap2/serial.c into the driver itself by using the runtime PM API. This should ensure that any users of the real serial driver will have an active UART. 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: beagle hangs in uart3 disabling clocks
On Tue, 5 Oct 2010, Pramod wrote: > On Tuesday 05 October 2010 03:33 PM, Paul Walmsley wrote: > > > > Looks to me like it boots fine. If you had hwmod debugging enabled, your > > kernel should have crashed after > > > > omap-hsuart.0: ttyO0 at MMIO 0x4806a000 (irq = 72) is a OMAP UART0 > > omap-hsuart.1: ttyO1 at MMIO 0x4806c000 (irq = 73) is a OMAP UART1 > > omap-hsuart.2: ttyO2 at MMIO 0x4902 (irq = 74) is a OMAP UART2 > > > > ... but it didn't crash there. I'm not seeing any hwmod debug messages > > though, so you probably don't have DEBUG defined in omap_hwmod.c. > > > > So, I suspect whatever problem you're seeing is unrelated to the problem > > that the patch was intended to solve. > > > > > > - Paul > > The hwmod debug messages will be seen when I enable them on the go with: > echo -n 'file omap_hwmod.c +p' > /debug/dynamic_debug/control > > This will show lots of logs as below ending with UART3 clock disabling and a > hang. > > omap_hwmod:omap_hwmod: uart1: idling > omap_hwmod:omap_hwmod: uart1: disabling clocks > omap_hwmod:omap_hwmod: uart2: idling > omap_hwmod:omap_hwmod: uart2: disabling clocks > omap_hwmod:omap_hwmod: uart1: enabling > omap_hwmod:omap_hwmod: uart1: enabling clocks > omap_hwmod:omap_hwmod: uart2: enabling > omap_hwmod:omap_hwmod: uart2: enabling clocks > omap_hwmod:omap_hwmod: uart3: idling > omap_hwmod:omap_hwmod: uart3: disabling clock OK, the problem here is probably with the real serial console generating messages while the hwmod is idle, not earlyconsole/bootconsole. The patch could be extended to fix that, but it doesn't address that right now. Why don't you take a shot at doing that? In this context, the real serial console is only part of the problem. For a complete fix, I suspect that one would have to tinker with the OMAP UART driver or serial core, since other drivers beyond the real console may be using the serial port (e.g. Bluetooth). Also, thinking about this issue further, there needs to be an additional fix at least in omap_serial_init_port() to ensure that the UART TX FIFO is completely drained before it starts messing around with the underlying hwmod. Similarly, whenever the PM runtime conversion is done for drivers/serial/omap-serial.c, it will need to ensure that the TX FIFO has drained before going to idle. regards, - 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: beagle hangs in uart3 disabling clocks
On Tuesday 05 October 2010 03:33 PM, Paul Walmsley wrote: On Tue, 5 Oct 2010, Pramod wrote: On Tuesday 05 October 2010 03:17 PM, Paul Walmsley wrote: On Tue, 5 Oct 2010, Pramod wrote: On Tuesday 05 October 2010 12:49 PM, Paul Walmsley wrote: On Tue, 5 Oct 2010, Pramod wrote: I applied this patch on my kernel which is based on android-2.6.32 enabling dynamic printks. I still see the console hang after enabling the logs in hwmod. I am using zoom3 board. Can you please let me know which defconfig from lo master branch can be used to test on zoom3? I would like to test this patch with lo master branch and zoom3. Could you please paste your boot log messages here? - Paul Hi paul, These are the boot log messages. Is that with the patch applied or without it? If without, please post the log messages from a boot after you apply the patch. - Paul These logs are with the patch shared by you. Looks to me like it boots fine. If you had hwmod debugging enabled, your kernel should have crashed after omap-hsuart.0: ttyO0 at MMIO 0x4806a000 (irq = 72) is a OMAP UART0 omap-hsuart.1: ttyO1 at MMIO 0x4806c000 (irq = 73) is a OMAP UART1 omap-hsuart.2: ttyO2 at MMIO 0x4902 (irq = 74) is a OMAP UART2 ... but it didn't crash there. I'm not seeing any hwmod debug messages though, so you probably don't have DEBUG defined in omap_hwmod.c. So, I suspect whatever problem you're seeing is unrelated to the problem that the patch was intended to solve. - Paul The hwmod debug messages will be seen when I enable them on the go with: echo -n 'file omap_hwmod.c +p' > /debug/dynamic_debug/control This will show lots of logs as below ending with UART3 clock disabling and a hang. omap_hwmod:omap_hwmod: uart1: idling omap_hwmod:omap_hwmod: uart1: disabling clocks omap_hwmod:omap_hwmod: uart2: idling omap_hwmod:omap_hwmod: uart2: disabling clocks omap_hwmod:omap_hwmod: uart1: enabling omap_hwmod:omap_hwmod: uart1: enabling clocks omap_hwmod:omap_hwmod: uart2: enabling omap_hwmod:omap_hwmod: uart2: enabling clocks omap_hwmod:omap_hwmod: uart3: idling omap_hwmod:omap_hwmod: uart3: disabling clock - Pramod -- 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: beagle hangs in uart3 disabling clocks
On Tue, 5 Oct 2010, Pramod wrote: > On Tuesday 05 October 2010 03:17 PM, Paul Walmsley wrote: > > On Tue, 5 Oct 2010, Pramod wrote: > > > > > On Tuesday 05 October 2010 12:49 PM, Paul Walmsley wrote: > > > > On Tue, 5 Oct 2010, Pramod wrote: > > > > > > > > > I applied this patch on my kernel which is based on android-2.6.32 > > > > > enabling > > > > > dynamic printks. I still see the console hang after enabling the logs > > > > > in > > > > > hwmod. > > > > > > > > > > I am using zoom3 board. Can you please let me know which defconfig > > > > > from lo > > > > > master branch can be used to test on zoom3? I would like to test this > > > > > patch > > > > > with lo master branch and zoom3. > > > > > > > > Could you please paste your boot log messages here? > > > > > > > > > > > > - Paul > > > > > > Hi paul, > > > These are the boot log messages. > > > > Is that with the patch applied or without it? If without, please post the > > log messages from a boot after you apply the patch. > > > > - Paul > > These logs are with the patch shared by you. Looks to me like it boots fine. If you had hwmod debugging enabled, your kernel should have crashed after omap-hsuart.0: ttyO0 at MMIO 0x4806a000 (irq = 72) is a OMAP UART0 omap-hsuart.1: ttyO1 at MMIO 0x4806c000 (irq = 73) is a OMAP UART1 omap-hsuart.2: ttyO2 at MMIO 0x4902 (irq = 74) is a OMAP UART2 ... but it didn't crash there. I'm not seeing any hwmod debug messages though, so you probably don't have DEBUG defined in omap_hwmod.c. So, I suspect whatever problem you're seeing is unrelated to the problem that the patch was intended to solve. - 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: beagle hangs in uart3 disabling clocks
On Tuesday 05 October 2010 03:17 PM, Paul Walmsley wrote: On Tue, 5 Oct 2010, Pramod wrote: On Tuesday 05 October 2010 12:49 PM, Paul Walmsley wrote: On Tue, 5 Oct 2010, Pramod wrote: I applied this patch on my kernel which is based on android-2.6.32 enabling dynamic printks. I still see the console hang after enabling the logs in hwmod. I am using zoom3 board. Can you please let me know which defconfig from lo master branch can be used to test on zoom3? I would like to test this patch with lo master branch and zoom3. Could you please paste your boot log messages here? - Paul Hi paul, These are the boot log messages. Is that with the patch applied or without it? If without, please post the log messages from a boot after you apply the patch. - Paul These logs are with the patch shared by you. Pramod -- 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: beagle hangs in uart3 disabling clocks
On Tue, 5 Oct 2010, Pramod wrote: > On Tuesday 05 October 2010 12:49 PM, Paul Walmsley wrote: > > On Tue, 5 Oct 2010, Pramod wrote: > > > > > I applied this patch on my kernel which is based on android-2.6.32 > > > enabling > > > dynamic printks. I still see the console hang after enabling the logs in > > > hwmod. > > > > > > I am using zoom3 board. Can you please let me know which defconfig from lo > > > master branch can be used to test on zoom3? I would like to test this > > > patch > > > with lo master branch and zoom3. > > > > Could you please paste your boot log messages here? > > > > > > - Paul > > Hi paul, > These are the boot log messages. Is that with the patch applied or without it? If without, please post the log messages from a boot after you apply the patch. - 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: beagle hangs in uart3 disabling clocks
On Tuesday 05 October 2010 12:49 PM, Paul Walmsley wrote: On Tue, 5 Oct 2010, Pramod wrote: I applied this patch on my kernel which is based on android-2.6.32 enabling dynamic printks. I still see the console hang after enabling the logs in hwmod. I am using zoom3 board. Can you please let me know which defconfig from lo master branch can be used to test on zoom3? I would like to test this patch with lo master branch and zoom3. Could you please paste your boot log messages here? - Paul Hi paul, These are the boot log messages. Uncompressing Linux.. .. done, booting the kernel. Initializing cgroup subsys cpu Linux version 2.6.32.9-1-g8d10978-dirty (d...@dw-desktop) (gcc version 4.4.1 (Sourcery G++ Lite 2009q3-67) ) #23 PREEMPT Tue Oct 5 12:25:20 IST 2010 CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP Zoom3 board Memory policy: ECC disabled, Data cache writeback On node 0 totalpages: 131072 free_area_init_node: node 0, pgdat c06c1968, node_mem_map c07cb000 Normal zone: 1024 pages used for memmap Normal zone: 0 pages reserved Normal zone: 130048 pages, LIFO batch:31 DIE ID: 5C320156087C06005013 OMAP3630 ES1.0 (l2cache iva sgx neon isp 192mhz_clk ) omap_sam_base (VA) == 0xfe40 omap_sram_start (PA) == 0x4020 omap_sram_size (SIZE) == 0x1 SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x10 Reserving 14745600 bytes SDRAM for VRAM Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 Kernel command line: console=ttyO2,115200n8 root=/dev/nfs rw nfsroot=172.24.137.0:/home/dw/l25.x/25.INC3.1/myfs,nolock,wsize=1024,rsize=1024 init=/init ip=dhcp videoout=omap24xx vout omap_vout.video1_numbuffers=6 omap_vout.vid1_static_vrfb_alloc=y omapfb.vram=0:4M earlyprintk loglevel=8 PID hash table entries: 2048 (order: 1, 8192 bytes) Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 256MB 256MB = 512MB total Memory: 491008KB available (6180K code, 1352K data, 224K init, 0K highmem) Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) vmalloc : 0xe080 - 0xf800 ( 376 MB) lowmem : 0xc000 - 0xe000 ( 512 MB) pkmap : 0xbfe0 - 0xc000 ( 2 MB) modules : 0xbf00 - 0xbfe0 ( 14 MB) .init : 0xc0008000 - 0xc004 ( 224 kB) .text : 0xc004 - 0xc0649000 (6180 kB) .data : 0xc0674000 - 0xc06ce3d0 ( 361 kB) Hierarchical RCU implementation. NR_IRQS:402 IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts Total of 96 interrupts on 1 active controller Clocking rate (Crystal/Core/MPU): 26.0/400/600 MHz Reprogramming SDRC clock to 4 Hz GPMC revision 5.0 OMAP GPIO hardware version 2.5 OMAP clockevent source: GPTIMER1 at 32768 Hz Console: colour dummy device 80x30 Calibrating delay loop... 597.64 BogoMIPS (lpj=2334720) Mount-cache hash table entries: 512 Initializing cgroup subsys debug Initializing cgroup subsys cpuacct Initializing cgroup subsys freezer CPU: Testing write buffer coherency: ok regulator: core version 0.5 NET: Registered protocol family 16 mux: Setting signal i2c2_scl.i2c2_scl 0x0118 -> 0x0100 mux: Setting signal i2c2_sda.i2c2_sda 0x0118 -> 0x0100 mux: Setting signal i2c3_scl.i2c3_scl 0x0118 -> 0x0100 mux: Setting signal i2c3_sda.i2c3_sda 0x0118 -> 0x0100 mux: Setting signal uart3_cts_rctx.gpio_163 0x0108 -> 0x011c mux: Setting signal cam_xclka.gpio_96 0x0004 -> 0x0004 mux: Setting signal cam_wen.gpio_167 0x0004 -> 0x0004 mux: Setting signal mcspi1_cs2.mcspi1_cs2 0x0108 -> 0x0108 mux: Setting signal cam_hs.gpio_94 0x010c -> 0x0104 mux: Setting signal cam_xclka.gpio_96 0x0004 -> 0x0004 mux: Setting signal gpmc_ncs5.gpio_56 0x0004 -> 0x0004 mux: Setting signal cam_vs.gpio_95 0x0114 -> 0x0004 mux: Setting signal sys_nirq.sys_nirq 0x0118 -> 0x4118 mux: Setting signal cam_pclk.gpio_97 0x0114 -> 0x011c mux: Setting signal cam_d2.gpio101 0x0104 -> 0x0004 mux: Setting signal mcbsp1_clkx.gpio162 0x011c -> 0x0104 mux: Setting signal etk_clk.etk_clk 0x001b -> 0x011a mux: Setting signal mcspi1_cs1.mcspi1_cs1 0x000b -> 0x011b mux: Setting signal etk_d4.etk_d4 0x0103 -> 0x011a mux: Setting signal etk_d5.etk_d5 0x0103 -> 0x011a mux: Setting signal etk_d6.etk_d6 0x0103 -> 0x011a mux: Setting signal etk_d3.etk_d3 0x0103 -> 0x011a (wl12xx): Connectivity board init (wl12xx): Connectivity board init for OMAP3+WL127x (wl12xx): wl127x_vio_leakage_fix (wl12xx): Adding Connectivity platform device (wl12xx): Configuring Connectivity GPIOs mux: Setting signal cam_d10.gpio109 0x0104 -> 0x0004 mux: Se
Re: beagle hangs in uart3 disabling clocks
On Tue, 5 Oct 2010, Pramod wrote: > I applied this patch on my kernel which is based on android-2.6.32 enabling > dynamic printks. I still see the console hang after enabling the logs in > hwmod. > > I am using zoom3 board. Can you please let me know which defconfig from lo > master branch can be used to test on zoom3? I would like to test this patch > with lo master branch and zoom3. Could you please paste your boot log messages here? - 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: beagle hangs in uart3 disabling clocks
On Tuesday 05 October 2010 11:44 AM, Paul Walmsley wrote:
Hello Lei,
On Tue, 5 Oct 2010, Ming Lei wrote:
2010/10/5 Kevin Hilman:
Ming Lei writes:
2010/10/4 Kevin Hilman:
Why? What do you need from the PM branch that is not in l-o master?
Seems master branch works fine for me, my beagle board doesn't hang
uart3 disabling clocks.
Master branch and PM branch have exactly the same functionality for
UART hwmods. The problem was that you manually enabled DEBUG in
omap_hwmod.c.
Yes, you are correct. If DEBUG in omap_hwmod.c is enabled manually,
and pass the parameter of 'earlyprintk loglevel=8' to kernel from bootloader,
this issue can be triggered even with master branch.
Does this experimental patch solve the problem, even if DEBUG is enabled
in the hwmod code?
- Paul
Hi Paul,
I applied this patch on my kernel which is based on android-2.6.32
enabling dynamic printks. I still see the console hang after enabling
the logs in hwmod.
I am using zoom3 board. Can you please let me know which defconfig from
lo master branch can be used to test on zoom3? I would like to test this
patch with lo master branch and zoom3.
Thanks,
Pramod
From d928bd31c9c4ad16a044b244ef3d2ad3ed648f6f Mon Sep 17 00:00:00 2001
From: Paul Walmsley
Date: Tue, 5 Oct 2010 00:11:27 -0600
Subject: [PATCH] RFC: omap serial: block console output while resetting
earlyconsole UART
Currently, no attempt is made to block console output while the
earlyconsole UART is unavailable. This can result in silent crashes
that are very difficult to debug due to the lack of console output.
This patch holds the console semaphore while resetting the active console
UART, which causes all console output during that time to be buffered and
then transmitted after the console semaphore is released.
Not-yet-signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/serial.c | 100 ++
1 files changed, 100 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 338e46a..577f8f9 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -28,10 +28,13 @@
#include
#include
+#include
+
#ifdef CONFIG_SERIAL_OMAP
#include
#endif
+#include
#include
#include
#include
@@ -39,6 +42,8 @@
#include
#include
+#include
+
#include "prm.h"
#include "pm.h"
#include "cm.h"
@@ -51,6 +56,8 @@
#define UART_ERRATA_FIFO_FULL_ABORT (0x1<< 0)
#define UART_ERRATA_i202_MDR1_ACCESS (0x1<< 1)
+#define uart_id_to_ttys_id(u) (u - 1)
+
/*
* NOTE: By default the serial timeout is disabled as it causes lost
characters
* over the serial ports. This means that the UART clocks will stay on until
@@ -106,6 +113,83 @@ static LIST_HEAD(uart_list);
static u8 num_uarts;
/*
+ * early_console_uart: if earlyconsole is enabled and active, the UART
+ * ID (e.g., 1, 2, 3, 4) will be stored here. '0' means earlyconsole
+ * is disabled or some problem occurred during earlyconsole handling.
+ */
+static int early_console_uart;
+
+#define for_each_console(con) \
+ for (con = console_drivers; con != NULL; con = con->next)
+
+/* XXX belongs in kernel/printk.c or some earlyconsole file */
+/* XXX The "earlycon" string is an ugly hack */
+int _is_early_console_enabled(void)
+{
+ int ret = 0;
+ struct console *c;
+
+ acquire_console_sem();
+ for_each_console(c)
+ if (!strcmp("earlycon", c->name))
+ ret = 1;
+ release_console_sem();
+
+ return ret;
+}
+
+/* XXX document */
+static int _get_early_console_uart(void)
+{
+ u32 v;
+ int u = -EINVAL;
+
+ v = __raw_readl(phys_to_virt(OMAP_UART_INFO));
+ /* XXX see the OMAP debug-macro.S for this table */
+ switch (v) {
+ case 0:
+ case OMAP2UART1:
+ u = 1;
+ break;
+ case OMAP2UART2:
+ u = 2;
+ break;
+ case OMAP2UART3:
+ case OMAP3UART3:
+ case OMAP4UART3:
+ u = 3;
+ break;
+ case OMAP3UART4:
+ case OMAP4UART4:
+ u = 4;
+ break;
+ case ZOOM_UART:
+ WARN(1, "omap serial: ZOOM UART in use - does that go through "
+"the OMAP serial code?\n");
+ break;
+ default:
+ WARN(1, "omap serial: unknown serial port in use!\n");
+ }
+
+ return u;
+}
+
+/* XXX document */
+static void _store_early_console_uart_id(void)
+{
+ int uart_id;
+
+ if (_is_early_console_enabled()) {
+ uart_id = _get_early_console_uart();
+ if (uart_id> 0) {
+ early_console_uart = uart_id;
+ pr_info("omap serial: early console active on UART%d
(ttyS%d)\n",
+ uart_id, uart_id_to_ttys_id(uart_id));
+ }
+ }
+}
+
+/*
* Since these idle
Re: beagle hangs in uart3 disabling clocks
Hi Paul,
2010/10/5 Paul Walmsley :
> Hello Lei,
>
> On Tue, 5 Oct 2010, Ming Lei wrote:
>
>> 2010/10/5 Kevin Hilman :
>> > Ming Lei writes:
>> >
>> >> 2010/10/4 Kevin Hilman :
>> >>>
>> >>> Why? What do you need from the PM branch that is not in l-o master?
>> >>
>> >> Seems master branch works fine for me, my beagle board doesn't hang
>> >> uart3 disabling clocks.
>> >
>> > Master branch and PM branch have exactly the same functionality for
>> > UART hwmods. The problem was that you manually enabled DEBUG in
>> > omap_hwmod.c.
>>
>> Yes, you are correct. If DEBUG in omap_hwmod.c is enabled manually,
>> and pass the parameter of 'earlyprintk loglevel=8' to kernel from bootloader,
>> this issue can be triggered even with master branch.
>
> Does this experimental patch solve the problem, even if DEBUG is enabled
> in the hwmod code?
>
>
> - Paul
>
> From d928bd31c9c4ad16a044b244ef3d2ad3ed648f6f Mon Sep 17 00:00:00 2001
> From: Paul Walmsley
> Date: Tue, 5 Oct 2010 00:11:27 -0600
> Subject: [PATCH] RFC: omap serial: block console output while resetting
> earlyconsole UART
>
> Currently, no attempt is made to block console output while the
> earlyconsole UART is unavailable. This can result in silent crashes
> that are very difficult to debug due to the lack of console output.
> This patch holds the console semaphore while resetting the active console
> UART, which causes all console output during that time to be buffered and
> then transmitted after the console semaphore is released.
Good works, this patch does fix the issue!
With the patch, even DEBUG in omap_hwmod.c is enabled manually
and 'earlyprintk loglevel=8' is passed to kernel, my beagle board can't
hang after 'uart3: disabling clocks' is printed.
>
> Not-yet-signed-off-by: Paul Walmsley
> ---
> arch/arm/mach-omap2/serial.c | 100
> ++
> 1 files changed, 100 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> index 338e46a..577f8f9 100644
> --- a/arch/arm/mach-omap2/serial.c
> +++ b/arch/arm/mach-omap2/serial.c
> @@ -28,10 +28,13 @@
> #include
> #include
>
> +#include
> +
> #ifdef CONFIG_SERIAL_OMAP
> #include
> #endif
>
> +#include
> #include
> #include
> #include
> @@ -39,6 +42,8 @@
> #include
> #include
>
> +#include
> +
> #include "prm.h"
> #include "pm.h"
> #include "cm.h"
> @@ -51,6 +56,8 @@
> #define UART_ERRATA_FIFO_FULL_ABORT (0x1 << 0)
> #define UART_ERRATA_i202_MDR1_ACCESS (0x1 << 1)
>
> +#define uart_id_to_ttys_id(u) (u - 1)
> +
> /*
> * NOTE: By default the serial timeout is disabled as it causes lost
> characters
> * over the serial ports. This means that the UART clocks will stay on until
> @@ -106,6 +113,83 @@ static LIST_HEAD(uart_list);
> static u8 num_uarts;
>
> /*
> + * early_console_uart: if earlyconsole is enabled and active, the UART
> + * ID (e.g., 1, 2, 3, 4) will be stored here. '0' means earlyconsole
> + * is disabled or some problem occurred during earlyconsole handling.
> + */
> +static int early_console_uart;
> +
> +#define for_each_console(con) \
> + for (con = console_drivers; con != NULL; con = con->next)
> +
> +/* XXX belongs in kernel/printk.c or some earlyconsole file */
> +/* XXX The "earlycon" string is an ugly hack */
> +int _is_early_console_enabled(void)
> +{
> + int ret = 0;
> + struct console *c;
> +
> + acquire_console_sem();
> + for_each_console(c)
> + if (!strcmp("earlycon", c->name))
> + ret = 1;
> + release_console_sem();
> +
> + return ret;
> +}
> +
> +/* XXX document */
> +static int _get_early_console_uart(void)
> +{
> + u32 v;
> + int u = -EINVAL;
> +
> + v = __raw_readl(phys_to_virt(OMAP_UART_INFO));
> + /* XXX see the OMAP debug-macro.S for this table */
> + switch (v) {
> + case 0:
> + case OMAP2UART1:
> + u = 1;
> + break;
> + case OMAP2UART2:
> + u = 2;
> + break;
> + case OMAP2UART3:
> + case OMAP3UART3:
> + case OMAP4UART3:
> + u = 3;
> + break;
> + case OMAP3UART4:
> + case OMAP4UART4:
> + u = 4;
> + break;
> + case ZOOM_UART:
> + WARN(1, "omap serial: ZOOM UART in use - does that go through
> "
> + "the OMAP serial code?\n");
> + break;
> + default:
> + WARN(1, "omap serial: unknown serial port in use!\n");
> + }
> +
> + return u;
> +}
> +
> +/* XXX document */
> +static void _store_early_console_uart_id(void)
> +{
> + int uart_id;
> +
> + if (_is_early_console_enabled()) {
> + uart_id = _get_early_console_uart();
> + if (uart_id > 0) {
> + early_console_uart = uart_id;
> + pr_info("omap serial: early cons
Re: beagle hangs in uart3 disabling clocks
Hello Lei,
On Tue, 5 Oct 2010, Ming Lei wrote:
> 2010/10/5 Kevin Hilman :
> > Ming Lei writes:
> >
> >> 2010/10/4 Kevin Hilman :
> >>>
> >>> Why? What do you need from the PM branch that is not in l-o master?
> >>
> >> Seems master branch works fine for me, my beagle board doesn't hang
> >> uart3 disabling clocks.
> >
> > Master branch and PM branch have exactly the same functionality for
> > UART hwmods. The problem was that you manually enabled DEBUG in
> > omap_hwmod.c.
>
> Yes, you are correct. If DEBUG in omap_hwmod.c is enabled manually,
> and pass the parameter of 'earlyprintk loglevel=8' to kernel from bootloader,
> this issue can be triggered even with master branch.
Does this experimental patch solve the problem, even if DEBUG is enabled
in the hwmod code?
- Paul
From d928bd31c9c4ad16a044b244ef3d2ad3ed648f6f Mon Sep 17 00:00:00 2001
From: Paul Walmsley
Date: Tue, 5 Oct 2010 00:11:27 -0600
Subject: [PATCH] RFC: omap serial: block console output while resetting
earlyconsole UART
Currently, no attempt is made to block console output while the
earlyconsole UART is unavailable. This can result in silent crashes
that are very difficult to debug due to the lack of console output.
This patch holds the console semaphore while resetting the active console
UART, which causes all console output during that time to be buffered and
then transmitted after the console semaphore is released.
Not-yet-signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/serial.c | 100 ++
1 files changed, 100 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 338e46a..577f8f9 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -28,10 +28,13 @@
#include
#include
+#include
+
#ifdef CONFIG_SERIAL_OMAP
#include
#endif
+#include
#include
#include
#include
@@ -39,6 +42,8 @@
#include
#include
+#include
+
#include "prm.h"
#include "pm.h"
#include "cm.h"
@@ -51,6 +56,8 @@
#define UART_ERRATA_FIFO_FULL_ABORT(0x1 << 0)
#define UART_ERRATA_i202_MDR1_ACCESS (0x1 << 1)
+#define uart_id_to_ttys_id(u) (u - 1)
+
/*
* NOTE: By default the serial timeout is disabled as it causes lost characters
* over the serial ports. This means that the UART clocks will stay on until
@@ -106,6 +113,83 @@ static LIST_HEAD(uart_list);
static u8 num_uarts;
/*
+ * early_console_uart: if earlyconsole is enabled and active, the UART
+ * ID (e.g., 1, 2, 3, 4) will be stored here. '0' means earlyconsole
+ * is disabled or some problem occurred during earlyconsole handling.
+ */
+static int early_console_uart;
+
+#define for_each_console(con) \
+ for (con = console_drivers; con != NULL; con = con->next)
+
+/* XXX belongs in kernel/printk.c or some earlyconsole file */
+/* XXX The "earlycon" string is an ugly hack */
+int _is_early_console_enabled(void)
+{
+ int ret = 0;
+ struct console *c;
+
+ acquire_console_sem();
+ for_each_console(c)
+ if (!strcmp("earlycon", c->name))
+ ret = 1;
+ release_console_sem();
+
+ return ret;
+}
+
+/* XXX document */
+static int _get_early_console_uart(void)
+{
+ u32 v;
+ int u = -EINVAL;
+
+ v = __raw_readl(phys_to_virt(OMAP_UART_INFO));
+ /* XXX see the OMAP debug-macro.S for this table */
+ switch (v) {
+ case 0:
+ case OMAP2UART1:
+ u = 1;
+ break;
+ case OMAP2UART2:
+ u = 2;
+ break;
+ case OMAP2UART3:
+ case OMAP3UART3:
+ case OMAP4UART3:
+ u = 3;
+ break;
+ case OMAP3UART4:
+ case OMAP4UART4:
+ u = 4;
+ break;
+ case ZOOM_UART:
+ WARN(1, "omap serial: ZOOM UART in use - does that go through "
+"the OMAP serial code?\n");
+ break;
+ default:
+ WARN(1, "omap serial: unknown serial port in use!\n");
+ }
+
+ return u;
+}
+
+/* XXX document */
+static void _store_early_console_uart_id(void)
+{
+ int uart_id;
+
+ if (_is_early_console_enabled()) {
+ uart_id = _get_early_console_uart();
+ if (uart_id > 0) {
+ early_console_uart = uart_id;
+ pr_info("omap serial: early console active on UART%d
(ttyS%d)\n",
+ uart_id, uart_id_to_ttys_id(uart_id));
+ }
+ }
+}
+
+/*
* Since these idle/enable hooks are used in the idle path itself
* which has interrupts disabled, use the non-locking versions of
* the hwmod enable/disable functions.
@@ -801,6 +885,17 @@ void __init omap_serial_init_port(int port)
oh->dev_attr = uart;
/*
+* XXX How do we know whether the console is on this UART or not?
+* We should only call acquire_console_sem(
Re: beagle hangs in uart3 disabling clocks
2010/10/5 Kevin Hilman : > Ming Lei writes: > >> 2010/10/4 Kevin Hilman : >>> >>> Why? What do you need from the PM branch that is not in l-o master? >> >> Seems master branch works fine for me, my beagle board doesn't hang >> uart3 disabling clocks. > > Master branch and PM branch have exactly the same functionality for > UART hwmods. The problem was that you manually enabled DEBUG in > omap_hwmod.c. Yes, you are correct. If DEBUG in omap_hwmod.c is enabled manually, and pass the parameter of 'earlyprintk loglevel=8' to kernel from bootloader, this issue can be triggered even with master branch. > >> I only want to have a try of the runtime pm feature of omap3, so use >> PM branch to do the test. > > master branch and PM branch have exactly the same functionality for > runtime PM Thanks for letting me know it. thanks, -- Lei Ming -- 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: beagle hangs in uart3 disabling clocks
Ming Lei writes: > 2010/10/4 Kevin Hilman : >> >> Why? What do you need from the PM branch that is not in l-o master? > > Seems master branch works fine for me, my beagle board doesn't hang > uart3 disabling clocks. Master branch and PM branch have exactly the same functionality for UART hwmods. The problem was that you manually enabled DEBUG in omap_hwmod.c. > I only want to have a try of the runtime pm feature of omap3, so use > PM branch to do the test. master branch and PM branch have exactly the same functionality for runtime PM 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: beagle hangs in uart3 disabling clocks
2010/10/4 Kevin Hilman : > > Why? What do you need from the PM branch that is not in l-o master? Seems master branch works fine for me, my beagle board doesn't hang uart3 disabling clocks. I only want to have a try of the runtime pm feature of omap3, so use PM branch to do the test. > > The PM branch is *experimental*, and is under significant change while > parts that are not yet ready for mainline are being reworked and in some > cases completely re-written. > > IOW, the PM branch is unstable and should not be trusted. (I can say > that, I am the maintainer.) ;) I see now, :-) -- Lei Ming -- 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: beagle hangs in uart3 disabling clocks
Ming Lei writes: > 2010/10/4 Govindraj : >> I tried now on zoom3 with uart3[ttyO2] as console >> >> It boots up fine for me >> >> Logs: >> >> http://pastebin.com/sXR5nYcD >> >> I am using omap2plus_defconfig and lo-master >> >> commit 0882b1455797b0a104978000a622c3f2412e7cf5 >> Author: Tony Lindgren >> Date: Fri Oct 1 17:23:48 2010 -0700 >> >> omap: READ CAREFULLY: Fix build after merging in hwmod support for testing > > Seems you are trying the master branch of Tony's linux-omap-2.6 tree, could > you > try the pm branch of the tree? Why? What do you need from the PM branch that is not in l-o master? The PM branch is *experimental*, and is under significant change while parts that are not yet ready for mainline are being reworked and in some cases completely re-written. IOW, the PM branch is unstable and should not be trusted. (I can say that, I am the maintainer.) ;) 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: beagle hangs in uart3 disabling clocks
Ming Lei writes: > I just tested pm branch of tony's linux-omap-2.6 tree, and found my > beagle will hang in uart3 disabling clocks, follows the log info: It greatly helps when you also state what defconfig you're using, and what you've changed from the default defconfig. ... more below... > Starting kernel ... > > Uncompressing Linux... done, booting the kernel. > Linux version 2.6.36-rc6+ (t...@tom-lei) (gcc version 4.3.3 (Sourcery > G++ Lite 2009q1-203) ) #320 PREEM > PT Sun Oct 3 16:46:04 CST 2010 > CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c53c7f > CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache > Machine: OMAP3 Beagle Board > bootconsole [earlycon0] enabled > Memory policy: ECC disabled, Data cache writeback > OMAP3430/3530 ES2.1 (l2cache iva sgx neon isp ) > SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x1 > On node 0 totalpages: 32768 > free_area_init_node: node 0, pgdat c04a1a00, node_mem_map c06b8000 > Normal zone: 256 pages used for memmap > Normal zone: 0 pages reserved > Normal zone: 32512 pages, LIFO batch:7 > Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 > Kernel command line: console=ttyO2,115200n8 root=/dev/mmcblk0p2 rw > rootdelay=1 earlyprintk initcall_de > bug=1 loglevel=8 > PID hash table entries: 512 (order: -1, 2048 bytes) > Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) > Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) > Memory: 128MB = 128MB total > Memory: 123068k/123068k available, 8004k reserved, 0K highmem > Virtual kernel memory layout: > vector : 0x - 0x1000 ( 4 kB) > fixmap : 0xfff0 - 0xfffe ( 896 kB) > DMA : 0xffc0 - 0xffe0 ( 2 MB) > vmalloc : 0xc880 - 0xf800 ( 760 MB) > lowmem : 0xc000 - 0xc800 ( 128 MB) > modules : 0xbf00 - 0xc000 ( 16 MB) > .init : 0xc0008000 - 0xc0034000 ( 176 kB) > .text : 0xc0034000 - 0xc046c000 (4320 kB) > .data : 0xc046c000 - 0xc04a2000 ( 216 kB) > Preemptable hierarchical RCU implementation. > RCU-based detection of stalled CPUs is disabled. > Verbose stalled-CPUs detection is disabled. > NR_IRQS:402 > omap_hwmod: l3_main: registering You've manually done a '#define DEBUG' in omap_hwmod.c. This does not work well with UART hwmods, especially when using a UART console and using DEBUG_LL + earlyprintk. [...] > omap_hwmod: uart2: idling > omap_hwmod: uart2: disabling clocks > omap_device: omap-hsuart: activating > omap_hwmod: uart2: enabling > omap_hwmod: uart2: enabling clocks > omap_device: omap-hsuart: pm_lat 0: activate: elapsed time 0 nsec > omap_device: omap-hsuart: deactivating > omap_hwmod: uart2: idling > omap_hwmod: uart2: disabling clocks > omap_device: omap-hsuart: pm_lat 0: deactivate: elapsed time 0 nsec > omap_device: omap-hsuart: activating > omap_hwmod: uart2: enabling > omap_hwmod: uart2: enabling clocks > omap_device: omap-hsuart: pm_lat 0: activate: elapsed time 0 nsec > omap_device: omap-hsuart: building with 1 hwmods > omap_device: omap-hsuart: counted 4 total resources across 1 hwmods > omap_device: omap-hsuart: registering > Registering platform device 'omap-hsuart.2'. Parent at omap > device: 'omap-hsuart.2': device_add > bus: 'platform': add device omap-hsuart.2 > PM: Adding info for platform:omap-hsuart.2 > omap_hwmod: uart3: idling > omap_hwmod: uart3: disabling clocks Remember UART3 is your serial console. Basically, what is happening is that the hwmod is trying to print debug messages for all hwmod changes. As soon as UART3 is disabled, the printing will fail since that is your console, so as soon as uart3 clocks are disabled, there is a fault when the polling-mode serial driver (used for earlyprintk) tries to access the UART, and you hang. 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: beagle hangs in uart3 disabling clocks
2010/10/4 Govindraj : > I tried now on zoom3 with uart3[ttyO2] as console > > It boots up fine for me > > Logs: > > http://pastebin.com/sXR5nYcD > > I am using omap2plus_defconfig and lo-master > > commit 0882b1455797b0a104978000a622c3f2412e7cf5 > Author: Tony Lindgren > Date: Fri Oct 1 17:23:48 2010 -0700 > > omap: READ CAREFULLY: Fix build after merging in hwmod support for testing Seems you are trying the master branch of Tony's linux-omap-2.6 tree, could you try the pm branch of the tree? thanks, -- Lei Ming -- 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: beagle hangs in uart3 disabling clocks
2010/10/4 Premi, Sanjeev : > >> -Original Message- >> From: linux-omap-ow...@vger.kernel.org >> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Ming Lei >> Sent: Sunday, October 03, 2010 2:34 PM >> To: Kevin Hilman; linux-omap@vger.kernel.org >> Subject: beagle hangs in uart3 disabling clocks >> >> Hi, >> >> I just tested pm branch of tony's linux-omap-2.6 tree, and found my >> beagle will hang in uart3 disabling clocks, follows the log info: >> >> > [snip]..[snip] > >> >> Texas Instruments X-Loader 1.41 >> Starting OS Bootloader... >> >> >> U-Boot 1.3.3 (Jul 10 2008 - 16:33:09) >> >> OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz >> OMAP3 Beagle Board + LPDDR/NAND >> DRAM: 128 MB >> NAND: > > Lei, > > Couldn't help noticing the version information for x-loader and > u-boot. Both seem to be quite old... > > Could you try update both? May be, there is a dependency... No difference even update x-load and u-boot with those in the link below: http://code.google.com/p/beagleboard/wiki/BeagleboardRevC3Validation thanks, -- Lei Ming -- 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: beagle hangs in uart3 disabling clocks
I tried now on zoom3 with uart3[ttyO2] as console It boots up fine for me Logs: http://pastebin.com/sXR5nYcD I am using omap2plus_defconfig and lo-master commit 0882b1455797b0a104978000a622c3f2412e7cf5 Author: Tony Lindgren Date: Fri Oct 1 17:23:48 2010 -0700 omap: READ CAREFULLY: Fix build after merging in hwmod support for testing --- Regards, Govindraj.R On Mon, Oct 4, 2010 at 5:47 PM, Pramod wrote: > Hi Sanjeev, >>> >>> I just tested pm branch of tony's linux-omap-2.6 tree, and found my >>> beagle will hang in uart3 disabling clocks, follows the log info: >>> >>> >> [snip]..[snip] >> >>> >>> Texas Instruments X-Loader 1.41 >>> Starting OS Bootloader... >>> >>> >>> U-Boot 1.3.3 (Jul 10 2008 - 16:33:09) >>> >>> OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz >>> OMAP3 Beagle Board + LPDDR/NAND >>> DRAM: 128 MB >>> NAND: >> >> Lei, >> >> Couldn't help noticing the version information for x-loader and >> u-boot. Both seem to be quite old... >> >> Could you try update both? May be, there is a dependency... >> > I am seeing the same issue with console on UART3 on zoom3 board. The > bootloaders are older. Can you please share a link to latest bootloader > which will have zoom3 support. > > I am using L25_INC3.x android kernel. The board hangs as soon as it boots > the kernel. Enabling the logs shows us that the hang occurs when UART3 > clocks are being disabled in omap_hwmod.c as mentioned by Lei Ming. Has > anyone observed this issue on any of omap boards? > >> ~sanjeev >> >>> > -- > 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 > -- 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: beagle hangs in uart3 disabling clocks
Hi Sanjeev, I just tested pm branch of tony's linux-omap-2.6 tree, and found my beagle will hang in uart3 disabling clocks, follows the log info: [snip]..[snip] Texas Instruments X-Loader 1.41 Starting OS Bootloader... U-Boot 1.3.3 (Jul 10 2008 - 16:33:09) OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz OMAP3 Beagle Board + LPDDR/NAND DRAM: 128 MB NAND: Lei, Couldn't help noticing the version information for x-loader and u-boot. Both seem to be quite old... Could you try update both? May be, there is a dependency... I am seeing the same issue with console on UART3 on zoom3 board. The bootloaders are older. Can you please share a link to latest bootloader which will have zoom3 support. I am using L25_INC3.x android kernel. The board hangs as soon as it boots the kernel. Enabling the logs shows us that the hang occurs when UART3 clocks are being disabled in omap_hwmod.c as mentioned by Lei Ming. Has anyone observed this issue on any of omap boards? ~sanjeev -- 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: beagle hangs in uart3 disabling clocks
> -Original Message- > From: linux-omap-ow...@vger.kernel.org > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Ming Lei > Sent: Sunday, October 03, 2010 2:34 PM > To: Kevin Hilman; linux-omap@vger.kernel.org > Subject: beagle hangs in uart3 disabling clocks > > Hi, > > I just tested pm branch of tony's linux-omap-2.6 tree, and found my > beagle will hang in uart3 disabling clocks, follows the log info: > > [snip]..[snip] > > Texas Instruments X-Loader 1.41 > Starting OS Bootloader... > > > U-Boot 1.3.3 (Jul 10 2008 - 16:33:09) > > OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz > OMAP3 Beagle Board + LPDDR/NAND > DRAM: 128 MB > NAND: Lei, Couldn't help noticing the version information for x-loader and u-boot. Both seem to be quite old... Could you try update both? May be, there is a dependency... ~sanjeev > > > -- > Lei Ming > -- > 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 > -- 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
