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]
Message-ID: <20130723170407.GI9858@sirena.org.uk>
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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ