linux-kernel - Re: [alsa-devel] [PATCH v2 3/3] ASoC: add generic dt-card support

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, 3 Feb 2015 16:47:48 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Jean-Francois Moine <moinejf@...e.fr>
Cc:	Lars-Peter Clausen <lars@...afoo.de>,
	Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
	devicetree@...r.kernel.org, alsa-devel@...a-project.org,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	linux-kernel@...r.kernel.org, Jyri Sarha <jsarha@...com>
Subject: Re: [alsa-devel] [PATCH v2 3/3] ASoC: add generic dt-card support

On Sat, Jan 24, 2015 at 08:30:27AM +0100, Jean-Francois Moine wrote:
> Mark Brown <broonie@...nel.org> wrote:
> > On Fri, Jan 23, 2015 at 07:34:56PM +0100, Jean-Francois Moine wrote:

> > > The simple card builder, 'dt-card' (maybe a better name would have been
> > > 'graph-card'), acts just like the simple-card except that it does not
> > > appear in the DT. Its creation is done by an audio controller.

> > Which audio controller?  There may be several CPU side audio interfaces
> > in the same card.  For example people often want to have both low
> > latency and high latency audio paths from the CPU into the hardware (low
> > latency tends to increase power burn).  SoC centric system designs do
> > sometimes also have PDM I/O, expecting to be directly connected to DMICs
> > and so on, which results in a relatively large number of CPU interfaces.

> The audio controller which creates the card depends on the complexity
> of the card. When there are many controllers, it is up to the designer
> to define either a master audio controller or to instantiate a 'card'
> device via the DT for doing the job.

So how does the simple controller interact with a more complex one given
that it's somehow picking some controller node to start from?

> > > Well, forget about this. I never clearly understood why some widgets
> > > and routes had to be defined at card level.

> > Please do try to understand the idea of representing simple components
> > on the board and analogue interconects between devices - it's really
> > important and not something that can be neglected.

> The problem is that this understanding would stay abstract: I have no
> such a hardware. Anyway, if the representation can be done with the
> simple-card, it may also be done with a graph of ports.

If you have a device with any sort of speaker or microphone, or any sort
of external connector for interfacing with an external device like a
headphone jack, then you have something that could be a widget.

> > That DT binding was done entirely in the context of video applications
> > IIRC, this is the first time it's been discussed in this context.

> http://mailman.alsa-project.org/pipermail/alsa-devel/2014-January/070622.html
> http://mailman.alsa-project.org/pipermail/alsa-devel/2015-January/086273.html

So there's been some in passing mentions, not really serious discussion
though...

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