On Friday 12 July 2013 01:33 PM, Tony Lindgren wrote:
> * Rajendra Nayak <rnayak@xxxxxx> [130712 00:38]:
>> On Friday 12 July 2013 12:50 PM, Tony Lindgren wrote:
>>> * Rajendra Nayak <rnayak@xxxxxx> [130711 03:59]:
>>>> This reverts commit 82702ea11ddfe0e43382e1fa5b66d807d8114916.
>>>>
>>>> The above commit stubbed out omap_serial_early_init() in case of
>>>> DT build thinking it was doing the serial port initializations.
>>>
>>> Well not really. It was done to cut dependency between device
>>> tree initialized drivers and pdata initialized drivers.
>>>
>>>> omap_serial_early_init() however does not do the serial port
>>>> inits (its instead done by omap_serial_init_port()) instead
>>>> it sets the HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags
>>>> for the console uart which causes hwmod to avoid doing a reset
>>>> followed by the idling of the console uart.
>>>>
>>>> This is still needed even in the DT case.
>>>
>>> This fix is going the wrong way.
>>>
>>> The console is working fine with DT based booting for me,
>>> except for the earlyprintk fix needed.
>>
>> It works on omap4 and omap5. It won't work on any
>> am33xx devices.
>
> OK. I assume the regular serial onsole works just fine, what does
> not work is the earlyprintk for am33xx?
Yes, thats right.
>
>>> And there should not be any need to parse cmdline for console
>>> as omap-serial.c sets it up and already knows about it.
>>>
>>> Care to state what exactly this attempts to fix and for which
>>> omaps? If this is only needed for am33xx, then why?
>>
>> Yes, this is needed only for am33xx because am33xx hwmod rightly
>> had the hwmod flags for NO_IDLE and NO_RESET removed and omap4
>> and omap5 wrongly still carry them around.
>
> OK.
>
>> Just try applying PATCH 2/2 of this series and it won't work on the
>> omap4 sdp anymore.
>
> OK, so that's only for earlyprintk then?
yes,
>
> If so, it seems the right fix is to set the NO_IDLE and NO_RESET
> flags based on ifdef CONFIG_DEBUG_OMAP4UART3 etc as that is selected
> in the Kconfig now.
ok makes sense. It seems like the static data in hwmod can be populated
based on these defines? something like
/* uart3 */
static struct omap_hwmod omap44xx_uart3_hwmod = {
.name = "uart3",
.class = &omap44xx_uart_hwmod_class,
.clkdm_name = "l4_per_clkdm",
#ifdef CONFIG_DEBUG_OMAP4UART3
.flags = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET |
HWMOD_SWSUP_SIDLE_ACT,
#else
.flags = HWMOD_SWSUP_SIDLE_ACT,
#endif
.main_clk = "func_48m_fclk",
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM_L4PER_UART3_CLKCTRL_OFFSET,
.context_offs = OMAP4_RM_L4PER_UART3_CONTEXT_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
};
And same way for others? That way the cmdline parsing can be done away
with even for the non-DT case.
>
> The current code in mach-omap2/serial.c is wrong, and is a hack
> needed for the pdata based booting. What's broken is that
> omap_serial_early_init() parses the cmdline for console, which
> itself is pretty nasty, and it won't work the right way as
> there's nothing stopping from having the earlycon in a different
> UART from the serial console. So we just want to get rid of the
> whole mach-omap2/serial.c once we're all DT.
>
> So to summarize, we have two bugs:
>
> 1. Omap hwmod code can reset UART while earlycon may be using
> it. The fix to this is to use NO_IDLE and NO_RESET flags in
> the hwmod code if CONFIG_DEBUG_OMAPxUARTy is specified.
>
> 2. A bug in drivers/tty/serial/omap-serial.c where the
> missing context loss count can cause NULL context to be
> initialized during driver probe causing port to hang for
> earlycon. The fix for that is what Felipe has suggested or
> fix it in the driver by removing the context loss count usage
> and detect the need for context restore based on the UART
> state.
>
> Or am I still missing something?
No, thats pretty much the 2 issues we have.
regards,
Rajendra
>
> 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
