Re: [alsa-devel][PATCH 1/3] SoC: fsl_sai: add sai master mode support

From: Nicolin Chen
Date: Wed Jan 21 2015 - 01:07:17 EST


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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/