You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[BUG] Platform & CPU timer should be distinct #3274
Describe the bug cpu_timer_get and timer_get that get timers from struct sof should return distinct physical or virtual timers, so user can register handler in one of them with not overriding another one.
To Reproduce
(On Baytrail) Try to set handler for one timer and then to another, previous one will be removed.
Example in: #3268
Reproduction Rate
100%
Expected behavior
I should get distinct timers or at least should be able to use them like they would be distinct.
Impact
Needed for implementation of budgeting in scheduler.
Environment
IMX and pre-CAVS platforms (it works as expected only on CAVS platforms).
Side note
Probably doxygen should be more verbose and specify that these timers should be distinct.
@jajanusz ack - but the new API must map easily onto Zephyr clock APIs i..e naming and calling convention @finikorg has Zephyr clock support for all IP on his TODO list IIRC.
On the i.MX one, I think we only have one (but we need to double check if there is nothing else in hardware), so we should be able to somehow reuse part of the infrastructure for cascaded IRQs (the part that allows multiple handlers per same interrupt) within the firmware itself. Or could we do a weird thing, like a fake cascaded IRQ controller that would expose one interrupt (the very same interrupt that is physical) and just run all handlers unconditionally? And update the clock definition to use this for its IRQ handler.
Activity
jajanusz commentedon Aug 5, 2020
@mengdonglin please assign some1 who supports baytrail, thanks
lgirdwood commentedon Aug 5, 2020
@jajanusz ack - but the new API must map easily onto Zephyr clock APIs i..e naming and calling convention @finikorg has Zephyr clock support for all IP on his TODO list IIRC.
paulstelian97 commentedon Aug 5, 2020
On the i.MX one, I think we only have one (but we need to double check if there is nothing else in hardware), so we should be able to somehow reuse part of the infrastructure for cascaded IRQs (the part that allows multiple handlers per same interrupt) within the firmware itself. Or could we do a weird thing, like a fake cascaded IRQ controller that would expose one interrupt (the very same interrupt that is physical) and just run all handlers unconditionally? And update the clock definition to use this for its IRQ handler.
@dbaluta Any feedback on this idea?