[Ksummit-discuss] Draft agenda for the kernel summit

Mauro Carvalho Chehab mchehab at osg.samsung.com
Tue Oct 20 15:29:55 UTC 2015


Em Tue, 20 Oct 2015 14:13:30 +0100
Mark Brown <broonie at kernel.org> escreveu:

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

Well, with such assumption, even having a debug option would be
a problem, as the firmware image may not be compiled with such option.

I think that it is actually easier to cross-compile a program with all
libraries required statically linked and then copy it to the target
than convincing the firmware image manufacturer to send an image
compiled with some additional options.

That's said, it shouldn't be hard to add some debugfs module that
would output the MC topology.

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

I'm open to suggestions. The advantage of the MC next gen API is that it
is subsystem independent, and we're adding some ways for an already
existing MC graph to be used by other subsystems. So, it can provide an
end-to-end graph that represents how the stream is wired on the entire
Kernel.

This is a requirement for some sorts of usages, where userspace may need
to change the stream path on more than one subsystem.

It also helps to lock resources that may be shared by more than one
subsystem. There are such cases between V4L2 and DVB subsystems, for
things like TV tuner. There are also such cases between V4L2 and DRM
subsystems, where the same video codec could be used by both
subsystems, but not at the same time.

So, I guess it is easier to extend the MC to fulfill the needs
for ALSA than doing the reverse or writing some other solution.

Regards,
Mauro
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Assinatura digital OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/ksummit-discuss/attachments/20151020/66a4bff2/attachment-0001.sig>


More information about the Ksummit-discuss mailing list