drivers: imx: sdma: Invalidate cache when reading info from BDs
This invalidation is required in order for the driver to correctly
report the available/free bytes on a given DMA channel.
Fixes: 87d79c48dd ("drivers: imx: sdma: Add SDMA support to SOF")
Signed-off-by: Paul Olaru <email address hidden>
588399d...
by
Laurentiu Mihalcea <email address hidden>
schedule: zephyr_dma_domain: Change domain thread priority to coop range
Problem: DMA domain thread can be preempted during a pipeline_copy()
operation. This leads to buffer->walking being set to true which, in
turn, leads to TRIGGER STOP in EDF thread (which has a higher
priority than the DMA domain and can preempt it) not being able
to stop all components in a pipeline.
This is evident in the following logs:
INFO ipc: new cmd 0x60050000
INFO starting pipeline trigger operation: 0x92c10aa0
INFO executing trigger 0 on pipe 0x92c10aa0, registrable: 0
INFO Starting first walk
INFO pipeline_comp_trigger(), current->comp.id = 17, dir = 0,
pipeline: 0x92c10aa0, registrable: 0
INFO component type: 1
ERROR BUFFER WALKING SKIP
INFO ended pipeline trigger operation returned: 0
INFO ipc: new cmd 0x60030000
INFO pipeline_comp_reset(), current->comp.id = 17, dir = 0
INFO component type: 1
ERROR BUFFER WALKING SKIP
Note: "BUFFER WALKING SKIP" error message is caused by a comp_err added
to the following section of pipeline_for_each_comp():
if (buffer->walking) {
comp_err(current. "BUFFER WALKING SKIP");
continue;
}
Most likely this has always been a problem with the DMA domain but
it was less likely to happen with only a single pipeline task at a
time (the only tested case). The problem was discovered when testing
the mixer component.
This commit solves this problem by simply changing the DMA domain's
thread priority to a value in the cooperative range. This way it won't
be preempted by the EDF thread.
d2fed60...
by
Laurentiu Mihalcea <email address hidden>
zephyr_dma_domain: Give semaphore resources based on sched_comp's state upon cancel
This implies the following changes:
1) domain_task_cancel() shall no longer receive the number
of tasks, but, instead, will receive the task to be cancelled.
2) zephyr_dma_domain_task_cancel() will do k_sem_give() if the
sched_comp associated with the given task is != COMP_STATE_ACTIVE.
3) SEM_LIMIT is changed to CONFIG_DMA_DOMAIN_SEM_LIMIT and can
be configured.
The reasoning for the changes are the following:
1) and 2): In the case of mixers, domain_task_cancel()'s
num_tasks is not a reliable way to determine if the DMA
IRQs got cut off. Let's consider the following scenario:
We have a mixer with 1 non-registrable pipeline task and
1 registrable pipeline task. Upon TRIGGER_STOP we'd have
the following flow (i.MX boards):
a) SAI_STOP => DMA IRQs get cut off.
b) Cancel non-registrable pipeline task.
c) Cancel registrable pipeline task.
During b) and c), domain_task_cancel() would get the following
arguments:
b) domain_task_cancel(sch, 1)
c) domain_task_cancel(sch, 1)
This is because the non-registrable pipeline task wasn't
dequeued before c) so, even though the DMA IRQs got cut
off during a), zephyr_dma_domain_task_cancel() does not give
resources to the semaphore so what happens is zephyr_ll_run()
will no longer execute and the pipeline tasks remain queued.
3) Since the semaphore can accumulate more than 1 resource
at a given time (and since it's safe to make SEM_LIMIT depend
on the load of the system), SEM_LIMIT was changed into a config.
This allows the user to change SEM_LIMIT based on the system
load. For example, if there's 2 non-registrable pipeline tasks
and 1 registrable pipeline task (same scheduling component),
an appropriate value for SEM_LIMIT should be 3 (since the
semaphore can be given at most 3 resources during the task
cancellation process). Of course, making SEM_LIMIT depend on
the system load is the worst case but this way we can make sure
that the cancelled tasks get dequeued properly.
56f086e...
by
Laurentiu Mihalcea <email address hidden>
schedule: zephyr_dma_domain: domain_register(): Return early for non-registrable tasks
Because DMA IRQs are not registered for non-registrable tasks,
register_dma_irq() will return 0 and not set data. This leads to
zephyr_dma_domain_register() returning -EINVAL for said tasks which
is not right.
This commit fixes this problem by returning early in the case
of non-registrable tasks. This means register_dma_irq() will not
even be attempted for such tasks.
b741d49...
by
Laurentiu Mihalcea <email address hidden>
schedule: zephyr_dma_domain: Add macro for interrupt_clear_mask() on ARM64
In the case of ARM64 with GIC, the interrupts are cleared after
the ISR is executed (for reference please see arm_gic_eoi() and
arch/arm64/core/isr_wrapper.S from Zephyr). Thanks to this, we
don't need to clear them explicitly, hence there's no need for
interrupt_clear_mask() to be defined. This commit fixes linkage
problems caused by the fact that interrupt_clear_mask() is not
defined on ARM64.
1. Now we are pointing to nxp-zephyr/imx-v3.3-branch.
2. This update is needed to include Zephyr specific patches required for
building SOF on i.MX platforms with Xtensa toolchain.
drivers: imx: interrupt: Use Zephyr wrapper definitions
For the functions platform_interrupt_clear and platform_interrupt_set,
the existing definitions based on arch_interrupt_* do not compile with
the xt-clang 2023 toolchain for imx. Use the Zephyr wrapper
implementations for those for now.
Signed-off-by: Paul Olaru <email address hidden>
(cherry picked from commit 1ae0d1a4ecd4ad7fa584190c3457eae7d7ac3941)
This define is used by the new 2023 xt-clang toolchain and, while there
are a few definitions (identical to this one) in various implementations
such as newlib, none of them is in use when building SOF with Zephyr
and XtensaTools.
Add this define so that the toolchain provided headers work correctly.
Signed-off-by: Paul Olaru <email address hidden>
(cherry picked from commit ef38a0c2654eb041479b933c68c71dbb5f199f7d)
f0e7d4f...
by
Seppo Ingalsuo <email address hidden>
Audio: Module adapter: Pass entire cdata to clients for all controls
This patch unifies all the control types (bytes, enum, switch).
Previously for binary control the fragment pointed to
cdata->data[0].data while for other control types the cdata
was passed via fragment. If fragment always points to cdata
the module adapter client can reliably check the control type
from cdata->cmd and handle other than binary control types.
Since the client components with binary control pass the
data to comp_data_blob_set() in data_blob.c the restore of
pointer fragment to cdata->data[0].data can be done there.
A check for SOF_CTRL_CMD_BINARY is added to comp_data_blob_set()
and comp_data_blob_get_cmd() to avoid wrong usage of controls.
With IPC4 in comp_data_blob_set() the use of
struct sof_ipc_ctrl_data pointer step is not done but the
fragment is treated as raw data payload without the header.
The generic support for other than binary control will be
solved later for IPC4.
Signed-off-by: Seppo Ingalsuo <email address hidden>
(cherry picked from commit 7d0a0c673f94fe59fbe9b7586f841434ac2569b4)
