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

[Mark Brown <broonie@kernel.org>]

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

On Tue, Oct 20, 2015 at 01:29:55PM -0200, Mauro Carvalho Chehab wrote:
> Mark Brown <broonie@kernel.org> escreveu:

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

No, not normally - this is usually within OEMs and in places where this
is a problem you've typically got separate teams looking after userspace
and kernel delivery.  The kernel team is providing the drivers, the
userspace team isn't really involved and so it's more natural to work
with the kernel people.  It's kind of a specific need but it's
surprisingly common, and if it's just a debugfs thing there's a
reasonable chance someone wanted debugfs anyway.

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

Yeah, I like the idea behind MC - I think what I'm suggesting is mainly
looking at the topology binary format that has been defined for the DSPs
and seeing if it can be reused in the MC ABI (or if there's some
blockers to reuse which might also impact the topology code in its
current use cases which would be just as valuable).


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