[alsa-devel] Two codecs using the same I2S bus
Hi,
for a samsung based project we have chosen two codecs, one for input, the other for output. The two codecs are using the same I2S bus due to audio requirements (HF audio in combination with EC)
When having two machine implementations at the same time for the two codecs we will run into problems attaching to the I2S bus. A solution is to combine the machine implementation into one file, but then I probaly have to modify generic kernel code.
I there some solution for this and/or example code
Thanks in advance,
Niels Langendorff
On Fri, Dec 11, 2009 at 01:29:07PM +0100, Niels Langendorff wrote:
for a samsung based project we have chosen two codecs, one for input, the other for output. The two codecs are using the same I2S bus due to audio requirements (HF audio in combination with EC)
When having two machine implementations at the same time for the two codecs we will run into problems attaching to the I2S bus. A solution is to combine the machine implementation into one file, but then I probaly have to modify generic kernel code.
I there some solution for this and/or example code
This should work with the kernel as-is providing the two CODECs don't both need register control, just declare DAI links for each of the links you need from your machine driver. Nothing will stop you adding one DAI to multiple links. You'll need to deal with resource contention issues in your machine driver but it should have enough hooks already to support that, or you can just arrange for your application to never try to do anything unsupported.
If you run into problems doing this please bring them up on the list.
On Sat, Dec 12, 2009 at 06:05:22PM +0000, Mark Brown wrote:
On Fri, Dec 11, 2009 at 01:29:07PM +0100, Niels Langendorff wrote:
I there some solution for this and/or example code
This should work with the kernel as-is providing the two CODECs don't
Oh, and the OMAP-based Pandora board is an example of doing this.
Hi Mark,
thanks for your response. My comments are in between.
Op 12 dec 2009, om 19:05 heeft Mark Brown het volgende geschreven:
On Fri, Dec 11, 2009 at 01:29:07PM +0100, Niels Langendorff wrote:
for a samsung based project we have chosen two codecs, one for input, the other for output. The two codecs are using the same I2S bus due to audio requirements (HF audio in combination with EC)
When having two machine implementations at the same time for the two codecs we will run into problems attaching to the I2S bus. A solution is to combine the machine implementation into one file, but then I probaly have to modify generic kernel code.
I there some solution for this and/or example code
This should work with the kernel as-is providing the two CODECs don't both need register control, just declare DAI links for each of the links you need from your machine driver.
Both the codecs needs to be reconfigured by writing the registers for every playback/recording, so that is the difficulty. I will have a look at the OMAP implementation as a good example.
Nothing will stop you adding one DAI to multiple links. You'll need to deal with resource contention issues in your machine driver but it should have enough hooks already to support that, or you can just arrange for your application to never try to do anything unsupported.
If you run into problems doing this please bring them up on the list.
On Sat, Dec 12, 2009 at 08:54:04PM +0100, Niels Langendorff wrote:
Op 12 dec 2009, om 19:05 heeft Mark Brown het volgende geschreven:
On Fri, Dec 11, 2009 at 01:29:07PM +0100, Niels Langendorff wrote:
This should work with the kernel as-is providing the two CODECs don't both need register control, just declare DAI links for each of the links you need from your machine driver.
Both the codecs needs to be reconfigured by writing the registers for every playback/recording, so that is the difficulty.
I see. The difficulty with more than one register based device is somewhat orthogonal to the DAIs. The current approach to such systems is to have a driver for one of the devices which provides functions which can be called from the machine drivers - the MAX9877 and TPA6130A2 in mainline are examples. This doesn't scale so well, though it is workable for the time being if the devices aren't too complex.
participants (2)
-
Mark Brown -
Niels Langendorff