[Ksummit-discuss] Draft agenda for the kernel summit

Mark Brown broonie at kernel.org
Tue Oct 20 13:13:30 UTC 2015


On Mon, Oct 19, 2015 at 05:34:19PM -0200, Mauro Carvalho Chehab wrote:
> Liam Girdwood <liam.r.girdwood at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/ksummit-discuss/attachments/20151020/bf50a292/attachment.sig>


More information about the Ksummit-discuss mailing list