linux-kernel - Re: [PATCH] ASoC: atmel_ssc_dai: note buggy I2S support when the codec masters LRCLK

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 13 May 2016 12:42:32 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Peter Rosin <peda@...ntia.se>
Cc:	Nicolas Ferre <nicolas.ferre@...el.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.de>,
	alsa-devel@...a-project.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ASoC: atmel_ssc_dai: note buggy I2S support when the
 codec masters LRCLK

On Wed, Apr 27, 2016 at 11:29:53PM +0200, Peter Rosin wrote:
> On 2016-04-27 18:23, Mark Brown wrote:

> > Almost every programmable serial port does this, it's a very common
> > issue which is why we always try to go for exact clocking where we can -
> > it greatly improves the interoperability for I2S if there are no dead
> > clocks.

> Someone said: be conservative in what you send, be liberal in what you
> accept. This is not that at all. This is more like: be conservative in
> what you send, and accept only a subset of valid input.

> It absolutely kills interoperability if you claim I2S and then don't
> do I2S. If you are not looking at both edges of LRCLK it simply isn't I2S.
> It's something else. Like "packed I2S" or "DSP moda A with inverted
> symmetric LRCLK" or something, so why not invent a way to say that?

The reason people do this is so that they can interface I2S only CODECs
(which are reasonably common, especially simpler CODECs with no register
map) with SoCs that have programmable serial ports.  If you want to
spend the time to represent this explicitly through the system that
would be useful but note that the main reason the format configuration
is currently done manually is that especially with older devices it is
common for there to be gotchas in this, either in terms of things like
this or in terms of performance.  Determining what should master the bus
is an especially thorny issue, there are frequently tradeoffs between
the quality of the clocks and other restrictions.

> I have this codec which does I2S but there is no way to get rid of dead
> clocks when it masters the clocks. It can divide MCLK with 1,2,4,8 or 16
> to get a BCLK, or it can generate BCLK as 48x or 64x LRCLK. But it only
> sports 16 bits per sample.

In order to make that interoperate you should declare support for 24 and
32 bit formats in the DAI formats and set sig_bits to 16.  The
representation of memory formats in the DAIs that don't interface with
memory was a really unfortunate choice which sadly nobody has ever had
the time and/or enthusiasm to address.

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)