Hi,
On Fri, Jul 29, 2011 at 08:43:49PM +0530, Govindraj wrote:
[giant snip]
Actually there is much more than this:
SNIP
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 180299e..221ffb9 100644
--- a/arch/arm/mach-omap2/clock.c
+++
Hi,
On Fri, Jul 29, 2011 at 08:43:49PM +0530, Govindraj wrote:
[giant snip]
Actually there is much more than this:
SNIP
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 180299e..221ffb9 100644
--- a/arch/arm/mach-omap2/clock.c
+++
Hi,
(fix your mailer dude)
On Mon, Aug 01, 2011 at 03:26:52PM +0530, Raja, Govindraj wrote:
@@ -254,14 +255,14 @@ void omap2_clk_disable(struct clk *clk)
� � � � � � � return;
� � � }
- � � pr_debug(clock: %s: decrementing usecount\n, clk-name);
+// �
On Mon, Aug 1, 2011 at 3:32 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
(fix your mailer dude)
Sorry some settings got screwed up with my mailer
On Mon, Aug 01, 2011 at 03:26:52PM +0530, Raja, Govindraj wrote:
[..]
this hunk is unnecessary. Clocks are always on when they are called.
Hi,
On Thu, Jul 28, 2011 at 02:59:55PM +0530, Govindraj.R wrote:
Proposal:
1. For the UART, follow the current approach of locking the console in
Idle/Suspend path before cutting the clock but using
pm_runtime_putsync.
That is, continue using the
On Fri, Jul 29, 2011 at 3:25 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
Thanks for replying.
On Thu, Jul 28, 2011 at 02:59:55PM +0530, Govindraj.R wrote:
Proposal:
1. For the UART, follow the current approach of locking the console in
Idle/Suspend path before cutting
Hi,
On Fri, Jul 29, 2011 at 04:54:44PM +0530, Govindraj wrote:
On Fri, Jul 29, 2011 at 3:25 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
Thanks for replying.
On Thu, Jul 28, 2011 at 02:59:55PM +0530, Govindraj.R wrote:
Proposal:
1. For the UART, follow the current
On Fri, Jul 29, 2011 at 5:07 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Fri, Jul 29, 2011 at 04:54:44PM +0530, Govindraj wrote:
On Fri, Jul 29, 2011 at 3:25 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
Thanks for replying.
On Thu, Jul 28, 2011 at 02:59:55PM +0530, Govindraj.R wrote:
Hi,
On Fri, Jul 29, 2011 at 05:29:12PM +0530, Govindraj wrote:
Yes fine, But there are scenarios even before first runtime_suspend happens,
ex: uart_port_configure - get_sync - pm_generic_runtime_resume
(omap_device_enable in this case) debug printk - console_write - get_sync.
there are
On Fri, Jul 29, 2011 at 5:49 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Fri, Jul 29, 2011 at 05:29:12PM +0530, Govindraj wrote:
Yes fine, But there are scenarios even before first runtime_suspend happens,
ex: uart_port_configure - get_sync - pm_generic_runtime_resume
(omap_device_enable in
Hi,
On Fri, Jul 29, 2011 at 06:28:32PM +0530, Govindraj wrote:
On Fri, Jul 29, 2011 at 5:49 PM, Felipe Balbi ba...@ti.com wrote:
On Fri, Jul 29, 2011 at 05:29:12PM +0530, Govindraj wrote:
Yes fine, But there are scenarios even before first runtime_suspend
happens,
ex:
On Fri, Jul 29, 2011 at 7:32 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Fri, Jul 29, 2011 at 06:28:32PM +0530, Govindraj wrote:
On Fri, Jul 29, 2011 at 5:49 PM, Felipe Balbi ba...@ti.com wrote:
On Fri, Jul 29, 2011 at 05:29:12PM +0530, Govindraj wrote:
Yes fine, But there are scenarios
To handle uart clocks within uart driver we need the *semantics of clock enable
API should not internally trigger any UART PORT operation* even before
completing clock_enable.
Ex: while configuring baud rate we may use runtime api's to enable uart port.
get_sync - printk - call console uart to
13 matches
Mail list logo
