Skip to content

timer_domain: bring the timer_domain_unregister() back #4885

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.

Sign up for GitHub

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

Merged
lgirdwood merged 2 commits into from
Oct 25, 2021
Merged

timer_domain: bring the timer_domain_unregister() back #4885

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
f48db1e
ll_schedule: keep the task in the list for finished task
keyonjie Oct 18, 2021
edf7c2b
timer_domain: bring the timer_domain_unregister() back
keyonjie Oct 18, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 4 additions & 5 deletions src/schedule/ll_schedule.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -107,11 +107,6 @@ static void schedule_ll_task_update_start(struct ll_schedule_data *sch,
static void schedule_ll_task_done(struct ll_schedule_data *sch,
struct task *task)
{
/* Remove from the task list, schedule_task_cancel() won't handle it again */
list_item_del(&task->list);

domain_unregister(sch->domain, task, atomic_sub(&sch->num_tasks, 1) - 1);

@lyakh lyakh Oct 22, 2021

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this function is now only called once and only prints traces, maybe you could remove it completely and move prints directly into the caller

@keyonjie keyonjie Oct 22, 2021

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this function is now only called once and only prints traces, maybe you could remove it completely and move prints directly into the caller

How about let's keep it at the moment for better bisection.

@lyakh lyakh Oct 28, 2021

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@keyonjie I've investigated the conflict between this PR and my now reverted #4724. As you know, the latter is moving TRIGGER_STOP handling into the pipeline task. That way the pipeline task itself processes the trigger and completes and yes, in that case there is no call to schedule_task_cancel() exactly because you don't want to cancel the task from itself, potentially deregistering the interrupt handler from itself.
Let's try to understand better what this PR was trying to fix. I see a comment from @ranj063 that this fixes "multicore playback" on ADL. What exactly does that mean? Running multiple-pipeline-playback.sh on a multicore topology? The SOF upstream after d4fd1b3 was broken or upstream plus multicore coherency API? Do we know how the breakage was happening?

@keyonjie keyonjie Oct 29, 2021

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@keyonjie I've investigated the conflict between this PR and my now reverted #4724. As you know, the latter is moving TRIGGER_STOP handling into the pipeline task. That way the pipeline task itself processes the trigger and completes and yes, in that case there is no call to schedule_task_cancel() exactly because you don't want to cancel the task from itself, potentially deregistering the interrupt handler from itself. Let's try to understand better what this PR was trying to fix. I see a comment from @ranj063 that this fixes "multicore playback" on ADL. What exactly does that mean? Running multiple-pipeline-playback.sh on a multicore topology? The SOF upstream after d4fd1b3 was broken or upstream plus multicore coherency API? Do we know how the breakage was happening?

@lyakh it broke the upstream + multi-core nocodec (multi-core + dynamic ppl actually) topology, normal playback or capture fails.

tr_info(&ll_tr, "task complete %p %pU", task, task->uid);
tr_info(&ll_tr, "num_tasks %d total_num_tasks %d",
atomic_read(&sch->num_tasks),
Expand Down Expand Up @@ -142,6 +137,10 @@ static void schedule_ll_tasks_execute(struct ll_schedule_data *sch)

/* do we need to reschedule this task */
if (task->state == SOF_TASK_STATE_COMPLETED) {
/*
* keep the task in the list and the subsequent call to
* schedule_ll_task_cancel() will clean it up.
*/
schedule_ll_task_done(sch, task);
} else {
/* update task's start time */
Expand Down
21 changes: 15 additions & 6 deletions src/schedule/timer_domain.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -67,12 +67,21 @@ static int timer_domain_register(struct ll_schedule_domain *domain,
static int timer_domain_unregister(struct ll_schedule_domain *domain,
struct task *task, uint32_t num_tasks)
{
/*
* domain_unregister() can be called from the domain handler itself,
* and we cannot unregister the timer interrupt handler from the handler
* itself. Keep the interrupt registered but disabled. This assumes that
* the handler is at least not unloaded.
*/
struct timer_domain *timer_domain = ll_sch_domain_get_pdata(domain);
int core = cpu_get_id();

tr_dbg(&ll_tr, "timer_domain_unregister()");

/* tasks still registered on this core */
if (!timer_domain->arg[core] || num_tasks)
return 0;

tr_info(&ll_tr, "timer_domain_unregister domain->type %d domain->clk %d",
domain->type, domain->clk);

timer_unregister(timer_domain->timer, timer_domain->arg[core]);

timer_domain->arg[core] = NULL;

return 0;
}
Expand Down