Re: beagle hangs in uart3 disabling clocks

[Kevin Hilman <khilman@deeprootsystems.com>]

Paul Walmsley <paul@pwsan.com> 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