All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Ujfalusi <peter.ujfalusi@nokia.com>
To: ext Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"lrg@slimlogic.co.uk" <lrg@slimlogic.co.uk>
Subject: Re: [PATCHv2 1/2] ASoC: TWL4030: AIF/APLL fix in DAPM domain
Date: Thu, 29 Apr 2010 09:46:07 +0300	[thread overview]
Message-ID: <201004290946.07847.peter.ujfalusi@nokia.com> (raw)
In-Reply-To: <20100428131235.GH31400@opensource.wolfsonmicro.com>

Hi,

On Wednesday 28 April 2010 16:12:35 ext Mark Brown wrote:
> On Wed, Apr 28, 2010 at 03:50:14PM +0300, Peter Ujfalusi wrote:
> > +	if (enable && twl4030->apll_enabled == 1)
> > 
> >  		/* Enable PLL */
> >  		status = twl4030_codec_enable_resource(TWL4030_CODEC_RES_APLL);
> > 
> > -	else
> > +	else if (!enable && twl4030->apll_enabled == 0)
> 
> This logic looks funny, especially the test for !enable in the second
> case (which should always be true).  I think the intention here is to
> look for "apll_enabled has done an interesting transition (0->1 or
> 1->0)" - it'd probably be clearer to look for that directly.

Yeah, I have not bothered to change this from Liam's patch, but yes. It does 
look funny.
Probably something like this would be nicer:
if (enable) {
	twl4030->apll_enabled++;
	if (twl4030->apll_enabled == 1)
		status = twl4030_codec_enable_resource(TWL4030_CODEC_RES_APLL);
} else {
	twl4030->apll_enabled--;
	if (!twl4030->apll_enabled)
		status = twl4030_codec_disable_resource(TWL4030_CODEC_RES_APLL);
}

After taking a deeper look, the aif does not need any refcounting, since DAPM 
already takes care of that.
So I will simplify that as well.

> 
> > +	/* AIF and APLL clocks for running DAIs (including loopback) */
> > +	SND_SOC_DAPM_OUTPUT("AIF DAC"),
> > +	SND_SOC_DAPM_INPUT("AIF ADC"),
> > +	SND_SOC_DAPM_OUTPUT("APLL"),
> 
> The use of INPUT and OUTPUT widgets here looks really odd - I'd at least
> except the AIF widgets to be actual AIF widgets.

I agree.
These supposed to be 'virtual' outputs, and input.
Is it helps, if I name them as:
SND_SOC_DAPM_OUTPUT("Virtual HiFi OUT"),
SND_SOC_DAPM_INPUT("Virtual HiFi IN"),
SND_SOC_DAPM_OUTPUT("Virtual Voice OUT"),

These are needed to enable the AIF, and/or APLL whenever they are needed by 
DAPM.

I'm switching the AIF/APLL within the DAPM (with DAPM_SUPPLY).
The problem is that if we don't have complete DAPM route (in playback or in 
capture), than DAPM will not enable the AIF/APLL. If the twl is master, than it 
means that the clocks will not run on the serial bus. This means that no data is 
going to be sent or received on the host side -> broken audio.

With these in place, I can make sure that we have complete route all the time, 
so AIF/APLL is enabled.

I know that other codecs (like the tlv320dac33) is enabling the AIF in 
pcm_prepare, or in other places, but with twl4030 those will not work in all 
cases:
If I use pcm_prepare for this, than I have a problem with the digital loopback, 
since that also needs the AIF/APLL enabled.
If I use the DAPM's set_bias_level, than I have two problems:
1. The analog loopback does not need the AIF/APLL enabled, so I have to handle 
that differently.
2. When there is no complete DAPM route, the codec will not change to BIAS_ON, 
so I still end up with dead interface.

The only solution so far is to introduce these virtual outputs/input, and handle 
the AIF/APLL within DAPM.

As a note: I'm already looking at the AIF widget usage, but I'm not sure how it 
supposed to be mapped in twl4030 case.
TWL has basically 4 channel interface:
Playback
AIF		Stereo mode	TDM mode
SDRL2	Left (1)		Ch 1
SDRL1	---			Ch 2
SDRR2	Right (2)		Ch 3
SDRR1	---			Ch 4

Capture
AIF		Stereo mode	TDM mode
ATXL1	Left (1)		Ch 1
AVTXL2	---			Ch 2
ATXR1	Right (2)		Ch 3
AVTXR2	---			Ch 4

How to map these with the AIF interface in Stereo and TDM (4 channel mode) in a 
consistent way?

I will rename the DAPM_OUTPUT and DAPM_INPUT widgets to the "Virtual *" 
convention, which I think sounds better also.


-- 
Péter

  reply	other threads:[~2010-04-29  6:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-28 12:50 [PATCHv2 0/2] ASoC: TWL4030: APLL/AIF ordering and DAPM updates Peter Ujfalusi
2010-04-28 12:50 ` [PATCHv2 1/2] ASoC: TWL4030: AIF/APLL fix in DAPM domain Peter Ujfalusi
2010-04-28 13:12   ` Mark Brown
2010-04-29  6:46     ` Peter Ujfalusi [this message]
2010-04-28 12:50 ` [PATCHv2 2/2] ASoC: TWL4030: Remove OUTL/R outputs Peter Ujfalusi
2010-04-28 13:12   ` Mark Brown

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=201004290946.07847.peter.ujfalusi@nokia.com \
    --to=peter.ujfalusi@nokia.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=lrg@slimlogic.co.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.