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 D1190410 for ; Mon, 19 Oct 2015 20:46:19 +0000 (UTC) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F2C8813E for ; Mon, 19 Oct 2015 20:46:18 +0000 (UTC) Received: by igbkq10 with SMTP id kq10so58968603igb.0 for ; Mon, 19 Oct 2015 13:46:18 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20151019173419.042d5e8b@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> Date: Mon, 19 Oct 2015 14:46:18 -0600 Message-ID: From: Shuah Khan To: Mauro Carvalho Chehab Content-Type: text/plain; charset=UTF-8 Cc: Liam Girdwood , Lars-Peter Clausen , Mark Brown , 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 Mon, Oct 19, 2015 at 1:34 PM, Mauro Carvalho Chehab wrote: > Hi Mark/Liam, > > Em Mon, 19 Oct 2015 17:27:56 +0100 > Liam Girdwood escreveu: > >> On Mon, 2015-10-19 at 14:53 +0100, Mark Brown wrote: >> > On Mon, Oct 19, 2015 at 10:33:04AM -0200, Mauro Carvalho Chehab wrote: >> > >> > > We did a Media Controller Summit in July. During the summit, it was >> > > pointed that other subsystems like IIO (Linux Industrial I/O) have >> > > similar needs and also need to track complex pipelines. >> > >> > > The goal of this tech topic is to present the MC next generation >> > > concepts and how the patches to support MC was written, showing some >> > > pipeline examples. >> > >> > > The next gen support patches were written in August, with some >> > > additional patches written after that, and it has support for DVB >> > > and for one ALSA driver (snd-usb-audio). >> > >> > > The patches are not merged yet at the media development tree and >> > > at -next, as one of the core developers of the media controller >> > > is missing time to review patches. So, while it was originally >> > > targeted to be merged on Kernel 4.4, it is likely that this will be >> > > merged only for Kernel 4.5, in order to give him more time to >> > > review the patchset. >> > >> > One fun thing on this that came up at the audio meeting we had in Dublin >> > after ELC-E is that there is some desire to export the internal topology >> > of audio devices to userspace using the same format that we're using to >> > load topology information for DSP firmwares (see include/sound/soc-topoloy.h). >> > If we go ahead with that it'd create an alternative topology ABI, it >> > seems like we should at least consider if it's worth trying to share >> > things here. > > Thanks for the feedback. I was wanting to go to ELC-E this year due to > ALSA summit, but, unfortunately, I had 3 other trips happening on a one > month interval (two of them are 28+28 hours of trip). So, I had to give > up going to ELC-E. > >> > >> > I've not had a chance to look at the new media controller work yet, I've >> > CCed Lars and Liam who have more knowledge in this area. Unfortunately >> > I don't think any of the people working directly on this will be at KS >> > this year. >> >> Just to give a little more background (for any non audio folks), there >> are many audio DSPs today that can load their topology and other >> capabilities at runtime depending on the target device (phone, laptop, >> PC, etc) and the audio use cases. >> >> Our intention is to also have a single audio driver per DSP family (i.e. >> single skylake audio DSP driver to cover all skylake based devices). The >> DSP driver would load it's topology data alongside the DSP firmware so >> that the driver topology (i.e. graph, controls, capabilities) would be >> aligned with the DSP firmware topology. >> >> The process for creating the topology data involves either compiling a >> text topology file to the binary topology file (used by the kernel) or >> using a new ALSA C API to generate the binary topology file (as part of >> a firmware toolchain). The topology text compiler and C API are both >> upstream. >> >> We are currently implementing de-compiler support to the userspace >> compiler in order to convert the binary topology files into text files >> for debug and development purposes. >> >> Ideally I'd like to be able to dump the topology data using the same >> format that it used for topology loading. That way we could easily feed >> them into the de-compiler for development/debug. >> >> Having a simple mechanism for dumping topology data is important as we >> will need to be able to easily dump this data on Android and Chrome >> alongside regular Linux for development and debug purposes. i.e. >> cat /sys/some/dump/file > audio_topology > > Well, it is not hard to get the topology using the media controller. > I wrote a testing program using it at: > http://git.linuxtv.org/cgit.cgi/mchehab/experimental-v4l-utils.git/tree/contrib/test/mc_nextgen_test.c > Adding to what Mauro said, I have a patch series out that updates ASLA and AU0828 drivers (Hauppauge Win TV HVR 950Q Hybrid USB TV Stick) to share tuner. I am speaking about this work at the KLF on Oct 26th. http://korealinuxforum2015.sched.org/event/f59175cc49f866dbc9bebc36f86fe663#.ViVWjGwVhBd You can find the media graph that includes ALSA Mixer Function and Control Interface (Device: /dev/snd/controlC2), PCM Audio Capture Function and PCM Audio Capture interface (Device: /dev/snd/pcmC2D0c) at: https://drive.google.com/open?id=0B0NIL0BQg-AlbjZkcElJb2RtVk0 thanks, -- Shuah