[alsa-devel] [PATCH] ASoC: rt286: set idle_bias_off to false

[Jie, Yang]

~Keyon


> -----Original Message-----
> From: Mark Brown [mailto:broonie at kernel.org]
> Sent: Thursday, January 29, 2015 4:10 AM
> To: Bard Liao
> Cc: lgirdwood at gmail.com; alsa-devel at alsa-project.org; Flove; Oder Chiou; Jie,
> Yang
> Subject: Re: [PATCH] ASoC: rt286: set idle_bias_off to false
> 
> On Wed, Jan 28, 2015 at 12:45:13PM +0000, Bard Liao wrote:
> 
> > > > -	.idle_bias_off = true,
> > > > +	.idle_bias_off = false,
> 
> > > There is no need to set false explicitly, it's the default.  It also
> > > seems better to keep the flag if it's true, even if we don't
> > > actively do anything at the minute we may in future (either in the
> > > framework or in the driver) so the information seems useful.
> 
> > Actually, we meet an issue. We use force enable in rt286_jack_detect.
> > If
> 
> So, this is one of the reasons why people ask for good, clear changelogs...
> 
> > a headset is inserted, the bias_level will not be OFF due to some
> > widgets are ON. If idle_bias_off is true, rt286_suspend will not be
> > invoked in suspend. And I "guess" rt286's power will be cut off in
> > suspend. That's what we handle in rt286_suspend/resume functions. If
> > rt286 's power is cut off and don't re-sync the cache, it will cause some
> unexpected issues.
> 
> > Is there any good way to fix such issues?
> 
> If jack detection should be disabled over suspend the machine driver should do
> that (eg, by setting a NULL jack).  It's actually common for systems to leave
> jack detection up over suspend as in systems like phones the jack can be a wake
[Keyon] as my understanding, setting idle_bias_off to false won't disable jack detection
over suspend, only the action that poweroff the codec will disable it, Bard, is it correct?

setting idle_bias_off to false is the easiest solution for us, it is also reasonable here,
because rt286 don't need soc core to set BIAS OFF specially when in idle status, (BIAS_OFF 
and BIAS_STANDBY are same for it), and seems no side effect here.

> source, the hook switch is commonly expected to always be operational.