Re: [pm-wip/uart][PATCH 0/5 v2] Serial HWMOD updation and uart4 support for 3630

[Kevin Hilman <khilman@deeprootsystems.com>]

Govindraj <govindraj.ti@gmail.com> writes:

> On Fri, Jun 18, 2010 at 11:53 PM, Kevin Hilman
> <khilman@deeprootsystems.com> wrote:
>> Kevin Hilman <khilman@deeprootsystems.com> writes:
>>
>>> "Govindraj.R" <govindraj.raja@ti.com> 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@vger.kernel.org/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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html