[PATCH] ASoC: Document DAI signal polarity

[PATCH] ASoC: Document DAI signal polarity

[Anatol Pomozov]

Per discussion at [1] currently there is no clear definition of what is FSYNC polarity.
Different drivers use its own definition of what is "normal" and what is "inverted"
fsync in different modes. This leads to compatibility problems between drivers.

Explicitly specify meaning of BCLK/FSYNC polarity.

[1] http://mailman.alsa-project.org/pipermail/alsa-devel/2015-August/097121.html

Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com>
---
 include/sound/soc-dai.h | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/include/sound/soc-dai.h b/include/sound/soc-dai.h
index 2df96b1..c8170c4 100644
--- a/include/sound/soc-dai.h
+++ b/include/sound/soc-dai.h
@@ -48,10 +48,15 @@ struct snd_compr_stream;
 #define SND_SOC_DAIFMT_GATED		(0 << 4) /* clock is gated */
 
 /*
- * DAI hardware signal inversions.
+ * DAI hardware signal polarity.
  *
- * Specifies whether the DAI can also support inverted clocks for the specified
- * format.
+ * For BCLK:
+ *  - "normal" polarity means signal sensing happens at rising edge of BCLK
+ *  - "inverted" polarity means signal sensing happens at falling edge of BCLK
+ *
+ * For FSYNC:
+ *  - "normal" polarity means frame starts at rising edge of FSYNC
+ *  - "inverted" polarity means frame starts at falling edge of FSYNC
  */
 #define SND_SOC_DAIFMT_NB_NF		(0 << 8) /* normal bit clock + frame */
 #define SND_SOC_DAIFMT_NB_IF		(2 << 8) /* normal BCLK + inv FRM */
-- 
2.5.0.457.gab17608

Re: [PATCH] ASoC: Document DAI signal polarity

[Albert Chen]

Loop more

-----Original Message-----
From: Anatol Pomozov [mailto:anatol.pomozov@gmail.com] 
Sent: Tuesday, September 01, 2015 4:51 AM
To: alsa-devel@alsa-project.org
Cc: broonie@kernel.org; lars@metafoo.de; Albert Chen; liam.r.girdwood@linux.intel.com; Anatol Pomozov
Subject: [PATCH] ASoC: Document DAI signal polarity

Per discussion at [1] currently there is no clear definition of what is FSYNC polarity.
Different drivers use its own definition of what is "normal" and what is "inverted"
fsync in different modes. This leads to compatibility problems between drivers.

Explicitly specify meaning of BCLK/FSYNC polarity.

[1] http://mailman.alsa-project.org/pipermail/alsa-devel/2015-August/097121.html

Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com>
---
 include/sound/soc-dai.h | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/include/sound/soc-dai.h b/include/sound/soc-dai.h index 2df96b1..c8170c4 100644
--- a/include/sound/soc-dai.h
+++ b/include/sound/soc-dai.h
@@ -48,10 +48,15 @@ struct snd_compr_stream;
 #define SND_SOC_DAIFMT_GATED		(0 << 4) /* clock is gated */
 
 /*
- * DAI hardware signal inversions.
+ * DAI hardware signal polarity.
  *
- * Specifies whether the DAI can also support inverted clocks for the specified
- * format.
+ * For BCLK:
+ *  - "normal" polarity means signal sensing happens at rising edge of 
+ BCLK
+ *  - "inverted" polarity means signal sensing happens at falling edge 
+ of BCLK
+ *
+ * For FSYNC:
+ *  - "normal" polarity means frame starts at rising edge of FSYNC
+ *  - "inverted" polarity means frame starts at falling edge of FSYNC
  */
 #define SND_SOC_DAIFMT_NB_NF		(0 << 8) /* normal bit clock + frame */
 #define SND_SOC_DAIFMT_NB_IF		(2 << 8) /* normal BCLK + inv FRM */
--
2.5.0.457.gab17608


------Please consider the environment before printing this e-mail.

Re: [PATCH] ASoC: Document DAI signal polarity

[arnaud.mouiche]

So, this example is a "normal" FSYNC, "normal" BCLK, DSP-B mode, 16 
bits/sample, isn't it (just to have something visual).
regards,
arnaud

--+  +--+  +--+  +--+  +--+  +--+  +--+  +--
   |  |  |  |  |  |  |  |  |  |  |  |  |  |    ...
   +--+  +--+  +--+  +--+  +--+  +--+  +--+

               +-----+
               |     |
--------------+     +------------------------ ...

   | b1  | b0  | b15 | b14 | b13 | b12 | b11 | ...

--frame N-1--> <----- frame N ---------


Le 31/08/2015 22:50, Anatol Pomozov a écrit :
> Per discussion at [1] currently there is no clear definition of what is FSYNC polarity.
> Different drivers use its own definition of what is "normal" and what is "inverted"
> fsync in different modes. This leads to compatibility problems between drivers.
>
> Explicitly specify meaning of BCLK/FSYNC polarity.
>
> [1] http://mailman.alsa-project.org/pipermail/alsa-devel/2015-August/097121.html
>
> Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com>
> ---
>   include/sound/soc-dai.h | 11 ++++++++---
>   1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/include/sound/soc-dai.h b/include/sound/soc-dai.h
> index 2df96b1..c8170c4 100644
> --- a/include/sound/soc-dai.h
> +++ b/include/sound/soc-dai.h
> @@ -48,10 +48,15 @@ struct snd_compr_stream;
>   #define SND_SOC_DAIFMT_GATED		(0 << 4) /* clock is gated */
>   
>   /*
> - * DAI hardware signal inversions.
> + * DAI hardware signal polarity.
>    *
> - * Specifies whether the DAI can also support inverted clocks for the specified
> - * format.
> + * For BCLK:
> + *  - "normal" polarity means signal sensing happens at rising edge of BCLK
> + *  - "inverted" polarity means signal sensing happens at falling edge of BCLK
> + *
> + * For FSYNC:
> + *  - "normal" polarity means frame starts at rising edge of FSYNC
> + *  - "inverted" polarity means frame starts at falling edge of FSYNC
>    */
>   #define SND_SOC_DAIFMT_NB_NF		(0 << 8) /* normal bit clock + frame */
>   #define SND_SOC_DAIFMT_NB_IF		(2 << 8) /* normal BCLK + inv FRM */

Re: [PATCH] ASoC: Document DAI signal polarity

[Mark Brown]

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

On Mon, Aug 31, 2015 at 01:50:58PM -0700, Anatol Pomozov wrote:

> Per discussion at [1] currently there is no clear definition of what is FSYNC polarity.
> Different drivers use its own definition of what is "normal" and what is "inverted"
> fsync in different modes. This leads to compatibility problems between drivers.

Please keep changelogs wrapped at under 80 columns as is covered in
SubmittingPatches and please write free standing changelogs that don't
require reference to external discussions unless there is a strong
reason to do so.  This makes both the e-mails and the git changelogs
easier to read, ensuring that people don't need to go online to read
things and links don't go bad.

> + * For BCLK:
> + *  - "normal" polarity means signal sensing happens at rising edge of BCLK
> + *  - "inverted" polarity means signal sensing happens at falling edge of BCLK

This is OK, though it's more normal to say that data "is available" or
"is sampled" - the term "signal sensing" is a bit unusual.

> + * For FSYNC:
> + *  - "normal" polarity means frame starts at rising edge of FSYNC
> + *  - "inverted" polarity means frame starts at falling edge of FSYNC

This isn't true (or at least isn't clear) for I2S based modes, normally
the left channel is thought of as the first channel sent and the left
channel starts on the falling edge of LRCLK, not the rising edge (which
signals the start of the right frame).  It is true for DSP based modes.

It's probably going to be more sensible to define the modes and then
define inversion relative to the definition of the modes (which is
basically what the existing documentation is doing).  I think what we
really need here is an explicit definition of the DSP modes.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

Re: [PATCH] ASoC: Document DAI signal polarity

[Anatol Pomozov]

Hi

On Fri, Sep 18, 2015 at 6:54 AM, Mark Brown <broonie@kernel.org> wrote:
> On Mon, Aug 31, 2015 at 01:50:58PM -0700, Anatol Pomozov wrote:
>
>> Per discussion at [1] currently there is no clear definition of what is FSYNC polarity.
>> Different drivers use its own definition of what is "normal" and what is "inverted"
>> fsync in different modes. This leads to compatibility problems between drivers.
>
> Please keep changelogs wrapped at under 80 columns as is covered in
> SubmittingPatches and please write free standing changelogs that don't
> require reference to external discussions unless there is a strong
> reason to do so.  This makes both the e-mails and the git changelogs
> easier to read, ensuring that people don't need to go online to read
> things and links don't go bad.

I see that external links quite actively used by developers:
$ git log --grep Link

but no problem, I can inline info into the commit description.

>
>> + * For BCLK:
>> + *  - "normal" polarity means signal sensing happens at rising edge of BCLK
>> + *  - "inverted" polarity means signal sensing happens at falling edge of BCLK
>
> This is OK, though it's more normal to say that data "is available" or
> "is sampled" - the term "signal sensing" is a bit unusual.

Done.

>
>> + * For FSYNC:
>> + *  - "normal" polarity means frame starts at rising edge of FSYNC
>> + *  - "inverted" polarity means frame starts at falling edge of FSYNC
>
> This isn't true (or at least isn't clear) for I2S based modes, normally
> the left channel is thought of as the first channel sent and the left
> channel starts on the falling edge of LRCLK, not the rising edge (which
> signals the start of the right frame).

In the I2S docs/specs I found I2S format has frames like you described
- starts at falling edge, left channel first. Per description above
this will have "negative" FSYNC polarity.

The I2S docs do not define frame polarity. Polarity is purely Linux
driver thing and we can choose definition we want.

>  It is true for DSP based modes.
>
> It's probably going to be more sensible to define the modes and then
> define inversion relative to the definition of the modes (which is
> basically what the existing documentation is doing).  I think what we
> really need here is an explicit definition of the DSP modes.

The beauty of rule "positive polarity is when frame starts at rising
FSYNC edge" that it easily applicable to all formats (I2S and DSP-*).

Or you keep another definition of polarity in mind?

Re: [PATCH] ASoC: Document DAI signal polarity

[Mark Brown]

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

On Tue, Sep 29, 2015 at 02:34:33PM -0700, Anatol Pomozov wrote:
> On Fri, Sep 18, 2015 at 6:54 AM, Mark Brown <broonie@kernel.org> wrote:
> > On Mon, Aug 31, 2015 at 01:50:58PM -0700, Anatol Pomozov wrote:

> >> Per discussion at [1] currently there is no clear definition of what is FSYNC polarity.
> >> Different drivers use its own definition of what is "normal" and what is "inverted"
> >> fsync in different modes. This leads to compatibility problems between drivers.

> > Please keep changelogs wrapped at under 80 columns as is covered in
> > SubmittingPatches and please write free standing changelogs that don't
> > require reference to external discussions unless there is a strong
> > reason to do so.  This makes both the e-mails and the git changelogs
> > easier to read, ensuring that people don't need to go online to read
> > things and links don't go bad.

> I see that external links quite actively used by developers:
> $ git log --grep Link

> but no problem, I can inline info into the commit description.

Like I say there can be strong reasons to do this but this doesn't seem
to be one of them.

> >> + * For FSYNC:
> >> + *  - "normal" polarity means frame starts at rising edge of FSYNC
> >> + *  - "inverted" polarity means frame starts at falling edge of FSYNC

> > This isn't true (or at least isn't clear) for I2S based modes, normally
> > the left channel is thought of as the first channel sent and the left
> > channel starts on the falling edge of LRCLK, not the rising edge (which
> > signals the start of the right frame).

> In the I2S docs/specs I found I2S format has frames like you described
> - starts at falling edge, left channel first. Per description above
> this will have "negative" FSYNC polarity.

> The I2S docs do not define frame polarity. Polarity is purely Linux
> driver thing and we can choose definition we want.

I don't think that's true, the expectation is that a left/right sample
pair is time aligned so the left channel is definitely the start of
frame for all meaningful purposes.  It's certainly what I'd expect most
people to understand - choosing a counterintuitive definition to make
this one statement convenient is going to lead to constant confusion for
the mode which is clearest.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

Re: [PATCH] ASoC: Document DAI signal polarity

[Anatol Pomozov]

Hi

On Wed, Sep 30, 2015 at 11:10 AM, Mark Brown <broonie@kernel.org> wrote:
> I don't think that's true, the expectation is that a left/right sample
> pair is time aligned so the left channel is definitely the start of
> frame for all meaningful purposes.  It's certainly what I'd expect most
> people to understand - choosing a counterintuitive definition to make
> this one statement convenient is going to lead to constant confusion for
> the mode which is clearest.

To clarify, you propose following definition of normal FSYNC polarity:
 - for I2S/left/right justified - frame starts with falling FSYNC edge
 - for DSP A/B - frame starts with rising edge of FSYNC edge (plus offset)
 - for AC97 my guess it is the same as DSP - frame starts with rising
FSYNC edge.

Is it correct?

Re: [PATCH] ASoC: Document DAI signal polarity

[Benoît Thébaudeau]

Hi,

On Wed, Sep 30, 2015 at 9:08 PM, Anatol Pomozov
<anatol.pomozov@gmail.com> wrote:
> Hi
>
> On Wed, Sep 30, 2015 at 11:10 AM, Mark Brown <broonie@kernel.org> wrote:
>> I don't think that's true, the expectation is that a left/right sample
>> pair is time aligned so the left channel is definitely the start of
>> frame for all meaningful purposes.  It's certainly what I'd expect most
>> people to understand - choosing a counterintuitive definition to make
>> this one statement convenient is going to lead to constant confusion for
>> the mode which is clearest.
>
> To clarify, you propose following definition of normal FSYNC polarity:
>  - for I2S/left/right justified - frame starts with falling FSYNC edge
>  - for DSP A/B - frame starts with rising edge of FSYNC edge (plus offset)
>  - for AC97 my guess it is the same as DSP - frame starts with rising
> FSYNC edge.
>
> Is it correct?

Most CODEC datasheets describe the regular left/right justified
formats as having the left channel starting on the rising edge of
FSYNC, like for DSP A/B and AC'97. I²S is the only exception here.

Best regards,
Benoît
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH] ASoC: Document DAI signal polarity

[Mark Brown]

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

On Wed, Sep 30, 2015 at 12:08:20PM -0700, Anatol Pomozov wrote:

> To clarify, you propose following definition of normal FSYNC polarity:
>  - for I2S/left/right justified - frame starts with falling FSYNC edge
>  - for DSP A/B - frame starts with rising edge of FSYNC edge (plus offset)

Yes.

>  - for AC97 my guess it is the same as DSP - frame starts with rising
> FSYNC edge.

For AC'97 we don't support any kind of non-standard framing and would
push back strongly against anyone who wants it but I guess yes.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

Re: [PATCH] ASoC: Document DAI signal polarity

[Lars-Peter Clausen]

On 09/30/2015 09:08 PM, Anatol Pomozov wrote:
>  - for I2S/left/right justified - frame starts with falling FSYNC edge

This is what most drivers implement:

I2S: Left channel starts with the falling edge, right channel starts with
the rising edge (data is delayed by one clock cycle)

Right/Left justified: Left channel starts with the rising edge, right
channel starts with the falling edge

DSP A/B: Frame starts with the rising edge. Channels are spaced by the
configured slot width (e.g. first channel at offset 0, second channel at
offset 16, third channel at offset 32, ...). If the slot with has not been
configured explicitly using the set_tdm_slots() API the slot with is the
number of bits in one single-channel sample (Return value of params_width()).

When using I2S or left/right justified in TDM mode channels are also spaced
by the configured slot width and the second edge should be ignored.

Re: [PATCH] ASoC: Document DAI signal polarity

[Mark Brown]

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

On Wed, Sep 30, 2015 at 09:22:18PM +0200, Benoît Thébaudeau wrote:

> Most CODEC datasheets describe the regular left/right justified
> formats as having the left channel starting on the rising edge of
> FSYNC, like for DSP A/B and AC'97. I²S is the only exception here.

Interesting, yes - I just did a quick survey of ones I have and that
does seem to be the case for the random selection I picked.  I have to
say I've never paid very much attention to those modes since they are so
rarely used (a quick survey of machine drivers suggests zero actual
users in mainline unless there's some DT selecting them).

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[PATCH] ASoC: Document DAI signal polarity

[Anatol Pomozov]

Currently there is no clear definition of what is FSYNC polarity.
Different drivers use its own definition of what is "normal" and what is
"inverted" fsync. This leads to compatibility problems between drivers.

For example TegraX1 driver assumes that DSP-A format with frames
starting at rising FSYNC edge has "negative" polarity,
while RT5677 assumes it is "positive" polarity.

Explicitly specify meaning of BCLK/FSYNC polarity to avoid future
compatibility problems.

Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com>
---
 include/sound/soc-dai.h | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/include/sound/soc-dai.h b/include/sound/soc-dai.h
index 2df96b1..45198db 100644
--- a/include/sound/soc-dai.h
+++ b/include/sound/soc-dai.h
@@ -48,10 +48,22 @@ struct snd_compr_stream;
 #define SND_SOC_DAIFMT_GATED		(0 << 4) /* clock is gated */
 
 /*
- * DAI hardware signal inversions.
+ * DAI hardware signal polarity.
  *
- * Specifies whether the DAI can also support inverted clocks for the specified
- * format.
+ * BCLK:
+ * - "normal" polarity means signal is available at rising edge of BCLK
+ * - "inverted" polarity means signal is available at falling edge of BCLK
+ *
+ * FSYNC "normal" polarity depends on the frame format:
+ * - I2S: frame consists of left then right channel data. Left channel starts
+ *      with falling FSYNC edge, right channel starts with rising FSYNC edge.
+ * - I2S right/left justified: frame consists of left then right channel data.
+ *      Left channel starts with rising FSYNC edge, right channel starts with
+ *      falling FSYNC edge.
+ * - DSP A/B: Frame starts with rising FSYNC edge.
+ * - AC97: Frame starts with rising FSYNC edge.
+ *
+ * "Negative" FSYNC polarity is the one opposite of "normal" polarity.
  */
 #define SND_SOC_DAIFMT_NB_NF		(0 << 8) /* normal bit clock + frame */
 #define SND_SOC_DAIFMT_NB_IF		(2 << 8) /* normal BCLK + inv FRM */
-- 
2.6.0.rc2.230.g3dd15c0

Re: [PATCH] ASoC: Document DAI signal polarity

[Benoît Thébaudeau]

Dear Anatol Pomozov,

On Thu, Oct 1, 2015 at 8:09 PM, Anatol Pomozov <anatol.pomozov@gmail.com> wrote:
> Currently there is no clear definition of what is FSYNC polarity.
> Different drivers use its own definition of what is "normal" and what is
> "inverted" fsync. This leads to compatibility problems between drivers.
>
> For example TegraX1 driver assumes that DSP-A format with frames
> starting at rising FSYNC edge has "negative" polarity,
> while RT5677 assumes it is "positive" polarity.

This wording is confusing. "Normal"/"inverted" are more appropriate
than "positive"/"negative" here, because the latter would refer to the
falling/rising edges, not to the regular polarity as the former.

> Explicitly specify meaning of BCLK/FSYNC polarity to avoid future
> compatibility problems.
>
> Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com>
> ---
>  include/sound/soc-dai.h | 18 +++++++++++++++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/include/sound/soc-dai.h b/include/sound/soc-dai.h
> index 2df96b1..45198db 100644
> --- a/include/sound/soc-dai.h
> +++ b/include/sound/soc-dai.h
> @@ -48,10 +48,22 @@ struct snd_compr_stream;
>  #define SND_SOC_DAIFMT_GATED           (0 << 4) /* clock is gated */
>
>  /*
> - * DAI hardware signal inversions.
> + * DAI hardware signal polarity.
>   *
> - * Specifies whether the DAI can also support inverted clocks for the specified
> - * format.

Please keep this sentence or rephrase it, but do not remove it: it
clarifies "normal" as meaning the default for the specified format
(I²S, L/R-justified, DSP A/B, AC'97, PDM).

> + * BCLK:
> + * - "normal" polarity means signal is available at rising edge of BCLK
> + * - "inverted" polarity means signal is available at falling edge of BCLK
> + *
> + * FSYNC "normal" polarity depends on the frame format:
> + * - I2S: frame consists of left then right channel data. Left channel starts
> + *      with falling FSYNC edge, right channel starts with rising FSYNC edge.
> + * - I2S right/left justified: frame consists of left then right channel data.

The L/R-justified formats are independent of I²S, so "I2S" should be
removed from this line.

> + *      Left channel starts with rising FSYNC edge, right channel starts with
> + *      falling FSYNC edge.
> + * - DSP A/B: Frame starts with rising FSYNC edge.
> + * - AC97: Frame starts with rising FSYNC edge.
> + *
> + * "Negative" FSYNC polarity is the one opposite of "normal" polarity.
>   */
>  #define SND_SOC_DAIFMT_NB_NF           (0 << 8) /* normal bit clock + frame */
>  #define SND_SOC_DAIFMT_NB_IF           (2 << 8) /* normal BCLK + inv FRM */
> --
> 2.6.0.rc2.230.g3dd15c0
>

Best regards,
Benoît
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

[PATCH] ASoC: Document DAI signal polarity

[Anatol Pomozov]

Currently there is no clear definition of what FSYNC polarity is.
Different drivers use its own definition of what is "normal" and what is
"inverted" fsync. This leads to compatibility problems between drivers.

For example TegraX1 driver assumes that DSP-A format with frames
starting at rising FSYNC edge has "inverted" polarity,
while RT5677 assumes it is "normal" polarity.

Explicitly specify meaning of BCLK/FSYNC polarity to avoid future
compatibility problems.

Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com>
---
 include/sound/soc-dai.h | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/include/sound/soc-dai.h b/include/sound/soc-dai.h
index 2df96b1..91e2e61 100644
--- a/include/sound/soc-dai.h
+++ b/include/sound/soc-dai.h
@@ -48,10 +48,25 @@ struct snd_compr_stream;
 #define SND_SOC_DAIFMT_GATED		(0 << 4) /* clock is gated */
 
 /*
- * DAI hardware signal inversions.
+ * DAI hardware signal polarity.
  *
  * Specifies whether the DAI can also support inverted clocks for the specified
  * format.
+ *
+ * BCLK:
+ * - "normal" polarity means signal is available at rising edge of BCLK
+ * - "inverted" polarity means signal is available at falling edge of BCLK
+ *
+ * FSYNC "normal" polarity depends on the frame format:
+ * - I2S: frame consists of left then right channel data. Left channel starts
+ *      with falling FSYNC edge, right channel starts with rising FSYNC edge.
+ * - Left/Right Justified: frame consists of left then right channel data.
+ *      Left channel starts with rising FSYNC edge, right channel starts with
+ *      falling FSYNC edge.
+ * - DSP A/B: Frame starts with rising FSYNC edge.
+ * - AC97: Frame starts with rising FSYNC edge.
+ *
+ * "Negative" FSYNC polarity is the one opposite of "normal" polarity.
  */
 #define SND_SOC_DAIFMT_NB_NF		(0 << 8) /* normal bit clock + frame */
 #define SND_SOC_DAIFMT_NB_IF		(2 << 8) /* normal BCLK + inv FRM */
-- 
2.6.0.rc2.230.g3dd15c0

Re: [PATCH] ASoC: Document DAI signal polarity

[Benoît Thébaudeau]

Dear Anatol Pomozov,

On Fri, Oct 2, 2015 at 5:33 PM, Anatol Pomozov <anatol.pomozov@gmail.com> wrote:
> Currently there is no clear definition of what FSYNC polarity is.
> Different drivers use its own definition of what is "normal" and what is
> "inverted" fsync. This leads to compatibility problems between drivers.
>
> For example TegraX1 driver assumes that DSP-A format with frames
> starting at rising FSYNC edge has "inverted" polarity,
> while RT5677 assumes it is "normal" polarity.
>
> Explicitly specify meaning of BCLK/FSYNC polarity to avoid future
> compatibility problems.
>
> Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com>
> ---
>  include/sound/soc-dai.h | 17 ++++++++++++++++-
>  1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/include/sound/soc-dai.h b/include/sound/soc-dai.h
> index 2df96b1..91e2e61 100644
> --- a/include/sound/soc-dai.h
> +++ b/include/sound/soc-dai.h
> @@ -48,10 +48,25 @@ struct snd_compr_stream;
>  #define SND_SOC_DAIFMT_GATED           (0 << 4) /* clock is gated */
>
>  /*
> - * DAI hardware signal inversions.
> + * DAI hardware signal polarity.
>   *
>   * Specifies whether the DAI can also support inverted clocks for the specified
>   * format.
> + *
> + * BCLK:
> + * - "normal" polarity means signal is available at rising edge of BCLK
> + * - "inverted" polarity means signal is available at falling edge of BCLK
> + *
> + * FSYNC "normal" polarity depends on the frame format:
> + * - I2S: frame consists of left then right channel data. Left channel starts
> + *      with falling FSYNC edge, right channel starts with rising FSYNC edge.
> + * - Left/Right Justified: frame consists of left then right channel data.
> + *      Left channel starts with rising FSYNC edge, right channel starts with
> + *      falling FSYNC edge.
> + * - DSP A/B: Frame starts with rising FSYNC edge.
> + * - AC97: Frame starts with rising FSYNC edge.
> + *
> + * "Negative" FSYNC polarity is the one opposite of "normal" polarity.
>   */
>  #define SND_SOC_DAIFMT_NB_NF           (0 << 8) /* normal bit clock + frame */
>  #define SND_SOC_DAIFMT_NB_IF           (2 << 8) /* normal BCLK + inv FRM */
> --
> 2.6.0.rc2.230.g3dd15c0
>

Reviewed-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>

Best regards,
Benoît
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH] ASoC: Document DAI signal polarity

[Mark Brown]

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

On Thu, Oct 01, 2015 at 11:09:19AM -0700, Anatol Pomozov wrote:

> + * - I2S right/left justified: frame consists of left then right channel data.
> + *      Left channel starts with rising FSYNC edge, right channel starts with
> + *      falling FSYNC edge.

These are just called left and right justified - they do look a lot like
I2S but I2S isn't part of the name in normal usage so it's a little
confusing.

Also it's more normal when talking about both left and right to list
left first, it scans better.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

Re: [PATCH] ASoC: Document DAI signal polarity

[Benoît Thébaudeau]

Dear Mark Brown,

On Mon, Oct 5, 2015 at 5:12 PM, Mark Brown <broonie@kernel.org> wrote:
> On Thu, Oct 01, 2015 at 11:09:19AM -0700, Anatol Pomozov wrote:
>
>> + * - I2S right/left justified: frame consists of left then right channel data.
>> + *      Left channel starts with rising FSYNC edge, right channel starts with
>> + *      falling FSYNC edge.
>
> These are just called left and right justified - they do look a lot like
> I2S but I2S isn't part of the name in normal usage so it's a little
> confusing.
>
> Also it's more normal when talking about both left and right to list
> left first, it scans better.

This has already been addressed in the v2 here (you were Cc'ed):
http://mailman.alsa-project.org/pipermail/alsa-devel/2015-October/098307.html

Best regards,
Benoît
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH] ASoC: Document DAI signal polarity

[Mark Brown]

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

On Mon, Oct 05, 2015 at 09:20:05PM +0200, Benoît Thébaudeau wrote:

> > Also it's more normal when talking about both left and right to list
> > left first, it scans better.

> This has already been addressed in the v2 here (you were Cc'ed):
> http://mailman.alsa-project.org/pipermail/alsa-devel/2015-October/098307.html

That's the only version I had in my inbox.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[PATCH] ASoC: Document DAI signal polarity

[Anatol Pomozov]

Currently there is no clear definition of what FSYNC polarity is.
Different drivers use its own definition of what is "normal" and what is
"inverted" fsync. This leads to compatibility problems between drivers.

For example TegraX1 driver assumes that DSP-A format with frames
starting at rising FSYNC edge has "inverted" polarity,
while RT5677 assumes it is "normal" polarity.

Explicitly specify meaning of BCLK/FSYNC polarity to avoid future
compatibility problems.

Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com>
---
 include/sound/soc-dai.h | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/include/sound/soc-dai.h b/include/sound/soc-dai.h
index 2df96b1..91e2e61 100644
--- a/include/sound/soc-dai.h
+++ b/include/sound/soc-dai.h
@@ -48,10 +48,25 @@ struct snd_compr_stream;
 #define SND_SOC_DAIFMT_GATED		(0 << 4) /* clock is gated */
 
 /*
- * DAI hardware signal inversions.
+ * DAI hardware signal polarity.
  *
  * Specifies whether the DAI can also support inverted clocks for the specified
  * format.
+ *
+ * BCLK:
+ * - "normal" polarity means signal is available at rising edge of BCLK
+ * - "inverted" polarity means signal is available at falling edge of BCLK
+ *
+ * FSYNC "normal" polarity depends on the frame format:
+ * - I2S: frame consists of left then right channel data. Left channel starts
+ *      with falling FSYNC edge, right channel starts with rising FSYNC edge.
+ * - Left/Right Justified: frame consists of left then right channel data.
+ *      Left channel starts with rising FSYNC edge, right channel starts with
+ *      falling FSYNC edge.
+ * - DSP A/B: Frame starts with rising FSYNC edge.
+ * - AC97: Frame starts with rising FSYNC edge.
+ *
+ * "Negative" FSYNC polarity is the one opposite of "normal" polarity.
  */
 #define SND_SOC_DAIFMT_NB_NF		(0 << 8) /* normal bit clock + frame */
 #define SND_SOC_DAIFMT_NB_IF		(2 << 8) /* normal BCLK + inv FRM */
-- 
2.6.0.rc2.230.g3dd15c0