On Wed, Nov 23, 2011 at 04:00:23PM +0200, Péter Ujfalusi wrote: > On Wednesday 23 November 2011 10:58:07 Mark Brown wrote: > > > 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. Meh, I guess. It's hard to love code-wise. > > 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. Sure, but on the other hand it means that someone reading the machine driver can tell what's going on without going back to the magic table either. Having the rates in the code makes the code more legible and means that people can at least refer to the DMIC driver for a list of supported rates rather than having to find the TRM. I'd also guess that it's much more likely that people will remember clock rates they can set than divider tables but perhaps that's just me. -- 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
