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

["Péter Ujfalusi" <peter.ujfalusi@ti.com>]

On Wednesday 23 November 2011 10:58:07 Mark Brown wrote:
> This just seems like it's making the code needlessly complex - there's
> no harm in holding the reference if you don't enable/disable the clock
> and it makes this function much simpler.

OK.

> > We enable the clocks at dai_startup for the DMIC (and disable them on
> > dai_shutdown). We can not reparent while the clocks are enabled.
> > This is the reason for this part.
> 
> That sounds like the enable is happening too early, then.

This only enables the clock for the DMIC block, the clock for the external 
DMIC will start at trigger time (and stop as well).
In order to access to DMIC registers we need clocks, and the clocks are 
enabled for the duration we have capture stream open.
I would think this is acceptable.

> If that's what you're doing then it seems like the machine drivers
> should be use set_sysclk() (or perhaps even the clk API) to set up the
> rate they're looking for from the visible clock rather than fiddling
> about with magic divider values.  That way they can say exactly what
> they want directly in terms of the result they're looking for.

In OMAP4 DMIC the divider can not be chosen freely.
The clock provided to the external microphones will depend on the selected 
DMIC_FCLK, and the divider.
If I ask the machine driver to ask for specific speed for the external mic, 
the writer of the machine driver anyways have to look up the table from the 
TRM for the possible frequencies. So instead of providing magic divider it has 
to provide magic speed.
I can do that if you prefer that way, but it just going to 'complicate' the 
driver a bit (well not that much, we just will have different way of looking 
up the register value for the divider, and it will be done in 
omap_dmic_set_dai_sysclk instead of omap_dmic_set_clkdiv).

--
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html