Message-ID: <20210721170043.GH4259@sirena.org.uk>
Date:   Wed, 21 Jul 2021 18:00:43 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
Cc:     Devicetree List <devicetree@...r.kernel.org>,
        Daniel Baluta <daniel.baluta@...il.com>,
        Kai Vehmanen <kai.vehmanen@...ux.intel.com>,
        Liam Girdwood <lgirdwood@...il.com>,
        Daniel Baluta <daniel.baluta@....nxp.com>,
        Linux-ALSA <alsa-devel@...a-project.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
        Takashi Iwai <tiwai@...e.com>,
        Daniel Baluta <daniel.baluta@....com>
Subject: Re: [PATCH 1/3] ASoC: SOF: Parse fw/tplg filename from DT

On Wed, Jul 21, 2021 at 08:28:17AM -0500, Pierre-Louis Bossart wrote:

> > Seems like it'd be trivial to arrange in the kernel, or with userspace
> > firmware loading the loader could do the unpacking.

> I think we can bundle the firmware inside of the kernel image itself,
> but we've never tried so it doesn't work by default.
> I don't know what userspace loading means, we rely on request_firmware
> and don't assume any specific support from userspace.

If you have a userspace handler that implements loading firmware into
the kernel (rather than having the kernel just try with a given path
prefix) then that program can do anything it likes to get the firmware,
including unpacking it out of another image.

> > That seems like an orthogonal issue here?  The requirement for a
> > firmware that's joined up with the hardware (and system description)
> > that it's being used with exists regardless of how we rename things.

> It's not completely orthogonal. The topology currently defines e.g. the
> I2S interface index, Mclk, bclk, fsync, etc, and my point is that these
> bits of information are completely related to the hardware and should
> probably come from platform firmware/ACPI.

If only ACPI based platforms offered a standard way to do this like DT
does and didn't rely on all these platform specific hacks!  In any case
my point is more that use case dependent selection of the firmware is a
separate issue to having firmware that matches a specific board and
there seemed to be some conflation of the two.  For having a completely
board specific firmware we already have system level identification in
both DT and ACPI which can be used.

> The topology framework currently provides too much freedom to
> developers, it's fine to add new pipelines, PCM devices and new
> processing, but when it comes to the hardware interfaces the topology is
> completely constrained. I've been arguing for a while now that the
> dailink descriptions and configurations should be treated as an input to
> the topology, not something that the topology can configure. I don't
> know how many issues we had to deal with because the topology settings
> were not supported by the hardware, or mismatches between topology and
> machine drivers (missing dailinks, bad dailink index, etc).

I think it'd definitely help to at least have some strong diagnostics
for detecting mismatches between the topology and the hardware and
machine driver it's being applied to, including what configurations the
machine driver is willing to have on the links (which could be just a
single configuration if that's what makes sense for the platform).  I
can see that the topology might want to select different configurations
for the various hardware links depending on how it wants to use them in
a given application, especially in more embedded contexts.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists