-
Notifications
You must be signed in to change notification settings - Fork 327
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
cadence: unification of cadence module naming #9287
cadence: unification of cadence module naming #9287
Conversation
This change improves and standardizes the naming convention of the cadence module during its creation. Signed-off-by: Damian Nikodem <damian.nikodem@intel.com>
Sof CI tests fails - WiP |
FYI: There is a compilation error problem, existing just before this patch!
I think it was introduce by @andyross fdb039e / #9261
|
@dnikodem Your PR not only unifies the cadence module naming! but also fixes a compilation problem! |
correct, this is why I prepared this PR. The problem is that I see a lot of fails in CI (probably not related to this change) - need to verify 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.
That's the correct way to adjust the naming. Is this not buildable in CI or otherwise from e.g. xtensa_build_{all,zephyr} or rebuild_testbench.sh? What's the correct way to validate this component? If the validation isn't in-tree, can we add an issue to make sure it gets a test?
(Honestly I sorta worry that there are others like this hiding. SOF has a lot of seemingly dead/zombied code and this was a pretty invasive PR that plays poorly in that kind of bathtub.)
Looks like the issues are not related to my PR:
I think that this is ready to merge. |
@dnikodem wrote:
Ack, (1) is fixed in main via sof-test PRs and (2) is tracked as thesofproject/linux#5098 Proceeding with merge. |
In order to validate this component you will need some proprietary libraries from Cadence. Intel / NXP are using different libraries. We validate this internally, using our CI - and it usually takes 1 or 2 days until we get signalled about issues. I think Intel does the same. |
The normal pattern for that sort of thing is to provide a "stub" implementation selected via kconfig that emulates the proprietary bits as some kind of noop. Then you build that in a default configuration (the fuzzer seems to be evolving in that direction as the official "enable everything for testing" config) that runs in CI, so you're guaranteed you don't get surprised by this kind of API change. |
This change improves and standardizes the naming convention of the cadence module during its creation.