Re: [PATCH] ASoC: docs: add clocking examples for DAI formats

Re: [PATCH] ASoC: docs: add clocking examples for DAI formats

[Peter Rosin]

Mark Brown wrote:
> On Mon, Apr 18, 2016 at 11:39:50AM +0200, Peter Rosin wrote:
> 
> > +I2S
> > + .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-.
> > +-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-
> 
> There is an actual spec for I2S which is going to be clearer than ASCII
> art:
> 
>    https://www.sparkfun.com/datasheets/BreakoutBoards/I2SBUS.pdf
> 
> is the first hit on google (there's a bunch of electrical stuff in there
> that gets roundly ignord these days but the clocking stuff is in there).

Yes, but where are the equivalent docs for the other formats?

> In general I'd rather have some words rather than just pictures, ASCII
> art as the only thing is pretty hard to read.

I'll post a v2 with some words about each format. Or will you reject
anything with ASCII art?

Cheers,
Peter

Re: [PATCH] ASoC: docs: add clocking examples for DAI formats

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 891 bytes --]

On Mon, Apr 18, 2016 at 12:55:23PM +0000, Peter Rosin wrote:
> Mark Brown wrote:

> > There is an actual spec for I2S which is going to be clearer than ASCII
> > art:

> >    https://www.sparkfun.com/datasheets/BreakoutBoards/I2SBUS.pdf

> > is the first hit on google (there's a bunch of electrical stuff in there
> > that gets roundly ignord these days but the clocking stuff is in there).

> Yes, but where are the equivalent docs for the other formats?

There aren't any (beyond the usual references to the Wolfson datasheets
which I'd suggest should be in here) but that doesn't mean we should
ignore this spec when we have it.

> > In general I'd rather have some words rather than just pictures, ASCII
> > art as the only thing is pretty hard to read.

> I'll post a v2 with some words about each format. Or will you reject
> anything with ASCII art?

So long as it's comprehensible.

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

SV: [PATCH] ASoC: docs: add clocking examples for DAI formats

[Peter Rosin]

Mark Brown wrote:
> On Mon, Apr 18, 2016 at 12:55:23PM +0000, Peter Rosin wrote:
> > Mark Brown wrote:
> 
> > > There is an actual spec for I2S which is going to be clearer than ASCII
> > > art:
> 
> > >    https://www.sparkfun.com/datasheets/BreakoutBoards/I2SBUS.pdf
> 
> > > is the first hit on google (there's a bunch of electrical stuff in there
> > > that gets roundly ignord these days but the clocking stuff is in there).
> 
> > Yes, but where are the equivalent docs for the other formats?
> 
> There aren't any (beyond the usual references to the Wolfson datasheets
> which I'd suggest should be in here) but that doesn't mean we should
> ignore this spec when we have it.

This is exactly the problem. For an outsider, it's impossible to know that
wolfson has the correct definition of the modes. Why should wolfson datasheets
trumph nxp or ti datasheets (or whatever), if there is an inconsistency?

We need to specify somewhere exactly what Linux means with the different
modes. Because there are bugs in this area, where DAIs claim to support
the same format but are not actually compatible. Which one is buggy then?
And this is not about flank timings or such details, it's about what bits go
where in relation to flanks etc.

> > > In general I'd rather have some words rather than just pictures, ASCII
> > > art as the only thing is pretty hard to read.
> 
> > I'll post a v2 with some words about each format. Or will you reject
> > anything with ASCII art?
> 
> So long as it's comprehensible.

Ok

Cheers,
Peter

Re: SV: [PATCH] ASoC: docs: add clocking examples for DAI formats

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 671 bytes --]

On Mon, Apr 18, 2016 at 01:18:47PM +0000, Peter Rosin wrote:
> Mark Brown wrote:

> > 
> > There aren't any (beyond the usual references to the Wolfson datasheets
> > which I'd suggest should be in here) but that doesn't mean we should
> > ignore this spec when we have it.

> This is exactly the problem. For an outsider, it's impossible to know that
> wolfson has the correct definition of the modes. Why should wolfson datasheets
> trumph nxp or ti datasheets (or whatever), if there is an inconsistency?

I'm not quite sure what your concern is here?  I'm saying that where
there are specs we should link to them.  I'm not saying we can't add
to that.

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