On Fri, Apr 09, 2021 at 10:55:38AM -0500, Pierre-Louis Bossart wrote:
> > For example do something along those lines:
> > struct snd_soc_tplg_manifest {
> > __le32 size; /* in bytes of this structure */
> > __le32 control_elems; /* number of control elements */
...
> > struct snd_soc_tplg_ucm_files {
> > struct snd_soc_tplg_ctl_hdr hdr;
> > __le32 size; /* size of struct in bytes */
> > __le32 count; /* UCM entries */
> > char ucms[SNDRV_CTL_ELEM_ID_NAME_MAXLEN][];
> > }
> > And then expose it somewhere under sysfs after parsing topology.
> Yes I had a similar idea that we could expose in sysfs information taken
> from parsing the firmware (e.g. list of module UUIDs) and topology.
> But it's not enough. The point is that you may use the same
> topology+firmware for different platforms, only the tuning varies. I think
> that's at that level that we should allow the OEMs to set a rule defining
> what the platform is and what tuning should be applied.
So the issue there is trying to put a list of UCM files in the kernel or
topology and exposing that (which I agree doesn't seem like something
that should come from the kernel), but exposing the information about
what's in the loaded topology file seems reasonable. It's just more
information that userspace has available to key off when deciding what
it wants to do isn't it?
Attachment:
signature.asc
Description: PGP signature
