ipc4: base_fw: Enable scheduler info retrieval for secondary cores

[tmleman]

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.

[lyakh]

FYI #5737 (comment)

[lgirdwood]

FYI #5737 (comment)

@lyakh can you expand - for legacy reason we need to reply with IPC4 codes to host, but internally its all posix.

[lyakh]

FYI #5737 (comment)

@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 IPC4_SUCCESS, but in some locations it mixes up even non-zero return codes, e.g. https://github.com/thesofproject/sof/blob/main/src/audio/base_fw.c#L502 should return POSIX errors, but it calls extended_global_perf_data_get() which returns IPC4 error codes

sof/src/audio/base_fw.c

Line 441 in b70d2bf

return IPC4_UNAVAILABLE;

and there are more such examples there. E.g.

sof/src/audio/base_fw.c

Line 397 in b70d2bf

int set_perf_meas_state(const char *data)

returns both IPC4_SUCCESS and -EINVAL