[alsa-devel] [PATCH 2/5] ASoC: OMAP4: omap-dmic: Initial support for OMAP DMIC
peter.ujfalusi at ti.com
Wed Nov 23 15:00:23 CET 2011
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.
> > 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).
More information about the Alsa-devel