[PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matt Flax]

This patch set lets the ASoC system specify that an IC between the SoC and codec
is master. This is intended to put both the SoC and Codec into slave modes.

By default un-patched SoC and Codec drivers will return -EINVAL if they aren't
enabled and tested for this mode.

soc-dia.h has the new SND_SOC_DAIFMT_IBM_IFM definition set as :
#define SND_SOC_DAIFMT_IBM_IFM		(5 << 12) /* IC clk & FRM master */

The cs42xx8 codec driver is enabled for this mode and so too is the BCM2835
SoC driver. This forms a chain : bcm2835<=>IC<=>cs42xx8
where the IC is bit and frame master.

Matt Flax (3):
  ASoC : Add an IC bit and frame master mode (SoC and Codec slave).
  ASoC: cs42xx8: allow IC master mode.
  ASoC: bcm2835: Add mutichannel mode in DSP and IC master modes.

 include/sound/soc-dai.h     |  9 ++++++---
 sound/soc/bcm/bcm2835-i2s.c | 21 ++++++++++++++++++++-
 sound/soc/codecs/cs42xx8.c  |  1 +
 3 files changed, 27 insertions(+), 4 deletions(-)

-- 
2.7.4

[PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matt Flax]

This patch set lets the ASoC system specify that an IC between the SoC and codec
is master. This is intended to put both the SoC and Codec into slave modes.

By default un-patched SoC and Codec drivers will return -EINVAL if they aren't
enabled and tested for this mode.

soc-dia.h has the new SND_SOC_DAIFMT_IBM_IFM definition set as :
#define SND_SOC_DAIFMT_IBM_IFM		(5 << 12) /* IC clk & FRM master */

The cs42xx8 codec driver is enabled for this mode and so too is the BCM2835
SoC driver. This forms a chain : bcm2835<=>IC<=>cs42xx8
where the IC is bit and frame master.

Matt Flax (3):
  ASoC : Add an IC bit and frame master mode (SoC and Codec slave).
  ASoC: cs42xx8: allow IC master mode.
  ASoC: bcm2835: Add mutichannel mode in DSP and IC master modes.

 include/sound/soc-dai.h     |  9 ++++++---
 sound/soc/bcm/bcm2835-i2s.c | 21 ++++++++++++++++++++-
 sound/soc/codecs/cs42xx8.c  |  1 +
 3 files changed, 27 insertions(+), 4 deletions(-)

-- 
2.7.4

[PATCH 1/3] ASoC : Add an IC bit and frame master mode (SoC and Codec slave).

[Matt Flax]

This patch adds a new clock mode to the SoC system. The new mode
allows for an IC (between the SoC and the Codec) to be bit and
frame master.

As SoC and codec drivers default to return -EINVAL, this new mode
can not set either as master.

Signed-off-by: Matt Flax <flatmax@flatmax.org>
---
 include/sound/soc-dai.h | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/include/sound/soc-dai.h b/include/sound/soc-dai.h
index 200e1f0..22f516f 100644
--- a/include/sound/soc-dai.h
+++ b/include/sound/soc-dai.h
@@ -77,14 +77,17 @@ struct snd_compr_stream;
 /*
  * DAI hardware clock masters.
  *
- * This is wrt the codec, the inverse is true for the interface
- * i.e. if the codec is clk and FRM master then the interface is
- * clk and frame slave.
+ * SND_SOC_DAIFMT_C* definitions are wrt the codec, the inverse is true
+ * for the interface. i.e. if the codec is clk and FRM master then the
+ * interface is clk and frame slave.
+ * The SND_SOC_DAIFMT_IBM_IFM indicates that an IC inbetween the codec and SoC
+ * is master. In SND_SOC_DAIFMT_IBM_IFM mode both the codec and SoC are slaves.
  */
 #define SND_SOC_DAIFMT_CBM_CFM		(1 << 12) /* codec clk & FRM master */
 #define SND_SOC_DAIFMT_CBS_CFM		(2 << 12) /* codec clk slave & FRM master */
 #define SND_SOC_DAIFMT_CBM_CFS		(3 << 12) /* codec clk master & frame slave */
 #define SND_SOC_DAIFMT_CBS_CFS		(4 << 12) /* codec clk & FRM slave */
+#define SND_SOC_DAIFMT_IBM_IFM		(5 << 12) /* IC clk & FRM master */
 
 #define SND_SOC_DAIFMT_FORMAT_MASK	0x000f
 #define SND_SOC_DAIFMT_CLOCK_MASK	0x00f0
-- 
2.7.4

[PATCH 1/3] ASoC : Add an IC bit and frame master mode (SoC and Codec slave).

[Matt Flax]

This patch adds a new clock mode to the SoC system. The new mode
allows for an IC (between the SoC and the Codec) to be bit and
frame master.

As SoC and codec drivers default to return -EINVAL, this new mode
can not set either as master.

Signed-off-by: Matt Flax <flatmax@flatmax.org>
---
 include/sound/soc-dai.h | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/include/sound/soc-dai.h b/include/sound/soc-dai.h
index 200e1f0..22f516f 100644
--- a/include/sound/soc-dai.h
+++ b/include/sound/soc-dai.h
@@ -77,14 +77,17 @@ struct snd_compr_stream;
 /*
  * DAI hardware clock masters.
  *
- * This is wrt the codec, the inverse is true for the interface
- * i.e. if the codec is clk and FRM master then the interface is
- * clk and frame slave.
+ * SND_SOC_DAIFMT_C* definitions are wrt the codec, the inverse is true
+ * for the interface. i.e. if the codec is clk and FRM master then the
+ * interface is clk and frame slave.
+ * The SND_SOC_DAIFMT_IBM_IFM indicates that an IC inbetween the codec and SoC
+ * is master. In SND_SOC_DAIFMT_IBM_IFM mode both the codec and SoC are slaves.
  */
 #define SND_SOC_DAIFMT_CBM_CFM		(1 << 12) /* codec clk & FRM master */
 #define SND_SOC_DAIFMT_CBS_CFM		(2 << 12) /* codec clk slave & FRM master */
 #define SND_SOC_DAIFMT_CBM_CFS		(3 << 12) /* codec clk master & frame slave */
 #define SND_SOC_DAIFMT_CBS_CFS		(4 << 12) /* codec clk & FRM slave */
+#define SND_SOC_DAIFMT_IBM_IFM		(5 << 12) /* IC clk & FRM master */
 
 #define SND_SOC_DAIFMT_FORMAT_MASK	0x000f
 #define SND_SOC_DAIFMT_CLOCK_MASK	0x00f0
-- 
2.7.4

Re: [PATCH 1/3] ASoC : Add an IC bit and frame master mode (SoC and Codec slave).

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 444 bytes --]

On Sat, Feb 25, 2017 at 04:03:12PM +1100, Matt Flax wrote:
> This patch adds a new clock mode to the SoC system. The new mode
> allows for an IC (between the SoC and the Codec) to be bit and
> frame master.
> 
> As SoC and codec drivers default to return -EINVAL, this new mode
> can not set either as master.

I think I'd expect to see this device represented as a CODEC with two
CODEC-CODEC links rather than transparently as here.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

[PATCH 1/3] ASoC : Add an IC bit and frame master mode (SoC and Codec slave).

[Mark Brown]

On Sat, Feb 25, 2017 at 04:03:12PM +1100, Matt Flax wrote:
> This patch adds a new clock mode to the SoC system. The new mode
> allows for an IC (between the SoC and the Codec) to be bit and
> frame master.
> 
> As SoC and codec drivers default to return -EINVAL, this new mode
> can not set either as master.

I think I'd expect to see this device represented as a CODEC with two
CODEC-CODEC links rather than transparently as here.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170315/8c2864b7/attachment.sig>

[PATCH 2/3] ASoC: cs42xx8: allow IC master mode.

[Matt Flax]

This patch allows the cs42xx8 to be put into slave mode when an IC
(between this codec and the SoC) is master.

It sets slave mode by treating SND_SOC_DAIFMT_IBM_IFM in the same way
it treats SND_SOC_DAIFMT_CBS_CFS.

Signed-off-by: Matt Flax <flatmax@flatmax.org>
---
 sound/soc/codecs/cs42xx8.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/codecs/cs42xx8.c b/sound/soc/codecs/cs42xx8.c
index c1785bd..34f9adb 100644
--- a/sound/soc/codecs/cs42xx8.c
+++ b/sound/soc/codecs/cs42xx8.c
@@ -235,6 +235,7 @@ static int cs42xx8_set_dai_fmt(struct snd_soc_dai *codec_dai,
 	/* Set master/slave audio interface */
 	switch (format & SND_SOC_DAIFMT_MASTER_MASK) {
 	case SND_SOC_DAIFMT_CBS_CFS:
+	case SND_SOC_DAIFMT_IBM_IFM:
 		cs42xx8->slave_mode = true;
 		break;
 	case SND_SOC_DAIFMT_CBM_CFM:
-- 
2.7.4

[PATCH 2/3] ASoC: cs42xx8: allow IC master mode.

[Matt Flax]

This patch allows the cs42xx8 to be put into slave mode when an IC
(between this codec and the SoC) is master.

It sets slave mode by treating SND_SOC_DAIFMT_IBM_IFM in the same way
it treats SND_SOC_DAIFMT_CBS_CFS.

Signed-off-by: Matt Flax <flatmax@flatmax.org>
---
 sound/soc/codecs/cs42xx8.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/codecs/cs42xx8.c b/sound/soc/codecs/cs42xx8.c
index c1785bd..34f9adb 100644
--- a/sound/soc/codecs/cs42xx8.c
+++ b/sound/soc/codecs/cs42xx8.c
@@ -235,6 +235,7 @@ static int cs42xx8_set_dai_fmt(struct snd_soc_dai *codec_dai,
 	/* Set master/slave audio interface */
 	switch (format & SND_SOC_DAIFMT_MASTER_MASK) {
 	case SND_SOC_DAIFMT_CBS_CFS:
+	case SND_SOC_DAIFMT_IBM_IFM:
 		cs42xx8->slave_mode = true;
 		break;
 	case SND_SOC_DAIFMT_CBM_CFM:
-- 
2.7.4

[PATCH 3/3] ASoC: bcm2835: Add mutichannel mode in DSP and IC master modes.

[Matt Flax]

This patch adds multitrack capability if in DSP mode A and an IC
(between the SoC and codec) is master.

In bcm2835_i2s_startup, snd_pcm_hw_constraint_single is used to set
channels to 8 if both SND_SOC_DAIFMT_IBM_IFM and SND_SOC_DAIFMT_DSP_A
are set. Otherwise, channels are set to 2. These settings are
accomplished using the SNDRV_PCM_HW_PARAM_CHANNELS variable.

This patch protects against DSP mode misuse by failing if either the
SoC or Codec is master. i.e. if SND_SOC_DAIFMT_DSP_A is chosen but not
in SND_SOC_DAIFMT_IBM_IFM mode, then -EINVAL is returned.

In bcm2835_i2s_shutdown the channels are set to 2 by default.

In bcm2835_i2s_hw_params, DSP mode A format is now an option.
Before replicating the format variable (from ch2 to ch1) for
register loading, requested channels are checked to be either 2 or 8.
This can be expanded later to accomodate other channel counts if
supported by the sound card hardware.

It has been tested to work with both a regular stereo sound card and
an 8 channel sound card.

Signed-off-by: Matt Flax <flatmax@flatmax.org>
---
 sound/soc/bcm/bcm2835-i2s.c | 21 ++++++++++++++++++++-
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/sound/soc/bcm/bcm2835-i2s.c b/sound/soc/bcm/bcm2835-i2s.c
index 6ba2049..dbfecb3 100644
--- a/sound/soc/bcm/bcm2835-i2s.c
+++ b/sound/soc/bcm/bcm2835-i2s.c
@@ -296,6 +296,7 @@ static int bcm2835_i2s_hw_params(struct snd_pcm_substream *substream,
 
 	switch (dev->fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
 	case SND_SOC_DAIFMT_I2S:
+	case SND_SOC_DAIFMT_DSP_A:
 		data_delay = 1;
 		break;
 	default:
@@ -312,6 +313,7 @@ static int bcm2835_i2s_hw_params(struct snd_pcm_substream *substream,
 
 	switch (params_channels(params)) {
 	case 2:
+	case 8:
 		format = BCM2835_I2S_CH1(format) | BCM2835_I2S_CH2(format);
 		format |= BCM2835_I2S_CH1(BCM2835_I2S_CHPOS(ch1pos));
 		format |= BCM2835_I2S_CH2(BCM2835_I2S_CHPOS(ch2pos));
@@ -526,7 +528,20 @@ static int bcm2835_i2s_startup(struct snd_pcm_substream *substream,
 	regmap_update_bits(dev->i2s_regmap, BCM2835_I2S_CS_A_REG,
 			BCM2835_I2S_STBY, BCM2835_I2S_STBY);
 
-	return 0;
+	/* Only allow 2 channels, unless in DSP mode where an IC (between 
+	 * the SoC and codec) is master.
+	 */
+	if ((dev->fmt & SND_SOC_DAIFMT_FORMAT_MASK)
+					== SND_SOC_DAIFMT_DSP_A)
+		if ((dev->fmt & SND_SOC_DAIFMT_MASTER_MASK)
+					!= SND_SOC_DAIFMT_IBM_IFM)
+			return -EINVAL;
+		else
+			return snd_pcm_hw_constraint_single(substream->runtime,
+						SNDRV_PCM_HW_PARAM_CHANNELS, 8);
+	else
+		return snd_pcm_hw_constraint_single(substream->runtime,
+			SNDRV_PCM_HW_PARAM_CHANNELS, 2);
 }
 
 static void bcm2835_i2s_shutdown(struct snd_pcm_substream *substream,
@@ -549,6 +564,10 @@ static void bcm2835_i2s_shutdown(struct snd_pcm_substream *substream,
 	 * not stop the clock when SND_SOC_DAIFMT_CONT
 	 */
 	bcm2835_i2s_stop_clock(dev);
+
+	/* Default to 2 channels */
+	snd_pcm_hw_constraint_single(substream->runtime,
+			SNDRV_PCM_HW_PARAM_CHANNELS, 2);
 }
 
 static const struct snd_soc_dai_ops bcm2835_i2s_dai_ops = {
-- 
2.7.4

[PATCH 3/3] ASoC: bcm2835: Add mutichannel mode in DSP and IC master modes.

[Matt Flax]

This patch adds multitrack capability if in DSP mode A and an IC
(between the SoC and codec) is master.

In bcm2835_i2s_startup, snd_pcm_hw_constraint_single is used to set
channels to 8 if both SND_SOC_DAIFMT_IBM_IFM and SND_SOC_DAIFMT_DSP_A
are set. Otherwise, channels are set to 2. These settings are
accomplished using the SNDRV_PCM_HW_PARAM_CHANNELS variable.

This patch protects against DSP mode misuse by failing if either the
SoC or Codec is master. i.e. if SND_SOC_DAIFMT_DSP_A is chosen but not
in SND_SOC_DAIFMT_IBM_IFM mode, then -EINVAL is returned.

In bcm2835_i2s_shutdown the channels are set to 2 by default.

In bcm2835_i2s_hw_params, DSP mode A format is now an option.
Before replicating the format variable (from ch2 to ch1) for
register loading, requested channels are checked to be either 2 or 8.
This can be expanded later to accomodate other channel counts if
supported by the sound card hardware.

It has been tested to work with both a regular stereo sound card and
an 8 channel sound card.

Signed-off-by: Matt Flax <flatmax@flatmax.org>
---
 sound/soc/bcm/bcm2835-i2s.c | 21 ++++++++++++++++++++-
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/sound/soc/bcm/bcm2835-i2s.c b/sound/soc/bcm/bcm2835-i2s.c
index 6ba2049..dbfecb3 100644
--- a/sound/soc/bcm/bcm2835-i2s.c
+++ b/sound/soc/bcm/bcm2835-i2s.c
@@ -296,6 +296,7 @@ static int bcm2835_i2s_hw_params(struct snd_pcm_substream *substream,
 
 	switch (dev->fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
 	case SND_SOC_DAIFMT_I2S:
+	case SND_SOC_DAIFMT_DSP_A:
 		data_delay = 1;
 		break;
 	default:
@@ -312,6 +313,7 @@ static int bcm2835_i2s_hw_params(struct snd_pcm_substream *substream,
 
 	switch (params_channels(params)) {
 	case 2:
+	case 8:
 		format = BCM2835_I2S_CH1(format) | BCM2835_I2S_CH2(format);
 		format |= BCM2835_I2S_CH1(BCM2835_I2S_CHPOS(ch1pos));
 		format |= BCM2835_I2S_CH2(BCM2835_I2S_CHPOS(ch2pos));
@@ -526,7 +528,20 @@ static int bcm2835_i2s_startup(struct snd_pcm_substream *substream,
 	regmap_update_bits(dev->i2s_regmap, BCM2835_I2S_CS_A_REG,
 			BCM2835_I2S_STBY, BCM2835_I2S_STBY);
 
-	return 0;
+	/* Only allow 2 channels, unless in DSP mode where an IC (between 
+	 * the SoC and codec) is master.
+	 */
+	if ((dev->fmt & SND_SOC_DAIFMT_FORMAT_MASK)
+					== SND_SOC_DAIFMT_DSP_A)
+		if ((dev->fmt & SND_SOC_DAIFMT_MASTER_MASK)
+					!= SND_SOC_DAIFMT_IBM_IFM)
+			return -EINVAL;
+		else
+			return snd_pcm_hw_constraint_single(substream->runtime,
+						SNDRV_PCM_HW_PARAM_CHANNELS, 8);
+	else
+		return snd_pcm_hw_constraint_single(substream->runtime,
+			SNDRV_PCM_HW_PARAM_CHANNELS, 2);
 }
 
 static void bcm2835_i2s_shutdown(struct snd_pcm_substream *substream,
@@ -549,6 +564,10 @@ static void bcm2835_i2s_shutdown(struct snd_pcm_substream *substream,
 	 * not stop the clock when SND_SOC_DAIFMT_CONT
 	 */
 	bcm2835_i2s_stop_clock(dev);
+
+	/* Default to 2 channels */
+	snd_pcm_hw_constraint_single(substream->runtime,
+			SNDRV_PCM_HW_PARAM_CHANNELS, 2);
 }
 
 static const struct snd_soc_dai_ops bcm2835_i2s_dai_ops = {
-- 
2.7.4

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matthias Reichl]

On Sat, Feb 25, 2017 at 04:03:11PM +1100, Matt Flax wrote:
> This patch set lets the ASoC system specify that an IC between the SoC and codec
> is master. This is intended to put both the SoC and Codec into slave modes.
> 
> By default un-patched SoC and Codec drivers will return -EINVAL if they aren't
> enabled and tested for this mode.
> 
> soc-dia.h has the new SND_SOC_DAIFMT_IBM_IFM definition set as :
> #define SND_SOC_DAIFMT_IBM_IFM		(5 << 12) /* IC clk & FRM master */
> 
> The cs42xx8 codec driver is enabled for this mode and so too is the BCM2835
> SoC driver. This forms a chain : bcm2835<=>IC<=>cs42xx8
> where the IC is bit and frame master.

Model your IC as a codec. No need to add patches to random drivers
and add a flag with the rather meaningless semantics "someone else is
automagically setting up clocks for me".

so long,

Hias
> 
> Matt Flax (3):
>   ASoC : Add an IC bit and frame master mode (SoC and Codec slave).
>   ASoC: cs42xx8: allow IC master mode.
>   ASoC: bcm2835: Add mutichannel mode in DSP and IC master modes.
> 
>  include/sound/soc-dai.h     |  9 ++++++---
>  sound/soc/bcm/bcm2835-i2s.c | 21 ++++++++++++++++++++-
>  sound/soc/codecs/cs42xx8.c  |  1 +
>  3 files changed, 27 insertions(+), 4 deletions(-)
> 
> -- 
> 2.7.4
> 

[PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matthias Reichl]

On Sat, Feb 25, 2017 at 04:03:11PM +1100, Matt Flax wrote:
> This patch set lets the ASoC system specify that an IC between the SoC and codec
> is master. This is intended to put both the SoC and Codec into slave modes.
> 
> By default un-patched SoC and Codec drivers will return -EINVAL if they aren't
> enabled and tested for this mode.
> 
> soc-dia.h has the new SND_SOC_DAIFMT_IBM_IFM definition set as :
> #define SND_SOC_DAIFMT_IBM_IFM		(5 << 12) /* IC clk & FRM master */
> 
> The cs42xx8 codec driver is enabled for this mode and so too is the BCM2835
> SoC driver. This forms a chain : bcm2835<=>IC<=>cs42xx8
> where the IC is bit and frame master.

Model your IC as a codec. No need to add patches to random drivers
and add a flag with the rather meaningless semantics "someone else is
automagically setting up clocks for me".

so long,

Hias
> 
> Matt Flax (3):
>   ASoC : Add an IC bit and frame master mode (SoC and Codec slave).
>   ASoC: cs42xx8: allow IC master mode.
>   ASoC: bcm2835: Add mutichannel mode in DSP and IC master modes.
> 
>  include/sound/soc-dai.h     |  9 ++++++---
>  sound/soc/bcm/bcm2835-i2s.c | 21 ++++++++++++++++++++-
>  sound/soc/codecs/cs42xx8.c  |  1 +
>  3 files changed, 27 insertions(+), 4 deletions(-)
> 
> -- 
> 2.7.4
> 

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matt Flax]

On 26/02/17 00:39, Matthias Reichl wrote:
> On Sat, Feb 25, 2017 at 04:03:11PM +1100, Matt Flax wrote:
>> This patch set lets the ASoC system specify that an IC between the SoC and codec
>> is master. This is intended to put both the SoC and Codec into slave modes.
>>
>> By default un-patched SoC and Codec drivers will return -EINVAL if they aren't
>> enabled and tested for this mode.
>>
>> soc-dia.h has the new SND_SOC_DAIFMT_IBM_IFM definition set as :
>> #define SND_SOC_DAIFMT_IBM_IFM		(5 << 12) /* IC clk & FRM master */
>>
>> The cs42xx8 codec driver is enabled for this mode and so too is the BCM2835
>> SoC driver. This forms a chain : bcm2835<=>IC<=>cs42xx8
>> where the IC is bit and frame master.
> Model your IC as a codec. No need to add patches to random drivers
> and add a flag with the rather meaningless semantics "someone else is
> automagically setting up clocks for me".
>
>

My last patch, used the two codec approach, however it was pointed out 
that the
bcm2835 was run in DSP mode with a codec master (rather then IC master) 
and that
the patch doesn't work. Which is clearly true and a problem, it can only 
work with an
intermediate non-codec master.

I think you summed it up well with your statement :

On 25/02/17 Matthias Reichl wrote:
If the clock timing adheres to DSP mode A timing and you add code
to the the CPU DAI driver so it can operate in DSP mode A then
that should also work. If not, it's broken.


This patch set fixes the problem of a daisy chain of three possible masters
(CPU <=> IC <=> codec) where only the IC can be master. In fact, when retro
fitting DSP mode to old silicon, the CPU can specify which of the three 
can be masters
and there is no chance that someone can fire the system up with the 
wrong master
(which we know produces bit offset and random channel swapping when a 
codec is
master).

thanks
Matt

[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matt Flax]

On 26/02/17 00:39, Matthias Reichl wrote:
> On Sat, Feb 25, 2017 at 04:03:11PM +1100, Matt Flax wrote:
>> This patch set lets the ASoC system specify that an IC between the SoC and codec
>> is master. This is intended to put both the SoC and Codec into slave modes.
>>
>> By default un-patched SoC and Codec drivers will return -EINVAL if they aren't
>> enabled and tested for this mode.
>>
>> soc-dia.h has the new SND_SOC_DAIFMT_IBM_IFM definition set as :
>> #define SND_SOC_DAIFMT_IBM_IFM		(5 << 12) /* IC clk & FRM master */
>>
>> The cs42xx8 codec driver is enabled for this mode and so too is the BCM2835
>> SoC driver. This forms a chain : bcm2835<=>IC<=>cs42xx8
>> where the IC is bit and frame master.
> Model your IC as a codec. No need to add patches to random drivers
> and add a flag with the rather meaningless semantics "someone else is
> automagically setting up clocks for me".
>
>

My last patch, used the two codec approach, however it was pointed out 
that the
bcm2835 was run in DSP mode with a codec master (rather then IC master) 
and that
the patch doesn't work. Which is clearly true and a problem, it can only 
work with an
intermediate non-codec master.

I think you summed it up well with your statement :

On 25/02/17 Matthias Reichl wrote:
If the clock timing adheres to DSP mode A timing and you add code
to the the CPU DAI driver so it can operate in DSP mode A then
that should also work. If not, it's broken.


This patch set fixes the problem of a daisy chain of three possible masters
(CPU <=> IC <=> codec) where only the IC can be master. In fact, when retro
fitting DSP mode to old silicon, the CPU can specify which of the three 
can be masters
and there is no chance that someone can fire the system up with the 
wrong master
(which we know produces bit offset and random channel swapping when a 
codec is
master).

thanks
Matt

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matthias Reichl]

On Sun, Feb 26, 2017 at 09:13:09AM +1100, Matt Flax wrote:
> 
> On 26/02/17 00:39, Matthias Reichl wrote:
> >On Sat, Feb 25, 2017 at 04:03:11PM +1100, Matt Flax wrote:
> >>This patch set lets the ASoC system specify that an IC between the SoC and codec
> >>is master. This is intended to put both the SoC and Codec into slave modes.
> >>
> >>By default un-patched SoC and Codec drivers will return -EINVAL if they aren't
> >>enabled and tested for this mode.
> >>
> >>soc-dia.h has the new SND_SOC_DAIFMT_IBM_IFM definition set as :
> >>#define SND_SOC_DAIFMT_IBM_IFM		(5 << 12) /* IC clk & FRM master */
> >>
> >>The cs42xx8 codec driver is enabled for this mode and so too is the BCM2835
> >>SoC driver. This forms a chain : bcm2835<=>IC<=>cs42xx8
> >>where the IC is bit and frame master.
> >Model your IC as a codec. No need to add patches to random drivers
> >and add a flag with the rather meaningless semantics "someone else is
> >automagically setting up clocks for me".
> >
> >
> 
> My last patch, used the two codec approach, however it was pointed out that
> the
> bcm2835 was run in DSP mode with a codec master (rather then IC master) and
> that
> the patch doesn't work. Which is clearly true and a problem, it can only
> work with an
> intermediate non-codec master.
>
> I think you summed it up well with your statement :
> 
> On 25/02/17 Matthias Reichl wrote:
> If the clock timing adheres to DSP mode A timing and you add code
> to the the CPU DAI driver so it can operate in DSP mode A then
> that should also work. If not, it's broken.

Your bcm2835 patch doesn't configure the bcm2835 to DSP mode A,
it's still setup for I2S (slave) mode. You are just adding code
to pretend it's running in DSP mode A. Don't do that, it's wrong.

> This patch set fixes the problem of a daisy chain of three possible masters
> (CPU <=> IC <=> codec) where only the IC can be master. In fact, when retro
> fitting DSP mode to old silicon, the CPU can specify which of the three can
> be masters
> and there is no chance that someone can fire the system up with the wrong
> master
> (which we know produces bit offset and random channel swapping when a codec
> is
> master).

Please follow the advice I gave you about 3 weeks ago and model your
setup properly.

| So you have bcm2835 I2S <-> FPGA <-> codec - IOW a standard codec<->codec
| link.
| 
| What you seem to be missing is just a method to transfer your 8-channel
| data via a 2-channel link - userspace want's to see an 8-channel PCM,
| but the hardware link (bcm2835-i2s) is only 2-channel.
| 
| And that's where IMO as userspace plugin looks like a very good solution.
| It's basically the counterpart of your FPGA and contains the code that's
| neccessary to encapsulate/pack/whatever the 8-channel data into a 2-channel
| stream so it can then be unpacked to 8-channel by the FPGA.
| 
| If you go this route your hardware and machine driver will work with
| other I2S codecs as well, and IMO that's a far better solution than
| adding very ugly hacks to a single I2S driver.

If you add an active hardware component (your "IC"/FPGA) you also
have to model that in software.

If that component is acting as a clock master it probably has some
method to setup clocks. Even if you don't have that, eg if you
are running at some fixed rate you'll have to store that information
somewhere.

The place to do that is in a codec driver. In your setup it'll look
like this:

That "IC" codec has 2 DAIs and operates as a clock master on both.
You link one DAI in I2S mode to the bcm2835 and the other DAI
in DSP (or whatever mode you are using) to the cs42xx8.

If you model it this way you no longer work against ALSA and
you can stop adding hacks to existing drivers.

so long,

Hias

[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matthias Reichl]

On Sun, Feb 26, 2017 at 09:13:09AM +1100, Matt Flax wrote:
> 
> On 26/02/17 00:39, Matthias Reichl wrote:
> >On Sat, Feb 25, 2017 at 04:03:11PM +1100, Matt Flax wrote:
> >>This patch set lets the ASoC system specify that an IC between the SoC and codec
> >>is master. This is intended to put both the SoC and Codec into slave modes.
> >>
> >>By default un-patched SoC and Codec drivers will return -EINVAL if they aren't
> >>enabled and tested for this mode.
> >>
> >>soc-dia.h has the new SND_SOC_DAIFMT_IBM_IFM definition set as :
> >>#define SND_SOC_DAIFMT_IBM_IFM		(5 << 12) /* IC clk & FRM master */
> >>
> >>The cs42xx8 codec driver is enabled for this mode and so too is the BCM2835
> >>SoC driver. This forms a chain : bcm2835<=>IC<=>cs42xx8
> >>where the IC is bit and frame master.
> >Model your IC as a codec. No need to add patches to random drivers
> >and add a flag with the rather meaningless semantics "someone else is
> >automagically setting up clocks for me".
> >
> >
> 
> My last patch, used the two codec approach, however it was pointed out that
> the
> bcm2835 was run in DSP mode with a codec master (rather then IC master) and
> that
> the patch doesn't work. Which is clearly true and a problem, it can only
> work with an
> intermediate non-codec master.
>
> I think you summed it up well with your statement :
> 
> On 25/02/17 Matthias Reichl wrote:
> If the clock timing adheres to DSP mode A timing and you add code
> to the the CPU DAI driver so it can operate in DSP mode A then
> that should also work. If not, it's broken.

Your bcm2835 patch doesn't configure the bcm2835 to DSP mode A,
it's still setup for I2S (slave) mode. You are just adding code
to pretend it's running in DSP mode A. Don't do that, it's wrong.

> This patch set fixes the problem of a daisy chain of three possible masters
> (CPU <=> IC <=> codec) where only the IC can be master. In fact, when retro
> fitting DSP mode to old silicon, the CPU can specify which of the three can
> be masters
> and there is no chance that someone can fire the system up with the wrong
> master
> (which we know produces bit offset and random channel swapping when a codec
> is
> master).

Please follow the advice I gave you about 3 weeks ago and model your
setup properly.

| So you have bcm2835 I2S <-> FPGA <-> codec - IOW a standard codec<->codec
| link.
| 
| What you seem to be missing is just a method to transfer your 8-channel
| data via a 2-channel link - userspace want's to see an 8-channel PCM,
| but the hardware link (bcm2835-i2s) is only 2-channel.
| 
| And that's where IMO as userspace plugin looks like a very good solution.
| It's basically the counterpart of your FPGA and contains the code that's
| neccessary to encapsulate/pack/whatever the 8-channel data into a 2-channel
| stream so it can then be unpacked to 8-channel by the FPGA.
| 
| If you go this route your hardware and machine driver will work with
| other I2S codecs as well, and IMO that's a far better solution than
| adding very ugly hacks to a single I2S driver.

If you add an active hardware component (your "IC"/FPGA) you also
have to model that in software.

If that component is acting as a clock master it probably has some
method to setup clocks. Even if you don't have that, eg if you
are running at some fixed rate you'll have to store that information
somewhere.

The place to do that is in a codec driver. In your setup it'll look
like this:

That "IC" codec has 2 DAIs and operates as a clock master on both.
You link one DAI in I2S mode to the bcm2835 and the other DAI
in DSP (or whatever mode you are using) to the cs42xx8.

If you model it this way you no longer work against ALSA and
you can stop adding hacks to existing drivers.

so long,

Hias

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matt Flax]

On 27/02/17 01:49, Matthias Reichl wrote:
> On Sun, Feb 26, 2017 at 09:13:09AM +1100, Matt Flax wrote:
>> On 26/02/17 00:39, Matthias Reichl wrote:
>>> On Sat, Feb 25, 2017 at 04:03:11PM +1100, Matt Flax wrote:
>>>> This patch set lets the ASoC system specify that an IC between the SoC and codec
>>>> is master. This is intended to put both the SoC and Codec into slave modes.
>>>>
>>>> By default un-patched SoC and Codec drivers will return -EINVAL if they aren't
>>>> enabled and tested for this mode.
>>>>
>>>> soc-dia.h has the new SND_SOC_DAIFMT_IBM_IFM definition set as :
>>>> #define SND_SOC_DAIFMT_IBM_IFM		(5 << 12) /* IC clk & FRM master */
>>>>
>>>> The cs42xx8 codec driver is enabled for this mode and so too is the BCM2835
>>>> SoC driver. This forms a chain : bcm2835<=>IC<=>cs42xx8
>>>> where the IC is bit and frame master.
>>> Model your IC as a codec. No need to add patches to random drivers
>>> and add a flag with the rather meaningless semantics "someone else is
>>> automagically setting up clocks for me".
>>>
>>>
>> My last patch, used the two codec approach, however it was pointed out that
>> the
>> bcm2835 was run in DSP mode with a codec master (rather then IC master) and
>> that
>> the patch doesn't work. Which is clearly true and a problem, it can only
>> work with an
>> intermediate non-codec master.
>>
>> I think you summed it up well with your statement :
>>
>> On 25/02/17 Matthias Reichl wrote:
>> If the clock timing adheres to DSP mode A timing and you add code
>> to the the CPU DAI driver so it can operate in DSP mode A then
>> that should also work. If not, it's broken.
> Your bcm2835 patch doesn't configure the bcm2835 to DSP mode A,
> it's still setup for I2S (slave) mode. You are just adding code
> to pretend it's running in DSP mode A. Don't do that, it's wrong.

All configuration is done in a machine driver, which I haven't submitted.
The machine driver's dai_fmt is as follows :

.dai_fmt = SND_SOC_DAIFMT_IBM_IFM|SND_SOC_DAIFMT_DSP_A|SND_SOC_DAIFMT_NB_NF,

>> This patch set fixes the problem of a daisy chain of three possible masters
>> (CPU <=> IC <=> codec) where only the IC can be master. In fact, when retro
>> fitting DSP mode to old silicon, the CPU can specify which of the three can
>> be masters
>> and there is no chance that someone can fire the system up with the wrong
>> master
>> (which we know produces bit offset and random channel swapping when a codec
>> is
>> master).
> Please follow the advice I gave you about 3 weeks ago and model your
> setup properly.
>
> | So you have bcm2835 I2S <-> FPGA <-> codec - IOW a standard codec<->codec
> | link.
> |
> | What you seem to be missing is just a method to transfer your 8-channel
> | data via a 2-channel link - userspace want's to see an 8-channel PCM,
> | but the hardware link (bcm2835-i2s) is only 2-channel.
> |
> | And that's where IMO as userspace plugin looks like a very good solution.
> | It's basically the counterpart of your FPGA and contains the code that's
> | neccessary to encapsulate/pack/whatever the 8-channel data into a 2-channel
> | stream so it can then be unpacked to 8-channel by the FPGA.
> |
> | If you go this route your hardware and machine driver will work with
> | other I2S codecs as well, and IMO that's a far better solution than
> | adding very ugly hacks to a single I2S driver.
>
> If you add an active hardware component (your "IC"/FPGA) you also
> have to model that in software.
>
> If that component is acting as a clock master it probably has some
> method to setup clocks. Even if you don't have that, eg if you
> are running at some fixed rate you'll have to store that information
> somewhere.

Clocks are set up in the machine driver as well.

>
> The place to do that is in a codec driver. In your setup it'll look
> like this:
>
> That "IC" codec has 2 DAIs and operates as a clock master on both.
> You link one DAI in I2S mode to the bcm2835 and the other DAI
> in DSP (or whatever mode you are using) to the cs42xx8.
>
> If you model it this way you no longer work against ALSA and
> you can stop adding hacks to existing drivers.
>
>
Thanks, this is actually very constructive advice. Let me try to 
understand what
you are suggesting here... I am confused about how to set bit depth 
correctly for
the codec when I play to the IC chip in this setup... lets walk me 
through this one...

I implement a new codec which matches this IC. The IC can be setup to be 
master in
its dai fmt. The sound card shows up with two devices, only the IC 
device can be used to play
and record.

Say I use aplay to play to the first device (the IC chip) it does 
hw_params and clocks are set.
But the second device (the codec) never gets hw_params executed ? If I 
select 16 or 24 bits,
it never knows ... is that right ? If so, how do we solve this problem ?

thanks
Matt

[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matt Flax]

On 27/02/17 01:49, Matthias Reichl wrote:
> On Sun, Feb 26, 2017 at 09:13:09AM +1100, Matt Flax wrote:
>> On 26/02/17 00:39, Matthias Reichl wrote:
>>> On Sat, Feb 25, 2017 at 04:03:11PM +1100, Matt Flax wrote:
>>>> This patch set lets the ASoC system specify that an IC between the SoC and codec
>>>> is master. This is intended to put both the SoC and Codec into slave modes.
>>>>
>>>> By default un-patched SoC and Codec drivers will return -EINVAL if they aren't
>>>> enabled and tested for this mode.
>>>>
>>>> soc-dia.h has the new SND_SOC_DAIFMT_IBM_IFM definition set as :
>>>> #define SND_SOC_DAIFMT_IBM_IFM		(5 << 12) /* IC clk & FRM master */
>>>>
>>>> The cs42xx8 codec driver is enabled for this mode and so too is the BCM2835
>>>> SoC driver. This forms a chain : bcm2835<=>IC<=>cs42xx8
>>>> where the IC is bit and frame master.
>>> Model your IC as a codec. No need to add patches to random drivers
>>> and add a flag with the rather meaningless semantics "someone else is
>>> automagically setting up clocks for me".
>>>
>>>
>> My last patch, used the two codec approach, however it was pointed out that
>> the
>> bcm2835 was run in DSP mode with a codec master (rather then IC master) and
>> that
>> the patch doesn't work. Which is clearly true and a problem, it can only
>> work with an
>> intermediate non-codec master.
>>
>> I think you summed it up well with your statement :
>>
>> On 25/02/17 Matthias Reichl wrote:
>> If the clock timing adheres to DSP mode A timing and you add code
>> to the the CPU DAI driver so it can operate in DSP mode A then
>> that should also work. If not, it's broken.
> Your bcm2835 patch doesn't configure the bcm2835 to DSP mode A,
> it's still setup for I2S (slave) mode. You are just adding code
> to pretend it's running in DSP mode A. Don't do that, it's wrong.

All configuration is done in a machine driver, which I haven't submitted.
The machine driver's dai_fmt is as follows :

.dai_fmt = SND_SOC_DAIFMT_IBM_IFM|SND_SOC_DAIFMT_DSP_A|SND_SOC_DAIFMT_NB_NF,

>> This patch set fixes the problem of a daisy chain of three possible masters
>> (CPU <=> IC <=> codec) where only the IC can be master. In fact, when retro
>> fitting DSP mode to old silicon, the CPU can specify which of the three can
>> be masters
>> and there is no chance that someone can fire the system up with the wrong
>> master
>> (which we know produces bit offset and random channel swapping when a codec
>> is
>> master).
> Please follow the advice I gave you about 3 weeks ago and model your
> setup properly.
>
> | So you have bcm2835 I2S <-> FPGA <-> codec - IOW a standard codec<->codec
> | link.
> |
> | What you seem to be missing is just a method to transfer your 8-channel
> | data via a 2-channel link - userspace want's to see an 8-channel PCM,
> | but the hardware link (bcm2835-i2s) is only 2-channel.
> |
> | And that's where IMO as userspace plugin looks like a very good solution.
> | It's basically the counterpart of your FPGA and contains the code that's
> | neccessary to encapsulate/pack/whatever the 8-channel data into a 2-channel
> | stream so it can then be unpacked to 8-channel by the FPGA.
> |
> | If you go this route your hardware and machine driver will work with
> | other I2S codecs as well, and IMO that's a far better solution than
> | adding very ugly hacks to a single I2S driver.
>
> If you add an active hardware component (your "IC"/FPGA) you also
> have to model that in software.
>
> If that component is acting as a clock master it probably has some
> method to setup clocks. Even if you don't have that, eg if you
> are running at some fixed rate you'll have to store that information
> somewhere.

Clocks are set up in the machine driver as well.

>
> The place to do that is in a codec driver. In your setup it'll look
> like this:
>
> That "IC" codec has 2 DAIs and operates as a clock master on both.
> You link one DAI in I2S mode to the bcm2835 and the other DAI
> in DSP (or whatever mode you are using) to the cs42xx8.
>
> If you model it this way you no longer work against ALSA and
> you can stop adding hacks to existing drivers.
>
>
Thanks, this is actually very constructive advice. Let me try to 
understand what
you are suggesting here... I am confused about how to set bit depth 
correctly for
the codec when I play to the IC chip in this setup... lets walk me 
through this one...

I implement a new codec which matches this IC. The IC can be setup to be 
master in
its dai fmt. The sound card shows up with two devices, only the IC 
device can be used to play
and record.

Say I use aplay to play to the first device (the IC chip) it does 
hw_params and clocks are set.
But the second device (the codec) never gets hw_params executed ? If I 
select 16 or 24 bits,
it never knows ... is that right ? If so, how do we solve this problem ?

thanks
Matt

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matthias Reichl]

On Mon, Feb 27, 2017 at 07:21:13AM +1100, Matt Flax wrote:
> 
> 
> On 27/02/17 01:49, Matthias Reichl wrote:
> >On Sun, Feb 26, 2017 at 09:13:09AM +1100, Matt Flax wrote:
> >>On 26/02/17 00:39, Matthias Reichl wrote:
> >>>On Sat, Feb 25, 2017 at 04:03:11PM +1100, Matt Flax wrote:
> >>>>This patch set lets the ASoC system specify that an IC between the SoC and codec
> >>>>is master. This is intended to put both the SoC and Codec into slave modes.
> >>>>
> >>>>By default un-patched SoC and Codec drivers will return -EINVAL if they aren't
> >>>>enabled and tested for this mode.
> >>>>
> >>>>soc-dia.h has the new SND_SOC_DAIFMT_IBM_IFM definition set as :
> >>>>#define SND_SOC_DAIFMT_IBM_IFM		(5 << 12) /* IC clk & FRM master */
> >>>>
> >>>>The cs42xx8 codec driver is enabled for this mode and so too is the BCM2835
> >>>>SoC driver. This forms a chain : bcm2835<=>IC<=>cs42xx8
> >>>>where the IC is bit and frame master.
> >>>Model your IC as a codec. No need to add patches to random drivers
> >>>and add a flag with the rather meaningless semantics "someone else is
> >>>automagically setting up clocks for me".
> >>>
> >>>
> >>My last patch, used the two codec approach, however it was pointed out that
> >>the
> >>bcm2835 was run in DSP mode with a codec master (rather then IC master) and
> >>that
> >>the patch doesn't work. Which is clearly true and a problem, it can only
> >>work with an
> >>intermediate non-codec master.
> >>
> >>I think you summed it up well with your statement :
> >>
> >>On 25/02/17 Matthias Reichl wrote:
> >>If the clock timing adheres to DSP mode A timing and you add code
> >>to the the CPU DAI driver so it can operate in DSP mode A then
> >>that should also work. If not, it's broken.
> >Your bcm2835 patch doesn't configure the bcm2835 to DSP mode A,
> >it's still setup for I2S (slave) mode. You are just adding code
> >to pretend it's running in DSP mode A. Don't do that, it's wrong.
> 
> All configuration is done in a machine driver, which I haven't submitted.
> The machine driver's dai_fmt is as follows :
> 
> .dai_fmt = SND_SOC_DAIFMT_IBM_IFM|SND_SOC_DAIFMT_DSP_A|SND_SOC_DAIFMT_NB_NF,
> 
> >>This patch set fixes the problem of a daisy chain of three possible masters
> >>(CPU <=> IC <=> codec) where only the IC can be master. In fact, when retro
> >>fitting DSP mode to old silicon, the CPU can specify which of the three can
> >>be masters
> >>and there is no chance that someone can fire the system up with the wrong
> >>master
> >>(which we know produces bit offset and random channel swapping when a codec
> >>is
> >>master).
> >Please follow the advice I gave you about 3 weeks ago and model your
> >setup properly.
> >
> >| So you have bcm2835 I2S <-> FPGA <-> codec - IOW a standard codec<->codec
> >| link.
> >|
> >| What you seem to be missing is just a method to transfer your 8-channel
> >| data via a 2-channel link - userspace want's to see an 8-channel PCM,
> >| but the hardware link (bcm2835-i2s) is only 2-channel.
> >|
> >| And that's where IMO as userspace plugin looks like a very good solution.
> >| It's basically the counterpart of your FPGA and contains the code that's
> >| neccessary to encapsulate/pack/whatever the 8-channel data into a 2-channel
> >| stream so it can then be unpacked to 8-channel by the FPGA.
> >|
> >| If you go this route your hardware and machine driver will work with
> >| other I2S codecs as well, and IMO that's a far better solution than
> >| adding very ugly hacks to a single I2S driver.
> >
> >If you add an active hardware component (your "IC"/FPGA) you also
> >have to model that in software.
> >
> >If that component is acting as a clock master it probably has some
> >method to setup clocks. Even if you don't have that, eg if you
> >are running at some fixed rate you'll have to store that information
> >somewhere.
> 
> Clocks are set up in the machine driver as well.
> 
> >
> >The place to do that is in a codec driver. In your setup it'll look
> >like this:
> >
> >That "IC" codec has 2 DAIs and operates as a clock master on both.
> >You link one DAI in I2S mode to the bcm2835 and the other DAI
> >in DSP (or whatever mode you are using) to the cs42xx8.
> >
> >If you model it this way you no longer work against ALSA and
> >you can stop adding hacks to existing drivers.
> >
> >
> Thanks, this is actually very constructive advice. Let me try to understand
> what
> you are suggesting here... I am confused about how to set bit depth
> correctly for
> the codec when I play to the IC chip in this setup... lets walk me through
> this one...
> 
> I implement a new codec which matches this IC. The IC can be setup to be
> master in
> its dai fmt. The sound card shows up with two devices, only the IC device
> can be used to play
> and record.

Actually you don't get 2 PCMs from that in userspace, you are only
telling ALSA that your stream is routed through another codec inbetween.

> Say I use aplay to play to the first device (the IC chip) it does hw_params
> and clocks are set.
> But the second device (the codec) never gets hw_params executed ? If I
> select 16 or 24 bits,
> it never knows ... is that right ? If so, how do we solve this problem ?

Have a look at the end of Documentation/sound/alsa/soc/DPCM.txt
where codec<->codec links are explained.

You can setup the stream parameters for the "IC"<->"real codec" link
with snd_soc_dai_link.params.

You can do that for example in your machine driver in hwparams:
when hw_params is called eg with 2 channels 192kHz just set the
dai link parameters of the codec to 8 channels 48kHz.

Maybe using dynamic pcm (which offers a be_hw_params_fixup hook)
is the more appropriate way to do that, but I can't tell for sure
as I never used it and am not familiar with it.

so long,

Hias

[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matthias Reichl]

On Mon, Feb 27, 2017 at 07:21:13AM +1100, Matt Flax wrote:
> 
> 
> On 27/02/17 01:49, Matthias Reichl wrote:
> >On Sun, Feb 26, 2017 at 09:13:09AM +1100, Matt Flax wrote:
> >>On 26/02/17 00:39, Matthias Reichl wrote:
> >>>On Sat, Feb 25, 2017 at 04:03:11PM +1100, Matt Flax wrote:
> >>>>This patch set lets the ASoC system specify that an IC between the SoC and codec
> >>>>is master. This is intended to put both the SoC and Codec into slave modes.
> >>>>
> >>>>By default un-patched SoC and Codec drivers will return -EINVAL if they aren't
> >>>>enabled and tested for this mode.
> >>>>
> >>>>soc-dia.h has the new SND_SOC_DAIFMT_IBM_IFM definition set as :
> >>>>#define SND_SOC_DAIFMT_IBM_IFM		(5 << 12) /* IC clk & FRM master */
> >>>>
> >>>>The cs42xx8 codec driver is enabled for this mode and so too is the BCM2835
> >>>>SoC driver. This forms a chain : bcm2835<=>IC<=>cs42xx8
> >>>>where the IC is bit and frame master.
> >>>Model your IC as a codec. No need to add patches to random drivers
> >>>and add a flag with the rather meaningless semantics "someone else is
> >>>automagically setting up clocks for me".
> >>>
> >>>
> >>My last patch, used the two codec approach, however it was pointed out that
> >>the
> >>bcm2835 was run in DSP mode with a codec master (rather then IC master) and
> >>that
> >>the patch doesn't work. Which is clearly true and a problem, it can only
> >>work with an
> >>intermediate non-codec master.
> >>
> >>I think you summed it up well with your statement :
> >>
> >>On 25/02/17 Matthias Reichl wrote:
> >>If the clock timing adheres to DSP mode A timing and you add code
> >>to the the CPU DAI driver so it can operate in DSP mode A then
> >>that should also work. If not, it's broken.
> >Your bcm2835 patch doesn't configure the bcm2835 to DSP mode A,
> >it's still setup for I2S (slave) mode. You are just adding code
> >to pretend it's running in DSP mode A. Don't do that, it's wrong.
> 
> All configuration is done in a machine driver, which I haven't submitted.
> The machine driver's dai_fmt is as follows :
> 
> .dai_fmt = SND_SOC_DAIFMT_IBM_IFM|SND_SOC_DAIFMT_DSP_A|SND_SOC_DAIFMT_NB_NF,
> 
> >>This patch set fixes the problem of a daisy chain of three possible masters
> >>(CPU <=> IC <=> codec) where only the IC can be master. In fact, when retro
> >>fitting DSP mode to old silicon, the CPU can specify which of the three can
> >>be masters
> >>and there is no chance that someone can fire the system up with the wrong
> >>master
> >>(which we know produces bit offset and random channel swapping when a codec
> >>is
> >>master).
> >Please follow the advice I gave you about 3 weeks ago and model your
> >setup properly.
> >
> >| So you have bcm2835 I2S <-> FPGA <-> codec - IOW a standard codec<->codec
> >| link.
> >|
> >| What you seem to be missing is just a method to transfer your 8-channel
> >| data via a 2-channel link - userspace want's to see an 8-channel PCM,
> >| but the hardware link (bcm2835-i2s) is only 2-channel.
> >|
> >| And that's where IMO as userspace plugin looks like a very good solution.
> >| It's basically the counterpart of your FPGA and contains the code that's
> >| neccessary to encapsulate/pack/whatever the 8-channel data into a 2-channel
> >| stream so it can then be unpacked to 8-channel by the FPGA.
> >|
> >| If you go this route your hardware and machine driver will work with
> >| other I2S codecs as well, and IMO that's a far better solution than
> >| adding very ugly hacks to a single I2S driver.
> >
> >If you add an active hardware component (your "IC"/FPGA) you also
> >have to model that in software.
> >
> >If that component is acting as a clock master it probably has some
> >method to setup clocks. Even if you don't have that, eg if you
> >are running at some fixed rate you'll have to store that information
> >somewhere.
> 
> Clocks are set up in the machine driver as well.
> 
> >
> >The place to do that is in a codec driver. In your setup it'll look
> >like this:
> >
> >That "IC" codec has 2 DAIs and operates as a clock master on both.
> >You link one DAI in I2S mode to the bcm2835 and the other DAI
> >in DSP (or whatever mode you are using) to the cs42xx8.
> >
> >If you model it this way you no longer work against ALSA and
> >you can stop adding hacks to existing drivers.
> >
> >
> Thanks, this is actually very constructive advice. Let me try to understand
> what
> you are suggesting here... I am confused about how to set bit depth
> correctly for
> the codec when I play to the IC chip in this setup... lets walk me through
> this one...
> 
> I implement a new codec which matches this IC. The IC can be setup to be
> master in
> its dai fmt. The sound card shows up with two devices, only the IC device
> can be used to play
> and record.

Actually you don't get 2 PCMs from that in userspace, you are only
telling ALSA that your stream is routed through another codec inbetween.

> Say I use aplay to play to the first device (the IC chip) it does hw_params
> and clocks are set.
> But the second device (the codec) never gets hw_params executed ? If I
> select 16 or 24 bits,
> it never knows ... is that right ? If so, how do we solve this problem ?

Have a look at the end of Documentation/sound/alsa/soc/DPCM.txt
where codec<->codec links are explained.

You can setup the stream parameters for the "IC"<->"real codec" link
with snd_soc_dai_link.params.

You can do that for example in your machine driver in hwparams:
when hw_params is called eg with 2 channels 192kHz just set the
dai link parameters of the codec to 8 channels 48kHz.

Maybe using dynamic pcm (which offers a be_hw_params_fixup hook)
is the more appropriate way to do that, but I can't tell for sure
as I never used it and am not familiar with it.

so long,

Hias

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matt Flax]

On 27/02/17 09:16, Matthias Reichl wrote:
> On Mon, Feb 27, 2017 at 07:21:13AM +1100, Matt Flax wrote:
>>
>> On 27/02/17 01:49, Matthias Reichl wrote:
>>> On Sun, Feb 26, 2017 at 09:13:09AM +1100, Matt Flax wrote:
>>>> On 26/02/17 00:39, Matthias Reichl wrote:
>>>>> On Sat, Feb 25, 2017 at 04:03:11PM +1100, Matt Flax wrote:
>>>>>> This patch set lets the ASoC system specify that an IC between the SoC and codec
>>>>>> is master. This is intended to put both the SoC and Codec into slave modes.
>>>>>>
>>>>>> By default un-patched SoC and Codec drivers will return -EINVAL if they aren't
>>>>>> enabled and tested for this mode.
>>>>>>
>>>>>> soc-dia.h has the new SND_SOC_DAIFMT_IBM_IFM definition set as :
>>>>>> #define SND_SOC_DAIFMT_IBM_IFM		(5 << 12) /* IC clk & FRM master */
>>>>>>
>>>>>> The cs42xx8 codec driver is enabled for this mode and so too is the BCM2835
>>>>>> SoC driver. This forms a chain : bcm2835<=>IC<=>cs42xx8
>>>>>> where the IC is bit and frame master.
>>>>> Model your IC as a codec. No need to add patches to random drivers
>>>>> and add a flag with the rather meaningless semantics "someone else is
>>>>> automagically setting up clocks for me".
>>>>>
>>>>>
>>>> My last patch, used the two codec approach, however it was pointed out that
>>>> the
>>>> bcm2835 was run in DSP mode with a codec master (rather then IC master) and
>>>> that
>>>> the patch doesn't work. Which is clearly true and a problem, it can only
>>>> work with an
>>>> intermediate non-codec master.
>>>>
>>>> I think you summed it up well with your statement :
>>>>
>>>> On 25/02/17 Matthias Reichl wrote:
>>>> If the clock timing adheres to DSP mode A timing and you add code
>>>> to the the CPU DAI driver so it can operate in DSP mode A then
>>>> that should also work. If not, it's broken.
>>> Your bcm2835 patch doesn't configure the bcm2835 to DSP mode A,
>>> it's still setup for I2S (slave) mode. You are just adding code
>>> to pretend it's running in DSP mode A. Don't do that, it's wrong.
>> All configuration is done in a machine driver, which I haven't submitted.
>> The machine driver's dai_fmt is as follows :
>>
>> .dai_fmt = SND_SOC_DAIFMT_IBM_IFM|SND_SOC_DAIFMT_DSP_A|SND_SOC_DAIFMT_NB_NF,
>>
>>>> This patch set fixes the problem of a daisy chain of three possible masters
>>>> (CPU <=> IC <=> codec) where only the IC can be master. In fact, when retro
>>>> fitting DSP mode to old silicon, the CPU can specify which of the three can
>>>> be masters
>>>> and there is no chance that someone can fire the system up with the wrong
>>>> master
>>>> (which we know produces bit offset and random channel swapping when a codec
>>>> is
>>>> master).
>>> Please follow the advice I gave you about 3 weeks ago and model your
>>> setup properly.
>>>
>>> | So you have bcm2835 I2S <-> FPGA <-> codec - IOW a standard codec<->codec
>>> | link.
>>> |
>>> | What you seem to be missing is just a method to transfer your 8-channel
>>> | data via a 2-channel link - userspace want's to see an 8-channel PCM,
>>> | but the hardware link (bcm2835-i2s) is only 2-channel.
>>> |
>>> | And that's where IMO as userspace plugin looks like a very good solution.
>>> | It's basically the counterpart of your FPGA and contains the code that's
>>> | neccessary to encapsulate/pack/whatever the 8-channel data into a 2-channel
>>> | stream so it can then be unpacked to 8-channel by the FPGA.
>>> |
>>> | If you go this route your hardware and machine driver will work with
>>> | other I2S codecs as well, and IMO that's a far better solution than
>>> | adding very ugly hacks to a single I2S driver.
>>>
>>> If you add an active hardware component (your "IC"/FPGA) you also
>>> have to model that in software.
>>>
>>> If that component is acting as a clock master it probably has some
>>> method to setup clocks. Even if you don't have that, eg if you
>>> are running at some fixed rate you'll have to store that information
>>> somewhere.
>> Clocks are set up in the machine driver as well.
>>
>>> The place to do that is in a codec driver. In your setup it'll look
>>> like this:
>>>
>>> That "IC" codec has 2 DAIs and operates as a clock master on both.
>>> You link one DAI in I2S mode to the bcm2835 and the other DAI
>>> in DSP (or whatever mode you are using) to the cs42xx8.
>>>
>>> If you model it this way you no longer work against ALSA and
>>> you can stop adding hacks to existing drivers.
>>>
>>>
>> Thanks, this is actually very constructive advice. Let me try to understand
>> what
>> you are suggesting here... I am confused about how to set bit depth
>> correctly for
>> the codec when I play to the IC chip in this setup... lets walk me through
>> this one...
>>
>> I implement a new codec which matches this IC. The IC can be setup to be
>> master in
>> its dai fmt. The sound card shows up with two devices, only the IC device
>> can be used to play
>> and record.
> Actually you don't get 2 PCMs from that in userspace, you are only
> telling ALSA that your stream is routed through another codec inbetween.
>
>> Say I use aplay to play to the first device (the IC chip) it does hw_params
>> and clocks are set.
>> But the second device (the codec) never gets hw_params executed ? If I
>> select 16 or 24 bits,
>> it never knows ... is that right ? If so, how do we solve this problem ?
> Have a look at the end of Documentation/sound/alsa/soc/DPCM.txt
> where codec<->codec links are explained.
>
> You can setup the stream parameters for the "IC"<->"real codec" link
> with snd_soc_dai_link.params.
>
> You can do that for example in your machine driver in hwparams:
> when hw_params is called eg with 2 channels 192kHz just set the
> dai link parameters of the codec to 8 channels 48kHz.
>
> Maybe using dynamic pcm (which offers a be_hw_params_fixup hook)
> is the more appropriate way to do that, but I can't tell for sure
> as I never used it and am not familiar with it.
>
>

Thanks for this information, I will give this a go - seems a better way 
now then introducing an IC master into the mix !

Do you agree that we still need the BCM2835 SoC CPU driver to be 
expanded to handle DSP mode
and multichannel setups ? I can't see any other way to enable the 
multichannel hardware setup without altering bcm2835_i2s.c to handle DSP 
mode and more then 2 channels in its _hw_params.

thanks
Matt

[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matt Flax]

On 27/02/17 09:16, Matthias Reichl wrote:
> On Mon, Feb 27, 2017 at 07:21:13AM +1100, Matt Flax wrote:
>>
>> On 27/02/17 01:49, Matthias Reichl wrote:
>>> On Sun, Feb 26, 2017 at 09:13:09AM +1100, Matt Flax wrote:
>>>> On 26/02/17 00:39, Matthias Reichl wrote:
>>>>> On Sat, Feb 25, 2017 at 04:03:11PM +1100, Matt Flax wrote:
>>>>>> This patch set lets the ASoC system specify that an IC between the SoC and codec
>>>>>> is master. This is intended to put both the SoC and Codec into slave modes.
>>>>>>
>>>>>> By default un-patched SoC and Codec drivers will return -EINVAL if they aren't
>>>>>> enabled and tested for this mode.
>>>>>>
>>>>>> soc-dia.h has the new SND_SOC_DAIFMT_IBM_IFM definition set as :
>>>>>> #define SND_SOC_DAIFMT_IBM_IFM		(5 << 12) /* IC clk & FRM master */
>>>>>>
>>>>>> The cs42xx8 codec driver is enabled for this mode and so too is the BCM2835
>>>>>> SoC driver. This forms a chain : bcm2835<=>IC<=>cs42xx8
>>>>>> where the IC is bit and frame master.
>>>>> Model your IC as a codec. No need to add patches to random drivers
>>>>> and add a flag with the rather meaningless semantics "someone else is
>>>>> automagically setting up clocks for me".
>>>>>
>>>>>
>>>> My last patch, used the two codec approach, however it was pointed out that
>>>> the
>>>> bcm2835 was run in DSP mode with a codec master (rather then IC master) and
>>>> that
>>>> the patch doesn't work. Which is clearly true and a problem, it can only
>>>> work with an
>>>> intermediate non-codec master.
>>>>
>>>> I think you summed it up well with your statement :
>>>>
>>>> On 25/02/17 Matthias Reichl wrote:
>>>> If the clock timing adheres to DSP mode A timing and you add code
>>>> to the the CPU DAI driver so it can operate in DSP mode A then
>>>> that should also work. If not, it's broken.
>>> Your bcm2835 patch doesn't configure the bcm2835 to DSP mode A,
>>> it's still setup for I2S (slave) mode. You are just adding code
>>> to pretend it's running in DSP mode A. Don't do that, it's wrong.
>> All configuration is done in a machine driver, which I haven't submitted.
>> The machine driver's dai_fmt is as follows :
>>
>> .dai_fmt = SND_SOC_DAIFMT_IBM_IFM|SND_SOC_DAIFMT_DSP_A|SND_SOC_DAIFMT_NB_NF,
>>
>>>> This patch set fixes the problem of a daisy chain of three possible masters
>>>> (CPU <=> IC <=> codec) where only the IC can be master. In fact, when retro
>>>> fitting DSP mode to old silicon, the CPU can specify which of the three can
>>>> be masters
>>>> and there is no chance that someone can fire the system up with the wrong
>>>> master
>>>> (which we know produces bit offset and random channel swapping when a codec
>>>> is
>>>> master).
>>> Please follow the advice I gave you about 3 weeks ago and model your
>>> setup properly.
>>>
>>> | So you have bcm2835 I2S <-> FPGA <-> codec - IOW a standard codec<->codec
>>> | link.
>>> |
>>> | What you seem to be missing is just a method to transfer your 8-channel
>>> | data via a 2-channel link - userspace want's to see an 8-channel PCM,
>>> | but the hardware link (bcm2835-i2s) is only 2-channel.
>>> |
>>> | And that's where IMO as userspace plugin looks like a very good solution.
>>> | It's basically the counterpart of your FPGA and contains the code that's
>>> | neccessary to encapsulate/pack/whatever the 8-channel data into a 2-channel
>>> | stream so it can then be unpacked to 8-channel by the FPGA.
>>> |
>>> | If you go this route your hardware and machine driver will work with
>>> | other I2S codecs as well, and IMO that's a far better solution than
>>> | adding very ugly hacks to a single I2S driver.
>>>
>>> If you add an active hardware component (your "IC"/FPGA) you also
>>> have to model that in software.
>>>
>>> If that component is acting as a clock master it probably has some
>>> method to setup clocks. Even if you don't have that, eg if you
>>> are running at some fixed rate you'll have to store that information
>>> somewhere.
>> Clocks are set up in the machine driver as well.
>>
>>> The place to do that is in a codec driver. In your setup it'll look
>>> like this:
>>>
>>> That "IC" codec has 2 DAIs and operates as a clock master on both.
>>> You link one DAI in I2S mode to the bcm2835 and the other DAI
>>> in DSP (or whatever mode you are using) to the cs42xx8.
>>>
>>> If you model it this way you no longer work against ALSA and
>>> you can stop adding hacks to existing drivers.
>>>
>>>
>> Thanks, this is actually very constructive advice. Let me try to understand
>> what
>> you are suggesting here... I am confused about how to set bit depth
>> correctly for
>> the codec when I play to the IC chip in this setup... lets walk me through
>> this one...
>>
>> I implement a new codec which matches this IC. The IC can be setup to be
>> master in
>> its dai fmt. The sound card shows up with two devices, only the IC device
>> can be used to play
>> and record.
> Actually you don't get 2 PCMs from that in userspace, you are only
> telling ALSA that your stream is routed through another codec inbetween.
>
>> Say I use aplay to play to the first device (the IC chip) it does hw_params
>> and clocks are set.
>> But the second device (the codec) never gets hw_params executed ? If I
>> select 16 or 24 bits,
>> it never knows ... is that right ? If so, how do we solve this problem ?
> Have a look at the end of Documentation/sound/alsa/soc/DPCM.txt
> where codec<->codec links are explained.
>
> You can setup the stream parameters for the "IC"<->"real codec" link
> with snd_soc_dai_link.params.
>
> You can do that for example in your machine driver in hwparams:
> when hw_params is called eg with 2 channels 192kHz just set the
> dai link parameters of the codec to 8 channels 48kHz.
>
> Maybe using dynamic pcm (which offers a be_hw_params_fixup hook)
> is the more appropriate way to do that, but I can't tell for sure
> as I never used it and am not familiar with it.
>
>

Thanks for this information, I will give this a go - seems a better way 
now then introducing an IC master into the mix !

Do you agree that we still need the BCM2835 SoC CPU driver to be 
expanded to handle DSP mode
and multichannel setups ? I can't see any other way to enable the 
multichannel hardware setup without altering bcm2835_i2s.c to handle DSP 
mode and more then 2 channels in its _hw_params.

thanks
Matt

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matthias Reichl]

On Mon, Feb 27, 2017 at 09:35:14AM +1100, Matt Flax wrote:
> 
> 
> On 27/02/17 09:16, Matthias Reichl wrote:
> >On Mon, Feb 27, 2017 at 07:21:13AM +1100, Matt Flax wrote:
> >>
> >>On 27/02/17 01:49, Matthias Reichl wrote:
> >>>On Sun, Feb 26, 2017 at 09:13:09AM +1100, Matt Flax wrote:
> >>>>On 26/02/17 00:39, Matthias Reichl wrote:
> >>>>>On Sat, Feb 25, 2017 at 04:03:11PM +1100, Matt Flax wrote:
> >>>>>>This patch set lets the ASoC system specify that an IC between the SoC and codec
> >>>>>>is master. This is intended to put both the SoC and Codec into slave modes.
> >>>>>>
> >>>>>>By default un-patched SoC and Codec drivers will return -EINVAL if they aren't
> >>>>>>enabled and tested for this mode.
> >>>>>>
> >>>>>>soc-dia.h has the new SND_SOC_DAIFMT_IBM_IFM definition set as :
> >>>>>>#define SND_SOC_DAIFMT_IBM_IFM		(5 << 12) /* IC clk & FRM master */
> >>>>>>
> >>>>>>The cs42xx8 codec driver is enabled for this mode and so too is the BCM2835
> >>>>>>SoC driver. This forms a chain : bcm2835<=>IC<=>cs42xx8
> >>>>>>where the IC is bit and frame master.
> >>>>>Model your IC as a codec. No need to add patches to random drivers
> >>>>>and add a flag with the rather meaningless semantics "someone else is
> >>>>>automagically setting up clocks for me".
> >>>>>
> >>>>>
> >>>>My last patch, used the two codec approach, however it was pointed out that
> >>>>the
> >>>>bcm2835 was run in DSP mode with a codec master (rather then IC master) and
> >>>>that
> >>>>the patch doesn't work. Which is clearly true and a problem, it can only
> >>>>work with an
> >>>>intermediate non-codec master.
> >>>>
> >>>>I think you summed it up well with your statement :
> >>>>
> >>>>On 25/02/17 Matthias Reichl wrote:
> >>>>If the clock timing adheres to DSP mode A timing and you add code
> >>>>to the the CPU DAI driver so it can operate in DSP mode A then
> >>>>that should also work. If not, it's broken.
> >>>Your bcm2835 patch doesn't configure the bcm2835 to DSP mode A,
> >>>it's still setup for I2S (slave) mode. You are just adding code
> >>>to pretend it's running in DSP mode A. Don't do that, it's wrong.
> >>All configuration is done in a machine driver, which I haven't submitted.
> >>The machine driver's dai_fmt is as follows :
> >>
> >>.dai_fmt = SND_SOC_DAIFMT_IBM_IFM|SND_SOC_DAIFMT_DSP_A|SND_SOC_DAIFMT_NB_NF,
> >>
> >>>>This patch set fixes the problem of a daisy chain of three possible masters
> >>>>(CPU <=> IC <=> codec) where only the IC can be master. In fact, when retro
> >>>>fitting DSP mode to old silicon, the CPU can specify which of the three can
> >>>>be masters
> >>>>and there is no chance that someone can fire the system up with the wrong
> >>>>master
> >>>>(which we know produces bit offset and random channel swapping when a codec
> >>>>is
> >>>>master).
> >>>Please follow the advice I gave you about 3 weeks ago and model your
> >>>setup properly.
> >>>
> >>>| So you have bcm2835 I2S <-> FPGA <-> codec - IOW a standard codec<->codec
> >>>| link.
> >>>|
> >>>| What you seem to be missing is just a method to transfer your 8-channel
> >>>| data via a 2-channel link - userspace want's to see an 8-channel PCM,
> >>>| but the hardware link (bcm2835-i2s) is only 2-channel.
> >>>|
> >>>| And that's where IMO as userspace plugin looks like a very good solution.
> >>>| It's basically the counterpart of your FPGA and contains the code that's
> >>>| neccessary to encapsulate/pack/whatever the 8-channel data into a 2-channel
> >>>| stream so it can then be unpacked to 8-channel by the FPGA.
> >>>|
> >>>| If you go this route your hardware and machine driver will work with
> >>>| other I2S codecs as well, and IMO that's a far better solution than
> >>>| adding very ugly hacks to a single I2S driver.
> >>>
> >>>If you add an active hardware component (your "IC"/FPGA) you also
> >>>have to model that in software.
> >>>
> >>>If that component is acting as a clock master it probably has some
> >>>method to setup clocks. Even if you don't have that, eg if you
> >>>are running at some fixed rate you'll have to store that information
> >>>somewhere.
> >>Clocks are set up in the machine driver as well.
> >>
> >>>The place to do that is in a codec driver. In your setup it'll look
> >>>like this:
> >>>
> >>>That "IC" codec has 2 DAIs and operates as a clock master on both.
> >>>You link one DAI in I2S mode to the bcm2835 and the other DAI
> >>>in DSP (or whatever mode you are using) to the cs42xx8.
> >>>
> >>>If you model it this way you no longer work against ALSA and
> >>>you can stop adding hacks to existing drivers.
> >>>
> >>>
> >>Thanks, this is actually very constructive advice. Let me try to understand
> >>what
> >>you are suggesting here... I am confused about how to set bit depth
> >>correctly for
> >>the codec when I play to the IC chip in this setup... lets walk me through
> >>this one...
> >>
> >>I implement a new codec which matches this IC. The IC can be setup to be
> >>master in
> >>its dai fmt. The sound card shows up with two devices, only the IC device
> >>can be used to play
> >>and record.
> >Actually you don't get 2 PCMs from that in userspace, you are only
> >telling ALSA that your stream is routed through another codec inbetween.
> >
> >>Say I use aplay to play to the first device (the IC chip) it does hw_params
> >>and clocks are set.
> >>But the second device (the codec) never gets hw_params executed ? If I
> >>select 16 or 24 bits,
> >>it never knows ... is that right ? If so, how do we solve this problem ?
> >Have a look at the end of Documentation/sound/alsa/soc/DPCM.txt
> >where codec<->codec links are explained.
> >
> >You can setup the stream parameters for the "IC"<->"real codec" link
> >with snd_soc_dai_link.params.
> >
> >You can do that for example in your machine driver in hwparams:
> >when hw_params is called eg with 2 channels 192kHz just set the
> >dai link parameters of the codec to 8 channels 48kHz.
> >
> >Maybe using dynamic pcm (which offers a be_hw_params_fixup hook)
> >is the more appropriate way to do that, but I can't tell for sure
> >as I never used it and am not familiar with it.
> >
> >
> 
> Thanks for this information, I will give this a go - seems a better way now
> then introducing an IC master into the mix !
> 
> Do you agree that we still need the BCM2835 SoC CPU driver to be expanded to
> handle DSP mode
> and multichannel setups ? I can't see any other way to enable the
> multichannel hardware setup without altering bcm2835_i2s.c to handle DSP
> mode and more then 2 channels in its _hw_params.

No, DSP mode and multichannel don't work on the BCM2835. Keep the driver
as it is.

Use the alsa plugin approach to tunnel multichannel data over a 2-channel
PCM and you don't need to modify existing drivers.

so long,

Hias
> 
> thanks
> Matt

[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matthias Reichl]

On Mon, Feb 27, 2017 at 09:35:14AM +1100, Matt Flax wrote:
> 
> 
> On 27/02/17 09:16, Matthias Reichl wrote:
> >On Mon, Feb 27, 2017 at 07:21:13AM +1100, Matt Flax wrote:
> >>
> >>On 27/02/17 01:49, Matthias Reichl wrote:
> >>>On Sun, Feb 26, 2017 at 09:13:09AM +1100, Matt Flax wrote:
> >>>>On 26/02/17 00:39, Matthias Reichl wrote:
> >>>>>On Sat, Feb 25, 2017 at 04:03:11PM +1100, Matt Flax wrote:
> >>>>>>This patch set lets the ASoC system specify that an IC between the SoC and codec
> >>>>>>is master. This is intended to put both the SoC and Codec into slave modes.
> >>>>>>
> >>>>>>By default un-patched SoC and Codec drivers will return -EINVAL if they aren't
> >>>>>>enabled and tested for this mode.
> >>>>>>
> >>>>>>soc-dia.h has the new SND_SOC_DAIFMT_IBM_IFM definition set as :
> >>>>>>#define SND_SOC_DAIFMT_IBM_IFM		(5 << 12) /* IC clk & FRM master */
> >>>>>>
> >>>>>>The cs42xx8 codec driver is enabled for this mode and so too is the BCM2835
> >>>>>>SoC driver. This forms a chain : bcm2835<=>IC<=>cs42xx8
> >>>>>>where the IC is bit and frame master.
> >>>>>Model your IC as a codec. No need to add patches to random drivers
> >>>>>and add a flag with the rather meaningless semantics "someone else is
> >>>>>automagically setting up clocks for me".
> >>>>>
> >>>>>
> >>>>My last patch, used the two codec approach, however it was pointed out that
> >>>>the
> >>>>bcm2835 was run in DSP mode with a codec master (rather then IC master) and
> >>>>that
> >>>>the patch doesn't work. Which is clearly true and a problem, it can only
> >>>>work with an
> >>>>intermediate non-codec master.
> >>>>
> >>>>I think you summed it up well with your statement :
> >>>>
> >>>>On 25/02/17 Matthias Reichl wrote:
> >>>>If the clock timing adheres to DSP mode A timing and you add code
> >>>>to the the CPU DAI driver so it can operate in DSP mode A then
> >>>>that should also work. If not, it's broken.
> >>>Your bcm2835 patch doesn't configure the bcm2835 to DSP mode A,
> >>>it's still setup for I2S (slave) mode. You are just adding code
> >>>to pretend it's running in DSP mode A. Don't do that, it's wrong.
> >>All configuration is done in a machine driver, which I haven't submitted.
> >>The machine driver's dai_fmt is as follows :
> >>
> >>.dai_fmt = SND_SOC_DAIFMT_IBM_IFM|SND_SOC_DAIFMT_DSP_A|SND_SOC_DAIFMT_NB_NF,
> >>
> >>>>This patch set fixes the problem of a daisy chain of three possible masters
> >>>>(CPU <=> IC <=> codec) where only the IC can be master. In fact, when retro
> >>>>fitting DSP mode to old silicon, the CPU can specify which of the three can
> >>>>be masters
> >>>>and there is no chance that someone can fire the system up with the wrong
> >>>>master
> >>>>(which we know produces bit offset and random channel swapping when a codec
> >>>>is
> >>>>master).
> >>>Please follow the advice I gave you about 3 weeks ago and model your
> >>>setup properly.
> >>>
> >>>| So you have bcm2835 I2S <-> FPGA <-> codec - IOW a standard codec<->codec
> >>>| link.
> >>>|
> >>>| What you seem to be missing is just a method to transfer your 8-channel
> >>>| data via a 2-channel link - userspace want's to see an 8-channel PCM,
> >>>| but the hardware link (bcm2835-i2s) is only 2-channel.
> >>>|
> >>>| And that's where IMO as userspace plugin looks like a very good solution.
> >>>| It's basically the counterpart of your FPGA and contains the code that's
> >>>| neccessary to encapsulate/pack/whatever the 8-channel data into a 2-channel
> >>>| stream so it can then be unpacked to 8-channel by the FPGA.
> >>>|
> >>>| If you go this route your hardware and machine driver will work with
> >>>| other I2S codecs as well, and IMO that's a far better solution than
> >>>| adding very ugly hacks to a single I2S driver.
> >>>
> >>>If you add an active hardware component (your "IC"/FPGA) you also
> >>>have to model that in software.
> >>>
> >>>If that component is acting as a clock master it probably has some
> >>>method to setup clocks. Even if you don't have that, eg if you
> >>>are running at some fixed rate you'll have to store that information
> >>>somewhere.
> >>Clocks are set up in the machine driver as well.
> >>
> >>>The place to do that is in a codec driver. In your setup it'll look
> >>>like this:
> >>>
> >>>That "IC" codec has 2 DAIs and operates as a clock master on both.
> >>>You link one DAI in I2S mode to the bcm2835 and the other DAI
> >>>in DSP (or whatever mode you are using) to the cs42xx8.
> >>>
> >>>If you model it this way you no longer work against ALSA and
> >>>you can stop adding hacks to existing drivers.
> >>>
> >>>
> >>Thanks, this is actually very constructive advice. Let me try to understand
> >>what
> >>you are suggesting here... I am confused about how to set bit depth
> >>correctly for
> >>the codec when I play to the IC chip in this setup... lets walk me through
> >>this one...
> >>
> >>I implement a new codec which matches this IC. The IC can be setup to be
> >>master in
> >>its dai fmt. The sound card shows up with two devices, only the IC device
> >>can be used to play
> >>and record.
> >Actually you don't get 2 PCMs from that in userspace, you are only
> >telling ALSA that your stream is routed through another codec inbetween.
> >
> >>Say I use aplay to play to the first device (the IC chip) it does hw_params
> >>and clocks are set.
> >>But the second device (the codec) never gets hw_params executed ? If I
> >>select 16 or 24 bits,
> >>it never knows ... is that right ? If so, how do we solve this problem ?
> >Have a look at the end of Documentation/sound/alsa/soc/DPCM.txt
> >where codec<->codec links are explained.
> >
> >You can setup the stream parameters for the "IC"<->"real codec" link
> >with snd_soc_dai_link.params.
> >
> >You can do that for example in your machine driver in hwparams:
> >when hw_params is called eg with 2 channels 192kHz just set the
> >dai link parameters of the codec to 8 channels 48kHz.
> >
> >Maybe using dynamic pcm (which offers a be_hw_params_fixup hook)
> >is the more appropriate way to do that, but I can't tell for sure
> >as I never used it and am not familiar with it.
> >
> >
> 
> Thanks for this information, I will give this a go - seems a better way now
> then introducing an IC master into the mix !
> 
> Do you agree that we still need the BCM2835 SoC CPU driver to be expanded to
> handle DSP mode
> and multichannel setups ? I can't see any other way to enable the
> multichannel hardware setup without altering bcm2835_i2s.c to handle DSP
> mode and more then 2 channels in its _hw_params.

No, DSP mode and multichannel don't work on the BCM2835. Keep the driver
as it is.

Use the alsa plugin approach to tunnel multichannel data over a 2-channel
PCM and you don't need to modify existing drivers.

so long,

Hias
> 
> thanks
> Matt

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matt Flax]

On 27/02/17 19:04, Matthias Reichl wrote:
> On Mon, Feb 27, 2017 at 09:35:14AM +1100, Matt Flax wrote:
>>
>> On 27/02/17 09:16, Matthias Reichl wrote:
>>>
>>> Have a look at the end of Documentation/sound/alsa/soc/DPCM.txt
>>> where codec<->codec links are explained.
>>>
>>> You can setup the stream parameters for the "IC"<->"real codec" link
>>> with snd_soc_dai_link.params.
>>>
>>> You can do that for example in your machine driver in hwparams:
>>> when hw_params is called eg with 2 channels 192kHz just set the
>>> dai link parameters of the codec to 8 channels 48kHz.
>>>
>>> Maybe using dynamic pcm (which offers a be_hw_params_fixup hook)
>>> is the more appropriate way to do that, but I can't tell for sure
>>> as I never used it and am not familiar with it.
>>>
>>>
>> Thanks for this information, I will give this a go - seems a better way now
>> then introducing an IC master into the mix !
>>
>> Do you agree that we still need the BCM2835 SoC CPU driver to be expanded to
>> handle DSP mode
>> and multichannel setups ? I can't see any other way to enable the
>> multichannel hardware setup without altering bcm2835_i2s.c to handle DSP
>> mode and more then 2 channels in its _hw_params.
> No, DSP mode and multichannel don't work on the BCM2835. Keep the driver
> as it is.
>
> Use the alsa plugin approach to tunnel multichannel data over a 2-channel
> PCM and you don't need to modify existing drivers.
>

Thanks again for this suggestion. I have been playing around with user 
space plugins lately, they are great. I plan to release some C++ classes 
to help trivialise the creation of such plugins.

However for a product, a piece of robustly functioning hardware, I am 
inclined to take the route of introducing a DSP mode into the 
bcm2835_i2s.c driver.

 From the previous patches, it is clear that people are willing to allow 
multichannel (DSP mode) into the bcm2835 CPU driver. It improves the 
usefulness of hardware which use the BCM2835 derived chipset. From my 
point of view that is a major simplification in terms of releasing 
functioning multichannel hardware. I would imagine from the 
manufacturer's point of view that is a big bonus too !

Again I intend to implement your concept of the snd_soc_dai_link for my 
machine driver, that is a fantasic lead you have given me ... when I 
have questions @ implementation time I will copy you in seeking for more 
guidance.

thanks again,
Matt

[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matt Flax]

On 27/02/17 19:04, Matthias Reichl wrote:
> On Mon, Feb 27, 2017 at 09:35:14AM +1100, Matt Flax wrote:
>>
>> On 27/02/17 09:16, Matthias Reichl wrote:
>>>
>>> Have a look at the end of Documentation/sound/alsa/soc/DPCM.txt
>>> where codec<->codec links are explained.
>>>
>>> You can setup the stream parameters for the "IC"<->"real codec" link
>>> with snd_soc_dai_link.params.
>>>
>>> You can do that for example in your machine driver in hwparams:
>>> when hw_params is called eg with 2 channels 192kHz just set the
>>> dai link parameters of the codec to 8 channels 48kHz.
>>>
>>> Maybe using dynamic pcm (which offers a be_hw_params_fixup hook)
>>> is the more appropriate way to do that, but I can't tell for sure
>>> as I never used it and am not familiar with it.
>>>
>>>
>> Thanks for this information, I will give this a go - seems a better way now
>> then introducing an IC master into the mix !
>>
>> Do you agree that we still need the BCM2835 SoC CPU driver to be expanded to
>> handle DSP mode
>> and multichannel setups ? I can't see any other way to enable the
>> multichannel hardware setup without altering bcm2835_i2s.c to handle DSP
>> mode and more then 2 channels in its _hw_params.
> No, DSP mode and multichannel don't work on the BCM2835. Keep the driver
> as it is.
>
> Use the alsa plugin approach to tunnel multichannel data over a 2-channel
> PCM and you don't need to modify existing drivers.
>

Thanks again for this suggestion. I have been playing around with user 
space plugins lately, they are great. I plan to release some C++ classes 
to help trivialise the creation of such plugins.

However for a product, a piece of robustly functioning hardware, I am 
inclined to take the route of introducing a DSP mode into the 
bcm2835_i2s.c driver.

 From the previous patches, it is clear that people are willing to allow 
multichannel (DSP mode) into the bcm2835 CPU driver. It improves the 
usefulness of hardware which use the BCM2835 derived chipset. From my 
point of view that is a major simplification in terms of releasing 
functioning multichannel hardware. I would imagine from the 
manufacturer's point of view that is a big bonus too !

Again I intend to implement your concept of the snd_soc_dai_link for my 
machine driver, that is a fantasic lead you have given me ... when I 
have questions @ implementation time I will copy you in seeking for more 
guidance.

thanks again,
Matt

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matthias Reichl]

On Mon, Feb 27, 2017 at 09:08:14PM +1100, Matt Flax wrote:
> 
> 
> On 27/02/17 19:04, Matthias Reichl wrote:
> >On Mon, Feb 27, 2017 at 09:35:14AM +1100, Matt Flax wrote:
> >>
> >>On 27/02/17 09:16, Matthias Reichl wrote:
> >>>
> >>>Have a look at the end of Documentation/sound/alsa/soc/DPCM.txt
> >>>where codec<->codec links are explained.
> >>>
> >>>You can setup the stream parameters for the "IC"<->"real codec" link
> >>>with snd_soc_dai_link.params.
> >>>
> >>>You can do that for example in your machine driver in hwparams:
> >>>when hw_params is called eg with 2 channels 192kHz just set the
> >>>dai link parameters of the codec to 8 channels 48kHz.
> >>>
> >>>Maybe using dynamic pcm (which offers a be_hw_params_fixup hook)
> >>>is the more appropriate way to do that, but I can't tell for sure
> >>>as I never used it and am not familiar with it.
> >>>
> >>>
> >>Thanks for this information, I will give this a go - seems a better way now
> >>then introducing an IC master into the mix !
> >>
> >>Do you agree that we still need the BCM2835 SoC CPU driver to be expanded to
> >>handle DSP mode
> >>and multichannel setups ? I can't see any other way to enable the
> >>multichannel hardware setup without altering bcm2835_i2s.c to handle DSP
> >>mode and more then 2 channels in its _hw_params.
> >No, DSP mode and multichannel don't work on the BCM2835. Keep the driver
> >as it is.
> >
> >Use the alsa plugin approach to tunnel multichannel data over a 2-channel
> >PCM and you don't need to modify existing drivers.
> >
> 
> Thanks again for this suggestion. I have been playing around with user space
> plugins lately, they are great. I plan to release some C++ classes to help
> trivialise the creation of such plugins.
> 
> However for a product, a piece of robustly functioning hardware, I am
> inclined to take the route of introducing a DSP mode into the bcm2835_i2s.c
> driver.

You can add DSP mode when you found which undocumented registers inside
the bcm2835 are needed to enable DSP mode, set channel 3-8 positions etc.
I'm not sure they exist, so there's little point in doing that - as we both
agreed, clocking the bcm2835 in DSP mode (while it's set up as a I2S slave)
doesn't work.

> From the previous patches, it is clear that people are willing to allow
> multichannel (DSP mode) into the bcm2835 CPU driver.

I don't see that. Some people might want to be able to use multichannel
on RPi, but that's something very different than adding code that just
lies about driver capabilites.

> It improves the
> usefulness of hardware which use the BCM2835 derived chipset. From my point
> of view that is a major simplification in terms of releasing functioning
> multichannel hardware. I would imagine from the manufacturer's point of view
> that is a big bonus too !
> 
> Again I intend to implement your concept of the snd_soc_dai_link for my
> machine driver, that is a fantasic lead you have given me ... when I have
> questions @ implementation time I will copy you in seeking for more
> guidance.
> 
> thanks again,
> Matt
> 
> 

[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matthias Reichl]

On Mon, Feb 27, 2017 at 09:08:14PM +1100, Matt Flax wrote:
> 
> 
> On 27/02/17 19:04, Matthias Reichl wrote:
> >On Mon, Feb 27, 2017 at 09:35:14AM +1100, Matt Flax wrote:
> >>
> >>On 27/02/17 09:16, Matthias Reichl wrote:
> >>>
> >>>Have a look at the end of Documentation/sound/alsa/soc/DPCM.txt
> >>>where codec<->codec links are explained.
> >>>
> >>>You can setup the stream parameters for the "IC"<->"real codec" link
> >>>with snd_soc_dai_link.params.
> >>>
> >>>You can do that for example in your machine driver in hwparams:
> >>>when hw_params is called eg with 2 channels 192kHz just set the
> >>>dai link parameters of the codec to 8 channels 48kHz.
> >>>
> >>>Maybe using dynamic pcm (which offers a be_hw_params_fixup hook)
> >>>is the more appropriate way to do that, but I can't tell for sure
> >>>as I never used it and am not familiar with it.
> >>>
> >>>
> >>Thanks for this information, I will give this a go - seems a better way now
> >>then introducing an IC master into the mix !
> >>
> >>Do you agree that we still need the BCM2835 SoC CPU driver to be expanded to
> >>handle DSP mode
> >>and multichannel setups ? I can't see any other way to enable the
> >>multichannel hardware setup without altering bcm2835_i2s.c to handle DSP
> >>mode and more then 2 channels in its _hw_params.
> >No, DSP mode and multichannel don't work on the BCM2835. Keep the driver
> >as it is.
> >
> >Use the alsa plugin approach to tunnel multichannel data over a 2-channel
> >PCM and you don't need to modify existing drivers.
> >
> 
> Thanks again for this suggestion. I have been playing around with user space
> plugins lately, they are great. I plan to release some C++ classes to help
> trivialise the creation of such plugins.
> 
> However for a product, a piece of robustly functioning hardware, I am
> inclined to take the route of introducing a DSP mode into the bcm2835_i2s.c
> driver.

You can add DSP mode when you found which undocumented registers inside
the bcm2835 are needed to enable DSP mode, set channel 3-8 positions etc.
I'm not sure they exist, so there's little point in doing that - as we both
agreed, clocking the bcm2835 in DSP mode (while it's set up as a I2S slave)
doesn't work.

> From the previous patches, it is clear that people are willing to allow
> multichannel (DSP mode) into the bcm2835 CPU driver.

I don't see that. Some people might want to be able to use multichannel
on RPi, but that's something very different than adding code that just
lies about driver capabilites.

> It improves the
> usefulness of hardware which use the BCM2835 derived chipset. From my point
> of view that is a major simplification in terms of releasing functioning
> multichannel hardware. I would imagine from the manufacturer's point of view
> that is a big bonus too !
> 
> Again I intend to implement your concept of the snd_soc_dai_link for my
> machine driver, that is a fantasic lead you have given me ... when I have
> questions @ implementation time I will copy you in seeking for more
> guidance.
> 
> thanks again,
> Matt
> 
> 

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matt Flax]

On 27/02/17 21:30, Matthias Reichl wrote:
>
> I don't see that. Some people might want to be able to use multichannel
> on RPi, but that's something very different than adding code that just
> lies about driver capabilites.
>

I am going to invite you over for dinner to eat steamed vegetables :)
If I make the steamed vegetables in the microwave and they taste like 
steamed vegetables, are they steamed vegetables ?

I have a bcm2835 (Pi 2 and 3) SoC here. It is producing multichannel (8 
out, 6 in) audio. In ALSA we call that DSP mode - right ?!

If a chipset can do multichannel, do we need to invent a new DSP mode 
name to call it dsp mode ? Surely not, because steamed vegetables are 
steamed vegetables :)

Just because steamed vegetables are made in the microwave doesn't mean 
they don't belong in the Linux Kernel !

Matt

[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matt Flax]

On 27/02/17 21:30, Matthias Reichl wrote:
>
> I don't see that. Some people might want to be able to use multichannel
> on RPi, but that's something very different than adding code that just
> lies about driver capabilites.
>

I am going to invite you over for dinner to eat steamed vegetables :)
If I make the steamed vegetables in the microwave and they taste like 
steamed vegetables, are they steamed vegetables ?

I have a bcm2835 (Pi 2 and 3) SoC here. It is producing multichannel (8 
out, 6 in) audio. In ALSA we call that DSP mode - right ?!

If a chipset can do multichannel, do we need to invent a new DSP mode 
name to call it dsp mode ? Surely not, because steamed vegetables are 
steamed vegetables :)

Just because steamed vegetables are made in the microwave doesn't mean 
they don't belong in the Linux Kernel !

Matt

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matthias Reichl]

On Mon, Feb 27, 2017 at 10:21:25PM +1100, Matt Flax wrote:
> 
> 
> On 27/02/17 21:30, Matthias Reichl wrote:
> >
> >I don't see that. Some people might want to be able to use multichannel
> >on RPi, but that's something very different than adding code that just
> >lies about driver capabilites.
> >
> 
> I am going to invite you over for dinner to eat steamed vegetables :)
> If I make the steamed vegetables in the microwave and they taste like
> steamed vegetables, are they steamed vegetables ?

If you connect an amplifier with a volume control to your soundcard
does that mean that your soundcard now has a volume control? No, your
amp has.

> I have a bcm2835 (Pi 2 and 3) SoC here. It is producing multichannel (8 out,
> 6 in) audio. In ALSA we call that DSP mode - right ?!

No. DSP modes are protocol/timing specifications as I2S, PDP, S/PDIF, ...
You can look these up in datasheets and if a chip implements such a
protocol you can be sure that it adheres to that standard - i.e. it
will sync the frames to the pulses on LRclk.

> If a chipset can do multichannel, do we need to invent a new DSP mode name
> to call it dsp mode ? Surely not, because steamed vegetables are steamed
> vegetables :)

You can do multichannel audio via IEC958 AC3/DTS passthrough as well. This
doesn't mean that each driver has to implement that as a separate mode.

In fact they are still operating in 2-channel PCM mode, only the data
packed into the stream has to be interpreted differently. This even worked
with standard CD players, you could have DTS on CD. Of course if you
connected a standard analog amp to it you'd only get noise. But an amp with
digital S/PDIF input and an AC3/DTS decoder could decode the multichannel
audio stream and output it to it's 5.1 speakers.

so long,

Hias

[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matthias Reichl]

On Mon, Feb 27, 2017 at 10:21:25PM +1100, Matt Flax wrote:
> 
> 
> On 27/02/17 21:30, Matthias Reichl wrote:
> >
> >I don't see that. Some people might want to be able to use multichannel
> >on RPi, but that's something very different than adding code that just
> >lies about driver capabilites.
> >
> 
> I am going to invite you over for dinner to eat steamed vegetables :)
> If I make the steamed vegetables in the microwave and they taste like
> steamed vegetables, are they steamed vegetables ?

If you connect an amplifier with a volume control to your soundcard
does that mean that your soundcard now has a volume control? No, your
amp has.

> I have a bcm2835 (Pi 2 and 3) SoC here. It is producing multichannel (8 out,
> 6 in) audio. In ALSA we call that DSP mode - right ?!

No. DSP modes are protocol/timing specifications as I2S, PDP, S/PDIF, ...
You can look these up in datasheets and if a chip implements such a
protocol you can be sure that it adheres to that standard - i.e. it
will sync the frames to the pulses on LRclk.

> If a chipset can do multichannel, do we need to invent a new DSP mode name
> to call it dsp mode ? Surely not, because steamed vegetables are steamed
> vegetables :)

You can do multichannel audio via IEC958 AC3/DTS passthrough as well. This
doesn't mean that each driver has to implement that as a separate mode.

In fact they are still operating in 2-channel PCM mode, only the data
packed into the stream has to be interpreted differently. This even worked
with standard CD players, you could have DTS on CD. Of course if you
connected a standard analog amp to it you'd only get noise. But an amp with
digital S/PDIF input and an AC3/DTS decoder could decode the multichannel
audio stream and output it to it's 5.1 speakers.

so long,

Hias

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Charles Keepax]

On Mon, Feb 27, 2017 at 12:51:08PM +0100, Matthias Reichl wrote:
> On Mon, Feb 27, 2017 at 10:21:25PM +1100, Matt Flax wrote:
> > 
> > 
> > On 27/02/17 21:30, Matthias Reichl wrote:
> > >
> > >I don't see that. Some people might want to be able to use multichannel
> > >on RPi, but that's something very different than adding code that just
> > >lies about driver capabilites.
> > >
> > 
> > I am going to invite you over for dinner to eat steamed vegetables :)
> > If I make the steamed vegetables in the microwave and they taste like
> > steamed vegetables, are they steamed vegetables ?
> 
> If you connect an amplifier with a volume control to your soundcard
> does that mean that your soundcard now has a volume control? No, your
> amp has.
> 
> > I have a bcm2835 (Pi 2 and 3) SoC here. It is producing multichannel (8 out,
> > 6 in) audio. In ALSA we call that DSP mode - right ?!
> 
> No. DSP modes are protocol/timing specifications as I2S, PDP, S/PDIF, ...
> You can look these up in datasheets and if a chip implements such a
> protocol you can be sure that it adheres to that standard - i.e. it
> will sync the frames to the pulses on LRclk.
> 

I agree with the thoughts in this thread really if the AP doesn't
actually support DSP A mode we shouldn't add DSP A mode.

Thanks,
Charles

[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Charles Keepax]

On Mon, Feb 27, 2017 at 12:51:08PM +0100, Matthias Reichl wrote:
> On Mon, Feb 27, 2017 at 10:21:25PM +1100, Matt Flax wrote:
> > 
> > 
> > On 27/02/17 21:30, Matthias Reichl wrote:
> > >
> > >I don't see that. Some people might want to be able to use multichannel
> > >on RPi, but that's something very different than adding code that just
> > >lies about driver capabilites.
> > >
> > 
> > I am going to invite you over for dinner to eat steamed vegetables :)
> > If I make the steamed vegetables in the microwave and they taste like
> > steamed vegetables, are they steamed vegetables ?
> 
> If you connect an amplifier with a volume control to your soundcard
> does that mean that your soundcard now has a volume control? No, your
> amp has.
> 
> > I have a bcm2835 (Pi 2 and 3) SoC here. It is producing multichannel (8 out,
> > 6 in) audio. In ALSA we call that DSP mode - right ?!
> 
> No. DSP modes are protocol/timing specifications as I2S, PDP, S/PDIF, ...
> You can look these up in datasheets and if a chip implements such a
> protocol you can be sure that it adheres to that standard - i.e. it
> will sync the frames to the pulses on LRclk.
> 

I agree with the thoughts in this thread really if the AP doesn't
actually support DSP A mode we shouldn't add DSP A mode.

Thanks,
Charles

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1621 bytes --]

On Tue, Feb 28, 2017 at 09:59:29AM +0000, Charles Keepax wrote:
> On Mon, Feb 27, 2017 at 12:51:08PM +0100, Matthias Reichl wrote:

> > > I have a bcm2835 (Pi 2 and 3) SoC here. It is producing multichannel (8 out,
> > > 6 in) audio. In ALSA we call that DSP mode - right ?!

> > No. DSP modes are protocol/timing specifications as I2S, PDP, S/PDIF, ...
> > You can look these up in datasheets and if a chip implements such a
> > protocol you can be sure that it adheres to that standard - i.e. it
> > will sync the frames to the pulses on LRclk.

> I agree with the thoughts in this thread really if the AP doesn't
> actually support DSP A mode we shouldn't add DSP A mode.

The trouble here is that this isn't 100% clear, the specifications of
the DSP modes are such that only one edge in the LRCLK matters and so
providing you're doing mono or have exact clocking they interoperate
perfectly well.  We already frequently do similar things the other way,
most of the programmable serial ports can't actually do I2S modes
properly and rely on exact clocking to get things right when operating
as I2S since they only sync on one edge (though they can generally
generate the clocks correctly when operating as master, they just don't
pay attention to the left/right switch edge).

That said unless we're doing something with the data layout or similar
configuration there's a fairly strong case for putting the mangling for
this in the core, something like just falling back to I2S mode if we set
DSP A and so on.  Which would be a lot nicer if we actually got round to
putting mode capability information in the drivers.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Mark Brown]

On Tue, Feb 28, 2017 at 09:59:29AM +0000, Charles Keepax wrote:
> On Mon, Feb 27, 2017 at 12:51:08PM +0100, Matthias Reichl wrote:

> > > I have a bcm2835 (Pi 2 and 3) SoC here. It is producing multichannel (8 out,
> > > 6 in) audio. In ALSA we call that DSP mode - right ?!

> > No. DSP modes are protocol/timing specifications as I2S, PDP, S/PDIF, ...
> > You can look these up in datasheets and if a chip implements such a
> > protocol you can be sure that it adheres to that standard - i.e. it
> > will sync the frames to the pulses on LRclk.

> I agree with the thoughts in this thread really if the AP doesn't
> actually support DSP A mode we shouldn't add DSP A mode.

The trouble here is that this isn't 100% clear, the specifications of
the DSP modes are such that only one edge in the LRCLK matters and so
providing you're doing mono or have exact clocking they interoperate
perfectly well.  We already frequently do similar things the other way,
most of the programmable serial ports can't actually do I2S modes
properly and rely on exact clocking to get things right when operating
as I2S since they only sync on one edge (though they can generally
generate the clocks correctly when operating as master, they just don't
pay attention to the left/right switch edge).

That said unless we're doing something with the data layout or similar
configuration there's a fairly strong case for putting the mangling for
this in the core, something like just falling back to I2S mode if we set
DSP A and so on.  Which would be a lot nicer if we actually got round to
putting mode capability information in the drivers.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170315/c7aeb7e6/attachment.sig>

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matt Flax]

On 16/03/17 06:01, Mark Brown wrote:
> On Tue, Feb 28, 2017 at 09:59:29AM +0000, Charles Keepax wrote:
>> On Mon, Feb 27, 2017 at 12:51:08PM +0100, Matthias Reichl wrote:
>>>> I have a bcm2835 (Pi 2 and 3) SoC here. It is producing multichannel (8 out,
>>>> 6 in) audio. In ALSA we call that DSP mode - right ?!
>>> No. DSP modes are protocol/timing specifications as I2S, PDP, S/PDIF, ...
>>> You can look these up in datasheets and if a chip implements such a
>>> protocol you can be sure that it adheres to that standard - i.e. it
>>> will sync the frames to the pulses on LRclk.
>> I agree with the thoughts in this thread really if the AP doesn't
>> actually support DSP A mode we shouldn't add DSP A mode.
> The trouble here is that this isn't 100% clear, the specifications of
> the DSP modes are such that only one edge in the LRCLK matters and so
> providing you're doing mono or have exact clocking they interoperate
> perfectly well.  We already frequently do similar things the other way,
> most of the programmable serial ports can't actually do I2S modes
> properly and rely on exact clocking to get things right when operating
> as I2S since they only sync on one edge (though they can generally
> generate the clocks correctly when operating as master, they just don't
> pay attention to the left/right switch edge).
>
> That said unless we're doing something with the data layout or similar
> configuration there's a fairly strong case for putting the mangling for
> this in the core, something like just falling back to I2S mode if we set
> DSP A and so on.  Which would be a lot nicer if we actually got round to
> putting mode capability information in the drivers.

I agree, the data layout is already configurable in the bcm2835_i2s.c 
platform driver. We can already use the "snd_soc_dai_set_bclk_ratio" 
function to manage word offsets in our machine drivers.

There is nothing which says that the bcm2835 SoC is I2S restricted in 
any way. In fact, the reference document says quite the opposite.

In the reference "BCM2835 ARM Peripherals" pdf, they call the audio 
system an "APB peripheral". They are saying that it is reconfigurable 
and part of the AMBA family of interconnect schemes.

As far as the bcm2835_i2s platform driver goes, it has implemented an 
AMBA protocol, where audio words are counted from the LR clock onset - 
for some reason people are insisting this is an I2S bus. Really our 
implementation is not I2S at all, because word onsets are programmable 
and flexible in the bcm2835_i2s.c driver.

What I have been trying to make happen over the past few months is to 
enable a different capability of the AMBA audio core on the bcm2835. Can 
you suggest a realistic approach to realising this which is acceptable 
to the ALSA code base ?

Do you suggest I go back to the approach of implementing the DSP mode 
for this platform driver ?

thanks
Matt

[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matt Flax]

On 16/03/17 06:01, Mark Brown wrote:
> On Tue, Feb 28, 2017 at 09:59:29AM +0000, Charles Keepax wrote:
>> On Mon, Feb 27, 2017 at 12:51:08PM +0100, Matthias Reichl wrote:
>>>> I have a bcm2835 (Pi 2 and 3) SoC here. It is producing multichannel (8 out,
>>>> 6 in) audio. In ALSA we call that DSP mode - right ?!
>>> No. DSP modes are protocol/timing specifications as I2S, PDP, S/PDIF, ...
>>> You can look these up in datasheets and if a chip implements such a
>>> protocol you can be sure that it adheres to that standard - i.e. it
>>> will sync the frames to the pulses on LRclk.
>> I agree with the thoughts in this thread really if the AP doesn't
>> actually support DSP A mode we shouldn't add DSP A mode.
> The trouble here is that this isn't 100% clear, the specifications of
> the DSP modes are such that only one edge in the LRCLK matters and so
> providing you're doing mono or have exact clocking they interoperate
> perfectly well.  We already frequently do similar things the other way,
> most of the programmable serial ports can't actually do I2S modes
> properly and rely on exact clocking to get things right when operating
> as I2S since they only sync on one edge (though they can generally
> generate the clocks correctly when operating as master, they just don't
> pay attention to the left/right switch edge).
>
> That said unless we're doing something with the data layout or similar
> configuration there's a fairly strong case for putting the mangling for
> this in the core, something like just falling back to I2S mode if we set
> DSP A and so on.  Which would be a lot nicer if we actually got round to
> putting mode capability information in the drivers.

I agree, the data layout is already configurable in the bcm2835_i2s.c 
platform driver. We can already use the "snd_soc_dai_set_bclk_ratio" 
function to manage word offsets in our machine drivers.

There is nothing which says that the bcm2835 SoC is I2S restricted in 
any way. In fact, the reference document says quite the opposite.

In the reference "BCM2835 ARM Peripherals" pdf, they call the audio 
system an "APB peripheral". They are saying that it is reconfigurable 
and part of the AMBA family of interconnect schemes.

As far as the bcm2835_i2s platform driver goes, it has implemented an 
AMBA protocol, where audio words are counted from the LR clock onset - 
for some reason people are insisting this is an I2S bus. Really our 
implementation is not I2S at all, because word onsets are programmable 
and flexible in the bcm2835_i2s.c driver.

What I have been trying to make happen over the past few months is to 
enable a different capability of the AMBA audio core on the bcm2835. Can 
you suggest a realistic approach to realising this which is acceptable 
to the ALSA code base ?

Do you suggest I go back to the approach of implementing the DSP mode 
for this platform driver ?

thanks
Matt

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Lars-Peter Clausen]

On 03/16/2017 09:51 PM, Matt Flax wrote:
> 
> 
> On 16/03/17 06:01, Mark Brown wrote:
>> On Tue, Feb 28, 2017 at 09:59:29AM +0000, Charles Keepax wrote:
>>> On Mon, Feb 27, 2017 at 12:51:08PM +0100, Matthias Reichl wrote:
>>>>> I have a bcm2835 (Pi 2 and 3) SoC here. It is producing multichannel (8
>>>>> out,
>>>>> 6 in) audio. In ALSA we call that DSP mode - right ?!
>>>> No. DSP modes are protocol/timing specifications as I2S, PDP, S/PDIF, ...
>>>> You can look these up in datasheets and if a chip implements such a
>>>> protocol you can be sure that it adheres to that standard - i.e. it
>>>> will sync the frames to the pulses on LRclk.
>>> I agree with the thoughts in this thread really if the AP doesn't
>>> actually support DSP A mode we shouldn't add DSP A mode.
>> The trouble here is that this isn't 100% clear, the specifications of
>> the DSP modes are such that only one edge in the LRCLK matters and so
>> providing you're doing mono or have exact clocking they interoperate
>> perfectly well.  We already frequently do similar things the other way,
>> most of the programmable serial ports can't actually do I2S modes
>> properly and rely on exact clocking to get things right when operating
>> as I2S since they only sync on one edge (though they can generally
>> generate the clocks correctly when operating as master, they just don't
>> pay attention to the left/right switch edge).
>>
>> That said unless we're doing something with the data layout or similar
>> configuration there's a fairly strong case for putting the mangling for
>> this in the core, something like just falling back to I2S mode if we set
>> DSP A and so on.  Which would be a lot nicer if we actually got round to
>> putting mode capability information in the drivers.
> 
> I agree, the data layout is already configurable in the bcm2835_i2s.c
> platform driver. We can already use the "snd_soc_dai_set_bclk_ratio"
> function to manage word offsets in our machine drivers.
> 
> There is nothing which says that the bcm2835 SoC is I2S restricted in any
> way. In fact, the reference document says quite the opposite.
> 
> In the reference "BCM2835 ARM Peripherals" pdf, they call the audio system
> an "APB peripheral". They are saying that it is reconfigurable and part of
> the AMBA family of interconnect schemes.
> 
> As far as the bcm2835_i2s platform driver goes, it has implemented an AMBA
> protocol, where audio words are counted from the LR clock onset - for some
> reason people are insisting this is an I2S bus. Really our implementation is
> not I2S at all, because word onsets are programmable and flexible in the
> bcm2835_i2s.c driver.

AMBA/APB is the interface which connects the peripheral to the system memory
bus. It is the interface over which the CPU does configuration register
writes. This has nothing and absolutely nothing to do with the I2S interface
that is also implemented by the peripheral that is used to stream audio to
and from external components.

[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Lars-Peter Clausen]

On 03/16/2017 09:51 PM, Matt Flax wrote:
> 
> 
> On 16/03/17 06:01, Mark Brown wrote:
>> On Tue, Feb 28, 2017 at 09:59:29AM +0000, Charles Keepax wrote:
>>> On Mon, Feb 27, 2017 at 12:51:08PM +0100, Matthias Reichl wrote:
>>>>> I have a bcm2835 (Pi 2 and 3) SoC here. It is producing multichannel (8
>>>>> out,
>>>>> 6 in) audio. In ALSA we call that DSP mode - right ?!
>>>> No. DSP modes are protocol/timing specifications as I2S, PDP, S/PDIF, ...
>>>> You can look these up in datasheets and if a chip implements such a
>>>> protocol you can be sure that it adheres to that standard - i.e. it
>>>> will sync the frames to the pulses on LRclk.
>>> I agree with the thoughts in this thread really if the AP doesn't
>>> actually support DSP A mode we shouldn't add DSP A mode.
>> The trouble here is that this isn't 100% clear, the specifications of
>> the DSP modes are such that only one edge in the LRCLK matters and so
>> providing you're doing mono or have exact clocking they interoperate
>> perfectly well.  We already frequently do similar things the other way,
>> most of the programmable serial ports can't actually do I2S modes
>> properly and rely on exact clocking to get things right when operating
>> as I2S since they only sync on one edge (though they can generally
>> generate the clocks correctly when operating as master, they just don't
>> pay attention to the left/right switch edge).
>>
>> That said unless we're doing something with the data layout or similar
>> configuration there's a fairly strong case for putting the mangling for
>> this in the core, something like just falling back to I2S mode if we set
>> DSP A and so on.  Which would be a lot nicer if we actually got round to
>> putting mode capability information in the drivers.
> 
> I agree, the data layout is already configurable in the bcm2835_i2s.c
> platform driver. We can already use the "snd_soc_dai_set_bclk_ratio"
> function to manage word offsets in our machine drivers.
> 
> There is nothing which says that the bcm2835 SoC is I2S restricted in any
> way. In fact, the reference document says quite the opposite.
> 
> In the reference "BCM2835 ARM Peripherals" pdf, they call the audio system
> an "APB peripheral". They are saying that it is reconfigurable and part of
> the AMBA family of interconnect schemes.
> 
> As far as the bcm2835_i2s platform driver goes, it has implemented an AMBA
> protocol, where audio words are counted from the LR clock onset - for some
> reason people are insisting this is an I2S bus. Really our implementation is
> not I2S at all, because word onsets are programmable and flexible in the
> bcm2835_i2s.c driver.

AMBA/APB is the interface which connects the peripheral to the system memory
bus. It is the interface over which the CPU does configuration register
writes. This has nothing and absolutely nothing to do with the I2S interface
that is also implemented by the peripheral that is used to stream audio to
and from external components.

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matt Flax]

On 17/03/17 08:27, Lars-Peter Clausen wrote:
> On 03/16/2017 09:51 PM, Matt Flax wrote:
>>
>> On 16/03/17 06:01, Mark Brown wrote:
>>> On Tue, Feb 28, 2017 at 09:59:29AM +0000, Charles Keepax wrote:
>>>> On Mon, Feb 27, 2017 at 12:51:08PM +0100, Matthias Reichl wrote:
>>>>>> I have a bcm2835 (Pi 2 and 3) SoC here. It is producing multichannel (8
>>>>>> out,
>>>>>> 6 in) audio. In ALSA we call that DSP mode - right ?!
>>>>> No. DSP modes are protocol/timing specifications as I2S, PDP, S/PDIF, ...
>>>>> You can look these up in datasheets and if a chip implements such a
>>>>> protocol you can be sure that it adheres to that standard - i.e. it
>>>>> will sync the frames to the pulses on LRclk.
>>>> I agree with the thoughts in this thread really if the AP doesn't
>>>> actually support DSP A mode we shouldn't add DSP A mode.
>>> The trouble here is that this isn't 100% clear, the specifications of
>>> the DSP modes are such that only one edge in the LRCLK matters and so
>>> providing you're doing mono or have exact clocking they interoperate
>>> perfectly well.  We already frequently do similar things the other way,
>>> most of the programmable serial ports can't actually do I2S modes
>>> properly and rely on exact clocking to get things right when operating
>>> as I2S since they only sync on one edge (though they can generally
>>> generate the clocks correctly when operating as master, they just don't
>>> pay attention to the left/right switch edge).
>>>
>>> That said unless we're doing something with the data layout or similar
>>> configuration there's a fairly strong case for putting the mangling for
>>> this in the core, something like just falling back to I2S mode if we set
>>> DSP A and so on.  Which would be a lot nicer if we actually got round to
>>> putting mode capability information in the drivers.
>> I agree, the data layout is already configurable in the bcm2835_i2s.c
>> platform driver. We can already use the "snd_soc_dai_set_bclk_ratio"
>> function to manage word offsets in our machine drivers.
>>
>> There is nothing which says that the bcm2835 SoC is I2S restricted in any
>> way. In fact, the reference document says quite the opposite.
>>
>> In the reference "BCM2835 ARM Peripherals" pdf, they call the audio system
>> an "APB peripheral". They are saying that it is reconfigurable and part of
>> the AMBA family of interconnect schemes.
>>
>> As far as the bcm2835_i2s platform driver goes, it has implemented an AMBA
>> protocol, where audio words are counted from the LR clock onset - for some
>> reason people are insisting this is an I2S bus. Really our implementation is
>> not I2S at all, because word onsets are programmable and flexible in the
>> bcm2835_i2s.c driver.
> AMBA/APB is the interface which connects the peripheral to the system memory
> bus. It is the interface over which the CPU does configuration register
> writes. This has nothing and absolutely nothing to do with the I2S interface
> that is also implemented by the peripheral that is used to stream audio to
> and from external components.
>

Their (BCM reference) document [1] specifically states "It supports many 
classic PCM formats including I2S".

Do agree with Mark's statement "the specifications of the DSP modes are 
such that only one edge in the LRCLK matters" ?

If we look at the bcm2835 platform driver setup, it is concerned with 
bit clock counting to specify the audio data for both of the AMBA/APB 
channels from serial bitstream into memory. It has two channels into 
memory, however "it supports many classic PCM formats" ... my vote for 
one classic format is DSP mode !

Do you see a problem with that ?

thanks
Matt
[1] 
https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf

[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matt Flax]

On 17/03/17 08:27, Lars-Peter Clausen wrote:
> On 03/16/2017 09:51 PM, Matt Flax wrote:
>>
>> On 16/03/17 06:01, Mark Brown wrote:
>>> On Tue, Feb 28, 2017 at 09:59:29AM +0000, Charles Keepax wrote:
>>>> On Mon, Feb 27, 2017 at 12:51:08PM +0100, Matthias Reichl wrote:
>>>>>> I have a bcm2835 (Pi 2 and 3) SoC here. It is producing multichannel (8
>>>>>> out,
>>>>>> 6 in) audio. In ALSA we call that DSP mode - right ?!
>>>>> No. DSP modes are protocol/timing specifications as I2S, PDP, S/PDIF, ...
>>>>> You can look these up in datasheets and if a chip implements such a
>>>>> protocol you can be sure that it adheres to that standard - i.e. it
>>>>> will sync the frames to the pulses on LRclk.
>>>> I agree with the thoughts in this thread really if the AP doesn't
>>>> actually support DSP A mode we shouldn't add DSP A mode.
>>> The trouble here is that this isn't 100% clear, the specifications of
>>> the DSP modes are such that only one edge in the LRCLK matters and so
>>> providing you're doing mono or have exact clocking they interoperate
>>> perfectly well.  We already frequently do similar things the other way,
>>> most of the programmable serial ports can't actually do I2S modes
>>> properly and rely on exact clocking to get things right when operating
>>> as I2S since they only sync on one edge (though they can generally
>>> generate the clocks correctly when operating as master, they just don't
>>> pay attention to the left/right switch edge).
>>>
>>> That said unless we're doing something with the data layout or similar
>>> configuration there's a fairly strong case for putting the mangling for
>>> this in the core, something like just falling back to I2S mode if we set
>>> DSP A and so on.  Which would be a lot nicer if we actually got round to
>>> putting mode capability information in the drivers.
>> I agree, the data layout is already configurable in the bcm2835_i2s.c
>> platform driver. We can already use the "snd_soc_dai_set_bclk_ratio"
>> function to manage word offsets in our machine drivers.
>>
>> There is nothing which says that the bcm2835 SoC is I2S restricted in any
>> way. In fact, the reference document says quite the opposite.
>>
>> In the reference "BCM2835 ARM Peripherals" pdf, they call the audio system
>> an "APB peripheral". They are saying that it is reconfigurable and part of
>> the AMBA family of interconnect schemes.
>>
>> As far as the bcm2835_i2s platform driver goes, it has implemented an AMBA
>> protocol, where audio words are counted from the LR clock onset - for some
>> reason people are insisting this is an I2S bus. Really our implementation is
>> not I2S at all, because word onsets are programmable and flexible in the
>> bcm2835_i2s.c driver.
> AMBA/APB is the interface which connects the peripheral to the system memory
> bus. It is the interface over which the CPU does configuration register
> writes. This has nothing and absolutely nothing to do with the I2S interface
> that is also implemented by the peripheral that is used to stream audio to
> and from external components.
>

Their (BCM reference) document [1] specifically states "It supports many 
classic PCM formats including I2S".

Do agree with Mark's statement "the specifications of the DSP modes are 
such that only one edge in the LRCLK matters" ?

If we look at the bcm2835 platform driver setup, it is concerned with 
bit clock counting to specify the audio data for both of the AMBA/APB 
channels from serial bitstream into memory. It has two channels into 
memory, however "it supports many classic PCM formats" ... my vote for 
one classic format is DSP mode !

Do you see a problem with that ?

thanks
Matt
[1] 
https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Emmanuel Fusté]

Le 16/03/2017 à 23:14, Matt Flax a écrit :
>
>
> On 17/03/17 08:27, Lars-Peter Clausen wrote:
>> On 03/16/2017 09:51 PM, Matt Flax wrote:
>>>
>>> On 16/03/17 06:01, Mark Brown wrote:
>>>> On Tue, Feb 28, 2017 at 09:59:29AM +0000, Charles Keepax wrote:
>>>>> On Mon, Feb 27, 2017 at 12:51:08PM +0100, Matthias Reichl wrote:
>>>>>>> I have a bcm2835 (Pi 2 and 3) SoC here. It is producing 
>>>>>>> multichannel (8
>>>>>>> out,
>>>>>>> 6 in) audio. In ALSA we call that DSP mode - right ?!
>>>>>> No. DSP modes are protocol/timing specifications as I2S, PDP, 
>>>>>> S/PDIF, ...
>>>>>> You can look these up in datasheets and if a chip implements such a
>>>>>> protocol you can be sure that it adheres to that standard - i.e. it
>>>>>> will sync the frames to the pulses on LRclk.
>>>>> I agree with the thoughts in this thread really if the AP doesn't
>>>>> actually support DSP A mode we shouldn't add DSP A mode.
>>>> The trouble here is that this isn't 100% clear, the specifications of
>>>> the DSP modes are such that only one edge in the LRCLK matters and so
>>>> providing you're doing mono or have exact clocking they interoperate
>>>> perfectly well.  We already frequently do similar things the other 
>>>> way,
>>>> most of the programmable serial ports can't actually do I2S modes
>>>> properly and rely on exact clocking to get things right when operating
>>>> as I2S since they only sync on one edge (though they can generally
>>>> generate the clocks correctly when operating as master, they just 
>>>> don't
>>>> pay attention to the left/right switch edge).
>>>>
>>>> That said unless we're doing something with the data layout or similar
>>>> configuration there's a fairly strong case for putting the mangling 
>>>> for
>>>> this in the core, something like just falling back to I2S mode if 
>>>> we set
>>>> DSP A and so on.  Which would be a lot nicer if we actually got 
>>>> round to
>>>> putting mode capability information in the drivers.
>>> I agree, the data layout is already configurable in the bcm2835_i2s.c
>>> platform driver. We can already use the "snd_soc_dai_set_bclk_ratio"
>>> function to manage word offsets in our machine drivers.
>>>
>>> There is nothing which says that the bcm2835 SoC is I2S restricted 
>>> in any
>>> way. In fact, the reference document says quite the opposite.
>>>
>>> In the reference "BCM2835 ARM Peripherals" pdf, they call the audio 
>>> system
>>> an "APB peripheral". They are saying that it is reconfigurable and 
>>> part of
>>> the AMBA family of interconnect schemes.
>>>
>>> As far as the bcm2835_i2s platform driver goes, it has implemented 
>>> an AMBA
>>> protocol, where audio words are counted from the LR clock onset - 
>>> for some
>>> reason people are insisting this is an I2S bus. Really our 
>>> implementation is
>>> not I2S at all, because word onsets are programmable and flexible in 
>>> the
>>> bcm2835_i2s.c driver.
>> AMBA/APB is the interface which connects the peripheral to the system 
>> memory
>> bus. It is the interface over which the CPU does configuration register
>> writes. This has nothing and absolutely nothing to do with the I2S 
>> interface
>> that is also implemented by the peripheral that is used to stream 
>> audio to
>> and from external components.
>>
>
> Their (BCM reference) document [1] specifically states "It supports 
> many classic PCM formats including I2S".
>
> Do agree with Mark's statement "the specifications of the DSP modes 
> are such that only one edge in the LRCLK matters" ?
>
> If we look at the bcm2835 platform driver setup, it is concerned with 
> bit clock counting to specify the audio data for both of the AMBA/APB 
> channels from serial bitstream into memory. It has two channels into 
> memory, however "it supports many classic PCM formats" ... my vote for 
> one classic format is DSP mode !
>
> Do you see a problem with that ?
>
> thanks
> Matt
> [1] 
> https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
> _______________________________________________
>
Re-reading this document, the bcm2835 PCM IP block SHOULD support real 
DSP mode, with one BCLK pulsed LRCLK, zero BCLK delay etc...
It just need to be properly setup.
According to the same document, you could program the bmc up to 16 
32bits channels when in master mode, so I suspect that you could go up 
to this limit in slave mode.
But as it is designed, it could only use up to two of any channels among 
the 16.

Emmanuel.

[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Emmanuel Fusté]

Le 16/03/2017 ? 23:14, Matt Flax a ?crit :
>
>
> On 17/03/17 08:27, Lars-Peter Clausen wrote:
>> On 03/16/2017 09:51 PM, Matt Flax wrote:
>>>
>>> On 16/03/17 06:01, Mark Brown wrote:
>>>> On Tue, Feb 28, 2017 at 09:59:29AM +0000, Charles Keepax wrote:
>>>>> On Mon, Feb 27, 2017 at 12:51:08PM +0100, Matthias Reichl wrote:
>>>>>>> I have a bcm2835 (Pi 2 and 3) SoC here. It is producing 
>>>>>>> multichannel (8
>>>>>>> out,
>>>>>>> 6 in) audio. In ALSA we call that DSP mode - right ?!
>>>>>> No. DSP modes are protocol/timing specifications as I2S, PDP, 
>>>>>> S/PDIF, ...
>>>>>> You can look these up in datasheets and if a chip implements such a
>>>>>> protocol you can be sure that it adheres to that standard - i.e. it
>>>>>> will sync the frames to the pulses on LRclk.
>>>>> I agree with the thoughts in this thread really if the AP doesn't
>>>>> actually support DSP A mode we shouldn't add DSP A mode.
>>>> The trouble here is that this isn't 100% clear, the specifications of
>>>> the DSP modes are such that only one edge in the LRCLK matters and so
>>>> providing you're doing mono or have exact clocking they interoperate
>>>> perfectly well.  We already frequently do similar things the other 
>>>> way,
>>>> most of the programmable serial ports can't actually do I2S modes
>>>> properly and rely on exact clocking to get things right when operating
>>>> as I2S since they only sync on one edge (though they can generally
>>>> generate the clocks correctly when operating as master, they just 
>>>> don't
>>>> pay attention to the left/right switch edge).
>>>>
>>>> That said unless we're doing something with the data layout or similar
>>>> configuration there's a fairly strong case for putting the mangling 
>>>> for
>>>> this in the core, something like just falling back to I2S mode if 
>>>> we set
>>>> DSP A and so on.  Which would be a lot nicer if we actually got 
>>>> round to
>>>> putting mode capability information in the drivers.
>>> I agree, the data layout is already configurable in the bcm2835_i2s.c
>>> platform driver. We can already use the "snd_soc_dai_set_bclk_ratio"
>>> function to manage word offsets in our machine drivers.
>>>
>>> There is nothing which says that the bcm2835 SoC is I2S restricted 
>>> in any
>>> way. In fact, the reference document says quite the opposite.
>>>
>>> In the reference "BCM2835 ARM Peripherals" pdf, they call the audio 
>>> system
>>> an "APB peripheral". They are saying that it is reconfigurable and 
>>> part of
>>> the AMBA family of interconnect schemes.
>>>
>>> As far as the bcm2835_i2s platform driver goes, it has implemented 
>>> an AMBA
>>> protocol, where audio words are counted from the LR clock onset - 
>>> for some
>>> reason people are insisting this is an I2S bus. Really our 
>>> implementation is
>>> not I2S at all, because word onsets are programmable and flexible in 
>>> the
>>> bcm2835_i2s.c driver.
>> AMBA/APB is the interface which connects the peripheral to the system 
>> memory
>> bus. It is the interface over which the CPU does configuration register
>> writes. This has nothing and absolutely nothing to do with the I2S 
>> interface
>> that is also implemented by the peripheral that is used to stream 
>> audio to
>> and from external components.
>>
>
> Their (BCM reference) document [1] specifically states "It supports 
> many classic PCM formats including I2S".
>
> Do agree with Mark's statement "the specifications of the DSP modes 
> are such that only one edge in the LRCLK matters" ?
>
> If we look at the bcm2835 platform driver setup, it is concerned with 
> bit clock counting to specify the audio data for both of the AMBA/APB 
> channels from serial bitstream into memory. It has two channels into 
> memory, however "it supports many classic PCM formats" ... my vote for 
> one classic format is DSP mode !
>
> Do you see a problem with that ?
>
> thanks
> Matt
> [1] 
> https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
> _______________________________________________
>
Re-reading this document, the bcm2835 PCM IP block SHOULD support real 
DSP mode, with one BCLK pulsed LRCLK, zero BCLK delay etc...
It just need to be properly setup.
According to the same document, you could program the bmc up to 16 
32bits channels when in master mode, so I suspect that you could go up 
to this limit in slave mode.
But as it is designed, it could only use up to two of any channels among 
the 16.

Emmanuel.

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matthias Reichl]

On Tue, Mar 21, 2017 at 10:21:04PM +0100, Emmanuel Fusté wrote:
> Le 16/03/2017 à 23:14, Matt Flax a écrit :
> >
> >
> >On 17/03/17 08:27, Lars-Peter Clausen wrote:
> >>On 03/16/2017 09:51 PM, Matt Flax wrote:
> >>>
> >>>On 16/03/17 06:01, Mark Brown wrote:
> >>>>On Tue, Feb 28, 2017 at 09:59:29AM +0000, Charles Keepax wrote:
> >>>>>On Mon, Feb 27, 2017 at 12:51:08PM +0100, Matthias Reichl wrote:
> >>>>>>>I have a bcm2835 (Pi 2 and 3) SoC here. It is producing
> >>>>>>>multichannel (8
> >>>>>>>out,
> >>>>>>>6 in) audio. In ALSA we call that DSP mode - right ?!
> >>>>>>No. DSP modes are protocol/timing specifications as I2S, PDP,
> >>>>>>S/PDIF, ...
> >>>>>>You can look these up in datasheets and if a chip implements such a
> >>>>>>protocol you can be sure that it adheres to that standard - i.e. it
> >>>>>>will sync the frames to the pulses on LRclk.
> >>>>>I agree with the thoughts in this thread really if the AP doesn't
> >>>>>actually support DSP A mode we shouldn't add DSP A mode.
> >>>>The trouble here is that this isn't 100% clear, the specifications of
> >>>>the DSP modes are such that only one edge in the LRCLK matters and so
> >>>>providing you're doing mono or have exact clocking they interoperate
> >>>>perfectly well.  We already frequently do similar things the other
> >>>>way,
> >>>>most of the programmable serial ports can't actually do I2S modes
> >>>>properly and rely on exact clocking to get things right when operating
> >>>>as I2S since they only sync on one edge (though they can generally
> >>>>generate the clocks correctly when operating as master, they just
> >>>>don't
> >>>>pay attention to the left/right switch edge).
> >>>>
> >>>>That said unless we're doing something with the data layout or similar
> >>>>configuration there's a fairly strong case for putting the mangling
> >>>>for
> >>>>this in the core, something like just falling back to I2S mode if we
> >>>>set
> >>>>DSP A and so on.  Which would be a lot nicer if we actually got
> >>>>round to
> >>>>putting mode capability information in the drivers.
> >>>I agree, the data layout is already configurable in the bcm2835_i2s.c
> >>>platform driver. We can already use the "snd_soc_dai_set_bclk_ratio"
> >>>function to manage word offsets in our machine drivers.
> >>>
> >>>There is nothing which says that the bcm2835 SoC is I2S restricted in
> >>>any
> >>>way. In fact, the reference document says quite the opposite.
> >>>
> >>>In the reference "BCM2835 ARM Peripherals" pdf, they call the audio
> >>>system
> >>>an "APB peripheral". They are saying that it is reconfigurable and
> >>>part of
> >>>the AMBA family of interconnect schemes.
> >>>
> >>>As far as the bcm2835_i2s platform driver goes, it has implemented an
> >>>AMBA
> >>>protocol, where audio words are counted from the LR clock onset - for
> >>>some
> >>>reason people are insisting this is an I2S bus. Really our
> >>>implementation is
> >>>not I2S at all, because word onsets are programmable and flexible in
> >>>the
> >>>bcm2835_i2s.c driver.
> >>AMBA/APB is the interface which connects the peripheral to the system
> >>memory
> >>bus. It is the interface over which the CPU does configuration register
> >>writes. This has nothing and absolutely nothing to do with the I2S
> >>interface
> >>that is also implemented by the peripheral that is used to stream audio
> >>to
> >>and from external components.
> >>
> >
> >Their (BCM reference) document [1] specifically states "It supports many
> >classic PCM formats including I2S".
> >
> >Do agree with Mark's statement "the specifications of the DSP modes are
> >such that only one edge in the LRCLK matters" ?
> >
> >If we look at the bcm2835 platform driver setup, it is concerned with bit
> >clock counting to specify the audio data for both of the AMBA/APB channels
> >from serial bitstream into memory. It has two channels into memory,
> >however "it supports many classic PCM formats" ... my vote for one classic
> >format is DSP mode !
> >
> >Do you see a problem with that ?
> >
> >thanks
> >Matt
> >[1] https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
> >_______________________________________________
> >
> Re-reading this document, the bcm2835 PCM IP block SHOULD support real DSP
> mode, with one BCLK pulsed LRCLK, zero BCLK delay etc...
> It just need to be properly setup.

I've re-read the document, too, last week and noticed the framesync
registers - sorry, I had completely forgotten about these. I guess it
should be possible to configure the bcm2835 to DSP mode but it'd still be
limited to 2 channel setups - the hardware only has 2 channel position
registers for each direction.

> According to the same document, you could program the bmc up to 16 32bits
> channels when in master mode, so I suspect that you could go up to this
> limit in slave mode.
> But as it is designed, it could only use up to two of any channels among the
> 16.

I'm not quite sure if I can follow you on this - how would you
configure 16 channels when there are only 2 channel position registers?

With bclk ratio eg set to 16*32=512 BCM2835 will only transmit 2*32
bits of data (at configurable bit positions), the remaining 448
bits will be zero.

so long,

Hias

[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matthias Reichl]

On Tue, Mar 21, 2017 at 10:21:04PM +0100, Emmanuel Fust? wrote:
> Le 16/03/2017 ? 23:14, Matt Flax a ?crit :
> >
> >
> >On 17/03/17 08:27, Lars-Peter Clausen wrote:
> >>On 03/16/2017 09:51 PM, Matt Flax wrote:
> >>>
> >>>On 16/03/17 06:01, Mark Brown wrote:
> >>>>On Tue, Feb 28, 2017 at 09:59:29AM +0000, Charles Keepax wrote:
> >>>>>On Mon, Feb 27, 2017 at 12:51:08PM +0100, Matthias Reichl wrote:
> >>>>>>>I have a bcm2835 (Pi 2 and 3) SoC here. It is producing
> >>>>>>>multichannel (8
> >>>>>>>out,
> >>>>>>>6 in) audio. In ALSA we call that DSP mode - right ?!
> >>>>>>No. DSP modes are protocol/timing specifications as I2S, PDP,
> >>>>>>S/PDIF, ...
> >>>>>>You can look these up in datasheets and if a chip implements such a
> >>>>>>protocol you can be sure that it adheres to that standard - i.e. it
> >>>>>>will sync the frames to the pulses on LRclk.
> >>>>>I agree with the thoughts in this thread really if the AP doesn't
> >>>>>actually support DSP A mode we shouldn't add DSP A mode.
> >>>>The trouble here is that this isn't 100% clear, the specifications of
> >>>>the DSP modes are such that only one edge in the LRCLK matters and so
> >>>>providing you're doing mono or have exact clocking they interoperate
> >>>>perfectly well.  We already frequently do similar things the other
> >>>>way,
> >>>>most of the programmable serial ports can't actually do I2S modes
> >>>>properly and rely on exact clocking to get things right when operating
> >>>>as I2S since they only sync on one edge (though they can generally
> >>>>generate the clocks correctly when operating as master, they just
> >>>>don't
> >>>>pay attention to the left/right switch edge).
> >>>>
> >>>>That said unless we're doing something with the data layout or similar
> >>>>configuration there's a fairly strong case for putting the mangling
> >>>>for
> >>>>this in the core, something like just falling back to I2S mode if we
> >>>>set
> >>>>DSP A and so on.  Which would be a lot nicer if we actually got
> >>>>round to
> >>>>putting mode capability information in the drivers.
> >>>I agree, the data layout is already configurable in the bcm2835_i2s.c
> >>>platform driver. We can already use the "snd_soc_dai_set_bclk_ratio"
> >>>function to manage word offsets in our machine drivers.
> >>>
> >>>There is nothing which says that the bcm2835 SoC is I2S restricted in
> >>>any
> >>>way. In fact, the reference document says quite the opposite.
> >>>
> >>>In the reference "BCM2835 ARM Peripherals" pdf, they call the audio
> >>>system
> >>>an "APB peripheral". They are saying that it is reconfigurable and
> >>>part of
> >>>the AMBA family of interconnect schemes.
> >>>
> >>>As far as the bcm2835_i2s platform driver goes, it has implemented an
> >>>AMBA
> >>>protocol, where audio words are counted from the LR clock onset - for
> >>>some
> >>>reason people are insisting this is an I2S bus. Really our
> >>>implementation is
> >>>not I2S at all, because word onsets are programmable and flexible in
> >>>the
> >>>bcm2835_i2s.c driver.
> >>AMBA/APB is the interface which connects the peripheral to the system
> >>memory
> >>bus. It is the interface over which the CPU does configuration register
> >>writes. This has nothing and absolutely nothing to do with the I2S
> >>interface
> >>that is also implemented by the peripheral that is used to stream audio
> >>to
> >>and from external components.
> >>
> >
> >Their (BCM reference) document [1] specifically states "It supports many
> >classic PCM formats including I2S".
> >
> >Do agree with Mark's statement "the specifications of the DSP modes are
> >such that only one edge in the LRCLK matters" ?
> >
> >If we look at the bcm2835 platform driver setup, it is concerned with bit
> >clock counting to specify the audio data for both of the AMBA/APB channels
> >from serial bitstream into memory. It has two channels into memory,
> >however "it supports many classic PCM formats" ... my vote for one classic
> >format is DSP mode !
> >
> >Do you see a problem with that ?
> >
> >thanks
> >Matt
> >[1] https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
> >_______________________________________________
> >
> Re-reading this document, the bcm2835 PCM IP block SHOULD support real DSP
> mode, with one BCLK pulsed LRCLK, zero BCLK delay etc...
> It just need to be properly setup.

I've re-read the document, too, last week and noticed the framesync
registers - sorry, I had completely forgotten about these. I guess it
should be possible to configure the bcm2835 to DSP mode but it'd still be
limited to 2 channel setups - the hardware only has 2 channel position
registers for each direction.

> According to the same document, you could program the bmc up to 16 32bits
> channels when in master mode, so I suspect that you could go up to this
> limit in slave mode.
> But as it is designed, it could only use up to two of any channels among the
> 16.

I'm not quite sure if I can follow you on this - how would you
configure 16 channels when there are only 2 channel position registers?

With bclk ratio eg set to 16*32=512 BCM2835 will only transmit 2*32
bits of data (at configurable bit positions), the remaining 448
bits will be zero.

so long,

Hias

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matt Flax]

On 22/03/17 09:11, Matthias Reichl wrote:
> On Tue, Mar 21, 2017 at 10:21:04PM +0100, Emmanuel Fusté wrote:
>> Le 16/03/2017 à 23:14, Matt Flax a écrit :
>>>
>>> On 17/03/17 08:27, Lars-Peter Clausen wrote:
>>>> On 03/16/2017 09:51 PM, Matt Flax wrote:
>>>>> On 16/03/17 06:01, Mark Brown wrote:
>>>>>> On Tue, Feb 28, 2017 at 09:59:29AM +0000, Charles Keepax wrote:
>>>>>>> On Mon, Feb 27, 2017 at 12:51:08PM +0100, Matthias Reichl wrote:
>>>>>>>>> I have a bcm2835 (Pi 2 and 3) SoC here. It is producing
>>>>>>>>> multichannel (8
>>>>>>>>> out,
>>>>>>>>> 6 in) audio. In ALSA we call that DSP mode - right ?!
>>>>>>>> No. DSP modes are protocol/timing specifications as I2S, PDP,
>>>>>>>> S/PDIF, ...
>>>>>>>> You can look these up in datasheets and if a chip implements such a
>>>>>>>> protocol you can be sure that it adheres to that standard - i.e. it
>>>>>>>> will sync the frames to the pulses on LRclk.
>>>>>>> I agree with the thoughts in this thread really if the AP doesn't
>>>>>>> actually support DSP A mode we shouldn't add DSP A mode.
>>>>>> The trouble here is that this isn't 100% clear, the specifications of
>>>>>> the DSP modes are such that only one edge in the LRCLK matters and so
>>>>>> providing you're doing mono or have exact clocking they interoperate
>>>>>> perfectly well.  We already frequently do similar things the other
>>>>>> way,
>>>>>> most of the programmable serial ports can't actually do I2S modes
>>>>>> properly and rely on exact clocking to get things right when operating
>>>>>> as I2S since they only sync on one edge (though they can generally
>>>>>> generate the clocks correctly when operating as master, they just
>>>>>> don't
>>>>>> pay attention to the left/right switch edge).
>>>>>>
>>>>>> That said unless we're doing something with the data layout or similar
>>>>>> configuration there's a fairly strong case for putting the mangling
>>>>>> for
>>>>>> this in the core, something like just falling back to I2S mode if we
>>>>>> set
>>>>>> DSP A and so on.  Which would be a lot nicer if we actually got
>>>>>> round to
>>>>>> putting mode capability information in the drivers.
>>>>> I agree, the data layout is already configurable in the bcm2835_i2s.c
>>>>> platform driver. We can already use the "snd_soc_dai_set_bclk_ratio"
>>>>> function to manage word offsets in our machine drivers.
>>>>>
>>>>> There is nothing which says that the bcm2835 SoC is I2S restricted in
>>>>> any
>>>>> way. In fact, the reference document says quite the opposite.
>>>>>
>>>>> In the reference "BCM2835 ARM Peripherals" pdf, they call the audio
>>>>> system
>>>>> an "APB peripheral". They are saying that it is reconfigurable and
>>>>> part of
>>>>> the AMBA family of interconnect schemes.
>>>>>
>>>>> As far as the bcm2835_i2s platform driver goes, it has implemented an
>>>>> AMBA
>>>>> protocol, where audio words are counted from the LR clock onset - for
>>>>> some
>>>>> reason people are insisting this is an I2S bus. Really our
>>>>> implementation is
>>>>> not I2S at all, because word onsets are programmable and flexible in
>>>>> the
>>>>> bcm2835_i2s.c driver.
>>>> AMBA/APB is the interface which connects the peripheral to the system
>>>> memory
>>>> bus. It is the interface over which the CPU does configuration register
>>>> writes. This has nothing and absolutely nothing to do with the I2S
>>>> interface
>>>> that is also implemented by the peripheral that is used to stream audio
>>>> to
>>>> and from external components.
>>>>
>>> Their (BCM reference) document [1] specifically states "It supports many
>>> classic PCM formats including I2S".
>>>
>>> Do agree with Mark's statement "the specifications of the DSP modes are
>>> such that only one edge in the LRCLK matters" ?
>>>
>>> If we look at the bcm2835 platform driver setup, it is concerned with bit
>>> clock counting to specify the audio data for both of the AMBA/APB channels
>> >from serial bitstream into memory. It has two channels into memory,
>>> however "it supports many classic PCM formats" ... my vote for one classic
>>> format is DSP mode !
>>>
>>> Do you see a problem with that ?
>>>
>>> thanks
>>> Matt
>>> [1] https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
>>> _______________________________________________
>>>
>> Re-reading this document, the bcm2835 PCM IP block SHOULD support real DSP
>> mode, with one BCLK pulsed LRCLK, zero BCLK delay etc...
>> It just need to be properly setup.
> I've re-read the document, too, last week and noticed the framesync
> registers - sorry, I had completely forgotten about these. I guess it
> should be possible to configure the bcm2835 to DSP mode but it'd still be
> limited to 2 channel setups - the hardware only has 2 channel position
> registers for each direction.
>
>> According to the same document, you could program the bmc up to 16 32bits
>> channels when in master mode, so I suspect that you could go up to this
>> limit in slave mode.
>> But as it is designed, it could only use up to two of any channels among the
>> 16.
> I'm not quite sure if I can follow you on this - how would you
> configure 16 channels when there are only 2 channel position registers?
>
> With bclk ratio eg set to 16*32=512 BCM2835 will only transmit 2*32
> bits of data (at configurable bit positions), the remaining 448
> bits will be zero.
>
The document seems to stipulate that the PCM audio device is an AMBA 
device with 2 APB data channels. The first sync edge marks the beginning 
of the two data words. Their frame lengths can be up to 1024+32 bits in 
length !

I think the point is that they intended their PCM audio interface to be 
configurable, they say in their document "It supports many classic PCM 
formats".

The important point here is that in ALSA we can only have I2S or DSP 
modes - right ?
Unless we want to create a new ALSA mode (which clearly worries people) 
then we need to support the versatility of the bcm2835 PCM hardware 
using either DSP or I2S modes. Now, we have already implemented the I2S 
mode, so logically the only available mode left is the DSP mode. Using 
this mode, we can implement more features of this device.

People seem to want to reserve DSP and I2S modes for strictly I2S and 
DSP protocols. At the same time people don't want to allow a looser 
"APB" mode into ALSA. For that reason, we have a lack of functionality 
for perfectly versatile hardware - the bcm2835 hardware.

Matt

[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matt Flax]

On 22/03/17 09:11, Matthias Reichl wrote:
> On Tue, Mar 21, 2017 at 10:21:04PM +0100, Emmanuel Fust? wrote:
>> Le 16/03/2017 ? 23:14, Matt Flax a ?crit :
>>>
>>> On 17/03/17 08:27, Lars-Peter Clausen wrote:
>>>> On 03/16/2017 09:51 PM, Matt Flax wrote:
>>>>> On 16/03/17 06:01, Mark Brown wrote:
>>>>>> On Tue, Feb 28, 2017 at 09:59:29AM +0000, Charles Keepax wrote:
>>>>>>> On Mon, Feb 27, 2017 at 12:51:08PM +0100, Matthias Reichl wrote:
>>>>>>>>> I have a bcm2835 (Pi 2 and 3) SoC here. It is producing
>>>>>>>>> multichannel (8
>>>>>>>>> out,
>>>>>>>>> 6 in) audio. In ALSA we call that DSP mode - right ?!
>>>>>>>> No. DSP modes are protocol/timing specifications as I2S, PDP,
>>>>>>>> S/PDIF, ...
>>>>>>>> You can look these up in datasheets and if a chip implements such a
>>>>>>>> protocol you can be sure that it adheres to that standard - i.e. it
>>>>>>>> will sync the frames to the pulses on LRclk.
>>>>>>> I agree with the thoughts in this thread really if the AP doesn't
>>>>>>> actually support DSP A mode we shouldn't add DSP A mode.
>>>>>> The trouble here is that this isn't 100% clear, the specifications of
>>>>>> the DSP modes are such that only one edge in the LRCLK matters and so
>>>>>> providing you're doing mono or have exact clocking they interoperate
>>>>>> perfectly well.  We already frequently do similar things the other
>>>>>> way,
>>>>>> most of the programmable serial ports can't actually do I2S modes
>>>>>> properly and rely on exact clocking to get things right when operating
>>>>>> as I2S since they only sync on one edge (though they can generally
>>>>>> generate the clocks correctly when operating as master, they just
>>>>>> don't
>>>>>> pay attention to the left/right switch edge).
>>>>>>
>>>>>> That said unless we're doing something with the data layout or similar
>>>>>> configuration there's a fairly strong case for putting the mangling
>>>>>> for
>>>>>> this in the core, something like just falling back to I2S mode if we
>>>>>> set
>>>>>> DSP A and so on.  Which would be a lot nicer if we actually got
>>>>>> round to
>>>>>> putting mode capability information in the drivers.
>>>>> I agree, the data layout is already configurable in the bcm2835_i2s.c
>>>>> platform driver. We can already use the "snd_soc_dai_set_bclk_ratio"
>>>>> function to manage word offsets in our machine drivers.
>>>>>
>>>>> There is nothing which says that the bcm2835 SoC is I2S restricted in
>>>>> any
>>>>> way. In fact, the reference document says quite the opposite.
>>>>>
>>>>> In the reference "BCM2835 ARM Peripherals" pdf, they call the audio
>>>>> system
>>>>> an "APB peripheral". They are saying that it is reconfigurable and
>>>>> part of
>>>>> the AMBA family of interconnect schemes.
>>>>>
>>>>> As far as the bcm2835_i2s platform driver goes, it has implemented an
>>>>> AMBA
>>>>> protocol, where audio words are counted from the LR clock onset - for
>>>>> some
>>>>> reason people are insisting this is an I2S bus. Really our
>>>>> implementation is
>>>>> not I2S at all, because word onsets are programmable and flexible in
>>>>> the
>>>>> bcm2835_i2s.c driver.
>>>> AMBA/APB is the interface which connects the peripheral to the system
>>>> memory
>>>> bus. It is the interface over which the CPU does configuration register
>>>> writes. This has nothing and absolutely nothing to do with the I2S
>>>> interface
>>>> that is also implemented by the peripheral that is used to stream audio
>>>> to
>>>> and from external components.
>>>>
>>> Their (BCM reference) document [1] specifically states "It supports many
>>> classic PCM formats including I2S".
>>>
>>> Do agree with Mark's statement "the specifications of the DSP modes are
>>> such that only one edge in the LRCLK matters" ?
>>>
>>> If we look at the bcm2835 platform driver setup, it is concerned with bit
>>> clock counting to specify the audio data for both of the AMBA/APB channels
>> >from serial bitstream into memory. It has two channels into memory,
>>> however "it supports many classic PCM formats" ... my vote for one classic
>>> format is DSP mode !
>>>
>>> Do you see a problem with that ?
>>>
>>> thanks
>>> Matt
>>> [1] https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
>>> _______________________________________________
>>>
>> Re-reading this document, the bcm2835 PCM IP block SHOULD support real DSP
>> mode, with one BCLK pulsed LRCLK, zero BCLK delay etc...
>> It just need to be properly setup.
> I've re-read the document, too, last week and noticed the framesync
> registers - sorry, I had completely forgotten about these. I guess it
> should be possible to configure the bcm2835 to DSP mode but it'd still be
> limited to 2 channel setups - the hardware only has 2 channel position
> registers for each direction.
>
>> According to the same document, you could program the bmc up to 16 32bits
>> channels when in master mode, so I suspect that you could go up to this
>> limit in slave mode.
>> But as it is designed, it could only use up to two of any channels among the
>> 16.
> I'm not quite sure if I can follow you on this - how would you
> configure 16 channels when there are only 2 channel position registers?
>
> With bclk ratio eg set to 16*32=512 BCM2835 will only transmit 2*32
> bits of data (at configurable bit positions), the remaining 448
> bits will be zero.
>
The document seems to stipulate that the PCM audio device is an AMBA 
device with 2 APB data channels. The first sync edge marks the beginning 
of the two data words. Their frame lengths can be up to 1024+32 bits in 
length !

I think the point is that they intended their PCM audio interface to be 
configurable, they say in their document "It supports many classic PCM 
formats".

The important point here is that in ALSA we can only have I2S or DSP 
modes - right ?
Unless we want to create a new ALSA mode (which clearly worries people) 
then we need to support the versatility of the bcm2835 PCM hardware 
using either DSP or I2S modes. Now, we have already implemented the I2S 
mode, so logically the only available mode left is the DSP mode. Using 
this mode, we can implement more features of this device.

People seem to want to reserve DSP and I2S modes for strictly I2S and 
DSP protocols. At the same time people don't want to allow a looser 
"APB" mode into ALSA. For that reason, we have a lack of functionality 
for perfectly versatile hardware - the bcm2835 hardware.

Matt

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Charles Keepax]

On Wed, Mar 22, 2017 at 10:29:33AM +1100, Matt Flax wrote:
> On 22/03/17 09:11, Matthias Reichl wrote:
> >On Tue, Mar 21, 2017 at 10:21:04PM +0100, Emmanuel Fusté wrote:
> >>Le 16/03/2017 à 23:14, Matt Flax a écrit :
> >>>On 17/03/17 08:27, Lars-Peter Clausen wrote:
> >>>>On 03/16/2017 09:51 PM, Matt Flax wrote:
> >>>>>On 16/03/17 06:01, Mark Brown wrote:
> >>>>>>On Tue, Feb 28, 2017 at 09:59:29AM +0000, Charles Keepax wrote:
> >>>>>>>On Mon, Feb 27, 2017 at 12:51:08PM +0100, Matthias Reichl wrote:
> >>Re-reading this document, the bcm2835 PCM IP block SHOULD support real DSP
> >>mode, with one BCLK pulsed LRCLK, zero BCLK delay etc...
> >>It just need to be properly setup.
> >I've re-read the document, too, last week and noticed the framesync
> >registers - sorry, I had completely forgotten about these. I guess it
> >should be possible to configure the bcm2835 to DSP mode but it'd still be
> >limited to 2 channel setups - the hardware only has 2 channel position
> >registers for each direction.
> >
> >>According to the same document, you could program the bmc up to 16 32bits
> >>channels when in master mode, so I suspect that you could go up to this
> >>limit in slave mode.
> >>But as it is designed, it could only use up to two of any channels among the
> >>16.
> >I'm not quite sure if I can follow you on this - how would you
> >configure 16 channels when there are only 2 channel position registers?
> >
> >With bclk ratio eg set to 16*32=512 BCM2835 will only transmit 2*32
> >bits of data (at configurable bit positions), the remaining 448
> >bits will be zero.
> >
> The document seems to stipulate that the PCM audio device is an AMBA device
> with 2 APB data channels. The first sync edge marks the beginning of the two
> data words. Their frame lengths can be up to 1024+32 bits in length !
> 
> I think the point is that they intended their PCM audio interface to be
> configurable, they say in their document "It supports many classic PCM
> formats".
> 
> The important point here is that in ALSA we can only have I2S or DSP modes -
> right ?
> Unless we want to create a new ALSA mode (which clearly worries people) then
> we need to support the versatility of the bcm2835 PCM hardware using either
> DSP or I2S modes. Now, we have already implemented the I2S mode, so
> logically the only available mode left is the DSP mode. Using this mode, we
> can implement more features of this device.
> 
> People seem to want to reserve DSP and I2S modes for strictly I2S and DSP
> protocols. At the same time people don't want to allow a looser "APB" mode
> into ALSA. For that reason, we have a lack of functionality for perfectly
> versatile hardware - the bcm2835 hardware.
> 

Apologies but I am still a little unclear as to what actually happens
on the bus here.

Are we saying that what gets transmitted on the bus is neither valid
I2S or DSP mode data? But as you have your custom hardware block in
the middle it interprets this data correctly and converts it to a
regular bus format on the other side that goes to the CODEC?

Thanks,
Charles

[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Charles Keepax]

On Wed, Mar 22, 2017 at 10:29:33AM +1100, Matt Flax wrote:
> On 22/03/17 09:11, Matthias Reichl wrote:
> >On Tue, Mar 21, 2017 at 10:21:04PM +0100, Emmanuel Fust? wrote:
> >>Le 16/03/2017 ? 23:14, Matt Flax a ?crit :
> >>>On 17/03/17 08:27, Lars-Peter Clausen wrote:
> >>>>On 03/16/2017 09:51 PM, Matt Flax wrote:
> >>>>>On 16/03/17 06:01, Mark Brown wrote:
> >>>>>>On Tue, Feb 28, 2017 at 09:59:29AM +0000, Charles Keepax wrote:
> >>>>>>>On Mon, Feb 27, 2017 at 12:51:08PM +0100, Matthias Reichl wrote:
> >>Re-reading this document, the bcm2835 PCM IP block SHOULD support real DSP
> >>mode, with one BCLK pulsed LRCLK, zero BCLK delay etc...
> >>It just need to be properly setup.
> >I've re-read the document, too, last week and noticed the framesync
> >registers - sorry, I had completely forgotten about these. I guess it
> >should be possible to configure the bcm2835 to DSP mode but it'd still be
> >limited to 2 channel setups - the hardware only has 2 channel position
> >registers for each direction.
> >
> >>According to the same document, you could program the bmc up to 16 32bits
> >>channels when in master mode, so I suspect that you could go up to this
> >>limit in slave mode.
> >>But as it is designed, it could only use up to two of any channels among the
> >>16.
> >I'm not quite sure if I can follow you on this - how would you
> >configure 16 channels when there are only 2 channel position registers?
> >
> >With bclk ratio eg set to 16*32=512 BCM2835 will only transmit 2*32
> >bits of data (at configurable bit positions), the remaining 448
> >bits will be zero.
> >
> The document seems to stipulate that the PCM audio device is an AMBA device
> with 2 APB data channels. The first sync edge marks the beginning of the two
> data words. Their frame lengths can be up to 1024+32 bits in length !
> 
> I think the point is that they intended their PCM audio interface to be
> configurable, they say in their document "It supports many classic PCM
> formats".
> 
> The important point here is that in ALSA we can only have I2S or DSP modes -
> right ?
> Unless we want to create a new ALSA mode (which clearly worries people) then
> we need to support the versatility of the bcm2835 PCM hardware using either
> DSP or I2S modes. Now, we have already implemented the I2S mode, so
> logically the only available mode left is the DSP mode. Using this mode, we
> can implement more features of this device.
> 
> People seem to want to reserve DSP and I2S modes for strictly I2S and DSP
> protocols. At the same time people don't want to allow a looser "APB" mode
> into ALSA. For that reason, we have a lack of functionality for perfectly
> versatile hardware - the bcm2835 hardware.
> 

Apologies but I am still a little unclear as to what actually happens
on the bus here.

Are we saying that what gets transmitted on the bus is neither valid
I2S or DSP mode data? But as you have your custom hardware block in
the middle it interprets this data correctly and converts it to a
regular bus format on the other side that goes to the CODEC?

Thanks,
Charles

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matt Flax]

On 22/03/17 20:43, Charles Keepax wrote:
> On Wed, Mar 22, 2017 at 10:29:33AM +1100, Matt Flax wrote:
>> On 22/03/17 09:11, Matthias Reichl wrote:
>>> On Tue, Mar 21, 2017 at 10:21:04PM +0100, Emmanuel Fusté wrote:
>>>> Le 16/03/2017 à 23:14, Matt Flax a écrit :
>>>>> On 17/03/17 08:27, Lars-Peter Clausen wrote:
>>>>>> On 03/16/2017 09:51 PM, Matt Flax wrote:
>>>>>>> On 16/03/17 06:01, Mark Brown wrote:
>>>>>>>> On Tue, Feb 28, 2017 at 09:59:29AM +0000, Charles Keepax wrote:
>>>>>>>>> On Mon, Feb 27, 2017 at 12:51:08PM +0100, Matthias Reichl wrote:
>>>> Re-reading this document, the bcm2835 PCM IP block SHOULD support real DSP
>>>> mode, with one BCLK pulsed LRCLK, zero BCLK delay etc...
>>>> It just need to be properly setup.
>>> I've re-read the document, too, last week and noticed the framesync
>>> registers - sorry, I had completely forgotten about these. I guess it
>>> should be possible to configure the bcm2835 to DSP mode but it'd still be
>>> limited to 2 channel setups - the hardware only has 2 channel position
>>> registers for each direction.
>>>
>>>> According to the same document, you could program the bmc up to 16 32bits
>>>> channels when in master mode, so I suspect that you could go up to this
>>>> limit in slave mode.
>>>> But as it is designed, it could only use up to two of any channels among the
>>>> 16.
>>> I'm not quite sure if I can follow you on this - how would you
>>> configure 16 channels when there are only 2 channel position registers?
>>>
>>> With bclk ratio eg set to 16*32=512 BCM2835 will only transmit 2*32
>>> bits of data (at configurable bit positions), the remaining 448
>>> bits will be zero.
>>>
>> The document seems to stipulate that the PCM audio device is an AMBA device
>> with 2 APB data channels. The first sync edge marks the beginning of the two
>> data words. Their frame lengths can be up to 1024+32 bits in length !
>>
>> I think the point is that they intended their PCM audio interface to be
>> configurable, they say in their document "It supports many classic PCM
>> formats".
>>
>> The important point here is that in ALSA we can only have I2S or DSP modes -
>> right ?
>> Unless we want to create a new ALSA mode (which clearly worries people) then
>> we need to support the versatility of the bcm2835 PCM hardware using either
>> DSP or I2S modes. Now, we have already implemented the I2S mode, so
>> logically the only available mode left is the DSP mode. Using this mode, we
>> can implement more features of this device.
>>
>> People seem to want to reserve DSP and I2S modes for strictly I2S and DSP
>> protocols. At the same time people don't want to allow a looser "APB" mode
>> into ALSA. For that reason, we have a lack of functionality for perfectly
>> versatile hardware - the bcm2835 hardware.
>>
> Apologies but I am still a little unclear as to what actually happens
> on the bus here.
>
> Are we saying that what gets transmitted on the bus is neither valid
> I2S or DSP mode data? But as you have your custom hardware block in
> the middle it interprets this data correctly and converts it to a
> regular bus format on the other side that goes to the CODEC?
>
>
Yes, essentially there is translation between the two data word edge 
triggered ABP (the bcm2835's PCM block) and a Cirrus Logic TDM codec.

Matt

[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matt Flax]

On 22/03/17 20:43, Charles Keepax wrote:
> On Wed, Mar 22, 2017 at 10:29:33AM +1100, Matt Flax wrote:
>> On 22/03/17 09:11, Matthias Reichl wrote:
>>> On Tue, Mar 21, 2017 at 10:21:04PM +0100, Emmanuel Fust? wrote:
>>>> Le 16/03/2017 ? 23:14, Matt Flax a ?crit :
>>>>> On 17/03/17 08:27, Lars-Peter Clausen wrote:
>>>>>> On 03/16/2017 09:51 PM, Matt Flax wrote:
>>>>>>> On 16/03/17 06:01, Mark Brown wrote:
>>>>>>>> On Tue, Feb 28, 2017 at 09:59:29AM +0000, Charles Keepax wrote:
>>>>>>>>> On Mon, Feb 27, 2017 at 12:51:08PM +0100, Matthias Reichl wrote:
>>>> Re-reading this document, the bcm2835 PCM IP block SHOULD support real DSP
>>>> mode, with one BCLK pulsed LRCLK, zero BCLK delay etc...
>>>> It just need to be properly setup.
>>> I've re-read the document, too, last week and noticed the framesync
>>> registers - sorry, I had completely forgotten about these. I guess it
>>> should be possible to configure the bcm2835 to DSP mode but it'd still be
>>> limited to 2 channel setups - the hardware only has 2 channel position
>>> registers for each direction.
>>>
>>>> According to the same document, you could program the bmc up to 16 32bits
>>>> channels when in master mode, so I suspect that you could go up to this
>>>> limit in slave mode.
>>>> But as it is designed, it could only use up to two of any channels among the
>>>> 16.
>>> I'm not quite sure if I can follow you on this - how would you
>>> configure 16 channels when there are only 2 channel position registers?
>>>
>>> With bclk ratio eg set to 16*32=512 BCM2835 will only transmit 2*32
>>> bits of data (at configurable bit positions), the remaining 448
>>> bits will be zero.
>>>
>> The document seems to stipulate that the PCM audio device is an AMBA device
>> with 2 APB data channels. The first sync edge marks the beginning of the two
>> data words. Their frame lengths can be up to 1024+32 bits in length !
>>
>> I think the point is that they intended their PCM audio interface to be
>> configurable, they say in their document "It supports many classic PCM
>> formats".
>>
>> The important point here is that in ALSA we can only have I2S or DSP modes -
>> right ?
>> Unless we want to create a new ALSA mode (which clearly worries people) then
>> we need to support the versatility of the bcm2835 PCM hardware using either
>> DSP or I2S modes. Now, we have already implemented the I2S mode, so
>> logically the only available mode left is the DSP mode. Using this mode, we
>> can implement more features of this device.
>>
>> People seem to want to reserve DSP and I2S modes for strictly I2S and DSP
>> protocols. At the same time people don't want to allow a looser "APB" mode
>> into ALSA. For that reason, we have a lack of functionality for perfectly
>> versatile hardware - the bcm2835 hardware.
>>
> Apologies but I am still a little unclear as to what actually happens
> on the bus here.
>
> Are we saying that what gets transmitted on the bus is neither valid
> I2S or DSP mode data? But as you have your custom hardware block in
> the middle it interprets this data correctly and converts it to a
> regular bus format on the other side that goes to the CODEC?
>
>
Yes, essentially there is translation between the two data word edge 
triggered ABP (the bcm2835's PCM block) and a Cirrus Logic TDM codec.

Matt

Re: [alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Charles Keepax]

On Wed, Mar 22, 2017 at 11:04:34PM +1100, Matt Flax wrote:
> >Are we saying that what gets transmitted on the bus is neither valid
> >I2S or DSP mode data? But as you have your custom hardware block in
> >the middle it interprets this data correctly and converts it to a
> >regular bus format on the other side that goes to the CODEC?
> >
> >
> Yes, essentially there is translation between the two data word edge
> triggered ABP (the bcm2835's PCM block) and a Cirrus Logic TDM codec.

Hmm... I guess that is the root difficulty here. As we probably
don't want to call it DSP mode in the driver if connecting it
to something that was expecting data in that format wouldn't
work. Especially if the device actually could support DSP mode as
well, since we would then be blocking someone for implementing
legimate DSP mode in the future.

I guess really the correct thing to do would be to add some
define for the new format, but I can see that might be a tricky
road. Would perhaps some sort of BESPOKE define or something be
possible to indicate odd formats that don't fall into regular
classifications?

Thanks,
Charles

[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Charles Keepax]

On Wed, Mar 22, 2017 at 11:04:34PM +1100, Matt Flax wrote:
> >Are we saying that what gets transmitted on the bus is neither valid
> >I2S or DSP mode data? But as you have your custom hardware block in
> >the middle it interprets this data correctly and converts it to a
> >regular bus format on the other side that goes to the CODEC?
> >
> >
> Yes, essentially there is translation between the two data word edge
> triggered ABP (the bcm2835's PCM block) and a Cirrus Logic TDM codec.

Hmm... I guess that is the root difficulty here. As we probably
don't want to call it DSP mode in the driver if connecting it
to something that was expecting data in that format wouldn't
work. Especially if the device actually could support DSP mode as
well, since we would then be blocking someone for implementing
legimate DSP mode in the future.

I guess really the correct thing to do would be to add some
define for the new format, but I can see that might be a tricky
road. Would perhaps some sort of BESPOKE define or something be
possible to indicate odd formats that don't fall into regular
classifications?

Thanks,
Charles

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Stephen Warren]

On 03/22/2017 06:04 AM, Matt Flax wrote:
>
>
> On 22/03/17 20:43, Charles Keepax wrote:
>> On Wed, Mar 22, 2017 at 10:29:33AM +1100, Matt Flax wrote:
>>> On 22/03/17 09:11, Matthias Reichl wrote:
>>>> On Tue, Mar 21, 2017 at 10:21:04PM +0100, Emmanuel Fusté wrote:
>>>>> Le 16/03/2017 à 23:14, Matt Flax a écrit :
>>>>>> On 17/03/17 08:27, Lars-Peter Clausen wrote:
>>>>>>> On 03/16/2017 09:51 PM, Matt Flax wrote:
>>>>>>>> On 16/03/17 06:01, Mark Brown wrote:
>>>>>>>>> On Tue, Feb 28, 2017 at 09:59:29AM +0000, Charles Keepax wrote:
>>>>>>>>>> On Mon, Feb 27, 2017 at 12:51:08PM +0100, Matthias Reichl wrote:
>>>>> Re-reading this document, the bcm2835 PCM IP block SHOULD support
>>>>> real DSP
>>>>> mode, with one BCLK pulsed LRCLK, zero BCLK delay etc...
>>>>> It just need to be properly setup.
>>>> I've re-read the document, too, last week and noticed the framesync
>>>> registers - sorry, I had completely forgotten about these. I guess it
>>>> should be possible to configure the bcm2835 to DSP mode but it'd
>>>> still be
>>>> limited to 2 channel setups - the hardware only has 2 channel position
>>>> registers for each direction.
>>>>
>>>>> According to the same document, you could program the bmc up to 16
>>>>> 32bits
>>>>> channels when in master mode, so I suspect that you could go up to
>>>>> this
>>>>> limit in slave mode.
>>>>> But as it is designed, it could only use up to two of any channels
>>>>> among the
>>>>> 16.
>>>> I'm not quite sure if I can follow you on this - how would you
>>>> configure 16 channels when there are only 2 channel position registers?
>>>>
>>>> With bclk ratio eg set to 16*32=512 BCM2835 will only transmit 2*32
>>>> bits of data (at configurable bit positions), the remaining 448
>>>> bits will be zero.
>>>>
>>> The document seems to stipulate that the PCM audio device is an AMBA
>>> device
>>> with 2 APB data channels. The first sync edge marks the beginning of
>>> the two
>>> data words. Their frame lengths can be up to 1024+32 bits in length !
>>>
>>> I think the point is that they intended their PCM audio interface to be
>>> configurable, they say in their document "It supports many classic PCM
>>> formats".
>>>
>>> The important point here is that in ALSA we can only have I2S or DSP
>>> modes -
>>> right ?
>>> Unless we want to create a new ALSA mode (which clearly worries
>>> people) then
>>> we need to support the versatility of the bcm2835 PCM hardware using
>>> either
>>> DSP or I2S modes. Now, we have already implemented the I2S mode, so
>>> logically the only available mode left is the DSP mode. Using this
>>> mode, we
>>> can implement more features of this device.
>>>
>>> People seem to want to reserve DSP and I2S modes for strictly I2S and
>>> DSP
>>> protocols. At the same time people don't want to allow a looser "APB"
>>> mode
>>> into ALSA. For that reason, we have a lack of functionality for
>>> perfectly
>>> versatile hardware - the bcm2835 hardware.
>>>
>> Apologies but I am still a little unclear as to what actually happens
>> on the bus here.
>>
>> Are we saying that what gets transmitted on the bus is neither valid
>> I2S or DSP mode data? But as you have your custom hardware block in
>> the middle it interprets this data correctly and converts it to a
>> regular bus format on the other side that goes to the CODEC?
>
> Yes, essentially there is translation between the two data word edge
> triggered ABP (the bcm2835's PCM block) and a Cirrus Logic TDM codec.

Are you really sure about this? I believe the BCM2835 I2S controller is 
a standard I2S controller.

Note that, as was pointed out earlier in this thread, "APB" has nothing 
to do with the audio side of the I2S controller's HW. Rather, the I2S 
controller connects to the SoC's APB bus so that the CPU can program the 
I2S controller's registers, and so that the CPU or DMA engine can 
read/write the audio data stream. The audio side of the I2S controller 
generates/consumes the standard I2S signals of clock, frame sync, data 
in, and data out. As such, I believe standard I2S and DSP modes are 
perfectly possible.

Now the BCM2835 I2S controller does appear to have a few features beyond 
plain I2S/DSP modes, that not all I2S controllers might have, such as:

- Frame length, FS length, channel position, and channel width are 
specified at bit resolution rather than byte/sample/...

- PDM mode (for digital mics).

- Sign extension of RX data.

So, the controller can generate/receive some formats beyond plain 
I2S/DSP, but to be honest I doubt that this level of detail needs to be 
exposed to the ALSA/ASoC core or user-space, nor is it required to 
interface to any typical HW, so it can be hidden in the driver's 
register programming implementation.

[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Stephen Warren]

On 03/22/2017 06:04 AM, Matt Flax wrote:
>
>
> On 22/03/17 20:43, Charles Keepax wrote:
>> On Wed, Mar 22, 2017 at 10:29:33AM +1100, Matt Flax wrote:
>>> On 22/03/17 09:11, Matthias Reichl wrote:
>>>> On Tue, Mar 21, 2017 at 10:21:04PM +0100, Emmanuel Fust? wrote:
>>>>> Le 16/03/2017 ? 23:14, Matt Flax a ?crit :
>>>>>> On 17/03/17 08:27, Lars-Peter Clausen wrote:
>>>>>>> On 03/16/2017 09:51 PM, Matt Flax wrote:
>>>>>>>> On 16/03/17 06:01, Mark Brown wrote:
>>>>>>>>> On Tue, Feb 28, 2017 at 09:59:29AM +0000, Charles Keepax wrote:
>>>>>>>>>> On Mon, Feb 27, 2017 at 12:51:08PM +0100, Matthias Reichl wrote:
>>>>> Re-reading this document, the bcm2835 PCM IP block SHOULD support
>>>>> real DSP
>>>>> mode, with one BCLK pulsed LRCLK, zero BCLK delay etc...
>>>>> It just need to be properly setup.
>>>> I've re-read the document, too, last week and noticed the framesync
>>>> registers - sorry, I had completely forgotten about these. I guess it
>>>> should be possible to configure the bcm2835 to DSP mode but it'd
>>>> still be
>>>> limited to 2 channel setups - the hardware only has 2 channel position
>>>> registers for each direction.
>>>>
>>>>> According to the same document, you could program the bmc up to 16
>>>>> 32bits
>>>>> channels when in master mode, so I suspect that you could go up to
>>>>> this
>>>>> limit in slave mode.
>>>>> But as it is designed, it could only use up to two of any channels
>>>>> among the
>>>>> 16.
>>>> I'm not quite sure if I can follow you on this - how would you
>>>> configure 16 channels when there are only 2 channel position registers?
>>>>
>>>> With bclk ratio eg set to 16*32=512 BCM2835 will only transmit 2*32
>>>> bits of data (at configurable bit positions), the remaining 448
>>>> bits will be zero.
>>>>
>>> The document seems to stipulate that the PCM audio device is an AMBA
>>> device
>>> with 2 APB data channels. The first sync edge marks the beginning of
>>> the two
>>> data words. Their frame lengths can be up to 1024+32 bits in length !
>>>
>>> I think the point is that they intended their PCM audio interface to be
>>> configurable, they say in their document "It supports many classic PCM
>>> formats".
>>>
>>> The important point here is that in ALSA we can only have I2S or DSP
>>> modes -
>>> right ?
>>> Unless we want to create a new ALSA mode (which clearly worries
>>> people) then
>>> we need to support the versatility of the bcm2835 PCM hardware using
>>> either
>>> DSP or I2S modes. Now, we have already implemented the I2S mode, so
>>> logically the only available mode left is the DSP mode. Using this
>>> mode, we
>>> can implement more features of this device.
>>>
>>> People seem to want to reserve DSP and I2S modes for strictly I2S and
>>> DSP
>>> protocols. At the same time people don't want to allow a looser "APB"
>>> mode
>>> into ALSA. For that reason, we have a lack of functionality for
>>> perfectly
>>> versatile hardware - the bcm2835 hardware.
>>>
>> Apologies but I am still a little unclear as to what actually happens
>> on the bus here.
>>
>> Are we saying that what gets transmitted on the bus is neither valid
>> I2S or DSP mode data? But as you have your custom hardware block in
>> the middle it interprets this data correctly and converts it to a
>> regular bus format on the other side that goes to the CODEC?
>
> Yes, essentially there is translation between the two data word edge
> triggered ABP (the bcm2835's PCM block) and a Cirrus Logic TDM codec.

Are you really sure about this? I believe the BCM2835 I2S controller is 
a standard I2S controller.

Note that, as was pointed out earlier in this thread, "APB" has nothing 
to do with the audio side of the I2S controller's HW. Rather, the I2S 
controller connects to the SoC's APB bus so that the CPU can program the 
I2S controller's registers, and so that the CPU or DMA engine can 
read/write the audio data stream. The audio side of the I2S controller 
generates/consumes the standard I2S signals of clock, frame sync, data 
in, and data out. As such, I believe standard I2S and DSP modes are 
perfectly possible.

Now the BCM2835 I2S controller does appear to have a few features beyond 
plain I2S/DSP modes, that not all I2S controllers might have, such as:

- Frame length, FS length, channel position, and channel width are 
specified at bit resolution rather than byte/sample/...

- PDM mode (for digital mics).

- Sign extension of RX data.

So, the controller can generate/receive some formats beyond plain 
I2S/DSP, but to be honest I doubt that this level of detail needs to be 
exposed to the ALSA/ASoC core or user-space, nor is it required to 
interface to any typical HW, so it can be hidden in the driver's 
register programming implementation.

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 905 bytes --]

On Wed, Mar 22, 2017 at 09:38:28AM -0600, Stephen Warren wrote:

> Now the BCM2835 I2S controller does appear to have a few features beyond
> plain I2S/DSP modes, that not all I2S controllers might have, such as:

> - Frame length, FS length, channel position, and channel width are specified
> at bit resolution rather than byte/sample/...

> - PDM mode (for digital mics).

> - Sign extension of RX data.

> So, the controller can generate/receive some formats beyond plain I2S/DSP,
> but to be honest I doubt that this level of detail needs to be exposed to
> the ALSA/ASoC core or user-space, nor is it required to interface to any
> typical HW, so it can be hidden in the driver's register programming
> implementation.

At the minute the driver doesn't even support these features, it just
supports plain stereo I2S mode and it *may* be that all that's needed
here is the addition of the DSP modes.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Mark Brown]

On Wed, Mar 22, 2017 at 09:38:28AM -0600, Stephen Warren wrote:

> Now the BCM2835 I2S controller does appear to have a few features beyond
> plain I2S/DSP modes, that not all I2S controllers might have, such as:

> - Frame length, FS length, channel position, and channel width are specified
> at bit resolution rather than byte/sample/...

> - PDM mode (for digital mics).

> - Sign extension of RX data.

> So, the controller can generate/receive some formats beyond plain I2S/DSP,
> but to be honest I doubt that this level of detail needs to be exposed to
> the ALSA/ASoC core or user-space, nor is it required to interface to any
> typical HW, so it can be hidden in the driver's register programming
> implementation.

At the minute the driver doesn't even support these features, it just
supports plain stereo I2S mode and it *may* be that all that's needed
here is the addition of the DSP modes.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170324/1c926b42/attachment.sig>

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 729 bytes --]

On Wed, Mar 22, 2017 at 11:04:34PM +1100, Matt Flax wrote:
> On 22/03/17 20:43, Charles Keepax wrote:

> > Are we saying that what gets transmitted on the bus is neither valid
> > I2S or DSP mode data? But as you have your custom hardware block in
> > the middle it interprets this data correctly and converts it to a
> > regular bus format on the other side that goes to the CODEC?

> Yes, essentially there is translation between the two data word edge
> triggered ABP (the bcm2835's PCM block) and a Cirrus Logic TDM codec.

Could you please be concrete about what the two formats you're talking
about here are and how these differences are observable on the wire?  I
don't know what "two data word edge triggered ABP" means.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Mark Brown]

On Wed, Mar 22, 2017 at 11:04:34PM +1100, Matt Flax wrote:
> On 22/03/17 20:43, Charles Keepax wrote:

> > Are we saying that what gets transmitted on the bus is neither valid
> > I2S or DSP mode data? But as you have your custom hardware block in
> > the middle it interprets this data correctly and converts it to a
> > regular bus format on the other side that goes to the CODEC?

> Yes, essentially there is translation between the two data word edge
> triggered ABP (the bcm2835's PCM block) and a Cirrus Logic TDM codec.

Could you please be concrete about what the two formats you're talking
about here are and how these differences are observable on the wire?  I
don't know what "two data word edge triggered ABP" means.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170324/e11e4711/attachment.sig>

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matt Flax]

On 25/03/17 06:09, Mark Brown wrote:
> On Wed, Mar 22, 2017 at 11:04:34PM +1100, Matt Flax wrote:
>> On 22/03/17 20:43, Charles Keepax wrote:
>>> Are we saying that what gets transmitted on the bus is neither valid
>>> I2S or DSP mode data? But as you have your custom hardware block in
>>> the middle it interprets this data correctly and converts it to a
>>> regular bus format on the other side that goes to the CODEC?
>> Yes, essentially there is translation between the two data word edge
>> triggered ABP (the bcm2835's PCM block) and a Cirrus Logic TDM codec.
> Could you please be concrete about what the two formats you're talking
> about here are and how these differences are observable on the wire?  I
> don't know what "two data word edge triggered ABP" means.
On the codec side it is a regular TDM stream.
On the SoC side, two channels  are arbitrarily offset from a PCM frame 
sync clock (PCM_FS) leading edge. I have chosen to have 64 bits per 
frame with 1 bit offset for the first word (from the leading edge) and 
33 bits offset (from the leading edge) for the second word. This 
resembles I2S, but it doesn't have to for the bcm2835.

In more detail ...
The bcm2835's flexible PCM hardware (serialiser+APB) is set up to handle 
two words at a time in/out from a 64 word FIFO buffers. The serialiser 
loads and unloads two registers according to offsets from the PCM_FS 
clock's leading edge. The APB interface is responsible for (un)loading 
the 64 word FIFO buffer to/from memory - with DMA I guess.

thanks
Matt

[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matt Flax]

On 25/03/17 06:09, Mark Brown wrote:
> On Wed, Mar 22, 2017 at 11:04:34PM +1100, Matt Flax wrote:
>> On 22/03/17 20:43, Charles Keepax wrote:
>>> Are we saying that what gets transmitted on the bus is neither valid
>>> I2S or DSP mode data? But as you have your custom hardware block in
>>> the middle it interprets this data correctly and converts it to a
>>> regular bus format on the other side that goes to the CODEC?
>> Yes, essentially there is translation between the two data word edge
>> triggered ABP (the bcm2835's PCM block) and a Cirrus Logic TDM codec.
> Could you please be concrete about what the two formats you're talking
> about here are and how these differences are observable on the wire?  I
> don't know what "two data word edge triggered ABP" means.
On the codec side it is a regular TDM stream.
On the SoC side, two channels  are arbitrarily offset from a PCM frame 
sync clock (PCM_FS) leading edge. I have chosen to have 64 bits per 
frame with 1 bit offset for the first word (from the leading edge) and 
33 bits offset (from the leading edge) for the second word. This 
resembles I2S, but it doesn't have to for the bcm2835.

In more detail ...
The bcm2835's flexible PCM hardware (serialiser+APB) is set up to handle 
two words at a time in/out from a 64 word FIFO buffers. The serialiser 
loads and unloads two registers according to offsets from the PCM_FS 
clock's leading edge. The APB interface is responsible for (un)loading 
the 64 word FIFO buffer to/from memory - with DMA I guess.

thanks
Matt

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 868 bytes --]

On Sat, Mar 25, 2017 at 04:45:46PM +1100, Matt Flax wrote:
> On 25/03/17 06:09, Mark Brown wrote:

> > Could you please be concrete about what the two formats you're talking
> > about here are and how these differences are observable on the wire?  I
> > don't know what "two data word edge triggered ABP" means.
> On the codec side it is a regular TDM stream.
> On the SoC side, two channels  are arbitrarily offset from a PCM frame sync
> clock (PCM_FS) leading edge. I have chosen to have 64 bits per frame with 1
> bit offset for the first word (from the leading edge) and 33 bits offset
> (from the leading edge) for the second word. This resembles I2S, but it
> doesn't have to for the bcm2835.

What's internal to the SoC is not relevant here, what matters is what's
externally visible.  The formats on the DAI are how the SoC interfaces
with the outside world.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Mark Brown]

On Sat, Mar 25, 2017 at 04:45:46PM +1100, Matt Flax wrote:
> On 25/03/17 06:09, Mark Brown wrote:

> > Could you please be concrete about what the two formats you're talking
> > about here are and how these differences are observable on the wire?  I
> > don't know what "two data word edge triggered ABP" means.
> On the codec side it is a regular TDM stream.
> On the SoC side, two channels  are arbitrarily offset from a PCM frame sync
> clock (PCM_FS) leading edge. I have chosen to have 64 bits per frame with 1
> bit offset for the first word (from the leading edge) and 33 bits offset
> (from the leading edge) for the second word. This resembles I2S, but it
> doesn't have to for the bcm2835.

What's internal to the SoC is not relevant here, what matters is what's
externally visible.  The formats on the DAI are how the SoC interfaces
with the outside world.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170327/b0422944/attachment.sig>

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matt Flax]

On 27/03/17 21:01, Mark Brown wrote:
> On Sat, Mar 25, 2017 at 04:45:46PM +1100, Matt Flax wrote:
>> On 25/03/17 06:09, Mark Brown wrote:
>>> Could you please be concrete about what the two formats you're talking
>>> about here are and how these differences are observable on the wire?  I
>>> don't know what "two data word edge triggered ABP" means.
>> On the codec side it is a regular TDM stream.
>> On the SoC side, two channels  are arbitrarily offset from a PCM frame sync
>> clock (PCM_FS) leading edge. I have chosen to have 64 bits per frame with 1
>> bit offset for the first word (from the leading edge) and 33 bits offset
>> (from the leading edge) for the second word. This resembles I2S, but it
>> doesn't have to for the bcm2835.
> What's internal to the SoC is not relevant here, what matters is what's
> externally visible.  The formats on the DAI are how the SoC interfaces
> with the outside world.
In this case, there is the TDM (DSP mode) protocol on the Codec. The SoC 
however is communicating in channel pairs {{0, 1}, {2, 3}, {4, 5}, {6, 
7}}. Each channel separated by the PCM_FS clk leading edge.

As far as the codec is concerned it is DSP mode. As far as the SoC is 
concerned, it is not I2S, nor is it strictly DSP mode because there is 
more then one PCM_FS per frame !

If we look at this from the perspective of the Codec, then it is DSP 
mode. I am just not sure what to call the SoC's protocol, other then 
multi-paired PCM.

Matt

[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matt Flax]

On 27/03/17 21:01, Mark Brown wrote:
> On Sat, Mar 25, 2017 at 04:45:46PM +1100, Matt Flax wrote:
>> On 25/03/17 06:09, Mark Brown wrote:
>>> Could you please be concrete about what the two formats you're talking
>>> about here are and how these differences are observable on the wire?  I
>>> don't know what "two data word edge triggered ABP" means.
>> On the codec side it is a regular TDM stream.
>> On the SoC side, two channels  are arbitrarily offset from a PCM frame sync
>> clock (PCM_FS) leading edge. I have chosen to have 64 bits per frame with 1
>> bit offset for the first word (from the leading edge) and 33 bits offset
>> (from the leading edge) for the second word. This resembles I2S, but it
>> doesn't have to for the bcm2835.
> What's internal to the SoC is not relevant here, what matters is what's
> externally visible.  The formats on the DAI are how the SoC interfaces
> with the outside world.
In this case, there is the TDM (DSP mode) protocol on the Codec. The SoC 
however is communicating in channel pairs {{0, 1}, {2, 3}, {4, 5}, {6, 
7}}. Each channel separated by the PCM_FS clk leading edge.

As far as the codec is concerned it is DSP mode. As far as the SoC is 
concerned, it is not I2S, nor is it strictly DSP mode because there is 
more then one PCM_FS per frame !

If we look at this from the perspective of the Codec, then it is DSP 
mode. I am just not sure what to call the SoC's protocol, other then 
multi-paired PCM.

Matt

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 852 bytes --]

On Mon, Mar 27, 2017 at 09:35:33PM +1100, Matt Flax wrote:

> In this case, there is the TDM (DSP mode) protocol on the Codec. The SoC
> however is communicating in channel pairs {{0, 1}, {2, 3}, {4, 5}, {6, 7}}.
> Each channel separated by the PCM_FS clk leading edge.

> As far as the codec is concerned it is DSP mode. As far as the SoC is
> concerned, it is not I2S, nor is it strictly DSP mode because there is more
> then one PCM_FS per frame !

> If we look at this from the perspective of the Codec, then it is DSP mode. I
> am just not sure what to call the SoC's protocol, other then multi-paired
> PCM.

This isn't DSP mode from anything's point of view, the extra frame syncs
mean it's a whole new format.  Off the top of my head I'd suggest just
running it as stereo DSP mode from a kernel point of view and fixing
things up in userspace.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Mark Brown]

On Mon, Mar 27, 2017 at 09:35:33PM +1100, Matt Flax wrote:

> In this case, there is the TDM (DSP mode) protocol on the Codec. The SoC
> however is communicating in channel pairs {{0, 1}, {2, 3}, {4, 5}, {6, 7}}.
> Each channel separated by the PCM_FS clk leading edge.

> As far as the codec is concerned it is DSP mode. As far as the SoC is
> concerned, it is not I2S, nor is it strictly DSP mode because there is more
> then one PCM_FS per frame !

> If we look at this from the perspective of the Codec, then it is DSP mode. I
> am just not sure what to call the SoC's protocol, other then multi-paired
> PCM.

This isn't DSP mode from anything's point of view, the extra frame syncs
mean it's a whole new format.  Off the top of my head I'd suggest just
running it as stereo DSP mode from a kernel point of view and fixing
things up in userspace.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170327/0d7f419f/attachment.sig>

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Emmanuel Fusté]

Le 21/03/2017 à 23:11, Matthias Reichl a écrit :
> On Tue, Mar 21, 2017 at 10:21:04PM +0100, Emmanuel Fusté wrote:
>> Le 16/03/2017 à 23:14, Matt Flax a écrit :
>>>
>>> On 17/03/17 08:27, Lars-Peter Clausen wrote:
>>>> On 03/16/2017 09:51 PM, Matt Flax wrote:
>>>>> On 16/03/17 06:01, Mark Brown wrote:
>>>>>> On Tue, Feb 28, 2017 at 09:59:29AM +0000, Charles Keepax wrote:
>>>>>>> On Mon, Feb 27, 2017 at 12:51:08PM +0100, Matthias Reichl wrote:
>>>>>>>>> I have a bcm2835 (Pi 2 and 3) SoC here. It is producing
>>>>>>>>> multichannel (8
>>>>>>>>> out,
>>>>>>>>> 6 in) audio. In ALSA we call that DSP mode - right ?!
>>>>>>>> No. DSP modes are protocol/timing specifications as I2S, PDP,
>>>>>>>> S/PDIF, ...
>>>>>>>> You can look these up in datasheets and if a chip implements such a
>>>>>>>> protocol you can be sure that it adheres to that standard - i.e. it
>>>>>>>> will sync the frames to the pulses on LRclk.
>>>>>>> I agree with the thoughts in this thread really if the AP doesn't
>>>>>>> actually support DSP A mode we shouldn't add DSP A mode.
>>>>>> The trouble here is that this isn't 100% clear, the specifications of
>>>>>> the DSP modes are such that only one edge in the LRCLK matters and so
>>>>>> providing you're doing mono or have exact clocking they interoperate
>>>>>> perfectly well.  We already frequently do similar things the other
>>>>>> way,
>>>>>> most of the programmable serial ports can't actually do I2S modes
>>>>>> properly and rely on exact clocking to get things right when operating
>>>>>> as I2S since they only sync on one edge (though they can generally
>>>>>> generate the clocks correctly when operating as master, they just
>>>>>> don't
>>>>>> pay attention to the left/right switch edge).
>>>>>>
>>>>>> That said unless we're doing something with the data layout or similar
>>>>>> configuration there's a fairly strong case for putting the mangling
>>>>>> for
>>>>>> this in the core, something like just falling back to I2S mode if we
>>>>>> set
>>>>>> DSP A and so on.  Which would be a lot nicer if we actually got
>>>>>> round to
>>>>>> putting mode capability information in the drivers.
>>>>> I agree, the data layout is already configurable in the bcm2835_i2s.c
>>>>> platform driver. We can already use the "snd_soc_dai_set_bclk_ratio"
>>>>> function to manage word offsets in our machine drivers.
>>>>>
>>>>> There is nothing which says that the bcm2835 SoC is I2S restricted in
>>>>> any
>>>>> way. In fact, the reference document says quite the opposite.
>>>>>
>>>>> In the reference "BCM2835 ARM Peripherals" pdf, they call the audio
>>>>> system
>>>>> an "APB peripheral". They are saying that it is reconfigurable and
>>>>> part of
>>>>> the AMBA family of interconnect schemes.
>>>>>
>>>>> As far as the bcm2835_i2s platform driver goes, it has implemented an
>>>>> AMBA
>>>>> protocol, where audio words are counted from the LR clock onset - for
>>>>> some
>>>>> reason people are insisting this is an I2S bus. Really our
>>>>> implementation is
>>>>> not I2S at all, because word onsets are programmable and flexible in
>>>>> the
>>>>> bcm2835_i2s.c driver.
>>>> AMBA/APB is the interface which connects the peripheral to the system
>>>> memory
>>>> bus. It is the interface over which the CPU does configuration register
>>>> writes. This has nothing and absolutely nothing to do with the I2S
>>>> interface
>>>> that is also implemented by the peripheral that is used to stream audio
>>>> to
>>>> and from external components.
>>>>
>>> Their (BCM reference) document [1] specifically states "It supports many
>>> classic PCM formats including I2S".
>>>
>>> Do agree with Mark's statement "the specifications of the DSP modes are
>>> such that only one edge in the LRCLK matters" ?
>>>
>>> If we look at the bcm2835 platform driver setup, it is concerned with bit
>>> clock counting to specify the audio data for both of the AMBA/APB channels
>> >from serial bitstream into memory. It has two channels into memory,
>>> however "it supports many classic PCM formats" ... my vote for one classic
>>> format is DSP mode !
>>>
>>> Do you see a problem with that ?
>>>
>>> thanks
>>> Matt
>>> [1] https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
>>> _______________________________________________
>>>
>> Re-reading this document, the bcm2835 PCM IP block SHOULD support real DSP
>> mode, with one BCLK pulsed LRCLK, zero BCLK delay etc...
>> It just need to be properly setup.
> I've re-read the document, too, last week and noticed the framesync
> registers - sorry, I had completely forgotten about these. I guess it
> should be possible to configure the bcm2835 to DSP mode but it'd still be
> limited to 2 channel setups - the hardware only has 2 channel position
> registers for each direction.
>
>> According to the same document, you could program the bmc up to 16 32bits
>> channels when in master mode, so I suspect that you could go up to this
>> limit in slave mode.
>> But as it is designed, it could only use up to two of any channels among the
>> 16.
> I'm not quite sure if I can follow you on this - how would you
> configure 16 channels when there are only 2 channel position registers?
>
> With bclk ratio eg set to 16*32=512 BCM2835 will only transmit 2*32
> bits of data (at configurable bit positions), the remaining 448
> bits will be zero.
>
>
Yes, two arbitrary tdm channels out of 16. And as I and you said, the 
others are not usable.
Could be useful in a TDM chained scenario , but not for what we are 
talking here.

Emmanuel.

[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Emmanuel Fusté]

Le 21/03/2017 ? 23:11, Matthias Reichl a ?crit :
> On Tue, Mar 21, 2017 at 10:21:04PM +0100, Emmanuel Fust? wrote:
>> Le 16/03/2017 ? 23:14, Matt Flax a ?crit :
>>>
>>> On 17/03/17 08:27, Lars-Peter Clausen wrote:
>>>> On 03/16/2017 09:51 PM, Matt Flax wrote:
>>>>> On 16/03/17 06:01, Mark Brown wrote:
>>>>>> On Tue, Feb 28, 2017 at 09:59:29AM +0000, Charles Keepax wrote:
>>>>>>> On Mon, Feb 27, 2017 at 12:51:08PM +0100, Matthias Reichl wrote:
>>>>>>>>> I have a bcm2835 (Pi 2 and 3) SoC here. It is producing
>>>>>>>>> multichannel (8
>>>>>>>>> out,
>>>>>>>>> 6 in) audio. In ALSA we call that DSP mode - right ?!
>>>>>>>> No. DSP modes are protocol/timing specifications as I2S, PDP,
>>>>>>>> S/PDIF, ...
>>>>>>>> You can look these up in datasheets and if a chip implements such a
>>>>>>>> protocol you can be sure that it adheres to that standard - i.e. it
>>>>>>>> will sync the frames to the pulses on LRclk.
>>>>>>> I agree with the thoughts in this thread really if the AP doesn't
>>>>>>> actually support DSP A mode we shouldn't add DSP A mode.
>>>>>> The trouble here is that this isn't 100% clear, the specifications of
>>>>>> the DSP modes are such that only one edge in the LRCLK matters and so
>>>>>> providing you're doing mono or have exact clocking they interoperate
>>>>>> perfectly well.  We already frequently do similar things the other
>>>>>> way,
>>>>>> most of the programmable serial ports can't actually do I2S modes
>>>>>> properly and rely on exact clocking to get things right when operating
>>>>>> as I2S since they only sync on one edge (though they can generally
>>>>>> generate the clocks correctly when operating as master, they just
>>>>>> don't
>>>>>> pay attention to the left/right switch edge).
>>>>>>
>>>>>> That said unless we're doing something with the data layout or similar
>>>>>> configuration there's a fairly strong case for putting the mangling
>>>>>> for
>>>>>> this in the core, something like just falling back to I2S mode if we
>>>>>> set
>>>>>> DSP A and so on.  Which would be a lot nicer if we actually got
>>>>>> round to
>>>>>> putting mode capability information in the drivers.
>>>>> I agree, the data layout is already configurable in the bcm2835_i2s.c
>>>>> platform driver. We can already use the "snd_soc_dai_set_bclk_ratio"
>>>>> function to manage word offsets in our machine drivers.
>>>>>
>>>>> There is nothing which says that the bcm2835 SoC is I2S restricted in
>>>>> any
>>>>> way. In fact, the reference document says quite the opposite.
>>>>>
>>>>> In the reference "BCM2835 ARM Peripherals" pdf, they call the audio
>>>>> system
>>>>> an "APB peripheral". They are saying that it is reconfigurable and
>>>>> part of
>>>>> the AMBA family of interconnect schemes.
>>>>>
>>>>> As far as the bcm2835_i2s platform driver goes, it has implemented an
>>>>> AMBA
>>>>> protocol, where audio words are counted from the LR clock onset - for
>>>>> some
>>>>> reason people are insisting this is an I2S bus. Really our
>>>>> implementation is
>>>>> not I2S at all, because word onsets are programmable and flexible in
>>>>> the
>>>>> bcm2835_i2s.c driver.
>>>> AMBA/APB is the interface which connects the peripheral to the system
>>>> memory
>>>> bus. It is the interface over which the CPU does configuration register
>>>> writes. This has nothing and absolutely nothing to do with the I2S
>>>> interface
>>>> that is also implemented by the peripheral that is used to stream audio
>>>> to
>>>> and from external components.
>>>>
>>> Their (BCM reference) document [1] specifically states "It supports many
>>> classic PCM formats including I2S".
>>>
>>> Do agree with Mark's statement "the specifications of the DSP modes are
>>> such that only one edge in the LRCLK matters" ?
>>>
>>> If we look at the bcm2835 platform driver setup, it is concerned with bit
>>> clock counting to specify the audio data for both of the AMBA/APB channels
>> >from serial bitstream into memory. It has two channels into memory,
>>> however "it supports many classic PCM formats" ... my vote for one classic
>>> format is DSP mode !
>>>
>>> Do you see a problem with that ?
>>>
>>> thanks
>>> Matt
>>> [1] https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
>>> _______________________________________________
>>>
>> Re-reading this document, the bcm2835 PCM IP block SHOULD support real DSP
>> mode, with one BCLK pulsed LRCLK, zero BCLK delay etc...
>> It just need to be properly setup.
> I've re-read the document, too, last week and noticed the framesync
> registers - sorry, I had completely forgotten about these. I guess it
> should be possible to configure the bcm2835 to DSP mode but it'd still be
> limited to 2 channel setups - the hardware only has 2 channel position
> registers for each direction.
>
>> According to the same document, you could program the bmc up to 16 32bits
>> channels when in master mode, so I suspect that you could go up to this
>> limit in slave mode.
>> But as it is designed, it could only use up to two of any channels among the
>> 16.
> I'm not quite sure if I can follow you on this - how would you
> configure 16 channels when there are only 2 channel position registers?
>
> With bclk ratio eg set to 16*32=512 BCM2835 will only transmit 2*32
> bits of data (at configurable bit positions), the remaining 448
> bits will be zero.
>
>
Yes, two arbitrary tdm channels out of 16. And as I and you said, the 
others are not usable.
Could be useful in a TDM chained scenario , but not for what we are 
talking here.

Emmanuel.

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Charles Keepax]

On Mon, Feb 27, 2017 at 07:21:13AM +1100, Matt Flax wrote:
> On 27/02/17 01:49, Matthias Reichl wrote:
> >On Sun, Feb 26, 2017 at 09:13:09AM +1100, Matt Flax wrote:
> >>On 26/02/17 00:39, Matthias Reichl wrote:
> >>>On Sat, Feb 25, 2017 at 04:03:11PM +1100, Matt Flax wrote:
> >The place to do that is in a codec driver. In your setup it'll look
> >like this:
> >
> >That "IC" codec has 2 DAIs and operates as a clock master on both.
> >You link one DAI in I2S mode to the bcm2835 and the other DAI
> >in DSP (or whatever mode you are using) to the cs42xx8.
> >
> >If you model it this way you no longer work against ALSA and
> >you can stop adding hacks to existing drivers.
> >
> >
> Thanks, this is actually very constructive advice. Let me try to understand
> what
> you are suggesting here... I am confused about how to set bit depth
> correctly for
> the codec when I play to the IC chip in this setup... lets walk me through
> this one...
> 
> I implement a new codec which matches this IC. The IC can be setup to be
> master in
> its dai fmt. The sound card shows up with two devices, only the IC device
> can be used to play
> and record.
> 
> Say I use aplay to play to the first device (the IC chip) it does hw_params
> and clocks are set.
> But the second device (the codec) never gets hw_params executed ? If I
> select 16 or 24 bits,
> it never knows ... is that right ? If so, how do we solve this problem ?

Yeah I think there are basically two ways you could model this
sort of setup, either with a CODEC to CODEC link as suggested
here or a DPCM setup.

The CODEC to CODEC link is probably the better model for the
system as that is really the direction people are trying to
take things within ASoC, however at the moment being a CODEC to
CODEC link does impose some restrictions, you have to basically
specify fixed parameters for the link in the machine driver. You
can specify multiple parameters and an ALSA control will be
created to switch between them, however this does require user
involvement.

I am interested you mention the bit depth but not the sample rate
which is often the bigger problem? Probably the easiest solution
here assuming you don't have sample rate issues, is just to have
the link between your FPGA and the CODEC always be 24bit and just
have the FPGA insert padding if the link on the other side is
16bit.

Alternatively you could look at implementing this as DPCM,
although I am not the greatest fan of it. That would let you
fix up the settings before they are passed to the CODEC, but
leaves the FPGA part relatively unmodelled and would likely be
implicitly supported in the machine driver.  Really DPCM is more
normally used to model hardware that is an actual part of the SoC
so this case does feel slightly abusive.

Thanks,
Charles

[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Charles Keepax]

On Mon, Feb 27, 2017 at 07:21:13AM +1100, Matt Flax wrote:
> On 27/02/17 01:49, Matthias Reichl wrote:
> >On Sun, Feb 26, 2017 at 09:13:09AM +1100, Matt Flax wrote:
> >>On 26/02/17 00:39, Matthias Reichl wrote:
> >>>On Sat, Feb 25, 2017 at 04:03:11PM +1100, Matt Flax wrote:
> >The place to do that is in a codec driver. In your setup it'll look
> >like this:
> >
> >That "IC" codec has 2 DAIs and operates as a clock master on both.
> >You link one DAI in I2S mode to the bcm2835 and the other DAI
> >in DSP (or whatever mode you are using) to the cs42xx8.
> >
> >If you model it this way you no longer work against ALSA and
> >you can stop adding hacks to existing drivers.
> >
> >
> Thanks, this is actually very constructive advice. Let me try to understand
> what
> you are suggesting here... I am confused about how to set bit depth
> correctly for
> the codec when I play to the IC chip in this setup... lets walk me through
> this one...
> 
> I implement a new codec which matches this IC. The IC can be setup to be
> master in
> its dai fmt. The sound card shows up with two devices, only the IC device
> can be used to play
> and record.
> 
> Say I use aplay to play to the first device (the IC chip) it does hw_params
> and clocks are set.
> But the second device (the codec) never gets hw_params executed ? If I
> select 16 or 24 bits,
> it never knows ... is that right ? If so, how do we solve this problem ?

Yeah I think there are basically two ways you could model this
sort of setup, either with a CODEC to CODEC link as suggested
here or a DPCM setup.

The CODEC to CODEC link is probably the better model for the
system as that is really the direction people are trying to
take things within ASoC, however at the moment being a CODEC to
CODEC link does impose some restrictions, you have to basically
specify fixed parameters for the link in the machine driver. You
can specify multiple parameters and an ALSA control will be
created to switch between them, however this does require user
involvement.

I am interested you mention the bit depth but not the sample rate
which is often the bigger problem? Probably the easiest solution
here assuming you don't have sample rate issues, is just to have
the link between your FPGA and the CODEC always be 24bit and just
have the FPGA insert padding if the link on the other side is
16bit.

Alternatively you could look at implementing this as DPCM,
although I am not the greatest fan of it. That would let you
fix up the settings before they are passed to the CODEC, but
leaves the FPGA part relatively unmodelled and would likely be
implicitly supported in the machine driver.  Really DPCM is more
normally used to model hardware that is an actual part of the SoC
so this case does feel slightly abusive.

Thanks,
Charles

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Emmanuel Fusté]

Le 26/02/2017 à 15:49, Matthias Reichl a écrit :
> On Sun, Feb 26, 2017 at 09:13:09AM +1100, Matt Flax wrote:
>> On 26/02/17 00:39, Matthias Reichl wrote:
>>> On Sat, Feb 25, 2017 at 04:03:11PM +1100, Matt Flax wrote:
>>>> This patch set lets the ASoC system specify that an IC between the SoC and codec
>>>> is master. This is intended to put both the SoC and Codec into slave modes.
>>>>
>>>> By default un-patched SoC and Codec drivers will return -EINVAL if they aren't
>>>> enabled and tested for this mode.
>>>>
>>>> soc-dia.h has the new SND_SOC_DAIFMT_IBM_IFM definition set as :
>>>> #define SND_SOC_DAIFMT_IBM_IFM		(5 << 12) /* IC clk & FRM master */
>>>>
>>>> The cs42xx8 codec driver is enabled for this mode and so too is the BCM2835
>>>> SoC driver. This forms a chain : bcm2835<=>IC<=>cs42xx8
>>>> where the IC is bit and frame master.
>>> Model your IC as a codec. No need to add patches to random drivers
>>> and add a flag with the rather meaningless semantics "someone else is
>>> automagically setting up clocks for me".
>>>
>>>
>> My last patch, used the two codec approach, however it was pointed out that
>> the
>> bcm2835 was run in DSP mode with a codec master (rather then IC master) and
>> that
>> the patch doesn't work. Which is clearly true and a problem, it can only
>> work with an
>> intermediate non-codec master.
>>
>> I think you summed it up well with your statement :
>>
>> On 25/02/17 Matthias Reichl wrote:
>> If the clock timing adheres to DSP mode A timing and you add code
>> to the the CPU DAI driver so it can operate in DSP mode A then
>> that should also work. If not, it's broken.
> Your bcm2835 patch doesn't configure the bcm2835 to DSP mode A,
> it's still setup for I2S (slave) mode. You are just adding code
> to pretend it's running in DSP mode A. Don't do that, it's wrong.
>
>> This patch set fixes the problem of a daisy chain of three possible masters
>> (CPU <=> IC <=> codec) where only the IC can be master. In fact, when retro
>> fitting DSP mode to old silicon, the CPU can specify which of the three can
>> be masters
>> and there is no chance that someone can fire the system up with the wrong
>> master
>> (which we know produces bit offset and random channel swapping when a codec
>> is
>> master).
> Please follow the advice I gave you about 3 weeks ago and model your
> setup properly.
>
> | So you have bcm2835 I2S <-> FPGA <-> codec - IOW a standard codec<->codec
> | link.
> |
> | What you seem to be missing is just a method to transfer your 8-channel
> | data via a 2-channel link - userspace want's to see an 8-channel PCM,
> | but the hardware link (bcm2835-i2s) is only 2-channel.
> |
> | And that's where IMO as userspace plugin looks like a very good solution.
> | It's basically the counterpart of your FPGA and contains the code that's
> | neccessary to encapsulate/pack/whatever the 8-channel data into a 2-channel
> | stream so it can then be unpacked to 8-channel by the FPGA.
> |
> | If you go this route your hardware and machine driver will work with
> | other I2S codecs as well, and IMO that's a far better solution than
> | adding very ugly hacks to a single I2S driver.
>
> If you add an active hardware component (your "IC"/FPGA) you also
> have to model that in software.
>
> If that component is acting as a clock master it probably has some
> method to setup clocks. Even if you don't have that, eg if you
> are running at some fixed rate you'll have to store that information
> somewhere.
>
> The place to do that is in a codec driver. In your setup it'll look
> like this:
>
> That "IC" codec has 2 DAIs and operates as a clock master on both.
> You link one DAI in I2S mode to the bcm2835 and the other DAI
> in DSP (or whatever mode you are using) to the cs42xx8.
>
> If you model it this way you no longer work against ALSA and
> you can stop adding hacks to existing drivers.
>
 From the beginning, I completely agree with you when you take the two 
problems apart:
- for the timing problem : model properly the converter as a codec
- for the encapsulation problem : do the encapsulation / packing with a 
userspace plugin

But when you take the whole together, the plugin part seems completely 
overcomplicated.
As the whole is properly modeled, if we could have a simple solution to 
relax the channel numbers constraint on the I2S on the higher part of 
the stack all will "magically" work with little effort/complexity.

Otherwise, the user-space packer would have to do a lot of more than 
packing :  interact with private machine driver controls to manage all 
the channels and the machine driver will need to forward /translate some 
parts to directly drive the final (cs42xx8) codec. An potentially if 
such hardware continue to pop-up, each machine driver will need it's own 
user-space counterpart.

Packing DSD in PCM (DoP) require zero kernel knowledge and could be 
fully implemented in user-space as we don't change the number of channel 
assumption of the data part of the format. But here, we simply want the 
DSP A data semantic with the I2S hardware bus timing.

I'm a complete newbie to ASoC  but I take part to this tread to learn as 
I hate to see how badly all diy and amateur audio hw are integrated with 
Alsa/ASoC/Linux and so never go upstream. On a professional/commercial 
dev, you would never take this ... convoluted I2S multi channel path.

Emmanuel.

[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Emmanuel Fusté]

Le 26/02/2017 ? 15:49, Matthias Reichl a ?crit :
> On Sun, Feb 26, 2017 at 09:13:09AM +1100, Matt Flax wrote:
>> On 26/02/17 00:39, Matthias Reichl wrote:
>>> On Sat, Feb 25, 2017 at 04:03:11PM +1100, Matt Flax wrote:
>>>> This patch set lets the ASoC system specify that an IC between the SoC and codec
>>>> is master. This is intended to put both the SoC and Codec into slave modes.
>>>>
>>>> By default un-patched SoC and Codec drivers will return -EINVAL if they aren't
>>>> enabled and tested for this mode.
>>>>
>>>> soc-dia.h has the new SND_SOC_DAIFMT_IBM_IFM definition set as :
>>>> #define SND_SOC_DAIFMT_IBM_IFM		(5 << 12) /* IC clk & FRM master */
>>>>
>>>> The cs42xx8 codec driver is enabled for this mode and so too is the BCM2835
>>>> SoC driver. This forms a chain : bcm2835<=>IC<=>cs42xx8
>>>> where the IC is bit and frame master.
>>> Model your IC as a codec. No need to add patches to random drivers
>>> and add a flag with the rather meaningless semantics "someone else is
>>> automagically setting up clocks for me".
>>>
>>>
>> My last patch, used the two codec approach, however it was pointed out that
>> the
>> bcm2835 was run in DSP mode with a codec master (rather then IC master) and
>> that
>> the patch doesn't work. Which is clearly true and a problem, it can only
>> work with an
>> intermediate non-codec master.
>>
>> I think you summed it up well with your statement :
>>
>> On 25/02/17 Matthias Reichl wrote:
>> If the clock timing adheres to DSP mode A timing and you add code
>> to the the CPU DAI driver so it can operate in DSP mode A then
>> that should also work. If not, it's broken.
> Your bcm2835 patch doesn't configure the bcm2835 to DSP mode A,
> it's still setup for I2S (slave) mode. You are just adding code
> to pretend it's running in DSP mode A. Don't do that, it's wrong.
>
>> This patch set fixes the problem of a daisy chain of three possible masters
>> (CPU <=> IC <=> codec) where only the IC can be master. In fact, when retro
>> fitting DSP mode to old silicon, the CPU can specify which of the three can
>> be masters
>> and there is no chance that someone can fire the system up with the wrong
>> master
>> (which we know produces bit offset and random channel swapping when a codec
>> is
>> master).
> Please follow the advice I gave you about 3 weeks ago and model your
> setup properly.
>
> | So you have bcm2835 I2S <-> FPGA <-> codec - IOW a standard codec<->codec
> | link.
> |
> | What you seem to be missing is just a method to transfer your 8-channel
> | data via a 2-channel link - userspace want's to see an 8-channel PCM,
> | but the hardware link (bcm2835-i2s) is only 2-channel.
> |
> | And that's where IMO as userspace plugin looks like a very good solution.
> | It's basically the counterpart of your FPGA and contains the code that's
> | neccessary to encapsulate/pack/whatever the 8-channel data into a 2-channel
> | stream so it can then be unpacked to 8-channel by the FPGA.
> |
> | If you go this route your hardware and machine driver will work with
> | other I2S codecs as well, and IMO that's a far better solution than
> | adding very ugly hacks to a single I2S driver.
>
> If you add an active hardware component (your "IC"/FPGA) you also
> have to model that in software.
>
> If that component is acting as a clock master it probably has some
> method to setup clocks. Even if you don't have that, eg if you
> are running at some fixed rate you'll have to store that information
> somewhere.
>
> The place to do that is in a codec driver. In your setup it'll look
> like this:
>
> That "IC" codec has 2 DAIs and operates as a clock master on both.
> You link one DAI in I2S mode to the bcm2835 and the other DAI
> in DSP (or whatever mode you are using) to the cs42xx8.
>
> If you model it this way you no longer work against ALSA and
> you can stop adding hacks to existing drivers.
>
 From the beginning, I completely agree with you when you take the two 
problems apart:
- for the timing problem : model properly the converter as a codec
- for the encapsulation problem : do the encapsulation / packing with a 
userspace plugin

But when you take the whole together, the plugin part seems completely 
overcomplicated.
As the whole is properly modeled, if we could have a simple solution to 
relax the channel numbers constraint on the I2S on the higher part of 
the stack all will "magically" work with little effort/complexity.

Otherwise, the user-space packer would have to do a lot of more than 
packing :  interact with private machine driver controls to manage all 
the channels and the machine driver will need to forward /translate some 
parts to directly drive the final (cs42xx8) codec. An potentially if 
such hardware continue to pop-up, each machine driver will need it's own 
user-space counterpart.

Packing DSD in PCM (DoP) require zero kernel knowledge and could be 
fully implemented in user-space as we don't change the number of channel 
assumption of the data part of the format. But here, we simply want the 
DSP A data semantic with the I2S hardware bus timing.

I'm a complete newbie to ASoC  but I take part to this tread to learn as 
I hate to see how badly all diy and amateur audio hw are integrated with 
Alsa/ASoC/Linux and so never go upstream. On a professional/commercial 
dev, you would never take this ... convoluted I2S multi channel path.

Emmanuel.

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matt Flax]

On 27/02/17 07:41, Emmanuel Fusté wrote:
>
>
> I'm a complete newbie to ASoC  but I take part to this tread to learn 
> as I hate to see how badly all diy and amateur audio hw are integrated 
> with Alsa/ASoC/Linux and so never go upstream. On a 
> professional/commercial dev, you would never take this ... convoluted 
> I2S multi channel path.
>

Hey Emmanuel,

We now know that we can retrofit legacy I2S silicon for multichannel, in 
a very direct manner.

If you were a chip manufacturer and you could potentially increase your 
market take up by hundreds of millions of new potential low power 
devices, wouldn't you manufacture ALL new chips with these minor 
modifications ?

Matt

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Emmanuel Fusté]

Le 26/02/2017 à 22:44, Matt Flax a écrit :
>
>
> On 27/02/17 07:41, Emmanuel Fusté wrote:
>>
>>
>> I'm a complete newbie to ASoC  but I take part to this tread to learn 
>> as I hate to see how badly all diy and amateur audio hw are 
>> integrated with Alsa/ASoC/Linux and so never go upstream. On a 
>> professional/commercial dev, you would never take this ... convoluted 
>> I2S multi channel path.
>>
>
> Hey Emmanuel,
>
> We now know that we can retrofit legacy I2S silicon for multichannel, 
> in a very direct manner.
>
> If you were a chip manufacturer and you could potentially increase 
> your market take up by hundreds of millions of new potential low power 
> devices, wouldn't you manufacture ALL new chips with these minor 
> modifications ?
>
> Matt
Hi,

No, because this is a hack. There is established an more importantly  
interoperable bus standards to do multichannel digital audio : TDM/DSP 
A/DSP B
As today standards, even ultra low power and low powerfull IC are able 
to do standard multichannel serial audio. Atmel AT & ARM cortex  M µC, 
STMicro STM32 family etc ...
I2S signaling is only part of the equation, fifo, DMA handling, etc... 
of the multichannel part could be important depending of the implementation.
And the FPGA glue logic is way more costly than choosing a SOC / µC with 
a properly designed multichannel serial audio IP.
The real question is why this SOC so poorly endowed with bad device IP 
is so popular... but this is another story...

Don't get me wrong. I'm nevertheless a real supporter of this "hack". 
But it should be done the "right" way.

Emmanuel.

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matthias Reichl]

On Sun, Feb 26, 2017 at 09:41:11PM +0100, Emmanuel Fusté wrote:
> Le 26/02/2017 à 15:49, Matthias Reichl a écrit :
> >On Sun, Feb 26, 2017 at 09:13:09AM +1100, Matt Flax wrote:
> >>On 26/02/17 00:39, Matthias Reichl wrote:
> >>>On Sat, Feb 25, 2017 at 04:03:11PM +1100, Matt Flax wrote:
> >>>>This patch set lets the ASoC system specify that an IC between the SoC and codec
> >>>>is master. This is intended to put both the SoC and Codec into slave modes.
> >>>>
> >>>>By default un-patched SoC and Codec drivers will return -EINVAL if they aren't
> >>>>enabled and tested for this mode.
> >>>>
> >>>>soc-dia.h has the new SND_SOC_DAIFMT_IBM_IFM definition set as :
> >>>>#define SND_SOC_DAIFMT_IBM_IFM		(5 << 12) /* IC clk & FRM master */
> >>>>
> >>>>The cs42xx8 codec driver is enabled for this mode and so too is the BCM2835
> >>>>SoC driver. This forms a chain : bcm2835<=>IC<=>cs42xx8
> >>>>where the IC is bit and frame master.
> >>>Model your IC as a codec. No need to add patches to random drivers
> >>>and add a flag with the rather meaningless semantics "someone else is
> >>>automagically setting up clocks for me".
> >>>
> >>>
> >>My last patch, used the two codec approach, however it was pointed out that
> >>the
> >>bcm2835 was run in DSP mode with a codec master (rather then IC master) and
> >>that
> >>the patch doesn't work. Which is clearly true and a problem, it can only
> >>work with an
> >>intermediate non-codec master.
> >>
> >>I think you summed it up well with your statement :
> >>
> >>On 25/02/17 Matthias Reichl wrote:
> >>If the clock timing adheres to DSP mode A timing and you add code
> >>to the the CPU DAI driver so it can operate in DSP mode A then
> >>that should also work. If not, it's broken.
> >Your bcm2835 patch doesn't configure the bcm2835 to DSP mode A,
> >it's still setup for I2S (slave) mode. You are just adding code
> >to pretend it's running in DSP mode A. Don't do that, it's wrong.
> >
> >>This patch set fixes the problem of a daisy chain of three possible masters
> >>(CPU <=> IC <=> codec) where only the IC can be master. In fact, when retro
> >>fitting DSP mode to old silicon, the CPU can specify which of the three can
> >>be masters
> >>and there is no chance that someone can fire the system up with the wrong
> >>master
> >>(which we know produces bit offset and random channel swapping when a codec
> >>is
> >>master).
> >Please follow the advice I gave you about 3 weeks ago and model your
> >setup properly.
> >
> >| So you have bcm2835 I2S <-> FPGA <-> codec - IOW a standard codec<->codec
> >| link.
> >|
> >| What you seem to be missing is just a method to transfer your 8-channel
> >| data via a 2-channel link - userspace want's to see an 8-channel PCM,
> >| but the hardware link (bcm2835-i2s) is only 2-channel.
> >|
> >| And that's where IMO as userspace plugin looks like a very good solution.
> >| It's basically the counterpart of your FPGA and contains the code that's
> >| neccessary to encapsulate/pack/whatever the 8-channel data into a 2-channel
> >| stream so it can then be unpacked to 8-channel by the FPGA.
> >|
> >| If you go this route your hardware and machine driver will work with
> >| other I2S codecs as well, and IMO that's a far better solution than
> >| adding very ugly hacks to a single I2S driver.
> >
> >If you add an active hardware component (your "IC"/FPGA) you also
> >have to model that in software.
> >
> >If that component is acting as a clock master it probably has some
> >method to setup clocks. Even if you don't have that, eg if you
> >are running at some fixed rate you'll have to store that information
> >somewhere.
> >
> >The place to do that is in a codec driver. In your setup it'll look
> >like this:
> >
> >That "IC" codec has 2 DAIs and operates as a clock master on both.
> >You link one DAI in I2S mode to the bcm2835 and the other DAI
> >in DSP (or whatever mode you are using) to the cs42xx8.
> >
> >If you model it this way you no longer work against ALSA and
> >you can stop adding hacks to existing drivers.
> >
> From the beginning, I completely agree with you when you take the two
> problems apart:
> - for the timing problem : model properly the converter as a codec
> - for the encapsulation problem : do the encapsulation / packing with a
> userspace plugin
> 
> But when you take the whole together, the plugin part seems completely
> overcomplicated.
> As the whole is properly modeled, if we could have a simple solution to
> relax the channel numbers constraint on the I2S on the higher part of the
> stack all will "magically" work with little effort/complexity.
> 
> Otherwise, the user-space packer would have to do a lot of more than packing
> :  interact with private machine driver controls to manage all the channels
> and the machine driver will need to forward /translate some parts to
> directly drive the final (cs42xx8) codec. An potentially if such hardware
> continue to pop-up, each machine driver will need it's own user-space
> counterpart.

Quite on the contrary. You'd need to add the channel relaxing constraint
to all existing I2S drivers to get this working. And I don't see a need
to artificially restrict that to a specific codec (cs42xx8) and a specific
number of channels. Why only 8 channels, why not 4 or 384?

Doing it as an ALSA plugin makes it reusable with existing drivers and
hardware.

The idea behind these modular components (plugins, codecs, dais) is to
create reusable components and you don't have to add identical code
to all other drivers when you add some new functionality.

Actually, if you add a new feature, you need to have very good reasons
to restrict it to a specific driver or change all existing drivers.
If you can implement that feature in a generic way without touching
existing code it's often the better solution.

Matt is trying to tunnel multichannel PCM over a 2-channel PCM link running
at a higher samplerate. I've described a way how this is possible without
modifying current code. There are certainly other, probably better,
ways to do that. This was a first quick idea how it could be done and I
still think it's not too bad.

All the plugin has to do is expose a multi-channel PCM and configure the 
hw/backend PCM to 2 channels at a higher samplerate (all of which
current drivers are already capable of). The plugin settings determine
the number of channels, channel map, samplerate factor etc. That same
plugin can also be used with other "unpacking codecs" and other channel
numbers - you just need to change the plugin configuration in your alsa
card conf and tell it you have 4 (or whatever) channels.

If you need interaction with the backend codec (Matt's "IC"/FPGA) that
does PCM unpacking to multichannel you can do that for example in the plugin
or in the alsa card.conf via the hooks plugin and alsa controls.

> Packing DSD in PCM (DoP) require zero kernel knowledge and could be fully
> implemented in user-space as we don't change the number of channel
> assumption of the data part of the format. But here, we simply want the DSP
> A data semantic with the I2S hardware bus timing.

Yes, and this is what Matt's codec (FPGA) is doing. It's creating that
semantic, together with the machine driver and the plugin to set it all up.

> I'm a complete newbie to ASoC  but I take part to this tread to learn as I
> hate to see how badly all diy and amateur audio hw are integrated with
> Alsa/ASoC/Linux and so never go upstream. On a professional/commercial dev,
> you would never take this ... convoluted I2S multi channel path.
> 
> Emmanuel.

[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Matthias Reichl]

On Sun, Feb 26, 2017 at 09:41:11PM +0100, Emmanuel Fust? wrote:
> Le 26/02/2017 ? 15:49, Matthias Reichl a ?crit :
> >On Sun, Feb 26, 2017 at 09:13:09AM +1100, Matt Flax wrote:
> >>On 26/02/17 00:39, Matthias Reichl wrote:
> >>>On Sat, Feb 25, 2017 at 04:03:11PM +1100, Matt Flax wrote:
> >>>>This patch set lets the ASoC system specify that an IC between the SoC and codec
> >>>>is master. This is intended to put both the SoC and Codec into slave modes.
> >>>>
> >>>>By default un-patched SoC and Codec drivers will return -EINVAL if they aren't
> >>>>enabled and tested for this mode.
> >>>>
> >>>>soc-dia.h has the new SND_SOC_DAIFMT_IBM_IFM definition set as :
> >>>>#define SND_SOC_DAIFMT_IBM_IFM		(5 << 12) /* IC clk & FRM master */
> >>>>
> >>>>The cs42xx8 codec driver is enabled for this mode and so too is the BCM2835
> >>>>SoC driver. This forms a chain : bcm2835<=>IC<=>cs42xx8
> >>>>where the IC is bit and frame master.
> >>>Model your IC as a codec. No need to add patches to random drivers
> >>>and add a flag with the rather meaningless semantics "someone else is
> >>>automagically setting up clocks for me".
> >>>
> >>>
> >>My last patch, used the two codec approach, however it was pointed out that
> >>the
> >>bcm2835 was run in DSP mode with a codec master (rather then IC master) and
> >>that
> >>the patch doesn't work. Which is clearly true and a problem, it can only
> >>work with an
> >>intermediate non-codec master.
> >>
> >>I think you summed it up well with your statement :
> >>
> >>On 25/02/17 Matthias Reichl wrote:
> >>If the clock timing adheres to DSP mode A timing and you add code
> >>to the the CPU DAI driver so it can operate in DSP mode A then
> >>that should also work. If not, it's broken.
> >Your bcm2835 patch doesn't configure the bcm2835 to DSP mode A,
> >it's still setup for I2S (slave) mode. You are just adding code
> >to pretend it's running in DSP mode A. Don't do that, it's wrong.
> >
> >>This patch set fixes the problem of a daisy chain of three possible masters
> >>(CPU <=> IC <=> codec) where only the IC can be master. In fact, when retro
> >>fitting DSP mode to old silicon, the CPU can specify which of the three can
> >>be masters
> >>and there is no chance that someone can fire the system up with the wrong
> >>master
> >>(which we know produces bit offset and random channel swapping when a codec
> >>is
> >>master).
> >Please follow the advice I gave you about 3 weeks ago and model your
> >setup properly.
> >
> >| So you have bcm2835 I2S <-> FPGA <-> codec - IOW a standard codec<->codec
> >| link.
> >|
> >| What you seem to be missing is just a method to transfer your 8-channel
> >| data via a 2-channel link - userspace want's to see an 8-channel PCM,
> >| but the hardware link (bcm2835-i2s) is only 2-channel.
> >|
> >| And that's where IMO as userspace plugin looks like a very good solution.
> >| It's basically the counterpart of your FPGA and contains the code that's
> >| neccessary to encapsulate/pack/whatever the 8-channel data into a 2-channel
> >| stream so it can then be unpacked to 8-channel by the FPGA.
> >|
> >| If you go this route your hardware and machine driver will work with
> >| other I2S codecs as well, and IMO that's a far better solution than
> >| adding very ugly hacks to a single I2S driver.
> >
> >If you add an active hardware component (your "IC"/FPGA) you also
> >have to model that in software.
> >
> >If that component is acting as a clock master it probably has some
> >method to setup clocks. Even if you don't have that, eg if you
> >are running at some fixed rate you'll have to store that information
> >somewhere.
> >
> >The place to do that is in a codec driver. In your setup it'll look
> >like this:
> >
> >That "IC" codec has 2 DAIs and operates as a clock master on both.
> >You link one DAI in I2S mode to the bcm2835 and the other DAI
> >in DSP (or whatever mode you are using) to the cs42xx8.
> >
> >If you model it this way you no longer work against ALSA and
> >you can stop adding hacks to existing drivers.
> >
> From the beginning, I completely agree with you when you take the two
> problems apart:
> - for the timing problem : model properly the converter as a codec
> - for the encapsulation problem : do the encapsulation / packing with a
> userspace plugin
> 
> But when you take the whole together, the plugin part seems completely
> overcomplicated.
> As the whole is properly modeled, if we could have a simple solution to
> relax the channel numbers constraint on the I2S on the higher part of the
> stack all will "magically" work with little effort/complexity.
> 
> Otherwise, the user-space packer would have to do a lot of more than packing
> :  interact with private machine driver controls to manage all the channels
> and the machine driver will need to forward /translate some parts to
> directly drive the final (cs42xx8) codec. An potentially if such hardware
> continue to pop-up, each machine driver will need it's own user-space
> counterpart.

Quite on the contrary. You'd need to add the channel relaxing constraint
to all existing I2S drivers to get this working. And I don't see a need
to artificially restrict that to a specific codec (cs42xx8) and a specific
number of channels. Why only 8 channels, why not 4 or 384?

Doing it as an ALSA plugin makes it reusable with existing drivers and
hardware.

The idea behind these modular components (plugins, codecs, dais) is to
create reusable components and you don't have to add identical code
to all other drivers when you add some new functionality.

Actually, if you add a new feature, you need to have very good reasons
to restrict it to a specific driver or change all existing drivers.
If you can implement that feature in a generic way without touching
existing code it's often the better solution.

Matt is trying to tunnel multichannel PCM over a 2-channel PCM link running
at a higher samplerate. I've described a way how this is possible without
modifying current code. There are certainly other, probably better,
ways to do that. This was a first quick idea how it could be done and I
still think it's not too bad.

All the plugin has to do is expose a multi-channel PCM and configure the 
hw/backend PCM to 2 channels at a higher samplerate (all of which
current drivers are already capable of). The plugin settings determine
the number of channels, channel map, samplerate factor etc. That same
plugin can also be used with other "unpacking codecs" and other channel
numbers - you just need to change the plugin configuration in your alsa
card conf and tell it you have 4 (or whatever) channels.

If you need interaction with the backend codec (Matt's "IC"/FPGA) that
does PCM unpacking to multichannel you can do that for example in the plugin
or in the alsa card.conf via the hooks plugin and alsa controls.

> Packing DSD in PCM (DoP) require zero kernel knowledge and could be fully
> implemented in user-space as we don't change the number of channel
> assumption of the data part of the format. But here, we simply want the DSP
> A data semantic with the I2S hardware bus timing.

Yes, and this is what Matt's codec (FPGA) is doing. It's creating that
semantic, together with the machine driver and the plugin to set it all up.

> I'm a complete newbie to ASoC  but I take part to this tread to learn as I
> hate to see how badly all diy and amateur audio hw are integrated with
> Alsa/ASoC/Linux and so never go upstream. On a professional/commercial dev,
> you would never take this ... convoluted I2S multi channel path.
> 
> Emmanuel.

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Emmanuel Fusté]

Le 27/02/2017 à 10:14, Matthias Reichl a écrit :
> On Sun, Feb 26, 2017 at 09:41:11PM +0100, Emmanuel Fusté wrote:
>> Le 26/02/2017 à 15:49, Matthias Reichl a écrit :
>>> On Sun, Feb 26, 2017 at 09:13:09AM +1100, Matt Flax wrote:
>>>> On 26/02/17 00:39, Matthias Reichl wrote:
>>>>> On Sat, Feb 25, 2017 at 04:03:11PM +1100, Matt Flax wrote:
>>>>>> This patch set lets the ASoC system specify that an IC between the SoC and codec
>>>>>> is master. This is intended to put both the SoC and Codec into slave modes.
>>>>>>
>>>>>> By default un-patched SoC and Codec drivers will return -EINVAL if they aren't
>>>>>> enabled and tested for this mode.
>>>>>>
>>>>>> soc-dia.h has the new SND_SOC_DAIFMT_IBM_IFM definition set as :
>>>>>> #define SND_SOC_DAIFMT_IBM_IFM		(5 << 12) /* IC clk & FRM master */
>>>>>>
>>>>>> The cs42xx8 codec driver is enabled for this mode and so too is the BCM2835
>>>>>> SoC driver. This forms a chain : bcm2835<=>IC<=>cs42xx8
>>>>>> where the IC is bit and frame master.
>>>>> Model your IC as a codec. No need to add patches to random drivers
>>>>> and add a flag with the rather meaningless semantics "someone else is
>>>>> automagically setting up clocks for me".
>>>>>
>>>>>
>>>> My last patch, used the two codec approach, however it was pointed out that
>>>> the
>>>> bcm2835 was run in DSP mode with a codec master (rather then IC master) and
>>>> that
>>>> the patch doesn't work. Which is clearly true and a problem, it can only
>>>> work with an
>>>> intermediate non-codec master.
>>>>
>>>> I think you summed it up well with your statement :
>>>>
>>>> On 25/02/17 Matthias Reichl wrote:
>>>> If the clock timing adheres to DSP mode A timing and you add code
>>>> to the the CPU DAI driver so it can operate in DSP mode A then
>>>> that should also work. If not, it's broken.
>>> Your bcm2835 patch doesn't configure the bcm2835 to DSP mode A,
>>> it's still setup for I2S (slave) mode. You are just adding code
>>> to pretend it's running in DSP mode A. Don't do that, it's wrong.
>>>
>>>> This patch set fixes the problem of a daisy chain of three possible masters
>>>> (CPU <=> IC <=> codec) where only the IC can be master. In fact, when retro
>>>> fitting DSP mode to old silicon, the CPU can specify which of the three can
>>>> be masters
>>>> and there is no chance that someone can fire the system up with the wrong
>>>> master
>>>> (which we know produces bit offset and random channel swapping when a codec
>>>> is
>>>> master).
>>> Please follow the advice I gave you about 3 weeks ago and model your
>>> setup properly.
>>>
>>> | So you have bcm2835 I2S <-> FPGA <-> codec - IOW a standard codec<->codec
>>> | link.
>>> |
>>> | What you seem to be missing is just a method to transfer your 8-channel
>>> | data via a 2-channel link - userspace want's to see an 8-channel PCM,
>>> | but the hardware link (bcm2835-i2s) is only 2-channel.
>>> |
>>> | And that's where IMO as userspace plugin looks like a very good solution.
>>> | It's basically the counterpart of your FPGA and contains the code that's
>>> | neccessary to encapsulate/pack/whatever the 8-channel data into a 2-channel
>>> | stream so it can then be unpacked to 8-channel by the FPGA.
>>> |
>>> | If you go this route your hardware and machine driver will work with
>>> | other I2S codecs as well, and IMO that's a far better solution than
>>> | adding very ugly hacks to a single I2S driver.
>>>
>>> If you add an active hardware component (your "IC"/FPGA) you also
>>> have to model that in software.
>>>
>>> If that component is acting as a clock master it probably has some
>>> method to setup clocks. Even if you don't have that, eg if you
>>> are running at some fixed rate you'll have to store that information
>>> somewhere.
>>>
>>> The place to do that is in a codec driver. In your setup it'll look
>>> like this:
>>>
>>> That "IC" codec has 2 DAIs and operates as a clock master on both.
>>> You link one DAI in I2S mode to the bcm2835 and the other DAI
>>> in DSP (or whatever mode you are using) to the cs42xx8.
>>>
>>> If you model it this way you no longer work against ALSA and
>>> you can stop adding hacks to existing drivers.
>>>
>>  From the beginning, I completely agree with you when you take the two
>> problems apart:
>> - for the timing problem : model properly the converter as a codec
>> - for the encapsulation problem : do the encapsulation / packing with a
>> userspace plugin
>>
>> But when you take the whole together, the plugin part seems completely
>> overcomplicated.
>> As the whole is properly modeled, if we could have a simple solution to
>> relax the channel numbers constraint on the I2S on the higher part of the
>> stack all will "magically" work with little effort/complexity.
>>
>> Otherwise, the user-space packer would have to do a lot of more than packing
>> :  interact with private machine driver controls to manage all the channels
>> and the machine driver will need to forward /translate some parts to
>> directly drive the final (cs42xx8) codec. An potentially if such hardware
>> continue to pop-up, each machine driver will need it's own user-space
>> counterpart.
> Quite on the contrary. You'd need to add the channel relaxing constraint
> to all existing I2S drivers to get this working. And I don't see a need
> to artificially restrict that to a specific codec (cs42xx8) and a specific
> number of channels. Why only 8 channels, why not 4 or 384?
>
> Doing it as an ALSA plugin makes it reusable with existing drivers and
> hardware.
>
> The idea behind these modular components (plugins, codecs, dais) is to
> create reusable components and you don't have to add identical code
> to all other drivers when you add some new functionality.
>
> Actually, if you add a new feature, you need to have very good reasons
> to restrict it to a specific driver or change all existing drivers.
> If you can implement that feature in a generic way without touching
> existing code it's often the better solution.
>
> Matt is trying to tunnel multichannel PCM over a 2-channel PCM link running
> at a higher samplerate. I've described a way how this is possible without
> modifying current code. There are certainly other, probably better,
> ways to do that. This was a first quick idea how it could be done and I
> still think it's not too bad.
>
> All the plugin has to do is expose a multi-channel PCM and configure the
> hw/backend PCM to 2 channels at a higher samplerate (all of which
> current drivers are already capable of). The plugin settings determine
> the number of channels, channel map, samplerate factor etc. That same
> plugin can also be used with other "unpacking codecs" and other channel
> numbers - you just need to change the plugin configuration in your alsa
> card conf and tell it you have 4 (or whatever) channels.
>
> If you need interaction with the backend codec (Matt's "IC"/FPGA) that
> does PCM unpacking to multichannel you can do that for example in the plugin
> or in the alsa card.conf via the hooks plugin and alsa controls.
>
>> Packing DSD in PCM (DoP) require zero kernel knowledge and could be fully
>> implemented in user-space as we don't change the number of channel
>> assumption of the data part of the format. But here, we simply want the DSP
>> A data semantic with the I2S hardware bus timing.
> Yes, and this is what Matt's codec (FPGA) is doing. It's creating that
> semantic, together with the machine driver and the plugin to set it all up.
>
Ok I'm convinced.

Thank you for your detailed explanation.

Emmanuel.

Re: [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Emmanuel Fusté]

Le 27/02/2017 à 10:14, Matthias Reichl a écrit :
> On Sun, Feb 26, 2017 at 09:41:11PM +0100, Emmanuel Fusté wrote:
>> Le 26/02/2017 à 15:49, Matthias Reichl a écrit :
>>> On Sun, Feb 26, 2017 at 09:13:09AM +1100, Matt Flax wrote:
>>>> On 26/02/17 00:39, Matthias Reichl wrote:
>>>>> On Sat, Feb 25, 2017 at 04:03:11PM +1100, Matt Flax wrote:
>>>>>> This patch set lets the ASoC system specify that an IC between the SoC and codec
>>>>>> is master. This is intended to put both the SoC and Codec into slave modes.
>>>>>>
>>>>>> By default un-patched SoC and Codec drivers will return -EINVAL if they aren't
>>>>>> enabled and tested for this mode.
>>>>>>
>>>>>> soc-dia.h has the new SND_SOC_DAIFMT_IBM_IFM definition set as :
>>>>>> #define SND_SOC_DAIFMT_IBM_IFM		(5 << 12) /* IC clk & FRM master */
>>>>>>
>>>>>> The cs42xx8 codec driver is enabled for this mode and so too is the BCM2835
>>>>>> SoC driver. This forms a chain : bcm2835<=>IC<=>cs42xx8
>>>>>> where the IC is bit and frame master.
>>>>> Model your IC as a codec. No need to add patches to random drivers
>>>>> and add a flag with the rather meaningless semantics "someone else is
>>>>> automagically setting up clocks for me".
>>>>>
>>>>>
>>>> My last patch, used the two codec approach, however it was pointed out that
>>>> the
>>>> bcm2835 was run in DSP mode with a codec master (rather then IC master) and
>>>> that
>>>> the patch doesn't work. Which is clearly true and a problem, it can only
>>>> work with an
>>>> intermediate non-codec master.
>>>>
>>>> I think you summed it up well with your statement :
>>>>
>>>> On 25/02/17 Matthias Reichl wrote:
>>>> If the clock timing adheres to DSP mode A timing and you add code
>>>> to the the CPU DAI driver so it can operate in DSP mode A then
>>>> that should also work. If not, it's broken.
>>> Your bcm2835 patch doesn't configure the bcm2835 to DSP mode A,
>>> it's still setup for I2S (slave) mode. You are just adding code
>>> to pretend it's running in DSP mode A. Don't do that, it's wrong.
>>>
>>>> This patch set fixes the problem of a daisy chain of three possible masters
>>>> (CPU <=> IC <=> codec) where only the IC can be master. In fact, when retro
>>>> fitting DSP mode to old silicon, the CPU can specify which of the three can
>>>> be masters
>>>> and there is no chance that someone can fire the system up with the wrong
>>>> master
>>>> (which we know produces bit offset and random channel swapping when a codec
>>>> is
>>>> master).
>>> Please follow the advice I gave you about 3 weeks ago and model your
>>> setup properly.
>>>
>>> | So you have bcm2835 I2S <-> FPGA <-> codec - IOW a standard codec<->codec
>>> | link.
>>> |
>>> | What you seem to be missing is just a method to transfer your 8-channel
>>> | data via a 2-channel link - userspace want's to see an 8-channel PCM,
>>> | but the hardware link (bcm2835-i2s) is only 2-channel.
>>> |
>>> | And that's where IMO as userspace plugin looks like a very good solution.
>>> | It's basically the counterpart of your FPGA and contains the code that's
>>> | neccessary to encapsulate/pack/whatever the 8-channel data into a 2-channel
>>> | stream so it can then be unpacked to 8-channel by the FPGA.
>>> |
>>> | If you go this route your hardware and machine driver will work with
>>> | other I2S codecs as well, and IMO that's a far better solution than
>>> | adding very ugly hacks to a single I2S driver.
>>>
>>> If you add an active hardware component (your "IC"/FPGA) you also
>>> have to model that in software.
>>>
>>> If that component is acting as a clock master it probably has some
>>> method to setup clocks. Even if you don't have that, eg if you
>>> are running at some fixed rate you'll have to store that information
>>> somewhere.
>>>
>>> The place to do that is in a codec driver. In your setup it'll look
>>> like this:
>>>
>>> That "IC" codec has 2 DAIs and operates as a clock master on both.
>>> You link one DAI in I2S mode to the bcm2835 and the other DAI
>>> in DSP (or whatever mode you are using) to the cs42xx8.
>>>
>>> If you model it this way you no longer work against ALSA and
>>> you can stop adding hacks to existing drivers.
>>>
>>  From the beginning, I completely agree with you when you take the two
>> problems apart:
>> - for the timing problem : model properly the converter as a codec
>> - for the encapsulation problem : do the encapsulation / packing with a
>> userspace plugin
>>
>> But when you take the whole together, the plugin part seems completely
>> overcomplicated.
>> As the whole is properly modeled, if we could have a simple solution to
>> relax the channel numbers constraint on the I2S on the higher part of the
>> stack all will "magically" work with little effort/complexity.
>>
>> Otherwise, the user-space packer would have to do a lot of more than packing
>> :  interact with private machine driver controls to manage all the channels
>> and the machine driver will need to forward /translate some parts to
>> directly drive the final (cs42xx8) codec. An potentially if such hardware
>> continue to pop-up, each machine driver will need it's own user-space
>> counterpart.
> Quite on the contrary. You'd need to add the channel relaxing constraint
> to all existing I2S drivers to get this working. And I don't see a need
> to artificially restrict that to a specific codec (cs42xx8) and a specific
> number of channels. Why only 8 channels, why not 4 or 384?
>
> Doing it as an ALSA plugin makes it reusable with existing drivers and
> hardware.
>
> The idea behind these modular components (plugins, codecs, dais) is to
> create reusable components and you don't have to add identical code
> to all other drivers when you add some new functionality.
>
> Actually, if you add a new feature, you need to have very good reasons
> to restrict it to a specific driver or change all existing drivers.
> If you can implement that feature in a generic way without touching
> existing code it's often the better solution.
>
> Matt is trying to tunnel multichannel PCM over a 2-channel PCM link running
> at a higher samplerate. I've described a way how this is possible without
> modifying current code. There are certainly other, probably better,
> ways to do that. This was a first quick idea how it could be done and I
> still think it's not too bad.
>
> All the plugin has to do is expose a multi-channel PCM and configure the
> hw/backend PCM to 2 channels at a higher samplerate (all of which
> current drivers are already capable of). The plugin settings determine
> the number of channels, channel map, samplerate factor etc. That same
> plugin can also be used with other "unpacking codecs" and other channel
> numbers - you just need to change the plugin configuration in your alsa
> card conf and tell it you have 4 (or whatever) channels.
>
> If you need interaction with the backend codec (Matt's "IC"/FPGA) that
> does PCM unpacking to multichannel you can do that for example in the plugin
> or in the alsa card.conf via the hooks plugin and alsa controls.
>
>> Packing DSD in PCM (DoP) require zero kernel knowledge and could be fully
>> implemented in user-space as we don't change the number of channel
>> assumption of the data part of the format. But here, we simply want the DSP
>> A data semantic with the I2S hardware bus timing.
> Yes, and this is what Matt's codec (FPGA) is doing. It's creating that
> semantic, together with the machine driver and the plugin to set it all up.
>
Ok I'm convinced.

Thank you for your detailed explanation.

Emmanuel.

PS: 2nd try, sorry for the html email.

[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Emmanuel Fusté]

Le 27/02/2017 ? 10:14, Matthias Reichl a ?crit :
> On Sun, Feb 26, 2017 at 09:41:11PM +0100, Emmanuel Fust? wrote:
>> Le 26/02/2017 ? 15:49, Matthias Reichl a ?crit :
>>> On Sun, Feb 26, 2017 at 09:13:09AM +1100, Matt Flax wrote:
>>>> On 26/02/17 00:39, Matthias Reichl wrote:
>>>>> On Sat, Feb 25, 2017 at 04:03:11PM +1100, Matt Flax wrote:
>>>>>> This patch set lets the ASoC system specify that an IC between the SoC and codec
>>>>>> is master. This is intended to put both the SoC and Codec into slave modes.
>>>>>>
>>>>>> By default un-patched SoC and Codec drivers will return -EINVAL if they aren't
>>>>>> enabled and tested for this mode.
>>>>>>
>>>>>> soc-dia.h has the new SND_SOC_DAIFMT_IBM_IFM definition set as :
>>>>>> #define SND_SOC_DAIFMT_IBM_IFM		(5 << 12) /* IC clk & FRM master */
>>>>>>
>>>>>> The cs42xx8 codec driver is enabled for this mode and so too is the BCM2835
>>>>>> SoC driver. This forms a chain : bcm2835<=>IC<=>cs42xx8
>>>>>> where the IC is bit and frame master.
>>>>> Model your IC as a codec. No need to add patches to random drivers
>>>>> and add a flag with the rather meaningless semantics "someone else is
>>>>> automagically setting up clocks for me".
>>>>>
>>>>>
>>>> My last patch, used the two codec approach, however it was pointed out that
>>>> the
>>>> bcm2835 was run in DSP mode with a codec master (rather then IC master) and
>>>> that
>>>> the patch doesn't work. Which is clearly true and a problem, it can only
>>>> work with an
>>>> intermediate non-codec master.
>>>>
>>>> I think you summed it up well with your statement :
>>>>
>>>> On 25/02/17 Matthias Reichl wrote:
>>>> If the clock timing adheres to DSP mode A timing and you add code
>>>> to the the CPU DAI driver so it can operate in DSP mode A then
>>>> that should also work. If not, it's broken.
>>> Your bcm2835 patch doesn't configure the bcm2835 to DSP mode A,
>>> it's still setup for I2S (slave) mode. You are just adding code
>>> to pretend it's running in DSP mode A. Don't do that, it's wrong.
>>>
>>>> This patch set fixes the problem of a daisy chain of three possible masters
>>>> (CPU <=> IC <=> codec) where only the IC can be master. In fact, when retro
>>>> fitting DSP mode to old silicon, the CPU can specify which of the three can
>>>> be masters
>>>> and there is no chance that someone can fire the system up with the wrong
>>>> master
>>>> (which we know produces bit offset and random channel swapping when a codec
>>>> is
>>>> master).
>>> Please follow the advice I gave you about 3 weeks ago and model your
>>> setup properly.
>>>
>>> | So you have bcm2835 I2S <-> FPGA <-> codec - IOW a standard codec<->codec
>>> | link.
>>> |
>>> | What you seem to be missing is just a method to transfer your 8-channel
>>> | data via a 2-channel link - userspace want's to see an 8-channel PCM,
>>> | but the hardware link (bcm2835-i2s) is only 2-channel.
>>> |
>>> | And that's where IMO as userspace plugin looks like a very good solution.
>>> | It's basically the counterpart of your FPGA and contains the code that's
>>> | neccessary to encapsulate/pack/whatever the 8-channel data into a 2-channel
>>> | stream so it can then be unpacked to 8-channel by the FPGA.
>>> |
>>> | If you go this route your hardware and machine driver will work with
>>> | other I2S codecs as well, and IMO that's a far better solution than
>>> | adding very ugly hacks to a single I2S driver.
>>>
>>> If you add an active hardware component (your "IC"/FPGA) you also
>>> have to model that in software.
>>>
>>> If that component is acting as a clock master it probably has some
>>> method to setup clocks. Even if you don't have that, eg if you
>>> are running at some fixed rate you'll have to store that information
>>> somewhere.
>>>
>>> The place to do that is in a codec driver. In your setup it'll look
>>> like this:
>>>
>>> That "IC" codec has 2 DAIs and operates as a clock master on both.
>>> You link one DAI in I2S mode to the bcm2835 and the other DAI
>>> in DSP (or whatever mode you are using) to the cs42xx8.
>>>
>>> If you model it this way you no longer work against ALSA and
>>> you can stop adding hacks to existing drivers.
>>>
>>  From the beginning, I completely agree with you when you take the two
>> problems apart:
>> - for the timing problem : model properly the converter as a codec
>> - for the encapsulation problem : do the encapsulation / packing with a
>> userspace plugin
>>
>> But when you take the whole together, the plugin part seems completely
>> overcomplicated.
>> As the whole is properly modeled, if we could have a simple solution to
>> relax the channel numbers constraint on the I2S on the higher part of the
>> stack all will "magically" work with little effort/complexity.
>>
>> Otherwise, the user-space packer would have to do a lot of more than packing
>> :  interact with private machine driver controls to manage all the channels
>> and the machine driver will need to forward /translate some parts to
>> directly drive the final (cs42xx8) codec. An potentially if such hardware
>> continue to pop-up, each machine driver will need it's own user-space
>> counterpart.
> Quite on the contrary. You'd need to add the channel relaxing constraint
> to all existing I2S drivers to get this working. And I don't see a need
> to artificially restrict that to a specific codec (cs42xx8) and a specific
> number of channels. Why only 8 channels, why not 4 or 384?
>
> Doing it as an ALSA plugin makes it reusable with existing drivers and
> hardware.
>
> The idea behind these modular components (plugins, codecs, dais) is to
> create reusable components and you don't have to add identical code
> to all other drivers when you add some new functionality.
>
> Actually, if you add a new feature, you need to have very good reasons
> to restrict it to a specific driver or change all existing drivers.
> If you can implement that feature in a generic way without touching
> existing code it's often the better solution.
>
> Matt is trying to tunnel multichannel PCM over a 2-channel PCM link running
> at a higher samplerate. I've described a way how this is possible without
> modifying current code. There are certainly other, probably better,
> ways to do that. This was a first quick idea how it could be done and I
> still think it's not too bad.
>
> All the plugin has to do is expose a multi-channel PCM and configure the
> hw/backend PCM to 2 channels at a higher samplerate (all of which
> current drivers are already capable of). The plugin settings determine
> the number of channels, channel map, samplerate factor etc. That same
> plugin can also be used with other "unpacking codecs" and other channel
> numbers - you just need to change the plugin configuration in your alsa
> card conf and tell it you have 4 (or whatever) channels.
>
> If you need interaction with the backend codec (Matt's "IC"/FPGA) that
> does PCM unpacking to multichannel you can do that for example in the plugin
> or in the alsa card.conf via the hooks plugin and alsa controls.
>
>> Packing DSD in PCM (DoP) require zero kernel knowledge and could be fully
>> implemented in user-space as we don't change the number of channel
>> assumption of the data part of the format. But here, we simply want the DSP
>> A data semantic with the I2S hardware bus timing.
> Yes, and this is what Matt's codec (FPGA) is doing. It's creating that
> semantic, together with the machine driver and the plugin to set it all up.
>
Ok I'm convinced.

Thank you for your detailed explanation.

Emmanuel.

PS: 2nd try, sorry for the html email.