-
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
DRAM: add debugging for cold code violations #9873
Conversation
@lgirdwood @kv2019i this PR adds a useful debugging feature, but if we keep adding that assertion to all |
@@ -321,3 +322,16 @@ struct ll_schedule_domain *zephyr_domain_init(int clk) | |||
|
|||
return domain; | |||
} | |||
|
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 have a comment here describing the API call
@@ -555,3 +555,10 @@ void scheduler_get_task_info_ll(struct scheduler_props *scheduler_props, | |||
scheduler_get_task_info(scheduler_props, data_off_size, &ll_sch->tasks); | |||
zephyr_ll_unlock(ll_sch, &flags); | |||
} | |||
|
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.
ditto, a comment to describe the call
CI:
|
It is important not to run in DRAM code, that can be called on hot paths, i.e. in LL-scheduler context. Add a Kconfig option to catch such cases and enable it in debug builds. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Add cold code path checks to all __cold functions. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
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.
LGTM
CI:
"Internal" was clean before the last update and the last update only added comments, so it should be clean now too |
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 you envision this becoming a hard rule that any function marked with __cold must have this assert? This does add new boilerplate to audio modules that people may find distracting and/or add to the learning curve. OTOH, this is a nice debugging tool, so net positive I think.
@kv2019i I'm rather flexible about this. I think we should in the beginning put them everywhere. But then I don't think it must be a hard rule. We can grep the code from time to time and add any missing ones. Since production builds won't have that enabled, there will be no run-time difference apart from CI runs. |
Add assertions to check that cold code isn't called on hot paths