On Thu, Apr 8, 2021 at 12:43 PM Pierre-Louis Bossart < pierre-louis.bossart@linux.intel.com> wrote:
Yes, I'm talking about rules which depends on the sound driver
specific sysfs
attributes (you can match the modified /sys/module/*/parameters here).
you lost me with 'match the modified parameters' wording. who matches and who modifies those parameters?
You can probably add something like this to the sound-card.rules:
SUBSYSTEMS=="pci",ATTR{device/driver/module}=="snd_soc_sof_sdw",
ATTR{device/driver/module/../snd_sof_pci/parameters/tplg_path}=="intel/sof-tplg/pdm1",
DO_SOMETHING_HERE
DO_SOMETHING_HERE may be ATTR{longname}="My Long Name" for example when
my change is accepted.
Humm, not sure this can work due to dependencies.
The machine device is neither an ACPI nor PCI one. It's a platform device.
When the PCI device is detected, the PCI core will call the SOF driver probe, which will first try and boot the firmware, and then create the platform device. That results in the probe of the machine driver which creates the card, but that happens *after* booting the firmware.
the DSP firmware is setup starting here:
https://elixir.bootlin.com/linux/latest/source/sound/soc/sof/core.c#L138
and the machine device is created almost last, after registering the ASoC components.
https://elixir.bootlin.com/linux/latest/source/sound/soc/sof/core.c#L234
when the card is created, it's too late to change the firmware path or any firmware-related parameters.
Thanks for raising this to my attention Pierre, yes we are also experiencing a similar issue since chromium builds will have default sof tplg and fw, but chrome builds will not. Since our UCMs are in a single location right now they will contain commands that will not execute on the defaults and we have no way of indicating to our audio server how to handle this. I am definitely interested in seeing a feature where we can pass indicators to the UCM about what we have available.