[alsa-devel] ASoC, DMI and UCM
Hi all,
I would like to discuss the way we use DMI information for the board identification in ASoC for the user space (long card name). It's a bit redundant information, because DMI is already exposed through /sys/class/dmi/id/ to the user space nowadays.
My idea is to add 'DMI:sysfs' ctl info component string for the appropriate ASoC driver to detect the existence of this dmi interface. Then I can add the sysfs support to the ucm2 conditions.
But it's really a quick idea. I'd like to have comments.
Thank you, Jaroslav
On Wed, Nov 20, 2019 at 11:04:38AM +0100, Jaroslav Kysela wrote:
I would like to discuss the way we use DMI information for the board identification in ASoC for the user space (long card name). It's a bit redundant information, because DMI is already exposed through /sys/class/dmi/id/ to the user space nowadays.
My idea is to add 'DMI:sysfs' ctl info component string for the appropriate ASoC driver to detect the existence of this dmi interface. Then I can add the sysfs support to the ucm2 conditions.
I'm not clear what adding the component string does here - is the intention just to say that the card is built in to the machine and hence DMI can be used? If that is the case something more generic that'd also work with other firmware interfaces might be good.
Dne 20. 11. 19 v 19:19 Mark Brown napsal(a):
On Wed, Nov 20, 2019 at 11:04:38AM +0100, Jaroslav Kysela wrote:
I would like to discuss the way we use DMI information for the board identification in ASoC for the user space (long card name). It's a bit redundant information, because DMI is already exposed through /sys/class/dmi/id/ to the user space nowadays.
My idea is to add 'DMI:sysfs' ctl info component string for the appropriate ASoC driver to detect the existence of this dmi interface. Then I can add the sysfs support to the ucm2 conditions.
I'm not clear what adding the component string does here - is the intention just to say that the card is built in to the machine and hence DMI can be used? If that is the case something more generic that'd also work with other firmware interfaces might be good.
Yes, basically, it would mean that the sound card is integrated to the motherboard thus the DMI info can be used for the special configs. I already added sysfs support to alsa-lib ucm substitution.
Thinking more - we don't need this probably urgently for ASoC drivers, because they all work with the integrated (built in) hardware, but it might make sense for other drivers. Probably another component identifier should be selected like 'integrated' or 'builtin' or so.
Jaroslav
On Wed, Nov 20, 2019 at 07:46:47PM +0100, Jaroslav Kysela wrote:
Dne 20. 11. 19 v 19:19 Mark Brown napsal(a):
I'm not clear what adding the component string does here - is the intention just to say that the card is built in to the machine and hence DMI can be used? If that is the case something more generic that'd also work with other firmware interfaces might be good.
Yes, basically, it would mean that the sound card is integrated to the motherboard thus the DMI info can be used for the special configs. I already added sysfs support to alsa-lib ucm substitution.
Thinking more - we don't need this probably urgently for ASoC drivers, because they all work with the integrated (built in) hardware, but it might make sense for other drivers. Probably another component identifier should be selected like 'integrated' or 'builtin' or so.
Either of those sounds good to me. You're right that it won't make a huge difference to most ASoC drivers, like you say it's not like most of them have any non built in variants to worry about. It seems most likely to be relevant for something like USB.
participants (2)
-
Jaroslav Kysela -
Mark Brown