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!
