On Fri, Mar 16, 2012 at 3:21 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Fri, Mar 16, 2012 at 07:18:18PM +0800, Shawn Guo wrote:
Maybe having "fsl,imx-audio-xxx" for machine drivers backed by SSI, and "fsl,imx-esai-audio-xxx" for the ones backed by ESAI?
It seems non-orthogonal to me that ESAI has esai in the name but SSI does not have ssi.
Alternatively if the SSI and ESAI devices are compatible enough at the ASoC API level (or can be identified by the driver just by looking at the DAI that's referenced without too much pain) the CPU DAI could just be linked to either type of DAI (probably with a more generic name for the property).
But either way works fine, and obviously you're going to end up with more complex systems which use a completely custom binding anyway.
The ESAI and SSI hardware are totally different. SSI gives you a playback and a record stream in an I2S, or I2S like, interface. A stream is mono or stereo. ESAI has IIRC up to six output and four inputs streams. Each stream is in parallel on the same clock, and can have one or more channels. So it's sort of like six SSI devices combined into one. Except all the streams share a single FIFO and DMA channel, so you can not independently turn the streams on and off in ALSA like you could with six distinct SSI devices. The hardware does have the ability to turn streams on and off on the fly, but ALSA models the device as something like a 12 channel PCM stream and doesn't provide a way to change the hw_params on the fly between periods. Hence why we have a custom driver that does ugly things so we can do this.