ipc4: base_fw: Enable scheduler info retrieval for secondary cores #9511
Conversation
tmleman
requested review from
dbaluta,
kv2019i,
lbetlej,
lgirdwood,
mmaka1 and
plbossart
as code owners
tmleman
requested review from
abonislawski,
dnikodem,
marcinszkudlinski,
serhiy-katsyuba-intel,
softwarecki and
tobonex
tmleman
force-pushed
the
topic/upstream/pr/ipc4/corex/schedulers_info_get
branch
2 times, most recently
from
7eb60bf to
df38838
Compare
This commit addresses the limitation in the schedulers_info_get function where scheduler information could only be retrieved for the primary core. The updated implementation now validates the core_id against the number of configured cores (CONFIG_CORE_COUNT) and initiates an IPC process on the requested core if it is not the current core. Changes include: - Adding a check to ensure the core_id is within the valid range. - Calling ipc4_process_on_core to handle IPC processing on secondary cores. - Returning appropriate IPC4 error codes based on the result of ipc4_process_on_core. Signed-off-by: Tomasz Leman <tomasz.m.leman@intel.com>
@lyakh can you expand - for legacy reason we need to reply with IPC4 codes to host, but internally its all posix. |
base_fw.c has more locations of mixing up the two error code families. The commit in this PR fixes one such case - a pretty harmless one, 0 is the same as Line 441 in b70d2bf Line 397 in b70d2bf IPC4_SUCCESS and -EINVAL
|
|
@tmleman do you need to make any updates here for IPC4 codes now that fix has merged ? |
From what I see, there are no conflicts so GitHub should be able to handle it. I can do a rebase, the diff will be smaller as a result. |
6 participants
This commit addresses the limitation in the schedulers_info_get function where scheduler information could only be retrieved for the primary core. The updated implementation now validates the core_id against the number of configured cores (CONFIG_CORE_COUNT) and initiates an IPC process on the requested core if it is not the current core.
Changes include: