[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAA+D8APexk_-o91B=u1bthVxXr_+gUL9Yq4UA5zscLfP3Xsa6Q@mail.gmail.com>
Date: Mon, 3 Aug 2020 09:28:01 +0800
From: Shengjiu Wang <shengjiu.wang@...il.com>
To: Nicolin Chen <nicoleotsuka@...il.com>
Cc: Shengjiu Wang <shengjiu.wang@....com>,
Linux-ALSA <alsa-devel@...a-project.org>,
Timur Tabi <timur@...nel.org>, Xiubo Li <Xiubo.Lee@...il.com>,
linuxppc-dev@...ts.ozlabs.org, Takashi Iwai <tiwai@...e.com>,
Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>,
Fabio Estevam <festevam@...il.com>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] ASoC: fsl-asoc-card: Remove fsl_asoc_card_set_bias_level
function
On Sun, Aug 2, 2020 at 2:44 PM Nicolin Chen <nicoleotsuka@...il.com> wrote:
>
> On Sun, Aug 02, 2020 at 10:22:35AM +0800, Shengjiu Wang wrote:
>
> > > > + /* Specific configuration for PLL */
> > > > + if (codec_priv->pll_id && codec_priv->fll_id) {
> > > > + if (priv->sample_format == SNDRV_PCM_FORMAT_S24_LE)
> > > > + pll_out = priv->sample_rate * 384;
> > > > + else
> > > > + pll_out = priv->sample_rate * 256;
> > > > +
> > > > + ret = snd_soc_dai_set_pll(asoc_rtd_to_codec(rtd, 0),
> > > > + codec_priv->pll_id,
> > > > + codec_priv->mclk_id,
> > > > + codec_priv->mclk_freq, pll_out);
> > > > + if (ret) {
> > > > + dev_err(dev, "failed to start FLL: %d\n", ret);
> > > > + goto out;
> > > > + }
> > > > +
> > > > + ret = snd_soc_dai_set_sysclk(asoc_rtd_to_codec(rtd, 0),
> > > > + codec_priv->fll_id,
> > > > + pll_out, SND_SOC_CLOCK_IN);
> > >
> > > Just came into my mind: do we need some protection here to prevent
> > > PLL/SYSCLK reconfiguration if TX/RX end up with different values?
> > >
> > Sorry, not really catching your point. could you please elaborate?
> > Why do TX/RX end up with different values?
>
> If TX and RX run concurrently but in different sample rates or
> sample formats, pll_out would be overwritten to PLL/SYSCLK?
>
> I remember imx-wm8962 uses SSI, having symmetric flags for rates/
> channels/samplebits, but fsl-asoc-card might have (or will have)
> other use case.
>
> If all existing combinations don't have any problem, we can add
> a protection later when we need.
Good point. Current cases should be ok, as the boards with
wm8960 and wm8962 are all designed as synchronous mode.
Agree to add protection when needed in the future.
I will fix the nits and send v3.
best regards
wang shengjiu
Powered by blists - more mailing lists