From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Hilman Subject: Re: [PATCH v2] AM3517 : support for suspend/resume Date: Fri, 23 Sep 2011 09:07:59 -0700 Message-ID: <87obybjl7k.fsf@ti.com> References: <1316008126-7322-1-git-send-email-abhilash.kv@ti.com> <87obycqm2v.fsf@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from na3sys009aog116.obsmtp.com ([74.125.149.240]:49767 "EHLO na3sys009aog116.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751959Ab1IWQIL (ORCPT ); Fri, 23 Sep 2011 12:08:11 -0400 In-Reply-To: (Abhilash Koyamangalath's message of "Fri, 23 Sep 2011 18:54:22 +0530") Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: "Koyamangalath, Abhilash" Cc: "linux-omap@vger.kernel.org" , "tony@atomide.com" , "linux@arm.linux.org.uk" , "V, Aneesh" , "Shilimkar, Santosh" , "Menon, Nishanth" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "Lohithakshan, Ranjith" "Koyamangalath, Abhilash" 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