[PATCH] ALSA: core - add more card sysfs entries

[Pierre-Louis Bossart]

On 4/8/21 8:18 AM, Takashi Iwai wrote:
> On Thu, 08 Apr 2021 14:05:02 +0200,
> Mark Brown wrote:
>>
>> On Thu, Apr 08, 2021 at 01:21:52PM +0200, Jaroslav Kysela wrote:
>>
>>> Yes, it's for UCM, but even if we don't consider this purpose, the kernel API
>>> should return some reasonable information rather than very generic (or empty)
>>> strings which are used in the native ALSA utilities for example. So, I think
>>> that we should allow to "fix" this info also from the user space rather than
>>> to extend the existing API.
>>
>> Half the point with UCM was supposed to be to rewrite the control names
>> we get from the devices into standard things that are useful for
>> userspace, having to remap things for UCM doesn't sound right.
> 
> 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?

Here's a summary of an earlier discussion with Jaroslav, based on an 
initial ask from Curtis https://github.com/thesofproject/linux/issues/2766:

When a specific PCI ID is detected, we probe the SOF driver and will 
load a default firmware binary and topology.

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.

The suggestion was made to use udev rules to modify the default path for 
the firmware and topology, so that e.g. on a specific Chromebook you 
could load firmware from /lib/firmware/google/<device name>/sof-tplg. 
The same can happen for other OEMs that support Linux distributions such 
as Dell and Lenovo.

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.

I don't think the point was to rewrite the controls but make sure that 
UCM is aware that the card definition was changed by a different 
selection of firmware.

Jaroslav, please correct me if I misunderstood the intent of this patch!