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 -- Jaroslav Kysela <perex@xxxxxxxx> Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
