From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Daniel Baluta <daniel.baluta@gmail.com>, Mark Brown <broonie@kernel.org>
Cc: Devicetree List <devicetree@vger.kernel.org>,
Linux-ALSA <alsa-devel@alsa-project.org>,
Kai Vehmanen <kai.vehmanen@linux.intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Daniel Baluta <daniel.baluta@oss.nxp.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Rob Herring <robh+dt@kernel.org>,
Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
Takashi Iwai <tiwai@suse.com>,
Daniel Baluta <daniel.baluta@nxp.com>
Subject: Re: [PATCH 1/3] ASoC: SOF: Parse fw/tplg filename from DT
Date: Tue, 20 Jul 2021 10:28:57 -0500 [thread overview]
Message-ID: <bd85ea7c-e9b5-de67-07ce-7104a1e19805@linux.intel.com> (raw)
In-Reply-To: <CAEnQRZCiC5aGK6AsD0TN5fzN6AxFn6=f8hCrd2B9fhCYfCFOSg@mail.gmail.com>
>>>> Introduce two DT properties in dsp node:
>>>> * fw-filename, optional property giving the firmware filename
>>>> (if this is missing fw filename is read from board description)
>>>> * tplg-filename, mandatory giving the topology filename.
>>>
>>> These sound entirely like operating system configuration which I'd
>>> expect to be inferred from the machine identification. What happens if
>>> a system has multiple options for firmware files, or if the OS ships the
>>> topology and firmware bundled up in a single image to avoid them getting
>>> out of sync? What's the benefit of putting them in the DT?
>
> Can you help me with this, specifically for selecting topology name.
>
> I think I'm fine selecting a default value for SOF firmware name. It
> looks like even
> for Intel platforms there is no way of changing the firmware name.
>
> But how about selecting topology name? We have lots of audio scenarios
> that can run on the exact same hardware:
> - e.g
> - Audio PCM playback + Post Processing
> - Audio Compress playback
> - Keyword detection
>
>
> So, we need to use different topologies to select the scenario we want
> to demonstrate.
>
> Would it be acceptable to add tplg_name as a module parameter?
we already have a "tplg_path" module parameter which was intended to differentiate between product skews/versions using the same hardware and firmware version. A typical example would be an OEM using 'public' firmware + topology for basic audio support, distributed through sof-bin and packaged by distros, and 3rd-party/closed sources firmware modules in more advanced packages distributed separately by the OEM. In the latter case you do want the same path for firmware and topology, otherwise you'd have a risk of using a topology making references to a library not bundled in the firmware.
There was an initial ask from Curtis to have the ability to override the firmware/topology names, but they've been able to work with the path parameters - set with udev rules for specific models.
If you wanted to demonstrate 'scenarios', you could use the same approach?
Two other points to reply to Mark:
- we currently don't support 'shipping the topology and firmware bundled up in a single image to avoid them getting out of sync'. No idea how that might work.
- if the machine driver is specified in DeviceTree, then the topology used is *required* to be aligned with the machine driver. The rules are that a topology may not make references to a BE dailink exposed in the machine driver, but conversely if the topology makes a reference to a BE dailink that is not exposed in the machine driver the topology parsing will fail. It's one of the current weaknesses of topology-based solutions, we have non-configurable hardware-related things that are described in topology but should really be described in platform firmware, be it ACPI or DT, and provided to the topology.
next prev parent reply other threads:[~2021-07-20 15:44 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-15 14:17 [PATCH 0/3] Read firmware, tplg and machine driver name from dts node Daniel Baluta
2021-07-15 14:18 ` [PATCH 1/3] ASoC: SOF: Parse fw/tplg filename from DT Daniel Baluta
2021-07-15 14:39 ` Mark Brown
2021-07-16 14:31 ` Daniel Baluta
2021-07-20 14:54 ` Daniel Baluta
2021-07-20 15:28 ` Pierre-Louis Bossart [this message]
2021-07-21 12:59 ` Mark Brown
2021-07-21 13:28 ` Pierre-Louis Bossart
2021-07-21 17:00 ` Mark Brown
2021-07-15 14:18 ` [PATCH 2/3] ASoC: SOF: Introduce machine driver name Daniel Baluta
2021-07-15 14:18 ` [PATCH 3/3] dt-bindings: dsp: fsl: Document newly introduced fsl,properties Daniel Baluta
2021-07-15 14:59 ` Rob Herring
2021-07-16 14:25 ` Daniel Baluta
2021-07-15 15:51 ` Rob Herring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bd85ea7c-e9b5-de67-07ce-7104a1e19805@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=daniel.baluta@gmail.com \
--cc=daniel.baluta@nxp.com \
--cc=daniel.baluta@oss.nxp.com \
--cc=devicetree@vger.kernel.org \
--cc=kai.vehmanen@linux.intel.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ranjani.sridharan@linux.intel.com \
--cc=robh+dt@kernel.org \
--cc=tiwai@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).