Probe ipc4 info #9669
Probe ipc4 info #9669
Conversation
jsarha
requested review from
RanderWang,
marcinszkudlinski,
pblaszko,
lgirdwood,
plbossart,
mmaka1,
lbetlej,
dbaluta and
kv2019i
as code owners
src/probe/probe.c
Outdated
| info->probe_point[j++] = _probe->probe_points[i]; | ||
| } | ||
| info->num_elems = j; | ||
| comp_info(dev, "probe_get_config() %u probe points sent", j); |
There was a problem hiding this comment.
With Zephyr logging the function name is included in the log message automatically. So including it also explicitly just wastes memory. Are you getting it duplicated in your logs or is it somehow just my configuration? If you do get it twice, let's remove it. Would be great to clean up all Zephyr-only sources from this... In theory probes can be used with XTOS too IIUC? But hardly important enough to keep these names.
src/probe/probe.c
Outdated
| if (offsetof(struct sof_ipc_probe_info_params, probe_point[index]) + | ||
| sizeof(pp) > max_size) { | ||
| info->num_elems = index; | ||
| return -1; |
There was a problem hiding this comment.
proper error code? I see that it isn't propagated (for now) but (1) it might get propagated in the future, and (2) -1 just doesn't make much sense - it looks like a magic constant. Something like -ENOMEM or -ENOSPC maybe
Implement IPC4 get_config() for getting currently active probe points, by using IPC4_PROBE_MODULE_PROBE_POINTS_ADD config_id. Signed-off-by: Jyri Sarha <jyri.sarha@linux.intel.com>
jsarha
force-pushed
the
probe_ipc4_info
branch
from
7202800
to
06b6965
Compare
Add new param_id recognized by get_config() for getting all available probe points. Signed-off-by: Jyri Sarha <jyri.sarha@linux.intel.com>
jsarha
force-pushed
the
probe_ipc4_info
branch
from
06b6965
to
2a32f9b
Compare
@lgirdwood , sorry I do not follow. Do you refer to module_interface get_configuration() method return values? |
No I mean there is some IPC4 message codes that should be used instead or POSIX result values if any of these functions is returning a result to the host. Pls take a look at the ipc4 code and you should see |
Oh, I do not need to worry about that, since I am hiding behind module adapter's get_configuration() call-back. That is called from module_adapter_ipc4.c module_get_large_config(), which is in turn called from ipc4_get_large_config_module_instance() which is converting the negative error codes to IPC4_MOD_INVALID_ID. All get_configuration() implementations I have checked use POSIX error codes. |
|
SOFCI TEST |
|
sof-docs fail and Intel LNL fails all known and tracked in https://github.com/thesofproject/sof/issues?q=is%3Aissue+is%3Aopen+label%3A%22Known+PR+Failures%22+ |
Implement probe IPC4 get_config() for IPC4_PROBE_MODULE_PROBE_POINTS_ADD and IPC4_PROBE_MODULE_AVAILABLE_PROBE_POINTS.