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 0x49020000 (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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
