[alsa-devel] [PATCH] ASoC: Document DAI signal polarity

[Mark Brown]

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 at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20150930/1569ecaf/attachment.sig>