On 2022-02-25 8:36 PM, Pierre-Louis Bossart wrote:
On 2/7/22 07:25, Cezary Rojewski wrote:
To implement ASoC PCM operations, DSP path handling is needed. With path
template concept present, information carried by topology file can be
converted into runtime path representation. Each may be composed of
several pipelines and each pipeline can contain a number of processing
it's not quite clear how you can have different pipelines with a single
dma_is per path?
Pipelines do not need to have a module that is connected to a gateway.
Layout of a path is for architecture to decide i.e. one takes
spreadsheet of all the scenarios to be supported and developers/archs
discuss/decide what's the best and optimal way to shape the paths that
implement all the possible scenarios.
modules inside. Number of templates and variants found within topology
may vastly outnumber the total amount of pipelines and modules supported
by AudioDSP firmware simultaneously (in runtime) so none of the IDs are
specified in the topology. These are assigned dynamically when needed
and account for limitations described by FIRMWARE_CONFIG and
HARDWARE_CONFIG basefw parameters.
It's already quite hard to create a topology using static IDs that will
work, this dynamic creation adds an element of risk and validation,
doesn't it?
Can you clarify how you validated this dynamic capability?
Static ID assignment i.e. taking IDs found in the topology file directly
when instantiating pipelines/modules in runtime is asking for trouble.
Firmware has its limitations in terms of number of pipelines/modules
supported simultaneously. Driver has to take these into account.
Here, we send an IPC to obtain all the limitations before any stream
could be opened for streaming.
Paths are created on ->hw_params() and are freed on ->hw_free() ALSA PCM
operations. This choice is based on firmware expectations - need for
So a path seems to be completely tied to an FE then?
That would mean that a 'dai pipeline' with 'mixin-dai-copier' would not
be managed by an avs-path, and would somehow need to be autonomously
created?
You really need to clarify how basic topologies with
mixers/demux/loopbacks are handled.
Path is either tied to a single FE or a BE. Don't understand what's
difficult with handling mixin/copier pipeliens or loopback scenario
here. We have all the tools necessary to do the job, no?
complete set of information when attempting to instantiate pipelines and
modules on AudioDSP side. With DMA and audio format provided, search
mechanism tests all path variants available in given path template until
a matching variant is found. Once found, information already available
is combined with all avs_tplg_* pieces pointed by matching path variant.
This finally allows to begin a cascade of IPCs which goes is to reserve
this sentence makes no sense.
did you mean 'which goals'?
Ack, thanks!
resources and prepare DSP for upcoming audio streaming.
+static struct avs_tplg_path *
+avs_path_find_variant(struct avs_dev *adev,
+ struct avs_tplg_path_template *template,
+ struct snd_pcm_hw_params *fe_params,
+ struct snd_pcm_hw_params *be_params)
+{
+ struct avs_tplg_path *variant;
+
+ list_for_each_entry(variant, &template->path_list, node) {
+ dev_dbg(adev->dev, "check FE rate %d chn %d vbd %d bd %d\n",
+ variant->fe_fmt->sampling_freq, variant->fe_fmt->num_channels,
+ variant->fe_fmt->valid_bit_depth, variant->fe_fmt->bit_depth);
+ dev_dbg(adev->dev, "check BE rate %d chn %d vbd %d bd %d\n",
+ variant->be_fmt->sampling_freq, variant->be_fmt->num_channels,
+ variant->be_fmt->valid_bit_depth, variant->be_fmt->bit_depth);
+
+ if (variant->fe_fmt && avs_test_hw_params(fe_params, variant->fe_fmt) &&
+ variant->be_fmt && avs_test_hw_params(be_params, variant->be_fmt))
+ return variant;
+ }
This matching between FE and BE formats is the key problem with this
patchset IMHO.
We need the ability to reconfigure the BE based on constraint matching,
not exact match with a fixed value!
We need to take into account what's set on the codec side too, can't
just ignore it. Topology is written for concrete configuration, so we
can crease a file that supports all possible configurations exposed by
given codec.
+
+ return NULL;
+}
+
+static void avs_path_module_free(struct avs_dev *adev, struct avs_path_module *mod)
+{
+ kfree(mod);
+}
+
+static struct avs_path_module *
+avs_path_module_create(struct avs_dev *adev,
+ struct avs_path_pipeline *owner,
+ struct avs_tplg_module *template)
so you have templates for paths AND modules?
Completely lost...
I'll skip the rest of this patch.
All the objects here have topology and runtime representation both.
Again, you cannot just take what's within a static topology file that
knows nothing about firmware limitations and expect success.
Don't understand what's surprising here. skylake-driver also has a
separate representation for module within topology and a separate one
for runtime. Nothing new here.
Regards,
Czarek
