From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jean-Francois Moine Subject: Re: [alsa-devel] [PATCH v2 3/3] ASoC: add generic dt-card support Date: Sat, 24 Jan 2015 08:30:27 +0100 Message-ID: <20150124083027.3b3a018f@armhf> References: <54C0088F.9070609@metafoo.de> <20150122090723.50ac0156@armhf> <54C14EB3.8080305@metafoo.de> <20150123131554.623003f9@armhf> <54C252F4.9000504@metafoo.de> <20150123193456.276ea512@armhf> <20150123191343.GW21293@sirena.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20150123191343.GW21293@sirena.org.uk> Sender: linux-kernel-owner@vger.kernel.org To: Mark Brown Cc: Lars-Peter Clausen , Kuninori Morimoto , devicetree@vger.kernel.org, alsa-devel@alsa-project.org, Russell King - ARM Linux , linux-kernel@vger.kernel.org, Jyri Sarha List-Id: devicetree@vger.kernel.org On Fri, 23 Jan 2015 19:13:43 +0000 Mark Brown wrote: > On Fri, Jan 23, 2015 at 07:34:56PM +0100, Jean-Francois Moine wrote: >=20 > > A card builder is a device which > > - scans the graph of ports, > > - fills the struct snd_soc_card according to the links between the > > ports and their properties, > > - and, eventually, calls snd_soc_register_card(). >=20 > > 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 n= ot > > appear in the DT. Its creation is done by an audio controller. >=20 > Which audio controller? There may be several CPU side audio interfac= es > 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 DM= ICs > and so on, which results in a relatively large number of CPU interfac= es. 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. > > > > With a DT graph, each CPU/CODEC would know exactly the widgets = and > > > > routes it has to define. >=20 > > > Which widgets/routes do you mean? >=20 > > Well, forget about this. I never clearly understood why some widget= s > > and routes had to be defined at card level. >=20 > Please do try to understand the idea of representing simple component= s > 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. > > > I'd agree if this was some kind of kernel internal stuff, but thi= s is=20 > > > creating ABI and we have to maintain it forever. Rushing this in = without=20 > > > proper discussion and consideration of the more complex use-cases= is in my=20 > > > opinion not a good idea. >=20 > > Using a graph of port to describe the audio subsystem has been push= ed > > forwards by many people for a long time, as shown by the creation o= f > > the document Documentation/devicetree/bindings/graph.txt. >=20 > That DT binding was done entirely in the context of video application= s > IIRC, this is the first time it's been discussed in this context. http://mailman.alsa-project.org/pipermail/alsa-devel/2014-January/07062= 2.html http://mailman.alsa-project.org/pipermail/alsa-devel/2015-January/08627= 3.html --=20 Ken ar c'henta=C3=B1 | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/