From: Kevin Hilman <khilman@ti.com>
To: "Koyamangalath, Abhilash" <abhilash.kv@ti.com>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"tony@atomide.com" <tony@atomide.com>,
"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
"V, Aneesh" <aneesh@ti.com>,
"Shilimkar, Santosh" <santosh.shilimkar@ti.com>,
"Menon, Nishanth" <nm@ti.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Lohithakshan, Ranjith" <ranjithl@ti.com>
Subject: Re: [PATCH v2] AM3517 : support for suspend/resume
Date: Fri, 23 Sep 2011 09:07:59 -0700 [thread overview]
Message-ID: <87obybjl7k.fsf@ti.com> (raw)
In-Reply-To: <FCCFB4CDC6E5564B9182F639FC356087037AF843F0@dbde02.ent.ti.com> (Abhilash Koyamangalath's message of "Fri, 23 Sep 2011 18:54:22 +0530")
"Koyamangalath, Abhilash" <abhilash.kv@ti.com> writes:
[...]
>>> @@ -485,6 +489,8 @@ console_still_active:
>>>
>>> int omap3_can_sleep(void)
>>> {
>>> + if (cpu_is_omap3505() || cpu_is_omap3517())
>>> + return 0;
>>
>> This needs to be a separate patch with a descriptive changelog and
>> justification as to why you can't do WFI in idle.
> [Abhilash K V]OK
>>
>> Adding something like this means the device will *never* attempt a WFI
>> during idle.
>
> [Abhilash K V] This patch was put in as dynamic sleep feature is not
> supported by the device, there are no C states etc. The only PM
> supported is forced suspend /resume. There is just one power-domain
> and it can be in ON or RET states.
>
If the device can WFI and hit retention in suspend, there should be no
not to target the same power state in idle.
You don't have to have CPUidle with multiple C-states to use idle.
>> I suspect that avoiding WFI in idle is masking a bug that you don't see
>> in the suspend path.
>
> [Abhilash K V] I need to recap a bit to find out if there is a better
> way to indicate the lack of "idle" feature.
Yes please. From my POV, deciding not to go idle is a SW decision, not
a hardware decision. As the same SW mechanisms are involved, whatever
power state that can be acheived from suspend should be targetted in
idle.
Kevin
WARNING: multiple messages have this Message-ID (diff)
From: khilman@ti.com (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] AM3517 : support for suspend/resume
Date: Fri, 23 Sep 2011 09:07:59 -0700 [thread overview]
Message-ID: <87obybjl7k.fsf@ti.com> (raw)
In-Reply-To: <FCCFB4CDC6E5564B9182F639FC356087037AF843F0@dbde02.ent.ti.com> (Abhilash Koyamangalath's message of "Fri, 23 Sep 2011 18:54:22 +0530")
"Koyamangalath, Abhilash" <abhilash.kv@ti.com> writes:
[...]
>>> @@ -485,6 +489,8 @@ console_still_active:
>>>
>>> int omap3_can_sleep(void)
>>> {
>>> + if (cpu_is_omap3505() || cpu_is_omap3517())
>>> + return 0;
>>
>> This needs to be a separate patch with a descriptive changelog and
>> justification as to why you can't do WFI in idle.
> [Abhilash K V]OK
>>
>> Adding something like this means the device will *never* attempt a WFI
>> during idle.
>
> [Abhilash K V] This patch was put in as dynamic sleep feature is not
> supported by the device, there are no C states etc. The only PM
> supported is forced suspend /resume. There is just one power-domain
> and it can be in ON or RET states.
>
If the device can WFI and hit retention in suspend, there should be no
not to target the same power state in idle.
You don't have to have CPUidle with multiple C-states to use idle.
>> I suspect that avoiding WFI in idle is masking a bug that you don't see
>> in the suspend path.
>
> [Abhilash K V] I need to recap a bit to find out if there is a better
> way to indicate the lack of "idle" feature.
Yes please. From my POV, deciding not to go idle is a SW decision, not
a hardware decision. As the same SW mechanisms are involved, whatever
power state that can be acheived from suspend should be targetted in
idle.
Kevin
WARNING: multiple messages have this Message-ID (diff)
From: Kevin Hilman <khilman@ti.com>
To: "Koyamangalath\, Abhilash" <abhilash.kv@ti.com>
Cc: "linux-omap\@vger.kernel.org" <linux-omap@vger.kernel.org>,
"tony\@atomide.com" <tony@atomide.com>,
"linux\@arm.linux.org.uk" <linux@arm.linux.org.uk>, "V\,
Aneesh" <aneesh@ti.com>, "Shilimkar\,
Santosh" <santosh.shilimkar@ti.com>, "Menon\,
Nishanth" <nm@ti.com>,
"linux-arm-kernel\@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Lohithakshan\, Ranjith" <ranjithl@ti.com>
Subject: Re: [PATCH v2] AM3517 : support for suspend/resume
Date: Fri, 23 Sep 2011 09:07:59 -0700 [thread overview]
Message-ID: <87obybjl7k.fsf@ti.com> (raw)
In-Reply-To: <FCCFB4CDC6E5564B9182F639FC356087037AF843F0@dbde02.ent.ti.com> (Abhilash Koyamangalath's message of "Fri, 23 Sep 2011 18:54:22 +0530")
"Koyamangalath, Abhilash" <abhilash.kv@ti.com> writes:
[...]
>>> @@ -485,6 +489,8 @@ console_still_active:
>>>
>>> int omap3_can_sleep(void)
>>> {
>>> + if (cpu_is_omap3505() || cpu_is_omap3517())
>>> + return 0;
>>
>> This needs to be a separate patch with a descriptive changelog and
>> justification as to why you can't do WFI in idle.
> [Abhilash K V]OK
>>
>> Adding something like this means the device will *never* attempt a WFI
>> during idle.
>
> [Abhilash K V] This patch was put in as dynamic sleep feature is not
> supported by the device, there are no C states etc. The only PM
> supported is forced suspend /resume. There is just one power-domain
> and it can be in ON or RET states.
>
If the device can WFI and hit retention in suspend, there should be no
not to target the same power state in idle.
You don't have to have CPUidle with multiple C-states to use idle.
>> I suspect that avoiding WFI in idle is masking a bug that you don't see
>> in the suspend path.
>
> [Abhilash K V] I need to recap a bit to find out if there is a better
> way to indicate the lack of "idle" feature.
Yes please. From my POV, deciding not to go idle is a SW decision, not
a hardware decision. As the same SW mechanisms are involved, whatever
power state that can be acheived from suspend should be targetted in
idle.
Kevin
next prev parent reply other threads:[~2011-09-23 16:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-14 13:48 [PATCH v2] AM3517 : support for suspend/resume Abhilash K V
2011-09-14 13:48 ` Abhilash K V
2011-09-14 13:48 ` Abhilash K V
2011-09-22 21:55 ` Kevin Hilman
2011-09-22 21:55 ` Kevin Hilman
2011-09-22 21:55 ` Kevin Hilman
2011-09-23 13:24 ` Koyamangalath, Abhilash
2011-09-23 13:24 ` Koyamangalath, Abhilash
2011-09-23 16:07 ` Kevin Hilman [this message]
2011-09-23 16:07 ` Kevin Hilman
2011-09-23 16:07 ` Kevin Hilman
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=87obybjl7k.fsf@ti.com \
--to=khilman@ti.com \
--cc=abhilash.kv@ti.com \
--cc=aneesh@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=nm@ti.com \
--cc=ranjithl@ti.com \
--cc=santosh.shilimkar@ti.com \
--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.