You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
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?
@keyonjie@kv2019i sorry guys, I've not heard any of the use cases where we need to reference components by UUID.
PCMs - referenced by ALSA ID.
Kcontrols - referenced by ALSA ID
debugFS - passed directly - userspace can translate
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.
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) ).
Activity
lgirdwood commentedon Dec 21, 2018
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 commentedon Apr 16, 2020
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):
- 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 commentedon Apr 16, 2020
@mmaka1 your call. Need your inputs here on your plan.
keyonjie commentedon Apr 22, 2020
Thanks for the summarize. yes, let me investigate on the implementation from the driver side and create new item to support UUID.
lgirdwood commentedon May 18, 2020
@keyonjie @kv2019i sorry guys, I've not heard any of the use cases where we need to reference components by 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 commentedon May 20, 2020
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 commentedon Jun 5, 2020
Implementation of the FW part completed by the #3010.