public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
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


      reply	other threads:[~2011-09-23 16:08 UTC|newest]

Thread overview: 4+ 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-22 21:55 ` Kevin Hilman
2011-09-23 13:24   ` Koyamangalath, Abhilash
2011-09-23 16:07     ` Kevin Hilman [this message]

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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox