On Thursday 11 July 2013 11:54 AM, Tony Lindgren wrote: > * Rajendra Nayak <rnayak@xxxxxx> [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 > -- 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