Re: Boot hang regression 3.10.0-rc4 -> 3.10.0

[Rajendra Nayak <rnayak@ti.com>]

On Thursday 11 July 2013 11:54 AM, Tony Lindgren wrote:
> * Rajendra Nayak <rnayak@ti.com> [130710 23:25]:
>> On Wednesday 10 July 2013 07:56 PM, Tony Lindgren wrote:
>>>
>>> Felipe is right, looks like all we need is to check if context is
>>> initialized or not. So no need for mach-omap2/serial.c or hwmod tinkering.
>>>
>>> After that having DEBUG_LL and cmdline with earlyprintk console=ttyO..
>>> works for me.
>>
>> On what platform? Like I said there are flags set statically in hmwod
>> data for OMAP4 and OMAP5, which make it work without any hwmod tinkering
>> in mach-omap2/serial.c. But it won't work for am33xx.
> 
> For me omap4 sdp hangs during ttyO2 probe if earlyprintk is enabled for
> that port and console is enabled for that port. That's because we attempt
> to restore uninitialized context.

Right, so thats the Issue 2: that you see on the omap4 sdp. You never hit
Issue 1: despite not doing any hwmod tinkering because of the static flags
set for uart3 in hwmod data.

> 
> It's possible that we have more than one bug here though.

Right, we have 2 issues like I said earlier. Issue 1: is when hwmod _setup()
does a console UART reset (Not seen if the flags are set either runtime or
statically)

Issue 2: Is when omap serial does a runtime resume before set_termios().

>  
>>> @@ -1523,6 +1524,8 @@ static int serial_omap_probe(struct platform_device *pdev)
>>>  
>>>  	pm_runtime_mark_last_busy(up->dev);
>>>  	pm_runtime_put_autosuspend(up->dev);
>>> +	up->initialized = true;
>>
>> This won't help as the context save for serial happens as part of set_termios() and not
>> when the device is probed.
> 
> The issue is that in serial probe we currently restore NULL context to
> the port which kills earlyprintk output until set_termios() is called.
> 
> But as discussed, there are better ways for fixing this issue.
> 
> Regards,
> 
> Tony
>