-
Notifications
You must be signed in to change notification settings - Fork 349
topology2: ssp: add link clock aux data for mtl #7060
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
lgirdwood
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
plbossart
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems a bit intrusive an repetitive @juimonen, can we not have a mtl default with the values added instead of changing all topologies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we not have some sort of enum that is self explanatory or a comment. This is very hard to review.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd not pollute the hw_config class with NHLT-specific stuff at all. The clock_source is a SSP-specific value that can be set in ssp.conf based on PLATFORM definition
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what i'd think you need is something like this:
diff --git a/tools/topology/topology2/include/dais/ssp.conf b/tools/topology/topology2/include/dais/ssp.conf
index 9c73e7562..99fc9024e 100644
--- a/tools/topology/topology2/include/dais/ssp.conf
+++ b/tools/topology/topology2/include/dais/ssp.conf
@@ -111,6 +111,25 @@ Class.Dai."SSP" {
# platform clock frequency
DefineAttribute.io_clk {}
+ DefineAttribute."clock_source" {
+ constraints {
+ !valid_values [
+ "XTAL"
+ "CARDINAL"
+ "PLL"
+ "MCLK"
+ "WOV_CRO"
+ ]
+ !tuple_values [
+ 0
+ 1
+ 2
+ 3
+ 4
+ ]
+ }
+ }
+
attributes {
!constructor [
"name"
@@ -140,4 +159,10 @@ Class.Dai."SSP" {
frame_pulse_width 0
tdm_padding_per_slot false
version $SSP_BLOB_VERSION
+
+ IncludeByKey.PLATFORM {
+ "mtl" {
+ clock_source PLL
+ }
+ }
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IncludeByKey.PLATFORM {"mtl" {clock_source PLL
I hope we are using the 24.576MHz cardinal clock that comes for free and not the PLL? That index 2 seems completely wrong...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@plbossart I could be wrong with the indices, I was just giving an example. @juimonen please correct me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
all this is good and dandy, but it would require me to rewrite/move the alsa-utils auxdata parser
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can debate about the sw-philosophical issues for a long time... So ssp blob is created per hw_config, like in BT we have 3 different hw_configs, we create 3 different blobs into nhlt. Aux data is embedded by the spec after the blob. So if the aux data is moved into ssp level, it would mean that all blobs would need a copy of the same aux data. I understand that in the link clock case this could be fine, but link clock is not the only aux data item. So if someone can guarantee me that any aux data items will not be different in any hw_configs per ssp, the move to ssp level would be justified. Otherwise I see the hw_config quite logical place for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will repeat my suggestion to ALWAYS provide the AUX information with the clock source, and have the firmware discard what it cannot understand.
The point is that if you select a bitclock that divided from 24.576 MHz then you have to select the clock_source 1. If you derive the bitclock from 19.2 then clock_source 0 it is.
There's no differences between platforms, the mapping between clock sources is always the same, and we only have to select between 0 and 1 for now.
In other words, rather than keep this optional make it a mandatory one-size-fits-all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we really want to add this everywhere, when this is clearly a SOC-specific configuration that should be default in all topologies?
This should be part of a platform definition, not in all topologies IMHO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@juimonen can we take this from platform.conf i.e. using the same method as SSP_BLOB_VERSION above ? This could be an attribute in teh base class that would default to PLATFORM_CLOCK_blah_DEFAULT ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't currently know a way to add this to all hw_configs in a certain platform in some other way than this
Dont we have a platform file that can be included like in topology1 ? if not, please add one. |
@lgirdwood yes we do. There's mtl.conf that we can add this to |
Add conditional link clock settings for mtl ssp using auxiliary data in the blob generation. Signed-off-by: Jaska Uimonen <jaska.uimonen@intel.com>
08cc93a to
d155d70
Compare
|
@juimonen still RFC ? |
I want to see the CI after rebase (zephyr update) and there's still topology "cleanup" issues to be discussed... |
|
@ranj063 @plbossart we need to figure this out, related code is merged and used in alsa-utils and zephyr ssp driver. This is a working solution, but if you want this cleaner, I need some guidance how to proceed. I would really like to get this for 2.5... |
@juimonen Looks like we need the clock source enum and the mtl.conf |
|
@juimonen Can you check how this could be moved to mtl.conf and evaluate the effort? I understand the concern that this bit now is needed in every topology used with mtl, and would b ebetter to have this in one place. @plbossart @lgirdwood Ok to merge this now if Jaska commits to making a follow-up change. We really do need this change, we are getting corruption in audio signal without and this could mask all kinds of other things. |
|
probably people would like something like this: https://github.com/juimonen/sof/tree/aux_test problem is that it just doesn't work with alsa-utils and I kind of don't know why. |
ranj063
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
im OK to merge this to unblock certain tests. We can work on beautifying it later
|
@lgirdwood @kv2019i lets not merge this one just yet. I have alternative PRs for this |
|
Can one of the admins verify this patch? |
Add conditional link clock settings for mtl ssp using auxiliary data in the blob generation.
Signed-off-by: Jaska Uimonen jaska.uimonen@intel.com