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