Re: [PATCH v5] ASoC: cs53l30: Add support for Cirrus Logic CS53L30

[Mark Brown <broonie@kernel.org>]

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

On Sun, Jun 05, 2016 at 09:48:36AM -0700, Caleb Crome wrote:
> On Thu, Jun 2, 2016 at 11:40 AM, Mark Brown <broonie@kernel.org> wrote:

> > TDM, at least in the sense Linux is using it, is multiple *unrelated*
> > audio streams on a single wire.  Any multi-channel audio stream is TDM
> > in some sense but the trivial extension to add two or more channels

>    Thanks for taking the time to describe this to me.  This definitely
> comes as a surprise to me.  I assumed that TDM mode simply means
> multi-channels on a single wire (which is what it means in all the
> datasheets).

It *really* depends on the datasheets you're looking at.  Things that
are doing generic programmable serial ports might have no concept of
channels and inflexible devices which just support configurable numbers
of channels are just as likely to refer to DSP mode or whatever as
anything else.

> Just so I have this straight, TDM in the linux sense is putting say,
> 6-channels on one wire where the channels are from logically different
> places? i.e. chanels 0-1 are from bluetooth, 2-3 from analog in, and
> 4-5 from somewhere else?

You also need some separation of devices for us to actually care - if
none of the hardware can tell this is going on it's not meaningfully
TDM.

> As far as I can see he's not trying to define *unrelated* streams in
> TDM mode, but very related streams, which is TDM in the
> datasheet-sense.  And there not only needs to be a mechanism of
> choosing the dual I2S mode, but also which TDM slots to drop the data
> in (which I think already exists, right?)

Yes.

> >> 'channels_max > 2'?  I was always under the assumption that's what TDM
> >> meant.

> > We don't particularly call it anything, it's such a trivial extension.

> That's not been my experience :-) Getting 16 channels onto a wire has
> been anything but trivial because of the lack of SoC driver support
> for it.  Perhaps I'm just using the wrong SoCs.

Yes, you're using the wrong SoCs - anything with a programmable serial
port should cope fine.

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

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