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

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

[Govindraj.R]

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.

 arch/arm/mach-omap2/clock3xxx_data.c   |   22 ++++++
 arch/arm/mach-omap2/cm-regbits-34xx.h  |    2 +
 arch/arm/mach-omap2/pm34xx.c           |   17 ++++-
 arch/arm/mach-omap2/prcm-common.h      |    2 +
 arch/arm/mach-omap2/prm-regbits-34xx.h |    1 +
 arch/arm/mach-omap2/serial.c           |  114 +++++++++++++++++++-------------
 6 files changed, 111 insertions(+), 47 deletions(-)

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

[Kevin Hilman]

"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?

Kevin

>From f63426a68cd4048e6a09e5aed2b101b7cb2ef141 Mon Sep 17 00:00:00 2001
From: Kevin Hilman <khilman@deeprootsystems.com>
Date: Thu, 17 Jun 2010 16:59:10 -0700
Subject: [PATCH] OMAP: UART: separate list of detected UARTs from registered UARTs

Use separate lists to track detected UARTs (available hwmods) and
registered UARTs (ones activated via board code.)

The hwmod_list is populated as soon as the UART hwmods are detected,
but the uart_list is only populated when a UART is registered via
board code.  This ensures that the various PM operaions are done only
on UARTs registered via board code.

This is particularily useful for boards where no OMAP UARTs are
registered (Zoom3).  Since all the PM operations only need to be done
on registered UARTs, when none are registered, these functions do
nothing as the list iteratates on an empty list.

Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
---
 arch/arm/mach-omap2/serial.c |   10 +++++++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 2ab8f25..37cc28e 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -98,7 +98,9 @@ struct omap_uart_state {
 #endif
 };
 
-static LIST_HEAD(uart_list);
+static LIST_HEAD(hwmod_list); /* list of detected UART hwmods */
+static LIST_HEAD(uart_list);  /* list of initialized UARTs */
+
 static u8 num_uarts;
 
 static struct omap_device_pm_latency omap_uart_latency[] = {
@@ -612,7 +614,7 @@ static int omap_serial_port_init(struct omap_hwmod *oh, void *user)
 
 	uart->oh = oh;
 	uart->num = i++;
-	list_add_tail(&uart->node, &uart_list);
+	list_add_tail(&uart->node, &hwmod_list);
 	num_uarts++;
 
 	/*
@@ -676,7 +678,7 @@ void __init omap_serial_init_port(int port)
 	if (WARN_ON(port >= num_uarts))
 		return;
 
-	list_for_each_entry(uart, &uart_list, node)
+	list_for_each_entry(uart, &hwmod_list, node)
 		if (port == uart->num)
 			break;
 
@@ -789,6 +791,8 @@ void __init omap_serial_init_port(int port)
 		device_init_wakeup(&od->pdev.dev, true);
 		DEV_CREATE_FILE(&od->pdev.dev, &dev_attr_sleep_timeout);
 	}
+
+	list_add_tail(&uart->node, &uart_list);
 }
 
 /**
-- 
1.7.0.2

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

[Kevin Hilman]

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.

Kevin

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

[Govindraj]

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.

Or is it the omap_serial_early_init call which populates certain data for uart
causing the issue.

IMHO if we are not enabling OMAP-UARTs by default then we should also not call
omap_serial_early_init

But I dont see any good reason why are we disabling omap-uarts for zoom boards.
Shouldn't we keep it enabled by default?

Currently OMAP-UARTs are getting disabled only with zoom defconfigs.

Regards,
Govindraj.R


>
> 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
>



-- 
---
Regards,
Govindraj.R
--
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

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

[Kevin Hilman]

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