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] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 12 Feb 2014 11:10:33 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Lars-Peter Clausen <lars@...afoo.de>
Cc:	Xiubo Li <Li.Xiubo@...escale.com>, lgirdwood@...il.com,
	alsa-devel@...a-project.org, kuninori.morimoto.gx@...esas.com,
	tiwai@...e.de, linux-kernel@...r.kernel.org
Subject: Re: [alsa-devel] [PATCH v2 1/3] ASoC: binding: add tdm-slot.txt

On Wed, Feb 12, 2014 at 10:26:52AM +0100, Lars-Peter Clausen wrote:

> The current internal API for TDM is very poor, I don't think we want
> to expose that 1 to 1 to the devicetree. Since this means we'd have
> to support that forever. The first thing is that the semantics of
> snd_soc_dai_set_tdm_slot() are very unclear. E.g. some drivers use a
> zero bit for a active slot, some drivers use a 1 bit for a active

Yes, and if we do end up using masks we need to nail down what's going
on in the DT.

> slot. The second thing is that we are not able to specify which
> channel should be mapped to which slot. You can merely specify
> from/to which slots the CODEC should read/write and then it is up to
> the driver to guess which channel should go to which slot. In my
> opinion a binding that allows to specify a explicit mapping of which
> channel goes to which slot would be much better.

It'd certainly be good to be able to do that, though having a default
would make life easier.

> Also those are four different settings. In my opinion they should
> not be expressed in one property, but rather in four. E.g.
> specifying a tx_mask for a rx only device does not make much sense.

That makes sense.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ