linux-kernel - Re: [alsa-devel] [PATCH v3] ARM: kirkwood: extend the kirkwood i2s driver for DT usage

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:	Tue, 23 Jul 2013 18:04:07 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
	Jean-Francois Moine <moinejf@...e.fr>,
	alsa-devel@...a-project.org, Takashi Iwai <tiwai@...e.de>,
	linux-kernel@...r.kernel.org, Liam Girdwood <lgirdwood@...il.com>,
	Rob Herring <rob.herring@...xeda.com>,
	devicetree-discuss@...r.kernel.org
Subject: Re: [alsa-devel] [PATCH v3] ARM: kirkwood: extend the kirkwood i2s
 driver for DT usage

On Tue, Jul 23, 2013 at 02:50:00PM +0100, Russell King - ARM Linux wrote:

> Not only that, but the lack of assistance from ASoC people on the
> multiple substream stuff really doesn't help one iota when it comes to
> making forward progress with SPDIF support.  I've explained to them the

It'd probably help if the people looking at this hardware started to
contribute some of the work that's being done here; this should help
move things forward by looking at concrete code rather than the very
general discussion that's happening at the minute.

> problem (SPDIF and I2S if used together must be enabled simultaneously
> or only one is permitted at any one time); they've suggested using the
> multiple PCM substream support, and then it's a case that "oh it's
> undocumented" "oh there's no examples yet".

As previously mentioned the OMAP4 and Qualcomm stuff is there, it's just
out of tree - there's also Haswell but I'm not sure if that's been made
public yet (Liam?).

> And then there's the problem of understanding the ASoC DAPM stuff
> "oh it's just a graph walk, you don't need to know the internals"
> is what I get from ASoC people.  Well, yes I do need to know the
> internals, so I can find out whether it's going to startup a second
> substream while a first one is active, and end up with SPDIF enabled
> non-concurrently with I2S.

As ever the answer is that DAPM will enable any connected audio path and
not enable other ones so it is possible to enable only one of multiple
paths (as you'd expect, really).

Can you be more specific about the problems you're having following the
code?  It should be relatively simple to trace through what's going on
from dapm_power_widgets()...

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