* 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),
> > 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
