From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
Subject: Re: [PATCH 2/4] ASoC: cx20442: add bias control over a
 platform provided regulator
Date: Tue, 27 Dec 2011 17:26:00 +0000
Message-ID: <20111227172559.GB22970@opensource.wolfsonmicro.com>
References: <1324681944-19067-1-git-send-email-jkrzyszt@tis.icnet.pl>
	<1324681944-19067-3-git-send-email-jkrzyszt@tis.icnet.pl>
	<20111226110201.GA8722@opensource.wolfsonmicro.com>
	<201112271516.09114.jkrzyszt@tis.icnet.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <alsa-devel-bounces@alsa-project.org>
Received: from opensource.wolfsonmicro.com (opensource.wolfsonmicro.com
	[80.75.67.52]) by alsa0.perex.cz (Postfix) with ESMTP id BCE322412D
	for <alsa-devel@alsa-project.org>; Tue, 27 Dec 2011 18:26:04 +0100 (CET)
Content-Disposition: inline
In-Reply-To: <201112271516.09114.jkrzyszt@tis.icnet.pl>
List-Unsubscribe: <http://mailman.alsa-project.org/mailman/listinfo/alsa-devel>,
	<mailto:alsa-devel-request@alsa-project.org?subject=unsubscribe>
List-Archive: <http://mailman.alsa-project.org/pipermail/alsa-devel>
List-Post: <mailto:alsa-devel@alsa-project.org>
List-Help: <mailto:alsa-devel-request@alsa-project.org?subject=help>
List-Subscribe: <http://mailman.alsa-project.org/mailman/listinfo/alsa-devel>,
	<mailto:alsa-devel-request@alsa-project.org?subject=subscribe>
Sender: alsa-devel-bounces@alsa-project.org
Errors-To: alsa-devel-bounces@alsa-project.org
To: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Cc: alsa-devel@alsa-project.org, Tony Lindgren <tony@atomide.com>, linux-kernel@vger.kernel.org, Jarkko Nikula <jarkko.nikula@bitmer.com>, linux-omap@vger.kernel.org, Liam Girdwood <lrg@ti.com>, linux-arm-kernel@lists.infradead.org
List-Id: alsa-devel@alsa-project.org

On Tue, Dec 27, 2011 at 03:16:08PM +0100, Janusz Krzysztofik wrote:
> On Monday 26 of December 2011 at 12:02:01, Mark Brown wrote:

> > which would look a lot more natural - you shouldn't need to remember if
> > the regulator is enabled, you should just turn it on in the STANDBY to
> > PREPARE transition and turn it off in the ON to PREPARE or PREPARE to
> > STANDBY transitions.

> Can I assume STANDBY or OFF at the time the codec .remove method is 
> called? If not, is there a helper function available which can be called 
> in order to perform all those ON -> PREPARE -> STANDBY [-> OFF] transitions before calling regulator_put()?

It'll be in STANDBY or OFF depending on if the device sets
idle_bias_off.