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

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2129 bytes --]

On Mon, Oct 19, 2015 at 05:34:19PM -0200, Mauro Carvalho Chehab wrote:
> Liam Girdwood <liam.r.girdwood@linux.intel.com> escreveu:

> > 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

> The only library optional dependency is libudev, used to get the
> device node names. The code falls back to use /sys/dev/char/ and
> /dev to find the device names when compiled without libudev.

> So, it should be easy to provide a cat-like program that would be
> dumping the audio topology on some file.

It's still a program that has to be built for and installed on the
device under test which is the big bar for a lot of users (consider the
case where an audio expert is doing system tuning on a device using a
firmware image supplied from elsewhere, it may be difficult for them to
build new programs for the image or request that they be included in the
image).

> > 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.

> Yeah, it sounds reasonable to have a mechanism like that just for
> debug purposes.

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

> Makes sense to me.

My main concern here is ending up with two different machine parsable
formats for exporting the topology information to userspace - it's
potentially a bit confusing for people to know which one to pick and
might end up needing multiple tools and libraries to parse depending on
the situation.  It would be much nicer if we could get a consistent
format between the two.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]