On Tue, Jan 20, 2015 at 08:21:18PM +0800, Zidan Wang wrote:
> +static int fsl_sai_set_bclk(struct snd_soc_dai *dai, bool tx, u32 freq)
> + if ((tx && sai->synchronous[TX]) || (!tx && !sai->synchronous[RX])) {
> + regmap_update_bits(sai->regmap, FSL_SAI_RCR2,
> + FSL_SAI_CR2_MSEL_MASK, FSL_SAI_CR2_MSEL(sai->mclk_id));
> + regmap_update_bits(sai->regmap, FSL_SAI_RCR2,
> + FSL_SAI_CR2_DIV_MASK, savediv - 1);
Hmm...the case should be a bit more complicated here IMO.
"tx && sai->synchronous[TX]" means the playback in synchronous
mode (TX following RX). What if the recording has been already
activated with an MSEL setting at this point? Then the playback
stream, as a secondary stream, will overwrite MSEL of the first
stream -- Record. Same would happen to the DIV configuration.
> @@ -297,6 +368,24 @@ static int fsl_sai_hw_params(struct snd_pcm_substream
> *substream,
> unsigned int channels = params_channels(params);
> u32 word_width = snd_pcm_format_width(params_format(params));
> u32 val_cr4 = 0, val_cr5 = 0;
> + int ret;
> +
> + if (!sai->is_slave_mode) {
> + ret = fsl_sai_set_bclk(cpu_dai, tx,
> + 2 * word_width * params_rate(params));
> + if (ret)
> + return ret;
> +
> + /* Do not enable the clock if it is already enabled */
It actually doesn't matter to enable the clock again since it
purely increaes its count. But we do need a protection for MSEL
overwritten issue resulted from the fsl_sai_set_bclk() call.
> @@ -133,10 +135,13 @@ struct fsl_sai {
> struct clk *mclk_clk[FSL_SAI_MCLK_MAX];
>
> bool is_lsb_first;
> + bool is_slave_mode;
> bool is_dsp_mode;
> bool sai_on_imx;
> bool synchronous[2];
>
> + unsigned int mclk_id;
> + unsigned int mclk_streams;
Besides, I doubt that only one property of mclk_id can content
Asynchronous Mode -- TX and RX can fetch their clocks from
different MCLK sources.
Nicolin
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
