From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 029F7268 for ; Tue, 20 Oct 2015 15:47:27 +0000 (UTC) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 792B8124 for ; Tue, 20 Oct 2015 15:47:26 +0000 (UTC) Date: Tue, 20 Oct 2015 17:47:24 +0200 Message-ID: From: Takashi Iwai To: Mauro Carvalho Chehab In-Reply-To: <20151020131816.1210dbf5@recife.lan> References: <20151012190137.GA1992@thunk.org> <20151019103304.27e596a5@recife.lan> <20151019135348.GH14956@sirena.org.uk> <1445272076.2481.37.camel@loki> <20151019173419.042d5e8b@recife.lan> <1445342137.7033.41.camel@loki> <20151020131816.1210dbf5@recife.lan> MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Liam Girdwood , Lars-Peter Clausen , ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] Draft agenda for the kernel summit List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tue, 20 Oct 2015 17:18:16 +0200, Mauro Carvalho Chehab wrote: > > Looks nice. Fwiw, the graph will probably get a lot bigger when we show > > the audio DSP and codec paths (as DSPs and codecs have multiple muxes > > and mixers). > > Yeah, the graph is simplified, as for now we only needed to represent > the parts of the graph that are associated with the ALSA interfaces. So this doesn't expose the graphs inside USB-audio chip but rather only the mixer elements parsed by ALSA driver, right? That's what I understood from Shuah's patchset, so far. > > It may be good to have a cmd line option to stop at certain > > nodes on the graph to avoid over populated/complex graphs ? > > Yes, it makes sense to have some ways to simplify the graph plot. > Yet, I'm not sure yet what would be the best ways to simplify > the graph when plotted, as this is not a simple task. > > For example, on the au0828/snd-usb-audio graph, the dvb-demux entity > actually has a lot more than 5 source PADs. The demux basically gets > a MPEG-TS stream and splits audio, video and data channels on different > I/O outputs. Most drivers (including au0828) have 256 outputs. > Each node connected to two or more I/O entities. On an USB driver > like this one, those outputs are seen via two device nodes, but > TV sets and Set Top Boxes provide ways to wire the output of the > demux to the aSoC and to the DRM driver, in order to be able to > output sound and video directly. On some hardware, it is even possible > to reboot the CPU keeping those wires while the CPU reboots. So, the > user may not even notice if the CPU reboots due to some trouble. > > So, we need all outputs of the demux to be controlled by the Media > Controller, for it to allow dynamically route audio and video to > the right entities at the ALSA and DRM parts of the graph. > > The au0828 graphs that Shuah and I have were generated with a Kernel > hack patch that reduces the number of outputs to just 5, just to make > the graph visually readable. Of course, such patch should not be sent > upstream, and we need to find a solution on userspace to simplify > the graph on plots. > > There are some ways that we could do that: > > 1) we could group entities/interfaces per subsystem. So, if all the user > wants is to see ALSA-related nodes, it will filter out the other nodes > (eventually, keeping the nodes that are directly connected to ALSA > but belongs to the other subsystems); This actually made me wonder how all things are managed. Are all mapped into the same topology, or they are individual trees (e.g. per device object)? thanks, Takashi