[alsa-devel] [PATCH 0/6] ASoC: 4 channel support for twl4030 and omap-mcbsp
Hello,
This series adds support for four channel DSP_A or DSP_B on omap-mcbsp and four channel support for the twl4030 codec (in Option1).
Constrains added to deal with the channel count in twl4030 codec driver.
As an example, the board file for Beagle is modified to add support for stereo and TDM mode depending on the stream's channel count, so the stereo and the four channel mode are supported on Beagle.
Please note that patch #2 modifies also the DSP_B mode to have single phase configuration, s since I think that is the correct for that mode also.
--- Peter Ujfalusi (6): ASoC: OMAP mcbsp: Add DSP_A support ASoC: OMAP mcbsp: Add 4 channel support ASoC: TWL4030: Enable all audio paths ASoC: TWL4030: Add 4 channel TDM support ASoC: TWL4030: Add constraints for 4 channel mode ASoC: Beagle: Add support for 4 channel mode
sound/soc/codecs/twl4030.c | 24 ++++++++++++++++++++---- sound/soc/omap/omap-mcbsp.c | 25 +++++++++++++++++++------ sound/soc/omap/omap3beagle.c | 26 ++++++++++++++++++-------- 3 files changed, 57 insertions(+), 18 deletions(-)
Add SND_SOC_DAIFMT_DSP_A support for omap-mcbsp. The configuration for DSP_A and DSP_B is the same.
Signed-off-by: Peter Ujfalusi peter.ujfalusi@nokia.com --- sound/soc/omap/omap-mcbsp.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index 9c09b94..d88e4cd 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -282,6 +282,7 @@ static int omap_mcbsp_dai_hw_params(struct snd_pcm_substream *substream, regs->srgr1 |= FWID(wlen - 1); break; case SND_SOC_DAIFMT_DSP_B: + case SND_SOC_DAIFMT_DSP_A: regs->srgr2 |= FPER(wlen * channels - 1); regs->srgr1 |= FWID(wlen * channels - 2); break; @@ -325,6 +326,7 @@ static int omap_mcbsp_dai_set_dai_fmt(struct snd_soc_dai *cpu_dai, regs->xcr2 |= XDATDLY(1); break; case SND_SOC_DAIFMT_DSP_B: + case SND_SOC_DAIFMT_DSP_A: /* 0-bit data delay */ regs->rcr2 |= RDATDLY(0); regs->xcr2 |= XDATDLY(0);
Add 4 channel support (with DSP_A format) to omap-mcbsp. This mode is used by the twl4030 codec, when it is configured in Option2 mode.
Also fixes the DSP_B mode, since it has to have single-phase configuration.
Signed-off-by: Peter Ujfalusi peter.ujfalusi@nokia.com --- sound/soc/omap/omap-mcbsp.c | 23 +++++++++++++++++------ 1 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index d88e4cd..eca50cc 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -216,6 +216,7 @@ static int omap_mcbsp_dai_hw_params(struct snd_pcm_substream *substream, int dma, bus_id = mcbsp_data->bus_id, id = cpu_dai->id; int wlen, channels; unsigned long port; + unsigned int format;
if (cpu_class_is_omap1()) { dma = omap1_dma_reqs[bus_id][substream->stream]; @@ -243,12 +244,22 @@ static int omap_mcbsp_dai_hw_params(struct snd_pcm_substream *substream, return 0; }
+ format = mcbsp_data->fmt & SND_SOC_DAIFMT_FORMAT_MASK; channels = params_channels(params); switch (channels) { case 2: - /* Use dual-phase frames */ - regs->rcr2 |= RPHASE; - regs->xcr2 |= XPHASE; + case 4: + if (format == SND_SOC_DAIFMT_DSP_A || + format == SND_SOC_DAIFMT_DSP_B) { + /* Use single-phase frames */ + regs->rcr1 |= RFRLEN1(channels - 1); + regs->xcr1 |= XFRLEN1(channels - 1); + break; + } else { + /* Use dual-phase frames */ + regs->rcr2 |= RPHASE; + regs->xcr2 |= XPHASE; + } case 1: /* Set 1 word per (McBSP) frame */ regs->rcr2 |= RFRLEN2(1 - 1); @@ -276,7 +287,7 @@ static int omap_mcbsp_dai_hw_params(struct snd_pcm_substream *substream, }
/* Set FS period and length in terms of bit clock periods */ - switch (mcbsp_data->fmt & SND_SOC_DAIFMT_FORMAT_MASK) { + switch (format) { case SND_SOC_DAIFMT_I2S: regs->srgr2 |= FPER(wlen * 2 - 1); regs->srgr1 |= FWID(wlen - 1); @@ -490,13 +501,13 @@ static struct snd_soc_dai_ops omap_mcbsp_dai_ops = { .id = (link_id), \ .playback = { \ .channels_min = 1, \ - .channels_max = 2, \ + .channels_max = 4, \ .rates = OMAP_MCBSP_RATES, \ .formats = SNDRV_PCM_FMTBIT_S16_LE, \ }, \ .capture = { \ .channels_min = 1, \ - .channels_max = 2, \ + .channels_max = 4, \ .rates = OMAP_MCBSP_RATES, \ .formats = SNDRV_PCM_FMTBIT_S16_LE, \ }, \
Enable all TX and RX paths on the TWL codec. This is not so nice, but doing it runtime brings quite a bit of challenge, since for example the Digital loopback also needs the RX and TX paths to be enabled.
In power consumption there is no difference keeping these enabled or disabled, but this issue worth to be revisited at some point.
Signed-off-by: Peter Ujfalusi peter.ujfalusi@nokia.com --- sound/soc/codecs/twl4030.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sound/soc/codecs/twl4030.c b/sound/soc/codecs/twl4030.c index bfda7a8..8b44a88 100644 --- a/sound/soc/codecs/twl4030.c +++ b/sound/soc/codecs/twl4030.c @@ -43,7 +43,7 @@ static const u8 twl4030_reg[TWL4030_CACHEREGNUM] = { 0x00, /* this register not used */ 0x91, /* REG_CODEC_MODE (0x1) */ - 0xc3, /* REG_OPTION (0x2) */ + 0xff, /* REG_OPTION (0x2) */ 0x00, /* REG_UNKNOWN (0x3) */ 0x00, /* REG_MICBIAS_CTL (0x4) */ 0x20, /* REG_ANAMICL (0x5) */
Support for 4 channel TDM (SND_SOC_DAIFMT_DSP_A) for twl4030 codec. The channel allocations are: Playback: TDM i2s TWL RX Channel 1 Left SDRL2 Channel 3 Right SDRR2 Channel 2 -- SDRL1 Channel 4 -- SDRR1
Capture: TDM i2s TWL TX Channel 1 Left TXL1 Channel 3 Right TXR1 Channel 2 -- TXL2 Channel 4 -- TXR2
Signed-off-by: Peter Ujfalusi peter.ujfalusi@nokia.com --- sound/soc/codecs/twl4030.c | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/twl4030.c b/sound/soc/codecs/twl4030.c index 8b44a88..927b876 100644 --- a/sound/soc/codecs/twl4030.c +++ b/sound/soc/codecs/twl4030.c @@ -1416,6 +1416,9 @@ static int twl4030_set_dai_fmt(struct snd_soc_dai *codec_dai, case SND_SOC_DAIFMT_I2S: format |= TWL4030_AIF_FORMAT_CODEC; break; + case SND_SOC_DAIFMT_DSP_A: + format |= TWL4030_AIF_FORMAT_TDM; + break; default: return -EINVAL; } @@ -1451,13 +1454,13 @@ struct snd_soc_dai twl4030_dai = { .playback = { .stream_name = "Playback", .channels_min = 2, - .channels_max = 2, + .channels_max = 4, .rates = TWL4030_RATES | SNDRV_PCM_RATE_96000, .formats = TWL4030_FORMATS,}, .capture = { .stream_name = "Capture", .channels_min = 2, - .channels_max = 2, + .channels_max = 4, .rates = TWL4030_RATES, .formats = TWL4030_FORMATS,}, .ops = &twl4030_dai_ops,
Constrain #1: The TDM mode only available in Option1 Constrain #2: The second stream has to have the same number of channels
Signed-off-by: Peter Ujfalusi peter.ujfalusi@nokia.com --- sound/soc/codecs/twl4030.c | 15 ++++++++++++++- 1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/sound/soc/codecs/twl4030.c b/sound/soc/codecs/twl4030.c index 927b876..a1ae6e7 100644 --- a/sound/soc/codecs/twl4030.c +++ b/sound/soc/codecs/twl4030.c @@ -1244,9 +1244,22 @@ static int twl4030_startup(struct snd_pcm_substream *substream) master_runtime->sample_bits, master_runtime->sample_bits);
+ snd_pcm_hw_constraint_minmax(substream->runtime, + SNDRV_PCM_HW_PARAM_CHANNELS, + master_runtime->channels, + master_runtime->channels); + twl4030->slave_substream = substream; - } else + } else { + if (!(twl4030_read_reg_cache(codec, TWL4030_REG_CODEC_MODE) & + TWL4030_OPT_MODE)) + /* In option2 4 channel is not supported */ + snd_pcm_hw_constraint_minmax(substream->runtime, + SNDRV_PCM_HW_PARAM_CHANNELS, + 2, 2); + twl4030->master_substream = substream; + }
return 0; }
This patch adds support for the four channel TDM mode on Beagle board.
Depending on the channel count, the interface needs to be configured differently (I2S for stereo DSP_A for four channels)
Signed-off-by: Peter Ujfalusi peter.ujfalusi@nokia.com --- sound/soc/omap/omap3beagle.c | 26 ++++++++++++++++++-------- 1 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/sound/soc/omap/omap3beagle.c b/sound/soc/omap/omap3beagle.c index fd24a4a..511a570 100644 --- a/sound/soc/omap/omap3beagle.c +++ b/sound/soc/omap/omap3beagle.c @@ -41,23 +41,33 @@ static int omap3beagle_hw_params(struct snd_pcm_substream *substream, struct snd_soc_pcm_runtime *rtd = substream->private_data; struct snd_soc_dai *codec_dai = rtd->dai->codec_dai; struct snd_soc_dai *cpu_dai = rtd->dai->cpu_dai; + unsigned int fmt; int ret;
+ switch (params_channels(params)) { + case 2: /* Stereo I2S mode */ + fmt = SND_SOC_DAIFMT_I2S | + SND_SOC_DAIFMT_NB_NF | + SND_SOC_DAIFMT_CBM_CFM; + break; + case 4: /* Four channel TDM mode */ + fmt = SND_SOC_DAIFMT_DSP_A | + SND_SOC_DAIFMT_IB_NF | + SND_SOC_DAIFMT_CBM_CFM; + break; + default: + return -EINVAL; + } + /* Set codec DAI configuration */ - ret = snd_soc_dai_set_fmt(codec_dai, - SND_SOC_DAIFMT_I2S | - SND_SOC_DAIFMT_NB_NF | - SND_SOC_DAIFMT_CBM_CFM); + ret = snd_soc_dai_set_fmt(codec_dai, fmt); if (ret < 0) { printk(KERN_ERR "can't set codec DAI configuration\n"); return ret; }
/* Set cpu DAI configuration */ - ret = snd_soc_dai_set_fmt(cpu_dai, - SND_SOC_DAIFMT_I2S | - SND_SOC_DAIFMT_NB_NF | - SND_SOC_DAIFMT_CBM_CFM); + ret = snd_soc_dai_set_fmt(cpu_dai, fmt); if (ret < 0) { printk(KERN_ERR "can't set cpu DAI configuration\n"); return ret;
On Mon, Apr 06, 2009 at 03:19:32PM +0300, Peter Ujfalusi wrote:
- switch (params_channels(params)) {
- case 2: /* Stereo I2S mode */
fmt = SND_SOC_DAIFMT_I2S |SND_SOC_DAIFMT_NB_NF |SND_SOC_DAIFMT_CBM_CFM;break;- case 4: /* Four channel TDM mode */
fmt = SND_SOC_DAIFMT_DSP_A |
Might it not be easier to just run in DSP mode all the time?
On Monday 06 April 2009 15:50:29 ext Mark Brown wrote:
On Mon, Apr 06, 2009 at 03:19:32PM +0300, Peter Ujfalusi wrote:
- switch (params_channels(params)) {
- case 2: /* Stereo I2S mode */
fmt = SND_SOC_DAIFMT_I2S |SND_SOC_DAIFMT_NB_NF |SND_SOC_DAIFMT_CBM_CFM;break;- case 4: /* Four channel TDM mode */
fmt = SND_SOC_DAIFMT_DSP_A |Might it not be easier to just run in DSP mode all the time?
The reason for this is the fact that twl4030 in TDM mode only supports 4. channel.
The Audio interface has three modes: codec mode (i2s) - Stereo Left-justified - Stereo Right-justified - Stereo TDM - 4 channels
On Mon, Apr 06, 2009 at 03:19:29PM +0300, Peter Ujfalusi wrote:
Enable all TX and RX paths on the TWL codec.
What does this mean by "enable" - I'm guessing it's powering blocks within the CODEC rather than connecting any audio paths?
This is not so nice, but doing it runtime brings quite a bit of challenge, since for example the Digital loopback also needs the RX and TX paths to be enabled.
What are the problems other than loopback (which really needs digital routing to work properly, though I've never seen much demand for it outside of testing)? Powering everything is probably fine, I'm just wondering if this is due to the hardware or the core.
On Monday 06 April 2009 15:45:21 ext Mark Brown wrote:
On Mon, Apr 06, 2009 at 03:19:29PM +0300, Peter Ujfalusi wrote:
Enable all TX and RX paths on the TWL codec.
What does this mean by "enable" - I'm guessing it's powering blocks within the CODEC rather than connecting any audio paths?
The TRM calls these as Audio/Voice digital filters. In effect, they enable the shifting out bits from the Capture path to the bus and shifting in bits on the Playback side.
The original driver had these filters enabled - all the time - for the digital filters needed for the i2s mode (AudioRX2 L/r, AudioTX1 L/R), in TDM mode all 4 filters on Capture and Playback need to be enabled.
This is not so nice, but doing it runtime brings quite a bit of challenge, since for example the Digital loopback also needs the RX and TX paths to be enabled.
What are the problems other than loopback (which really needs digital routing to work properly, though I've never seen much demand for it outside of testing)? Powering everything is probably fine, I'm just wondering if this is due to the hardware or the core.
The digital loopback needs the AudioTX1 L/R and AudioRX2 L/R enabled in order to function, and I have a requirement, that the codec should support it ;)
I had two other implementation for these: a) Enable the needed Digital filters in twl4030_startup based on the channel number and stream type (Playback/Capture). Disable the Digital filters on twl4030_shutdown, based on the just closed stream's parameters. b) Adding another widgets to the DAPM routing paths, so it tries to enable only the needed Digital filters.
There were couple of problems with these: a) Digital loopback was not functioning b) It did enabled other filters, than what it is needed (in stereo mode AudioRX1 L/R and AudioTX2 L/R should not be enabled). I guess this is because the DAPM knows only about streams, but here we can have 2 channel or 4 channel streams, which need to be handled a bit differently.
But as I said, this is not so nice thing to do, so it need to be revisited.
On Tue, Apr 07, 2009 at 07:59:19AM +0300, Peter Ujfalusi wrote:
On Monday 06 April 2009 15:45:21 ext Mark Brown wrote:
What does this mean by "enable" - I'm guessing it's powering blocks within the CODEC rather than connecting any audio paths?
The TRM calls these as Audio/Voice digital filters. In effect, they enable the shifting out bits from the Capture path to the bus and shifting in bits on the Playback side.
Hrm, so this is a routing thing then - from your description I'm a bit surprised that this can be turned on unconditionally since it sounds like it'll give you a sidetone all the time which might not be what people want.
But as I said, this is not so nice thing to do, so it need to be revisited.
It needs digital routing. In the interim another option would be to provide switches to user space, possibly?
On Tuesday 07 April 2009 12:45:59 ext Mark Brown wrote:
On Tue, Apr 07, 2009 at 07:59:19AM +0300, Peter Ujfalusi wrote:
On Monday 06 April 2009 15:45:21 ext Mark Brown wrote:
What does this mean by "enable" - I'm guessing it's powering blocks within the CODEC rather than connecting any audio paths?
The TRM calls these as Audio/Voice digital filters. In effect, they enable the shifting out bits from the Capture path to the bus and shifting in bits on the Playback side.
Hrm, so this is a routing thing then - from your description I'm a bit surprised that this can be turned on unconditionally since it sounds like it'll give you a sidetone all the time which might not be what people want.
Not quite. The sidetone/loopback can be turned off inside of twl4030 with the 'Left Digital Loopback' and 'Right Digital Loopback' set to 0.
With the current implementation the capture path is powered only when there is need for it, which means that ADCs, TX PGAs are powered off. So even if the Digital filters are enabled on the capture end, you will not see data going to the bus (from twl4030).
I think the twl4030 codec still holds some interesting 'features'...
But as I said, this is not so nice thing to do, so it need to be revisited.
It needs digital routing. In the interim another option would be to provide switches to user space, possibly?
It is possible to add 8 switches, or 4 stereo switch - I have to check the code ;) Placing them to the correct location in the paths might be possible. I have to check it.
But than there is this Option selection... twl4030 has two modes: Option1 and Option2. In same cases the config is the same, but in most of the cases it behaves like two different codec... Option1 has only HiFi interface with up to 4 channel RX/TX The interface for the host processor in this case: i2s, l_just, r_just or TDM (stereo or 4 channel).
Option2 has HiFi (up to 2 channel RX/TX) + Voice stereo uplink and mono downlink. Than it has interface: i2s, l_just, r_just (stereo only) PCM BT
Some of the bits in the OPTION register (and also in other registers) means totally different things (or not valid for the mode) in Option1 than in Option2...
On Tue, Apr 07, 2009 at 01:30:22PM +0300, Peter Ujfalusi wrote:
On Tuesday 07 April 2009 12:45:59 ext Mark Brown wrote:
Hrm, so this is a routing thing then - from your description I'm a bit surprised that this can be turned on unconditionally since it sounds like it'll give you a sidetone all the time which might not be what people want.
Not quite. The sidetone/loopback can be turned off inside of twl4030 with the 'Left Digital Loopback' and 'Right Digital Loopback' set to 0.
Ah, so there's a separate control to enable the path.
I think the twl4030 codec still holds some interesting 'features'...
It certainly seems that way.
On Mon, Apr 06, 2009 at 03:19:27PM +0300, Peter Ujfalusi wrote:
Add SND_SOC_DAIFMT_DSP_A support for omap-mcbsp. The configuration for DSP_A and DSP_B is the same.
That doesn't sound right - the two formats do differ on the wire. In mode B the MSB of data is transmitted along with the LRC pulse while in mode A it is transmitted after the trailing edge of the LRC pulse.
On Monday 06 April 2009 15:22:33 ext Mark Brown wrote:
On Mon, Apr 06, 2009 at 03:19:27PM +0300, Peter Ujfalusi wrote:
Add SND_SOC_DAIFMT_DSP_A support for omap-mcbsp. The configuration for DSP_A and DSP_B is the same.
That doesn't sound right - the two formats do differ on the wire. In mode B the MSB of data is transmitted along with the LRC pulse while in mode A it is transmitted after the trailing edge of the LRC pulse.
That is why I have asked previously about these... I'm still a bit confused, but at the end (I think) the configuration in omap-mcbsp is right for the twl4030: regs->srgr2 |= FPER(wlen * channels - 1); regs->srgr1 |= FWID(wlen * channels - 2); and /* 0-bit data delay */ regs->rcr2 |= RDATDLY(0); regs->xcr2 |= XDATDLY(0);
I'll revisit this.
Thanks, Péter
On Monday 06 April 2009 15:37:58 Ujfalusi Peter (Nokia-D/Tampere) wrote:
On Monday 06 April 2009 15:22:33 ext Mark Brown wrote:
On Mon, Apr 06, 2009 at 03:19:27PM +0300, Peter Ujfalusi wrote:
Add SND_SOC_DAIFMT_DSP_A support for omap-mcbsp. The configuration for DSP_A and DSP_B is the same.
That doesn't sound right - the two formats do differ on the wire. In mode B the MSB of data is transmitted along with the LRC pulse while in mode A it is transmitted after the trailing edge of the LRC pulse.
That is why I have asked previously about these... I'm still a bit confused, but at the end (I think) the configuration in omap-mcbsp is right for the twl4030: regs->srgr2 |= FPER(wlen * channels - 1); regs->srgr1 |= FWID(wlen * channels - 2); and /* 0-bit data delay */ regs->rcr2 |= RDATDLY(0); regs->xcr2 |= XDATDLY(0);
I'll revisit this.
I have taken a look about the DSP_A and DSP_B modes in omap-mcbsp. The only board uses the DSP_B mode is the osk5912 with the tlv320aic23 codec. I have downloaded the data sheet for the tlv320aic23 and I think that the DSP mode in tlv320aic23 is identical to the TDM mode in twl4030 except for the clock polarity twl4030: Samples the data on falling edge, shifts data out (and changes the FS) on rising edge tlv320aic23: Samples the data on rising, shifts data out (and changes the FS) on falling edge
This difference is taken care with the SND_SOC_DAIFMT_NB_IF (osk5912) and SND_SOC_DAIFMT_IB_NF (beagle).
I would say, that I'm still confused over this...
References: tlv320aic23: http://focus.ti.com/lit/ds/slws106d/slws106d.pdf Page 28 (3-8) twl4030: http://focus.tij.co.jp/jp/lit/ug/swcu050b/swcu050b.pdf Page 712 (TDM mode, Sample length 16 bits; Word length 16 bits)
On Tue, Apr 07, 2009 at 08:19:11AM +0300, Peter Ujfalusi wrote:
twl4030: Samples the data on falling edge, shifts data out (and changes the FS) on rising edge tlv320aic23: Samples the data on rising, shifts data out (and changes the FS) on falling edge
What ASoC expects for DSP mode is that the data can be sampled on either the first (mode B) or second (mode A) rising edge of BCLK after a rising edge of LRCLK. This implies that the data should be driven on the falling edge of BCLK.
The TLV320AIC23 can do either mode - the description on page 24 matches exactly. Unless I'm missing something the inversion of the frame clock for osk5912 looks like a mistake. I'd need to read the code a bit more closely to check I've not missed something but it looks like the codec driver is never actually setting LRP so it's got the mode the wrong way round for the one it supports.
The TWL4030 datasheet does not appear to be a model of clarity in this area but it looks awfully like mode A with an inverted bit clock (the data appears to be being driven rather than sampled on the rising edge but the first bit does start on the falling edge of the frame clock). This means the Beagle code looks about right unless I'm misreading something.
On Wednesday 08 April 2009 01:14:05 ext Mark Brown wrote:
On Tue, Apr 07, 2009 at 08:19:11AM +0300, Peter Ujfalusi wrote:
twl4030: Samples the data on falling edge, shifts data out (and changes the FS) on rising edge tlv320aic23: Samples the data on rising, shifts data out (and changes the FS) on falling edge
What ASoC expects for DSP mode is that the data can be sampled on either the first (mode B) or second (mode A) rising edge of BCLK after a rising edge of LRCLK. This implies that the data should be driven on the falling edge of BCLK.
The TLV320AIC23 can do either mode - the description on page 24 matches exactly. Unless I'm missing something the inversion of the frame clock for osk5912 looks like a mistake. I'd need to read the code a bit more closely to check I've not missed something but it looks like the codec driver is never actually setting LRP so it's got the mode the wrong way round for the one it supports.
I have been also wondering about the missing LRP handling, but I do not have access to osk5912 board neither to tlv320aic32 codec...
The TWL4030 datasheet does not appear to be a model of clarity in this area but it looks awfully like mode A with an inverted bit clock (the data appears to be being driven rather than sampled on the rising edge but the first bit does start on the falling edge of the frame clock).
Well, in general there are lots of these kind of 'small' details missing from the documentation. One just have to try it out and see how it behaves ;)
This means the Beagle code looks about right unless I'm misreading something.
Does it means that the DSP_A addition is also correct? I have it drawn to paper, how the configuration in omap-mcbsp used by the beagle in 4 channel mode would look like, and it does look 100% as the TDM mode described in the twl datasheet...
BTW: when the twl is in 4 channel mode, it has to be the master on the bus (small thing, since twl usually is the master on the bus anyway)
On Wed, Apr 08, 2009 at 09:01:18AM +0300, Peter Ujfalusi wrote:
Does it means that the DSP_A addition is also correct? I have it drawn to paper, how the configuration in omap-mcbsp used by the beagle in 4 channel mode would look like, and it does look 100% as the TDM mode described in the twl datasheet...
I don't know what the OMAP itself is doing, I'm not familiar with that processor at all. The reason I had a concern was that DSP A and DSP B differ so there's no way you should be able to set both up with the same case statement. This means that either your addition is incorrect or the existing code is incorrect - I don't know which.
On Wed, 8 Apr 2009 00:14:05 +0200 ext Mark Brown broonie@sirena.org.uk wrote:
The TWL4030 datasheet does not appear to be a model of clarity in this area but it looks awfully like mode A with an inverted bit clock (the data appears to be being driven rather than sampled on the rising edge but the first bit does start on the falling edge of the frame clock). This means the Beagle code looks about right unless I'm misreading something.
What I've seen few codec specs there is no uniform way for different DSP formats between their specifications except Wolfson codecs. So I use to keep those as a reference and match codec accordingly. Like in AIC3x where bit-clock polarity is fixed.
Jarkko
On Wed, Apr 08, 2009 at 09:08:16AM +0300, Jarkko Nikula wrote:
What I've seen few codec specs there is no uniform way for different DSP formats between their specifications except Wolfson codecs. So I use to keep those as a reference and match codec accordingly. Like in AIC3x where bit-clock polarity is fixed.
Well, often there's not much polarity but generally the device will offer something that can be expressed as a combination of mode A or B and BCLK inversion. The Wolfson devices are the way they are mostly to give them the flexibility to interoperate with whatever the other device is able to do - there's no reason to select any particular clocking mode other than for interoperability.
On Mon, 6 Apr 2009 14:19:26 +0200 "Ujfalusi Peter (Nokia-D/Tampere)" peter.ujfalusi@nokia.com wrote:
As an example, the board file for Beagle is modified to add support for stereo and TDM mode depending on the stream's channel count, so the stereo and the four channel mode are supported on Beagle.
Peter, before starting to hack on this, did I interpret TWL block diagram correctly so that I can route both R1/R2 and L1/L2 into same outputs? It seems that only codec outputs available in Beagle are the HSOL and HSOR. There seems to be no test pads for PreDriv and IHF outputs.
Jarkko
On Tuesday 07 April 2009 08:45:36 Nikula Jarkko (Nokia-D/Helsinki) wrote:
On Mon, 6 Apr 2009 14:19:26 +0200
"Ujfalusi Peter (Nokia-D/Tampere)" peter.ujfalusi@nokia.com wrote:
As an example, the board file for Beagle is modified to add support for stereo and TDM mode depending on the stream's channel count, so the stereo and the four channel mode are supported on Beagle.
Peter, before starting to hack on this, did I interpret TWL block diagram correctly so that I can route both R1/R2 and L1/L2 into same outputs? It seems that only codec outputs available in Beagle are the HSOL and HSOR. There seems to be no test pads for PreDriv and IHF outputs.
With the current implementation there is a mux on Headset outputs: 'HeadsetL Mux': Off, DACL1, DACL2 'HeadsetR Mux': Off, DACR1, DACR2
So you can select which Left channel (Channel 1 or 2 in TDM) goes to HSOL and which Right channel (channel 3 or 4 in TDM) goes to HSOR.
In i2s/stereo mode the codec receives the data on DACL2/DACR2.
I have been misled by the TRM on these, since it seams that these can be mixed on the output (and not muxes, as they are implemented at the moment).
There has been proposed patches sent to alsa-devel some time ago, which fixed these mistakes...
Jarkko
On Mon, 6 Apr 2009 14:19:26 +0200 "Ujfalusi Peter (Nokia-D/Tampere)" peter.ujfalusi@nokia.com wrote:
As an example, the board file for Beagle is modified to add support for stereo and TDM mode depending on the stream's channel count, so the stereo and the four channel mode are supported on Beagle.
What's actually state of the TDM container format support in ASoC? I see there is that set_tdm_slot callback in struct snd_soc_dai_ops but only pxa-ssp.c is setting it currently.
Am I correct that DSP_x, I2S are not multichannel but should be embedded into TDM if multichannel operation is wanted?
So should Peter's these two patches take this API into use?
"[PATCH 2/6] ASoC: OMAP mcbsp: Add 4 channel support" "[PATCH 6/6] ASoC: Beagle: Add support for 4 channel mode"
Jarkko
On Wed, Apr 08, 2009 at 09:23:23AM +0300, Jarkko Nikula wrote:
What's actually state of the TDM container format support in ASoC?
It's largely punted to the machine driver.
I see there is that set_tdm_slot callback in struct snd_soc_dai_ops but only pxa-ssp.c is setting it currently.
Right. A large proprortion of the Wolfson codecs could set it too, as could many platforms that generate clocks manually, but it's not widely used since there's relatively few use cases in public hardware.
Am I correct that DSP_x, I2S are not multichannel but should be embedded into TDM if multichannel operation is wanted?
TDM mode is more intended for situations where a device is only going to be paying attention to some of the timeslots - for example, if you have a CPU, CODEC and baseband processor sharing one set of data lines and want to send data between multiple devices.
For I2S the normal multichannel implementation is to use multiple data lines with shared clock lines - there's no natural extension within the one data line - so TDM mode would be needed. For DSP mode there's a more natural extension (just transmit additional channel data after the final one, you're allowed extra bit clocks anyway) so it's less needed.
So should Peter's these two patches take this API into use?
"[PATCH 2/6] ASoC: OMAP mcbsp: Add 4 channel support" "[PATCH 6/6] ASoC: Beagle: Add support for 4 channel mode"
For DSP mode it's up to you; personally I wouldn't bother unless the code supports ignoring some of the timeslots. It's more likely that any other devices sharing the DAI would need TDM to pick out or fill the data streams relevant to them.
participants (4)
-
Jarkko Nikula -
Mark Brown -
Mark Brown -
Peter Ujfalusi