| Message ID | 1441054258-33200-1-git-send-email-anatol.pomozov@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 */
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.
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?
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.
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?
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
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.
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.
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).
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 */
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(-)