Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
PTL upstream #9185
PTL upstream #9185
Changes from all commits
06988c8
1b3420c
67607b9
4248a11
215d595
18b4b5e
0c6544d
d4be840
f7502b8
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
This is another spot where SOF is hiding a divergence from Zephyr. This should be using CONFIG_MP_MAX_NUM_CPUS, or if it has to be here for legacy builds there should be a BUILD_ASSERT somewhere to make sure they're identical.
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.
It was for compatibility in the past but right now it could be easily removed because we are already using CONFIG_MP_MAX_NUM_CPUS in most places.
In sof the most used core kconfig is CONFIG_CORE_COUNT which is based on zephyr
so this is a good thing to do but in a separate PR
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.
Still whining that this is a 100% parallel and unconstrained recapitulation of platform selection that is already in the Zephyr tree. All this does is create the possibility of getting it wrong.
I get that this is "how it's always been done", but the time to fix that is now, when submitting a new platform. If PTL doesn't do it, then when will it happen?
At the very least (if the use of these older kconfigs is too hard to untangle) you should be deriving it from the existing constants and disallowing apps from setting it incorrectly:
default y if SOC_INTEL_ACE30_PTL
sets it correctly alwaysThere 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 you check these names? TGL is cAVS 2.5, not ACE 1.5 (which is what Zephyr claims to be building for MTL, not 2.0!), etc.. Something looks mixed up.
Also: this kind of field-shifted versioning is a bad code smell. Everyone does it thinking that they'll be able to write "#if VERSION > whatever", but it never actually works that way over long term maintenance, because compatibility is hard, especially in hardware. And the hard constants end up in places they shouldn't, like binary formats, making changes to the scheme impossible in the future. Even if you don't want to use the Zephyr constants directly, strongly suggest junking these and using an enum. Everyone with a number-format version scheme ends up regretting the practice.
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.
Still really dislike introducing numbered versions for a system that doesn't guaranteed backward compatibility. Is a PTL device always compatible with a LNL one? Clearly no, right? So this is creating a promise you can't keep, even if the handful of spots in this PR work that way.
And to repeat: this is a new API, not a legacy one you're trying to accomodate.
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.
Actually... what's the point of all the separately-defined version constants? Zephyr is already doing that for you with the board/soc{,_series,_family} hierarchy. At the very least this should be predicated on that. Doing otherwise opens up the possibility of building "pantherlake" against a build with CONFIG_SOC_SERIES_INTEL_CAVS_V25=y.
@ceolin @dcpleung are available for support if you need help figuring out the Zephyr hardware scheme, or if it's not doing something you need.