[alsa-devel] PATCH[1/1] Add I2S common driver for Intel MID platform
Hi, This patch set is for new I2S SSP common driver that supports I2S audio on Intel MID platforms.
It is used for sending/receving I2S audio samples on Intel MID platform.
This interface is mostly used on Intel MID platforms and provide the low level interface for some upper layer drivers such as Alsa sound card driver for Bluetooth/FM peripherals, char device interfaces for modem (cmt_speech),... As this is used to transfer speech frames from/to cellular modem that have specific timing constraints (and modem also uses the I2S path to send some side-info), the Alsa SoC interface cannot be used. It is based on low level part of cmt_speech driver that can be found in N900 (see http://lists.meego.com/pipermail/meego-kernel/2010-September/000078.html ). The intel_mid_i2s have been separated from cmt_speech in order to be more generic and to be used on other ports (for instance, to provide Alsa sound card driver for Bluetooth and FM). Upper level drivers cmt_speech and Alsa sound card driver that uses intel_mid_i2s will be up-streamed in coming days and is planned to use the same folder path (sound/pci/intel_mid_i2s/). So once these files will be upstream, this will provides Alsa sound driver interface for Bluetooth and FM for Intel Mid platform, and specific speech audio interface (char device) that is used by lib cmt speech data.
I will provide soon some draft version of example driver that uses intel_mid_i2s so reviewers can have better understanding of how it is used and how it fits together.
Best Regards, Louis Le Gall
Here is a simple diagram that explain where is the intel_mid_i2s in software architecture.
+-----------+ | | |Pulse Audio| | | | | +-----------+ | | +------------+------------+ | | | | | | +-----------+ +-----------+ | | |Lib cmt | |Alsa Lib |------+ |speech |------+ | | | |data | | | | | | | | +-----------+ | +-----------+ | | | | | | | User ......|............|.........................|................................. | | | Kernel | | | | | | | | | | | | | | | | | | |/ |/ |/ V V V +---------+ ++---------++ ++---------++ | | ||Alsa snd || ||cmt || |Intel SST| ||driver || ||speech || | "MAD" | ||SSP || ||driver || | | ||BT/FM || || || +---------+ ++---------++ ++---------++ | | | | | | | | | | | | |/ | |/ V | V +-----------+ | ++---------++ | | | \ ||intel mid|| |LPE | +------------------>||i2s || | | / ||unified || | | ||driver || +-----------+ ++---------++ | | | | Kernel ......|......................................|................................. | | Hardware |/ |/ V V +-- --+ +-- --+ | | | | |MISC | |SSP in I2S | | | |config | | | | | +-- --+ +-- --+
On Mon, Oct 18, 2010 at 12:39:56PM +0100, Le Gall, Louis wrote:
[Please fix your mail client to wrap within paragraphs - see Documentation/email-clients.txt for help with common clients.]
As this is used to transfer speech frames from/to cellular modem that have specific timing constraints (and modem also uses the I2S path to send some side-info), the Alsa SoC interface cannot be used.
What makes you say this? You have provided no detail on what problems you believe exist and since ASoC is a *very* thin wrapper around the core ALSA for DMA stuff it is very surprising that you would see any issues here that don't also affect plain ALSA. If there are any issues then it would seem better to resolve these within the current framework rather than completely discarding the entire existing infrastructure.
Also, how does this stuff relate to the other Moorestown SST drivers which Alan Cox posted recently (after some previous postings by the original authors)?
+enum mrst_ssp_mode {
SSP_IN_NORMAL_MODE = 0x0,SSP_IN_NETWORK_MODE+};
A lot of this stuff looks suspicously like the SSP ports in Marvell CPUs (which were obviously Intel originally).
As this is used to transfer speech frames from/to cellular modem that have specific timing constraints (and modem also uses the I2S path to send some side-info), the Alsa SoC interface cannot be used.
What makes you say this? You have provided no detail on what problems you believe exist and since ASoC is a *very* thin wrapper around the core ALSA for DMA stuff it is very surprising that you would see any issues here that don't also affect plain ALSA. If there are any issues then it would seem better to resolve these within the current framework rather than completely discarding the entire existing infrastructure.
Louis meant ALSA rather than ASOC. We use burst transfers to reduce round-trip delay, the whole notion of periods/period elapsed/ring buffer doesn't make sense here and there is in-band signalling that should not be interpreted as samples. If ALSA had a simplified API for byte streams sent over a serial output, we would have no problems using it and of course ASOC would be used then.
+enum mrst_ssp_mode {
- SSP_IN_NORMAL_MODE = 0x0,
- SSP_IN_NETWORK_MODE
+};
A lot of this stuff looks suspicously like the SSP ports in Marvell CPUs (which were obviously Intel originally).
If it ain't broke don't fix it. :-)
-Pierre
On Tue, 2010-10-19 at 17:48 -0500, pl bossart wrote:
As this is used to transfer speech frames from/to cellular modem that have specific timing constraints (and modem also uses the I2S path to send some side-info), the Alsa SoC interface cannot be used.What makes you say this? You have provided no detail on what problems you believe exist and since ASoC is a *very* thin wrapper around the core ALSA for DMA stuff it is very surprising that you would see any issues here that don't also affect plain ALSA. If there are any issues then it would seem better to resolve these within the current framework rather than completely discarding the entire existing infrastructure.
Louis meant ALSA rather than ASOC. We use burst transfers to reduce round-trip delay, the whole notion of periods/period elapsed/ring buffer doesn't make sense here and there is in-band signalling that should not be interpreted as samples. If ALSA had a simplified API for byte streams sent over a serial output, we would have no problems using it and of course ASOC would be used then.
Is the inband signaling here done in software ? I'd expect this to be multiplexed in the DAI by the hardware leaving the software to send PCM bursts to the CODEC/MODEM/whatever like Peter's DAC33 driver.
Liam
Is the inband signaling here done in software ? I'd expect this to be multiplexed in the DAI by the hardware leaving the software to send PCM bursts to the CODEC/MODEM/whatever like Peter's DAC33 driver.
No, this signaling is handled by sw in user space, it's all modem specific. -Pierre
On Tue, Oct 19, 2010 at 05:48:23PM -0500, pl bossart wrote:
Louis meant ALSA rather than ASOC. We use burst transfers to reduce round-trip delay, the whole notion of periods/period elapsed/ring buffer doesn't make sense here and there is in-band signalling that
Actually the burst mode stuff has been done with TLV320DAC33, though more for power consumption reduction than for reducing RTT.
should not be interpreted as samples. If ALSA had a simplified API for byte streams sent over a serial output, we would have no problems using it and of course ASOC would be used then.
Non-audio data in-band is more of a problem, though, as is data that doesn't at the end of the day map down to periodic data.
participants (4)
-
Le Gall, Louis -
Liam Girdwood -
Mark Brown -
pl bossart