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 7535E1BB for ; Mon, 19 Oct 2015 16:27:59 +0000 (UTC) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id E3346166 for ; Mon, 19 Oct 2015 16:27:58 +0000 (UTC) Message-ID: <1445272076.2481.37.camel@loki> From: Liam Girdwood To: Mark Brown Date: Mon, 19 Oct 2015 17:27:56 +0100 In-Reply-To: <20151019135348.GH14956@sirena.org.uk> References: <20151012190137.GA1992@thunk.org> <20151019103304.27e596a5@recife.lan> <20151019135348.GH14956@sirena.org.uk> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: Lars-Peter Clausen , ksummit-discuss@lists.linuxfoundation.org, Mauro Carvalho Chehab Subject: Re: [Ksummit-discuss] Draft agenda for the kernel summit List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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. > > 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 I'm also supportive of having a higher level and more elegant topology query interface for non kernel/firmware developers using media controller. What I'd like to propose is that we support both mechanisms for dumping the audio topology data. :- 1) Simple file dump using same format that topology is loaded. Used by kernel/firmware developers only when media controller userspace not available. Enabled by kernel Kconfig debug option. 2) Media controller API used by everyone else. Liam