Paul Walmsley <paul@xxxxxxxxx> 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 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. 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
