Re: [PATCH v8 17/20] OMAP2+: UART: Use custom activate func for console uart.

2011-11-21 Thread Govindraj
On Sat, Nov 19, 2011 at 2:54 AM, Kevin Hilman khil...@ti.com wrote:
 Govindraj.R govindraj.r...@ti.com writes:

 Omap-uart can be used as console uart to print early boot
 messages using earlyprintk so for console uart prevent
 hwmod reset or idling during bootup.

 Identify the console_uart set the id and use the custom
 pm_latency ops for console uart for the first time
 to idle console uart left enabled from bootup and then enable
 them back and reset pm_latency ops to default ops.

 Thanks to Kevin Hilman khil...@ti.com for suggesting
 this approach.

 You're welcome, but Rajendra's solution is much better. ;)

Agree.


 Can you updated your branch without these custom hooks and using
 Rajendra's INIT_NO_IDLE change to the hwmod core.


Yes done, rebased on 3.2-rc2 and created a new branch [1].

Removed custom activate function usage and used Rajendra's hwmod patch[2]

--
Thanks,
Govindraj.R

[1]:
git://gitorious.org/runtime_3-0/runtime_3-0.git
3.2-rc1_uart_runtime

[2]:
http://permalink.gmane.org/gmane.linux.ports.arm.omap/66974
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v8 17/20] OMAP2+: UART: Use custom activate func for console uart.

2011-11-21 Thread Govindraj
On Mon, Nov 21, 2011 at 7:17 PM, Govindraj govindraj...@gmail.com wrote:
 On Sat, Nov 19, 2011 at 2:54 AM, Kevin Hilman khil...@ti.com wrote:
 Govindraj.R govindraj.r...@ti.com writes:

 Omap-uart can be used as console uart to print early boot
 messages using earlyprintk so for console uart prevent
 hwmod reset or idling during bootup.

 Identify the console_uart set the id and use the custom
 pm_latency ops for console uart for the first time
 to idle console uart left enabled from bootup and then enable
 them back and reset pm_latency ops to default ops.

 Thanks to Kevin Hilman khil...@ti.com for suggesting
 this approach.

 You're welcome, but Rajendra's solution is much better. ;)

 Agree.


 Can you updated your branch without these custom hooks and using
 Rajendra's INIT_NO_IDLE change to the hwmod core.


 Yes done, rebased on 3.2-rc2 and created a new branch [1].

 Removed custom activate function usage and used Rajendra's hwmod patch[2]

 --
 Thanks,
 Govindraj.R

 [1]:
 git://gitorious.org/runtime_3-0/runtime_3-0.git
 3.2-rc1_uart_runtime
   ^

small correction new branch is
3.2-rc2_uart_runtime

--
Thanks,
Govindraj.R
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v8 17/20] OMAP2+: UART: Use custom activate func for console uart.

2011-11-18 Thread Kevin Hilman
Govindraj.R govindraj.r...@ti.com writes:

 Omap-uart can be used as console uart to print early boot
 messages using earlyprintk so for console uart prevent
 hwmod reset or idling during bootup.

 Identify the console_uart set the id and use the custom
 pm_latency ops for console uart for the first time
 to idle console uart left enabled from bootup and then enable
 them back and reset pm_latency ops to default ops.

 Thanks to Kevin Hilman khil...@ti.com for suggesting
 this approach.

You're welcome, but Rajendra's solution is much better. ;)

Can you updated your branch without these custom hooks and using
Rajendra's INIT_NO_IDLE change to the hwmod core.

Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v8 17/20] OMAP2+: UART: Use custom activate func for console uart.

2011-11-11 Thread Govindraj.R
Omap-uart can be used as console uart to print early boot
messages using earlyprintk so for console uart prevent
hwmod reset or idling during bootup.

Identify the console_uart set the id and use the custom
pm_latency ops for console uart for the first time
to idle console uart left enabled from bootup and then enable
them back and reset pm_latency ops to default ops.

Thanks to Kevin Hilman khil...@ti.com for suggesting
this approach.

Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
 arch/arm/mach-omap2/serial.c |   86 +
 1 files changed, 61 insertions(+), 25 deletions(-)

diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 4d65d00..631d72a 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -61,8 +61,10 @@ struct omap_uart_state {
struct platform_device *pdev;
 };
 
+static struct omap_device_pm_latency *default_uart_latency;
 static LIST_HEAD(uart_list);
 static u8 num_uarts;
+static u8 console_uart_id = -1;
 
 #define DEFAULT_RXDMA_POLLRATE 1   /* RX DMA polling rate (us) */
 #define DEFAULT_RXDMA_BUFSIZE  4096/* RX DMA buffer size */
@@ -78,6 +80,34 @@ static struct omap_uart_port_info omap_serial_default_info[] 
__initdata = {
},
 };
 
+static int console_uart_enable_hwmod(struct omap_device *od)
+{
+   console_lock();
+   /*
+* For early console we prevented hwmod reset and idle
+* So before we enable the uart clocks idle the console
+* uart clocks, then enable back the console uart hwmod.
+*/
+   omap_hwmod_idle(od-hwmods[0]);
+   omap_hwmod_enable(od-hwmods[0]);
+   console_unlock();
+
+   /*
+* Restore the default activate/deactivate funcs,
+* since now we have set the hwmod state machine right
+* with the idle/enable for console uart
+*/
+   od-pm_lats = default_uart_latency;
+
+   return 0;
+}
+
+static struct omap_device_pm_latency console_uart_latency[] = {
+   {
+   .activate_func   = console_uart_enable_hwmod,
+   },
+};
+
 #ifdef CONFIG_PM
 
 int omap_uart_can_sleep(void)
@@ -264,12 +294,20 @@ static void omap_serial_fill_default_pads(struct 
omap_board_data *bdata)
 static void omap_serial_fill_default_pads(struct omap_board_data *bdata) {}
 #endif
 
+char *cmdline_find_option(char *str)
+{
+   extern char *saved_command_line;
+
+   return strstr(saved_command_line, str);
+}
+
 static int __init omap_serial_early_init(void)
 {
do {
char oh_name[MAX_UART_HWMOD_NAME_LEN];
struct omap_hwmod *oh;
struct omap_uart_state *uart;
+   char uart_name[MAX_UART_HWMOD_NAME_LEN];
 
snprintf(oh_name, MAX_UART_HWMOD_NAME_LEN,
 uart%d, num_uarts + 1);
@@ -284,18 +322,23 @@ static int __init omap_serial_early_init(void)
uart-oh = oh;
uart-num = num_uarts++;
list_add_tail(uart-node, uart_list);
+   snprintf(uart_name, MAX_UART_HWMOD_NAME_LEN,
+   %s%d, OMAP_SERIAL_NAME, uart-num);
+
+   if (cmdline_find_option(uart_name)) {
+   console_uart_id = uart-num;
+   /*
+* omap-uart can be used for earlyprintk logs
+* So if omap-uart is used as console then prevent
+* uart reset and idle to get logs from omap-uart
+* until uart console driver is available to take
+* care for console messages.
+* Idling or resetting omap-uart while printing logs
+* early boot logs can stall the boot-up.
+*/
+   oh-flags |= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET;
+   }
 
-   /*
-* NOTE: omap_hwmod_setup*() has not yet been called,
-*   so no hwmod functions will work yet.
-*/
-
-   /*
-* During UART early init, device need to be probed
-* to determine SoC specific init before omap_device
-* is ready.  Therefore, don't allow idle here
-*/
-   uart-oh-flags |= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET;
} while (1);
 
return 0;
@@ -324,6 +367,7 @@ void __init omap_serial_init_port(struct omap_board_data 
*bdata,
u32 pdata_size = 0;
char *name;
struct omap_uart_port_info omap_up;
+   struct omap_device *od;
 
if (WARN_ON(!bdata))
return;
@@ -369,6 +413,12 @@ void __init omap_serial_init_port(struct omap_board_data 
*bdata,
WARN(IS_ERR(pdev), Could not build omap_device for %s: %s.\n,
 name, oh-name);
 
+   if (console_uart_id == bdata-id) {
+   od =