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.