On 4/8/2021 5:04 PM, Jaroslav Kysela wrote:
Dne 08. 04. 21 v 16:47 Mark Brown napsal(a):
On Thu, Apr 08, 2021 at 09:12:57AM -0500, Pierre-Louis Bossart wrote:
On 4/8/21 8:18 AM, Takashi Iwai wrote:
I guess the question here is how to identify the proper profile for a certain platform and how to get it passed over the whole system. Theoretically, the rename of the card name or mixer name strings could be done in user-space side, too (e.g. mapping in alsa-lib or whatever), so I don't think it mandatory to make them variable via sysfs, if it's meant only for the consistency reason.
Didn't we discuss in the past about the possibility to store the profile name in the card component string?
Because of OEM or user customization, we will have multiple versions of firmware and topology that will have to be enabled in specific setting. The last thing we want is hard-coded rules in the kernel on which firmware customization to use for which platform.
...
If the users wipes the OEM image and installs a standard distribution on the same device, they would by default use the firmware generated from the SOF main branch, without any differentiation and 3rd party IP.
So the point is: how do we expose this information to UCM? In the machine driver where the card is created? There is zero information on what the firmware/topology does. The information can only be extracted when the topology is loaded when probing the SOF component driver.
So what we're looking for here is a mechanism to tell userspace what firmware has been loaded?
It's just a part of the issue with the proper runtime sound card identification. But yes, the firmware can really change the created sound card (controls, PCM devices, paramters for those devices). In this case, UCM should pick another configuration.
I'm looking for a straight solution here.
Jaroslav
Wouldn't dsp_status from snd_hwdep already work here? The only thing which would need to be done is to connect it to ASoC card?
And in userspace ask using hwdep interface for what is the loaded FW?
Amadeusz