[PATCH] ALSA: core - add more card sysfs entries

Mark Brown broonie at kernel.org
Fri Apr 9 18:39:07 CEST 2021


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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20210409/8c31c8ca/attachment.sig>


More information about the Alsa-devel mailing list