alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Nicolin Chen <b42378@freescale.com>
To: Mark Brown <broonie@kernel.org>
Cc: tiwai@suse.de, alsa-devel@alsa-project.org, lgirdwood@gmail.com
Subject: Re: [PATCH] ASoC: fsl: imx-wm8962: Do FLL configuration in hw_params() and hw_free()
Date: Thu, 5 Dec 2013 10:56:31 +0800	[thread overview]
Message-ID: <20131205025630.GG8609@MrMyself> (raw)
In-Reply-To: <20131204190211.GD29268@sirena.org.uk>

On Wed, Dec 04, 2013 at 07:02:11PM +0000, Mark Brown wrote:
> On Thu, Dec 05, 2013 at 12:54:08AM +0800, Nicolin Chen wrote:
> 
> > Previously, we couldn't use hw_params() and hw_free() to open and close FLL
> > becuase there might be race between two simmultaneous substreams and cause
> > FLL configuration being changed and accordingly mulfunction. So we adopted
> > DAPM to control it since there won't be any race in DAPM. However, if we
> > want to playback a different sample rate file, we need to wait for DAPM to
> > change its bias_level to reconfigure FLL.
> > 
> > But after we introduced full symmetry protection in the soc-pcm, we don't
> > need to worry about the race any more. And the instance by using hw_params()
> > and hw_free() to control FLL would allow us to support flexible use cases,
> > 'aplay -Dhw:0 44k16bit.wav 48k24bit.wav 32k32bit.wav' for example.
> > 
> > Thus this patch mainly moves FLL configuration from set_bias_level() to
> > hw_params() and hw_free() so as to enchance the sound card's capability.
> 
> That's not the only reason for using set_bias_level(), it's also used so
> that bypass paths from the CODEC inputs to outputs get the FLL started
> - all the outputs need the device to be clocked.

Thank you for reminding me of this case. And I still have a concern.

As far as I can understand, the point that all the outputs needs the device
to be clocked is undeniably true, but the external MCLK should be sufficient
to source the SYSCLK of WM8962. Does the bypass mode also need to set FLL
to get an accurate frequency?

Sorry I am not so familiar with the bypass path. So what I can imagine is
WM8962 just bypass input (DAC) to outputs (DAC) via MIXER or some routes
else, then there's no need for WM8962 to generate accurate BCLK and LRCLK.
Sir, could you please also shed some light on this point if it's not a
comprehensive one?

Thank you,
Nicolin Chen

  reply	other threads:[~2013-12-05  3:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-04 16:54 [PATCH] ASoC: fsl: imx-wm8962: Do FLL configuration in hw_params() and hw_free() Nicolin Chen
2013-12-04 19:02 ` Mark Brown
2013-12-05  2:56   ` Nicolin Chen [this message]
2013-12-05 11:15     ` [PATCH] ASoC: fsl: imx-wm8962: Do FLL configuration in hw_params() and hw_kree() Mark Brown
2013-12-05 11:07       ` Nicolin Chen
2013-12-05 12:21         ` Mark Brown
2013-12-05 14:17           ` Nicolin Chen

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=20131205025630.GG8609@MrMyself \
    --to=b42378@freescale.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=tiwai@suse.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).