2009/7/27 Mark Brown broonie@opensource.wolfsonmicro.com:
On Mon, Jul 27, 2009 at 06:00:48PM +0800, Barry Song wrote:
2009/7/25 Mark Brown broonie@opensource.wolfsonmicro.com:
Looking at the code it appears that the main difference is that your TDM mode always configures the DMA layout for 8 channel blocks. This
I2S is not a special case of TDM with only left and right two slots for SPORT interface. I2S coordinates with TDM in SPORT, but not a part of TDM. TDM require different hardware configuration with I2S, not only different slot number. One is "Stereo Serial Operation" mode of SPORT, the other one is "Multichannel Operation" mode. They are incompatible at the same time.
Right, but that's something I'd expect to be handleable at run time - and in any case, the multi-channel varaint can drop down to only two channels.
Mainly due to hardware, it's really difficult for us to control the memory layout on the fly. That causes much trouble in hardware and driver reliability. Datasheet claims DMA buffer should be fixed while SPORT is enabled, but also claims the layout may be changed while SPORT is disabled. So it's maybe possible for us to change the SPORT api to support the configuration on the fly with a SPORT shutdown, then i2s, tdm even ac97 can all use them to reduce the amount of code duplication. But it need much work on debugging and testing to make it work and reliable. So how about to patch it later as an individual project since the changes will involve sport, i2s, ac97 and tdm?
OK, if the hardware is as difficult to use as that I guess the current situation is adequate. I'll check over your patch later but the code was almost ready last time so I don't anticipate any problems. However...
On the other hand, hardware board connection decides the I2S/TDM mode directly. It's needless to switch between I2S and TDM dynamically. For TDM mode, board driver can refer to the TDM instance, for I2S mode,
Are you saying that a physically different SPORT or other hardware configuration on the CPU is required to use TDM mode? The impression given by the drivers has always been that this is some kind of generic synchronous serial port and the way the SPORT number is set up seems to support that. Could you go into more detail here, please - this would be a very unusual implementation decision for a CPU.
Here I means the different hardware configuration, and the semantic of pins has some differences too for I2S and TDM.
...are you sure there's a different meaning for the external pins - what are these differences? If they're not just related to the number of bit clock cycles per frame clock then are you sure it will interoperate with other DSP mode devices?
The main differences are the usages. For I2S mode, each SPORT has two sets of independent transmit and receive pins. Every set of pins support a stereo receive or transmit. So a typical hardware connection to support multi-channels in I2S mode is like attached "I2S.gif". Many pins are connected, and the main characteristic is using multi-sets of pins concurrently. And in the codec side, DSDATA1-n get the semantic as "DACx Data In", ASDATA1-n are "ADCx Data Out". For TDM mode, the main characteristic is using time-sharing to a set of pins. A typical connection for TDM is like "tdm.gif". Only tx/rx/clk/sync are connected to codec. And in codec side, DSDATA1 gets the semantic as "DAC TDM Data In", DSDATA2-n are not "DACx Data In" again. ASDATA1 becomes "ADC TDM Data Out", ASDATA2-n are not "ADCx Data Out" again. And another difference is when multichannel mode is enabled on a SPORT, both the transmitter and the receiver use RFS, which is only a receive sync in I2S mode, as a frame sync. The RFS signal is used to synchronize the channels and restart each multichannel sequence. TFS, which is "Transmit Frame Sync" in I2S mode, becomes TDV "transmit data valid" for external logic in TDM. In TDM mode, the SPORT can interoperate with other DSP mode devices considering they are using "tx/rx/clk/sync" pins. That's very common.
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
