From: Sourav Poddar <sourav.poddar@ti.com>
To: Kevin Hilman <khilman@linaro.org>
Cc: gregkh@linuxfoundation.org, tony@atomide.com,
rmk+kernel@arm.linux.org.uk, linux-serial@vger.kernel.org,
linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/6] arm: mach-omap2: remove "OMAP_DEVICE_NO_IDLE_ON_SUSPEND" check
Date: Fri, 19 Apr 2013 19:25:24 +0530 [thread overview]
Message-ID: <51714CCC.9090800@ti.com> (raw)
In-Reply-To: <874nf31opn.fsf@linaro.org>
Hi Kevin,
On Friday 19 April 2013 03:33 AM, Kevin Hilman wrote:
> Sourav Poddar<sourav.poddar@ti.com> writes:
>
>> On Thursday 18 April 2013 11:35 PM, Kevin Hilman wrote:
>>> Sourav Poddar<sourav.poddar@ti.com> writes:
>>>
>>>> Remove the "OMAP_DEVICE_NO_IDLE_ON_SUSPEND" check, since UART was the only one making
>>>> use of it. Now serial core/driver takes care of the case when "no_console_suspend"
>>>> is used in the bootargs and you need to keep the clock enable for console even while suspend.
>>>>
>>>> Signed-off-by: Sourav Poddar<sourav.poddar@ti.com>
>>> NAK. This patch will break many things...
>>>
>>>> ---
>>>> arch/arm/mach-omap2/omap_device.c | 7 +------
>>>> 1 files changed, 1 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
>>>> index 381be7a..d6dce8f 100644
>>>> --- a/arch/arm/mach-omap2/omap_device.c
>>>> +++ b/arch/arm/mach-omap2/omap_device.c
>>>> @@ -620,11 +620,8 @@ static int _od_suspend_noirq(struct device *dev)
>>>> ret = pm_generic_suspend_noirq(dev);
>>>>
>>>> if (!ret&& !pm_runtime_status_suspended(dev)) {
>>>> - if (pm_generic_runtime_suspend(dev) == 0) {
>>>> - if (!(od->flags& OMAP_DEVICE_NO_IDLE_ON_SUSPEND))
>>>> - omap_device_idle(pdev);
>>> Why did you remove the omap_device_idle() here?
>> This patch is used along with patch3 to get rid of the issue. I posted
>> them as a
>> seperate patch beacuse of the subject line as one goes under drivers/*
>> and the other
>> arm/mach-omap2/*..
>>
>> This check was only valid for UART, and if od->flags is set to the
>> "OMAP_DEVICE_NO_IDLE_ON_SUSPEND" flag, then UART will not be idled.
> correct, but *every other device* would be idled (if not already idle.)
>
>> But now, we no longer depend on od->flag value to prevent idling of
>> our console UART as the prepare/complete apis will take care of them.
> Right, so removing the check on od->flags is fine, but what I asked
> about is why you removed the omap_device_idle() call.
>
> Remember that this code is called for *every* omap_device during
> suspend, not just UART.
>
> What you did stops *every* device from being idled during suspend.
>
> You didn't read my whole message. Specifically this part:
>
Yes, got your point. omap_device_idle should not be called only
for console uart.
Just did a quick testing by including the following hunk on top of my
patch series..
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index c226946..7480e87 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -617,8 +617,10 @@ static int _od_suspend_noirq(struct device *dev)
ret = pm_generic_suspend_noirq(dev);
if (!ret && !pm_runtime_status_suspended(dev)) {
- if (pm_generic_runtime_suspend(dev) == 0)
+ if (pm_generic_runtime_suspend(dev) == 0) {
+ omap_device_idle(pdev);
od->flags |= OMAP_DEVICE_SUSPENDED;
+ }
}
return ret;
@@ -631,6 +633,7 @@ static int _od_resume_noirq(struct device *dev)
if ((od->flags & OMAP_DEVICE_SUSPENDED) &&
!pm_runtime_status_suspended(dev)) {
+ omap_device_enable(pdev);
od->flags &= ~OMAP_DEVICE_SUSPENDED;
pm_generic_runtime_resume(dev);
}
And found the wakeup from UART is no more functional.
So, the omap_device_idle gets called for console UART also, thereby
preventing the "no_idle_on_suspend" theory.
Hence, merely putting prepare/complete callback the way I did is not
helping.
We need to delete omap_device_idle also, which I agree is not correct.
So, we need a way to bypass this "omap_device_idle"
call for console UART. ?
What my understanding was that after modifying serial driver,
bypass the entire hunk[1] for console UART?
>>> Note that the check is for when the flag is *not* set, so this patch
>>> changes behavior for all the drivers that do not use
>>> _NO_IDLE_ON_SUSPEND. I think that's the opposite of what you intended.
> Kevin
WARNING: multiple messages have this Message-ID (diff)
From: Sourav Poddar <sourav.poddar@ti.com>
To: Kevin Hilman <khilman@linaro.org>
Cc: <gregkh@linuxfoundation.org>, <tony@atomide.com>,
<rmk+kernel@arm.linux.org.uk>, <linux-serial@vger.kernel.org>,
<linux-omap@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 4/6] arm: mach-omap2: remove "OMAP_DEVICE_NO_IDLE_ON_SUSPEND" check
Date: Fri, 19 Apr 2013 19:25:24 +0530 [thread overview]
Message-ID: <51714CCC.9090800@ti.com> (raw)
In-Reply-To: <874nf31opn.fsf@linaro.org>
Hi Kevin,
On Friday 19 April 2013 03:33 AM, Kevin Hilman wrote:
> Sourav Poddar<sourav.poddar@ti.com> writes:
>
>> On Thursday 18 April 2013 11:35 PM, Kevin Hilman wrote:
>>> Sourav Poddar<sourav.poddar@ti.com> writes:
>>>
>>>> Remove the "OMAP_DEVICE_NO_IDLE_ON_SUSPEND" check, since UART was the only one making
>>>> use of it. Now serial core/driver takes care of the case when "no_console_suspend"
>>>> is used in the bootargs and you need to keep the clock enable for console even while suspend.
>>>>
>>>> Signed-off-by: Sourav Poddar<sourav.poddar@ti.com>
>>> NAK. This patch will break many things...
>>>
>>>> ---
>>>> arch/arm/mach-omap2/omap_device.c | 7 +------
>>>> 1 files changed, 1 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
>>>> index 381be7a..d6dce8f 100644
>>>> --- a/arch/arm/mach-omap2/omap_device.c
>>>> +++ b/arch/arm/mach-omap2/omap_device.c
>>>> @@ -620,11 +620,8 @@ static int _od_suspend_noirq(struct device *dev)
>>>> ret = pm_generic_suspend_noirq(dev);
>>>>
>>>> if (!ret&& !pm_runtime_status_suspended(dev)) {
>>>> - if (pm_generic_runtime_suspend(dev) == 0) {
>>>> - if (!(od->flags& OMAP_DEVICE_NO_IDLE_ON_SUSPEND))
>>>> - omap_device_idle(pdev);
>>> Why did you remove the omap_device_idle() here?
>> This patch is used along with patch3 to get rid of the issue. I posted
>> them as a
>> seperate patch beacuse of the subject line as one goes under drivers/*
>> and the other
>> arm/mach-omap2/*..
>>
>> This check was only valid for UART, and if od->flags is set to the
>> "OMAP_DEVICE_NO_IDLE_ON_SUSPEND" flag, then UART will not be idled.
> correct, but *every other device* would be idled (if not already idle.)
>
>> But now, we no longer depend on od->flag value to prevent idling of
>> our console UART as the prepare/complete apis will take care of them.
> Right, so removing the check on od->flags is fine, but what I asked
> about is why you removed the omap_device_idle() call.
>
> Remember that this code is called for *every* omap_device during
> suspend, not just UART.
>
> What you did stops *every* device from being idled during suspend.
>
> You didn't read my whole message. Specifically this part:
>
Yes, got your point. omap_device_idle should not be called only
for console uart.
Just did a quick testing by including the following hunk on top of my
patch series..
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index c226946..7480e87 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -617,8 +617,10 @@ static int _od_suspend_noirq(struct device *dev)
ret = pm_generic_suspend_noirq(dev);
if (!ret && !pm_runtime_status_suspended(dev)) {
- if (pm_generic_runtime_suspend(dev) == 0)
+ if (pm_generic_runtime_suspend(dev) == 0) {
+ omap_device_idle(pdev);
od->flags |= OMAP_DEVICE_SUSPENDED;
+ }
}
return ret;
@@ -631,6 +633,7 @@ static int _od_resume_noirq(struct device *dev)
if ((od->flags & OMAP_DEVICE_SUSPENDED) &&
!pm_runtime_status_suspended(dev)) {
+ omap_device_enable(pdev);
od->flags &= ~OMAP_DEVICE_SUSPENDED;
pm_generic_runtime_resume(dev);
}
And found the wakeup from UART is no more functional.
So, the omap_device_idle gets called for console UART also, thereby
preventing the "no_idle_on_suspend" theory.
Hence, merely putting prepare/complete callback the way I did is not
helping.
We need to delete omap_device_idle also, which I agree is not correct.
So, we need a way to bypass this "omap_device_idle"
call for console UART. ?
What my understanding was that after modifying serial driver,
bypass the entire hunk[1] for console UART?
>>> Note that the check is for when the flag is *not* set, so this patch
>>> changes behavior for all the drivers that do not use
>>> _NO_IDLE_ON_SUSPEND. I think that's the opposite of what you intended.
> Kevin
next prev parent reply other threads:[~2013-04-19 13:55 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-17 11:34 [PATCH 0/6] Serial Omap fixes and cleanups Sourav Poddar
2013-04-17 11:34 ` Sourav Poddar
2013-04-17 11:34 ` [PATCH 1/6] driver: tty: serial: Move "uart_console" def to core header file Sourav Poddar
2013-04-17 11:34 ` Sourav Poddar
2013-04-17 11:34 ` [RFT/PATCH 2/6] driver: serial: mpc52xx_uart: Remove "uart_console" defintion Sourav Poddar
2013-04-17 11:34 ` Sourav Poddar
2013-04-18 3:56 ` Felipe Balbi
2013-04-18 3:56 ` Felipe Balbi
2013-04-18 5:17 ` Sourav Poddar
2013-04-18 5:17 ` Sourav Poddar
2013-04-18 10:50 ` Russell King - ARM Linux
2013-04-18 10:51 ` Sourav Poddar
2013-04-18 10:51 ` Sourav Poddar
2013-04-17 11:34 ` [PATCH 3/6] driver: serial: omap: add prepare/complete callback for "no_console_suspend" case Sourav Poddar
2013-04-17 11:34 ` Sourav Poddar
2013-04-18 3:58 ` Felipe Balbi
2013-04-18 3:58 ` Felipe Balbi
2013-04-18 12:07 ` Sourav Poddar
2013-04-18 12:07 ` Sourav Poddar
2013-04-18 13:06 ` Felipe Balbi
2013-04-18 13:06 ` Felipe Balbi
2013-04-18 17:56 ` Kevin Hilman
2013-04-18 17:56 ` Kevin Hilman
2013-04-18 18:11 ` Sourav Poddar
2013-04-18 18:11 ` Sourav Poddar
2013-04-18 21:56 ` Kevin Hilman
2013-04-18 21:56 ` Kevin Hilman
2013-04-17 11:34 ` [PATCH 4/6] arm: mach-omap2: remove "OMAP_DEVICE_NO_IDLE_ON_SUSPEND" check Sourav Poddar
2013-04-17 11:34 ` Sourav Poddar
2013-04-18 18:05 ` Kevin Hilman
2013-04-18 18:05 ` Kevin Hilman
2013-04-18 19:02 ` Sourav Poddar
2013-04-18 19:02 ` Sourav Poddar
2013-04-18 22:03 ` Kevin Hilman
2013-04-18 22:03 ` Kevin Hilman
2013-04-19 13:55 ` Sourav Poddar [this message]
2013-04-19 13:55 ` Sourav Poddar
2013-04-19 14:52 ` Kevin Hilman
2013-04-19 14:52 ` Kevin Hilman
2013-04-22 5:50 ` Sourav Poddar
2013-04-22 5:50 ` Sourav Poddar
2013-04-17 11:34 ` [PATCH 5/6] arm: dts: am33xx: Remove "ti,no_idle_on_suspend" property Sourav Poddar
2013-04-17 11:34 ` Sourav Poddar
2013-04-17 11:34 ` [PATCH 6/6] arm: mach-omap2: Remove "no_console_suspend" Sourav Poddar
2013-04-17 11:34 ` Sourav Poddar
2013-04-18 18:09 ` Kevin Hilman
2013-04-18 18:09 ` Kevin Hilman
2013-04-18 19:09 ` Sourav Poddar
2013-04-18 19:09 ` Sourav Poddar
2013-04-18 18:11 ` Kevin Hilman
2013-04-18 18:11 ` Kevin Hilman
2013-04-18 19:11 ` Sourav Poddar
2013-04-18 19:11 ` Sourav Poddar
2013-04-18 18:23 ` [PATCH 0/6] Serial Omap fixes and cleanups Kevin Hilman
2013-04-18 18:23 ` Kevin Hilman
2013-04-18 19:17 ` Sourav Poddar
2013-04-18 19:17 ` Sourav Poddar
2013-04-19 12:02 ` Grygorii Strashko
2013-04-19 12:02 ` Grygorii Strashko
2013-04-19 14:04 ` Sourav Poddar
2013-04-19 14:04 ` Sourav Poddar
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=51714CCC.9090800@ti.com \
--to=sourav.poddar@ti.com \
--cc=gregkh@linuxfoundation.org \
--cc=khilman@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=rmk+kernel@arm.linux.org.uk \
--cc=tony@atomide.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.