Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Liam Girdwood <liam.r.girdwood@linux.intel.com>]

On Wed, 2015-10-21 at 03:04 +0300, Laurent Pinchart wrote:
> Hi Liam,
> 
> On Monday 19 October 2015 17:27:56 Liam Girdwood wrote:
> > 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.
> 
> I wouldn't be against an option to dump the topology of MC devices through a 
> file to capture the topology on a remote system that doesn't have the 
> necessary tools installed and analyze it on a development machine. I'm however 
> not saying that such a feature should be a hard requirement for MC as I 
> haven't evaluated the complexity yet. Using the same format as the ALSA DSP 
> firmware topology binary would probably not be possible though, as I expect 
> that format to be quite ALSA-specific.

Yeah, it is quite ALSA specific. It may just be best to just dump this
data format for driver/firmware developers only if it's going to be
difficult to align with MC. The internal ALSA code used to gather this
data will be mostly similar for this simple dump and MC though, so we
will still have a lot of codec reuse.

I think we may just have to support both formats, but stick a big fat
warning about the simple developer format is not for general use and
will change without warning etc. It's intended that the topology
compiler will be the only tool that will read this format (when it
de-compiles ALSA topology data).

Liam
> 
> > 2) Media controller API used by everyone else.
>