From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Dooks Subject: Re: [RFC] IDLE/DEEP IDLE scheduler modification for power savings Date: Tue, 11 May 2010 01:22:13 +0100 Message-ID: <20100511002212.GA26401@trinity.fluff.org> References: <000001cada24$01a5ee90$04f1cbb0$%majewski@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from trinity.fluff.org ([89.16.178.74]:38215 "EHLO trinity.fluff.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751330Ab0EKAWZ (ORCPT ); Mon, 10 May 2010 20:22:25 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-samsung-soc-owner@vger.kernel.org List-Id: linux-samsung-soc@vger.kernel.org To: jassi brar Cc: Lukasz Majewski , linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, Ingo Molnar , Tomasz Fujak , Marek Szyprowski , Kyungmin Park On Mon, Apr 12, 2010 at 09:55:28PM +0900, jassi brar wrote: > On Mon, Apr 12, 2010 at 6:39 PM, Lukasz Majewski wrote: > > One approach to solve the problem, and therefore deliver power savi= ngs, > > is to modify the ALSA driver and provide a switch to inform the CPU= IDLE > > framework that it should now use the DEEP IDLE instead of IDLE when= entering > > the Low Power Audio playback mode is expected. =A0This change may b= e performed > > by replacing the method for entering the IDLE mode to DEEP IDLE. Mo= reover > > some sources immune to power gating (like e.g. RTC timer) have to b= e used > > for waking up. The biggest problem for this approach is the kernel'= s policy > > violation, that no user program should directly change scheduling/i= dle > > policy. > Actually any power saving mode is transparent to the LPAM(LowPowerAud= ioMode). > "LPAM h/w" is simply an I2S controller with an additional 'overlay' > stereo channel > which is h/w-mix'ed with the first two of the 6 channels. And these o= verlay > channels works just as well in normal power mode. LPAM is but one > ramification of > of the platform using the interrupt as a wakeup source. It is also us= ed for > low latency playback like 'alerts' and 'alarms'. > Our LPAM doesn't work right away not because of the power management = stack > but because ASoC can't yet handle a > codec-active-in-system-suspended-mode scenario. > So, I too think it's a bad idea to hack core PM for things like LPAM. >=20 > > So what is your opinion about integrating use of the DEEP IDLE stat= e mode > > in the scheduler (either as new scheduling policy or modifying sche= duler > > code)? > imho, such 'variation' in suspend had better be implemented in > platform specific manner. > Just because samsung's manual call it deep-IDLE doesn't make it an 'I= DLE' mode. > It is closer to suspend than idle, at least to me. It does seem to be a form of suspend, as it halts the SDRAM and powers down the ARM core... this means that there's a whole pile of stuff that needs to be considered before allowing the system to go into such a sta= te. --=20 Ben Q: What's a light-year? A: One-third less calories than a regular year. From mboxrd@z Thu Jan 1 00:00:00 1970 From: ben-linux@fluff.org (Ben Dooks) Date: Tue, 11 May 2010 01:22:13 +0100 Subject: [RFC] IDLE/DEEP IDLE scheduler modification for power savings In-Reply-To: References: <000001cada24$01a5ee90$04f1cbb0$%majewski@samsung.com> Message-ID: <20100511002212.GA26401@trinity.fluff.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, Apr 12, 2010 at 09:55:28PM +0900, jassi brar wrote: > On Mon, Apr 12, 2010 at 6:39 PM, Lukasz Majewski wrote: > > One approach to solve the problem, and therefore deliver power savings, > > is to modify the ALSA driver and provide a switch to inform the CPU IDLE > > framework that it should now use the DEEP IDLE instead of IDLE when entering > > the Low Power Audio playback mode is expected. ?This change may be performed > > by replacing the method for entering the IDLE mode to DEEP IDLE. Moreover > > some sources immune to power gating (like e.g. RTC timer) have to be used > > for waking up. The biggest problem for this approach is the kernel's policy > > violation, that no user program should directly change scheduling/idle > > policy. > Actually any power saving mode is transparent to the LPAM(LowPowerAudioMode). > "LPAM h/w" is simply an I2S controller with an additional 'overlay' > stereo channel > which is h/w-mix'ed with the first two of the 6 channels. And these overlay > channels works just as well in normal power mode. LPAM is but one > ramification of > of the platform using the interrupt as a wakeup source. It is also used for > low latency playback like 'alerts' and 'alarms'. > Our LPAM doesn't work right away not because of the power management stack > but because ASoC can't yet handle a > codec-active-in-system-suspended-mode scenario. > So, I too think it's a bad idea to hack core PM for things like LPAM. > > > So what is your opinion about integrating use of the DEEP IDLE state mode > > in the scheduler (either as new scheduling policy or modifying scheduler > > code)? > imho, such 'variation' in suspend had better be implemented in > platform specific manner. > Just because samsung's manual call it deep-IDLE doesn't make it an 'IDLE' mode. > It is closer to suspend than idle, at least to me. It does seem to be a form of suspend, as it halts the SDRAM and powers down the ARM core... this means that there's a whole pile of stuff that needs to be considered before allowing the system to go into such a state. -- Ben Q: What's a light-year? A: One-third less calories than a regular year.