All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@ti.com>
To: "Govindraj.R" <govindraj.raja@ti.com>
Cc: Tony Lindgren <tony@atomide.com>, Rajendra Nayak <rnayak@ti.com>,
	Partha Basak <p-basak2@ti.com>,
	Santosh Shilimkar <santosh.shilimkar@ti.com>,
	linux-serial@vger.kernel.org,
	Vishwanath Sripathy <vishwanath.bs@ti.com>,
	linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v6 10/16] OMAP2+: UART: Modify omap_uart_can_sleep function
Date: Tue, 11 Oct 2011 11:24:46 -0700	[thread overview]
Message-ID: <87vcrv2xox.fsf@ti.com> (raw)
In-Reply-To: <1317380561-661-1-git-send-email-govindraj.raja@ti.com> (Govindraj R.'s message of "Fri, 30 Sep 2011 16:32:35 +0530")

"Govindraj.R" <govindraj.raja@ti.com> writes:

> Modify the omap_uart_can_sleep function to check uart is active
> or not to be used by pm code to enter low power states.

Doesn't the driver now control when the UART clocks are gated (using
runtime PM autosuspend)?

IMO, this check should be completely removed and the driver should
be managing this with the autosuspend timeout.

> Removing this check can cause console response little sluggish.

Sluggish in what way?

If the driver is runtime suspended, it should only be sluggish for the
first character.  After that, the autosuspend timeout should prevent it
from feeling sluggish.

> However no characters will be lost until uart clocks are gated
> and woken up using rx-pad. UART interface clocks can be auto gated
> this can make response on uart slower. This behaviour was observed
> only on some of OMAP3 boards(beagleboard xm rev c).
>
> Reported-by: Tero Kristo <t-kristo@ti.com>
> Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
> ---
>  arch/arm/mach-omap2/serial.c |   21 +++++++++------------
>  1 files changed, 9 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> index 6725caf..ccf3550 100644
> --- a/arch/arm/mach-omap2/serial.c
> +++ b/arch/arm/mach-omap2/serial.c
> @@ -156,23 +156,20 @@ static void omap_uart_smart_idle_enable(struct omap_uart_state *uart,
>  
>  int omap_uart_can_sleep(void)
>  {
> -	struct omap_uart_state *uart;
> -	int can_sleep = 1;
> -
> -	list_for_each_entry(uart, &uart_list, node) {
> -		if (!uart->clocked)
> -			continue;
> +	struct omap_hwmod *oh;
> +	u8 i, ret = true;
>  
> -		if (!uart->can_sleep) {
> -			can_sleep = 0;
> +	for (i = 0; i < num_uarts; i++) {
> +		oh = omap_uart_hwmod_lookup(i);

This is a heavy operation to add for *every* entry into idle.

> +		if (!oh)
>  			continue;
> -		}
>  
> -		/* This UART can now safely sleep. */
> -		omap_uart_allow_sleep(uart);
> +		if (oh->od && oh->od->pdev &&
> +				!pm_runtime_suspended(&oh->od->pdev->dev))
> +			return false;
>  	}
>  
> -	return can_sleep;
> +	return ret;
>  }
>  
>  #ifdef CONFIG_OMAP_MUX

Kevin

WARNING: multiple messages have this Message-ID (diff)
From: khilman@ti.com (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 10/16] OMAP2+: UART: Modify omap_uart_can_sleep function
Date: Tue, 11 Oct 2011 11:24:46 -0700	[thread overview]
Message-ID: <87vcrv2xox.fsf@ti.com> (raw)
In-Reply-To: <1317380561-661-1-git-send-email-govindraj.raja@ti.com> (Govindraj R.'s message of "Fri, 30 Sep 2011 16:32:35 +0530")

"Govindraj.R" <govindraj.raja@ti.com> writes:

> Modify the omap_uart_can_sleep function to check uart is active
> or not to be used by pm code to enter low power states.

Doesn't the driver now control when the UART clocks are gated (using
runtime PM autosuspend)?

IMO, this check should be completely removed and the driver should
be managing this with the autosuspend timeout.

> Removing this check can cause console response little sluggish.

Sluggish in what way?

If the driver is runtime suspended, it should only be sluggish for the
first character.  After that, the autosuspend timeout should prevent it
from feeling sluggish.

> However no characters will be lost until uart clocks are gated
> and woken up using rx-pad. UART interface clocks can be auto gated
> this can make response on uart slower. This behaviour was observed
> only on some of OMAP3 boards(beagleboard xm rev c).
>
> Reported-by: Tero Kristo <t-kristo@ti.com>
> Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
> ---
>  arch/arm/mach-omap2/serial.c |   21 +++++++++------------
>  1 files changed, 9 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> index 6725caf..ccf3550 100644
> --- a/arch/arm/mach-omap2/serial.c
> +++ b/arch/arm/mach-omap2/serial.c
> @@ -156,23 +156,20 @@ static void omap_uart_smart_idle_enable(struct omap_uart_state *uart,
>  
>  int omap_uart_can_sleep(void)
>  {
> -	struct omap_uart_state *uart;
> -	int can_sleep = 1;
> -
> -	list_for_each_entry(uart, &uart_list, node) {
> -		if (!uart->clocked)
> -			continue;
> +	struct omap_hwmod *oh;
> +	u8 i, ret = true;
>  
> -		if (!uart->can_sleep) {
> -			can_sleep = 0;
> +	for (i = 0; i < num_uarts; i++) {
> +		oh = omap_uart_hwmod_lookup(i);

This is a heavy operation to add for *every* entry into idle.

> +		if (!oh)
>  			continue;
> -		}
>  
> -		/* This UART can now safely sleep. */
> -		omap_uart_allow_sleep(uart);
> +		if (oh->od && oh->od->pdev &&
> +				!pm_runtime_suspended(&oh->od->pdev->dev))
> +			return false;
>  	}
>  
> -	return can_sleep;
> +	return ret;
>  }
>  
>  #ifdef CONFIG_OMAP_MUX

Kevin

  parent reply	other threads:[~2011-10-11 18:24 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-30 11:02 [PATCH v6 10/16] OMAP2+: UART: Modify omap_uart_can_sleep function Govindraj.R
2011-09-30 11:02 ` Govindraj.R
2011-09-30 11:02 ` [PATCH v6 11/16] OMAP2+: UART: Move errata handling from serial.c to omap-serial Govindraj.R
2011-09-30 11:02   ` Govindraj.R
2011-10-11 21:01   ` Kevin Hilman
2011-10-11 21:01     ` Kevin Hilman
2011-10-12 10:43     ` Govindraj
2011-10-12 10:43       ` Govindraj
2011-09-30 11:02 ` [PATCH v6 12/16] OMAP2+: UART: Allow UART parameters to be configured from board file Govindraj.R
2011-09-30 11:02   ` Govindraj.R
2011-10-11 18:53   ` Kevin Hilman
2011-10-11 18:53     ` Kevin Hilman
2011-10-12 10:44     ` Govindraj
2011-10-12 10:44       ` Govindraj
2011-09-30 11:02 ` [PATCH v6 13/16] OMAP2+: UART: Make the RX_TIMEOUT for DMA configurable for each UART Govindraj.R
2011-09-30 11:02   ` Govindraj.R
2011-09-30 11:02 ` [PATCH v6 14/16] OMAP2+: UART: Take console_lock in suspend path if not taken Govindraj.R
2011-09-30 11:02   ` Govindraj.R
2011-10-11 19:01   ` Kevin Hilman
2011-10-11 19:01     ` Kevin Hilman
2011-10-12 11:23     ` Govindraj
2011-10-12 11:23       ` Govindraj
2011-10-12 23:47       ` Kevin Hilman
2011-10-12 23:47         ` Kevin Hilman
2011-10-13  1:11         ` Govindraj
2011-10-13  1:11           ` Govindraj
2011-09-30 11:02 ` [PATCH v6 15/16] OMAP2+: UART: Enable back uart clocks with runtime API for early console Govindraj.R
2011-09-30 11:02   ` Govindraj.R
2011-10-11 21:06   ` Kevin Hilman
2011-10-11 21:06     ` Kevin Hilman
2011-10-12 14:04     ` Govindraj
2011-10-12 14:04       ` Govindraj
2011-10-13  0:00       ` Kevin Hilman
2011-10-13  0:00         ` Kevin Hilman
2011-10-13  1:22         ` Govindraj
2011-10-13  1:22           ` Govindraj
2011-10-13 21:01           ` Kevin Hilman
2011-10-13 21:01             ` Kevin Hilman
2011-10-14 14:18             ` Govindraj
2011-10-14 14:18               ` Govindraj
2011-10-14 17:12               ` Kevin Hilman
2011-10-14 17:12                 ` Kevin Hilman
2011-09-30 11:02 ` [PATCH v6 16/16] OMAP2+: UART: Do not gate uart clocks if used for debug_prints Govindraj.R
2011-09-30 11:02   ` Govindraj.R
2011-10-11 18:24 ` Kevin Hilman [this message]
2011-10-11 18:24   ` [PATCH v6 10/16] OMAP2+: UART: Modify omap_uart_can_sleep function Kevin Hilman
2011-10-12 13:38   ` Govindraj
2011-10-12 13:38     ` Govindraj
2011-10-12 19:41     ` Kevin Hilman
2011-10-12 19:41       ` Kevin Hilman
2011-10-13  1:09       ` Govindraj
2011-10-13  1:09         ` Govindraj
2011-10-13  6:59         ` Jean Pihet
2011-10-13  6:59           ` Jean Pihet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87vcrv2xox.fsf@ti.com \
    --to=khilman@ti.com \
    --cc=govindraj.raja@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=p-basak2@ti.com \
    --cc=rnayak@ti.com \
    --cc=santosh.shilimkar@ti.com \
    --cc=tony@atomide.com \
    --cc=vishwanath.bs@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.