On Friday 12 July 2013 02:48 PM, Tony Lindgren wrote:
> * Rajendra Nayak <rnayak@xxxxxx> [130712 02:06]:
>> On Friday 12 July 2013 01:33 PM, Tony Lindgren wrote:
>>>
>>> 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.
>
> Yes we can do it that way. How about add a common macro for it if
> it's always the same? Then the .flags line would be just:
>
> #define HWMOD_OMAP_UART_FLAGS(soc, port)
> ...
>
> .flags = HWMOD_OMAP_UART_FLAGS(4, 3),
I started doing this and ended up with equal number of #ifdefs in the
header :( Was the intention of doing this to reduce the #ifdefs? in which
case maybe I am doing something wrong.
>
>>> 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.
>
> OK thanks good to hear it's limited to earlycon issues.
>
> 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
