linux-kernel - Re: [alsa-devel][PATCH 1/3] SoC: fsl

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150121092529.GA27441@b50113>
Date:	Wed, 21 Jan 2015 17:25:32 +0800
From:	Zidan Wang <b50113@...escale.com>
To:	Nicolin Chen <nicoleotsuka@...il.com>
CC:	Zidan Wang <zidan.wang@...escale.com>, <timur@...i.org>,
	<Xiubo.Lee@...il.com>, <lgirdwood@...il.com>, <broonie@...nel.org>,
	<perex@...ex.cz>, <tiwai@...e.de>, <alsa-devel@...a-project.org>,
	<linuxppc-dev@...ts.ozlabs.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [alsa-devel][PATCH 1/3] SoC: fsl_sai: add sai master mode support

On Tue, Jan 20, 2015 at 10:07:03PM -0800, Nicolin Chen wrote:
> 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.
> 
When TX following RX(or RX following TX), TX and RX works on same bit
clock and frame clock. They will use same MCLK source, and just need set
the bclk DIV for RX(or TX). The secondary stream will overwrite MSEL and
bclk DIV of the first stream, but it doesn't matter.

For RX(or TX) sync:
fsl_sai_dai.symmetric_rates = 1;
fsl_sai_dai.symmetric_channels = 1;
fsl_sai_dai.symmetric_samplebits = 1;

When TX and RX both works on async mode, TX and RX may works on
different bit clock and frame clock. We need set MCLK source and bclk
DIV for TX and RX. mclk_id just save a MCLK source id, so i need to define
mclk_id[2] for differnet stream.

For TX and RX async:
fsl_sai_dai.symmetric_rates = 0;
fsl_sai_dai.symmetric_channels = 0;
fsl_sai_dai.symmetric_samplebits = 0;

> > @@ -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.
> 
When hw_params failed before mclk enable, hw_free will also decrease 
the clk usecount. So add mclk_streams, when clk successful enabled, 
set corresponding bit of mclk_stream. And clear such bit after clk disabled.
> Nicolin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/