Govindraj <govindraj.ti@xxxxxxxxx> writes: > On Fri, Jun 18, 2010 at 11:53 PM, Kevin Hilman > <khilman@xxxxxxxxxxxxxxxxxxx> wrote: >> Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> writes: >> >>> "Govindraj.R" <govindraj.raja@xxxxxx> writes: >>> >>>> Changes from v1: >>>> * Incorporated : OMAP clock: Add uart4_ick/fck definitions for 3630 >>>> * using omap_mux_request_signal to retreive padconf offset >>>> as per Tony's comments. >>>> http://marc.info/?l=linux-omap&m=127609369220618&w=2 >>>> This patch series as a dependecy on the patch >>>> for "omap_mux_request_signal" posted earlier >>>> https://patchwork.kernel.org/patch/105962/ >>>> * Clean up certain comments. >>>> http://www.mail-archive.com/linux-omap@xxxxxxxxxxxxxxx/msg30348.html >>>> >>>> Patch series is based on remotes/origin/pm-wip/uart >>>> branch from Kevin's PM tree. >>>> >>>> 1.) Add support for UART4 for 3630. >>>> 2.) Modify Serial hwmod to avoid hwmod lookup using name string. >>>> >>>> Govindraj.R (5): >>>> OMAP clock: Add uart4_ick/fck definitions for 3630 >>>> OMAP3: PRCM: Consider UART4 for 3630 chip in prcm_setup_regs >>>> OMAP3: serial: Fix uart4 handling for 3630 >>>> OMAP3: PM: Add prepare idle and resume idle call for uart4 >>>> Serial: Avoid using hwmod lookup using name string. >>> >>> Govindraj, >>> >>> Can you add this one to your series and test it on your boards? >>> >> >> Actually, my patch doesn't really work either, so it needs some more digging. >> >> Basically, there's a problem during static suspend on boards like Zoom3 >> that don't ever add/register any OMAP UARTs and just use the ones >> on the debug board. >> >> Somehow, we have to keep from adding UARTs to the uart_list unless >> they are actually registered to board files. > > for zoom boards we are not calling omap_serial_init from board files > > omap_serial_init ---> omap_serial_init_port which is the one that does > an list_add_tail > > So in my understanding basically the list will be empty for zoom boards. Well, it *should* be empty. > Or is it the omap_serial_early_init call which populates certain data for uart > causing the issue. Correct. Using your last series as the baseline (ending at Serial: Avoid using hwmod lookup using name string), the uart_list uart_list is still populated for every hwmod, but it hasn't been fully initialized since the board code hasn't called omap_serial_init() or _init_port() So, when the idle path calls into this code, it does strange things (for example omap_uart_enable_irqs() tries to request/free IRQ 0 since the IRQ has not bee initialized. > IMHO if we are not enabling OMAP-UARTs by default then we should also not call > omap_serial_early_init Well, we need to have a list of available UART hwmods so that if somone eventually enables a UART, we are ready. > But I dont see any good reason why are we disabling omap-uarts for zoom boards. > Shouldn't we keep it enabled by default? No, they should only be enabled if used. That will speed up the idle path by not managing UARTS. > Currently OMAP-UARTs are getting disabled only with zoom defconfigs. A similar problem exists on Rover where only a single UART is being enabled in the board file instead of all. Kevin -- 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
