On Mon, Mar 05, 2012 at 12:09:13PM -0600, Matt Sealey wrote:
There is in the BSP but the BSP driver is trying to be way too fancy with I2S settings on the imx-ssi driver you wrote (it works well for AC97, but for SSI in I2S slave mode there are so many hacks upon hacks "they" have presented, it'd never mainline)
I'm really having a very hard time comprehending this paragraph, and indeed much of the rest of your mail. The lack of any context isn't helping here... There is what exactly in the BSP?
codec config. In theory the playback and capture should be serialized by the driver, though, right? It wouldn't be possible to be a slave to
That would be *really* bad, simultaneous playback and record is very widely used.
the codec if it had to run the clock two different rates at the same time.. app1 sends a sample buffer, codec does dma, app2 requests capture buffer, codec does dma, they can't happen at the same time, maybe we are missing an important mutex or spinlock here that would enforce this and stop the configuration changing mid-stream.. I'm far from the ALSA expert though)
If the hardware has constraints on the sample rates the driver should be telling the application about this. For the very common case where you need the same rate for playback and record there's framework support for doing this, the relevant driver just needs to set the symmetric_rates flag and the core will do everything. Note that the ALSA APIs are racy here.