DRAM: add debugging for cold code violations #9873
Conversation
lyakh
requested review from
a team,
LaurentiuM1234,
abonislawski,
dbaluta,
iuliana-prodan,
kv2019i,
lbetlej,
lgirdwood,
marcinszkudlinski,
mmaka1,
pblaszko,
plbossart and
singalsu
as code owners
|
@lgirdwood @kv2019i this PR adds a useful debugging feature, but if we keep adding that assertion to all |
|
|
||
| return domain; | ||
| } | ||
|
|
There was a problem hiding this comment.
can we have a comment here describing the API call
| 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.
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>
|
CI:
"Internal" was clean before the last update and the last update only added comments, so it should be clean now too |
kv2019i
left a comment
kv2019i
left a comment
There was a problem hiding this comment.
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. |
4 participants
Add assertions to check that cold code isn't called on hot paths