[alsa-devel] [PATCH v3 2/5] ASoC: OMAP4: omap-dmic: Initial support for OMAP DMIC

Péter Ujfalusi peter.ujfalusi at ti.com
Mon Nov 28 08:49:19 CET 2011


On Sunday 27 November 2011 19:50:41 Mark Brown wrote:
> On Fri, Nov 25, 2011 at 02:20:33PM +0200, Peter Ujfalusi wrote:
> > +	/*
> > +	 * 192KHz rate is only supported with 19.2MHz/3.84MHz clock
> > +	 * configuration. The same clock configuration allows 96KHz sampling
> > +	 * rate as well. omap_dmic_select_divider() function configures the
> > +	 * dividers for 96KHz, if the current stream is running in 192KHz we
> > +	 * can change the divider value, while respecting the machine driver
> > +	 * requested clock configuration.
> > +	 */
> > +	if (params_rate(params) == 192000) {
> > +		if (dmic->fclk_freq == 19200000 && dmic->clk_div == 0x1) {
> > +			dmic->clk_div = 0x6;
> > +		} else {
> > +			dev_err(dmic->dev,
> > +				"invalid clock configuration for 192KHz\n");
> > +			return -EINVAL;
> > +		}
> > +	}
> 
> So what happens if the user starts recording at 192kHz then goes back to
> 96kHz?  This all feels a bit clunky and fragile.

I expect another HW param calls. The stream is stopped, and I reconfigure the 
divider for 96KHz (I will not change the divider here, since the stream is 
96KHz). I don't see any issue here.

The comment explains the situation, and the reasoning behind of this check, 
and divider reconfiguration.

> It seems like the
> neatest solution here is to just record the desired DMICCLK rate when
> the user sets it and then apply it here rather than doing this patching
> later on.

I'm applying the divider in omap_dmic_dai_prepare callback.

--
Péter


More information about the Alsa-devel mailing list