Add UUID for firmware components

[ranj063]

Implement a module identifier for modules which can be used to check if the module is compatible with the driver

[lgirdwood]

This would also allow several versions of the same component type to exist too (e.g. 3rd party alternatives of common components like SRC, volume could be easily differentiated and mixed with the common versions in a single topology)

[kv2019i]

Status check:

The UUID support has been added on FW side and is used for tracing. It is documented here:
https://thesofproject.github.io/latest/developer_guides/firmware/components/component-overview.html

What is missing is ability to use UUID from kernel side. Things missing (or are implemented but not documented):

• method to discover UUIDs of a loaded FW
• method to describe topologies with effect components identified by UUID
  • one proposal documented (but not implemented in https://github.com/orgs/thesofproject/teams/sof-developers/discussions/32/comments/10 )
• kernel support to handle topologies with generic effects identified by UUID
  • for "effect" component, kernel should not need changes in enumerations to support a new component UUID, rather topology parsing should be generic
  • ability to pass generic configuration data (kernel verifies UUIDs match and then blobs can be passed)
• plan how to transition effect components (like EQs) to use UUID
  - these are currently identified with explicit handlers and enums in kernel driver (topology.c)

@mmaka1 @lgirdwood @keyonjie Do we close this item and add a new one for above, or continue with this enhancement item?

FYI @ranj063 @plbossart @juimonen @singalsu @mengdonglin

[lgirdwood]

@mmaka1 your call. Need your inputs here on your plan.

[keyonjie]

Status check:

The UUID support has been added on FW side and is used for tracing. It is documented here:
https://thesofproject.github.io/latest/developer_guides/firmware/components/component-overview.html

What is missing is ability to use UUID from kernel side. Things missing (or are implemented but not documented):

• method to discover UUIDs of a loaded FW

• method to describe topologies with effect components identified by UUID

  • one proposal documented (but not implemented in https://github.com/orgs/thesofproject/teams/sof-developers/discussions/32/comments/10 )

• kernel support to handle topologies with generic effects identified by UUID

  • for "effect" component, kernel should not need changes in enumerations to support a new component UUID, rather topology parsing should be generic
  • ability to pass generic configuration data (kernel verifies UUIDs match and then blobs can be passed)

• plan how to transition effect components (like EQs) to use UUID

  • these are currently identified with explicit handlers and enums in kernel driver (topology.c)

@mmaka1 @lgirdwood @keyonjie Do we close this item and add a new one for above, or continue with this enhancement item?

FYI @ranj063 @plbossart @juimonen @singalsu @mengdonglin

Thanks for the summarize. yes, let me investigate on the implementation from the driver side and create new item to support UUID.

[lgirdwood]

@keyonjie @kv2019i sorry guys, I've not heard any of the use cases where we need to reference components by UUID.

1. PCMs - referenced by ALSA ID.
2. Kcontrols - referenced by ALSA ID
3. debugFS - passed directly - userspace can translate
4. probes - not really applicable since we need instance ID rather than component UUID.

The only place where I see the need for the UUID is when the component is being referenced by the kernel for topology loading. After this we should always use ALSA ID or object ID.

In this case there should be nothing stopping the UUID (large) -> UUID (compressed) being done as ;part of teh topology build.

[kv2019i]

Ack @lgirdwood . Actually that's aligned with the summary I put earlier:
#769 (comment)
... all the requirements for UUID usage are linked to topology loading, and ability to detect configuration mismatches at load time. I agree with you that we have no other use-cases where UUID would be used (well, tracing is one, but for that the UUID conversion is already done in user-space).

The option of doing "compressed<->full" mapping at topology compile time, would meet the functional requirements. But at least with current definition for the compressed format, this creates a very close coupling with topology file and the FW binary -- i.e. topology file has to be from the same exact build (raised in #2914 (comment) ).

[mmaka1]

Implementation of the FW part completed by the #3010.