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
