Repository navigation
Conversation
ipc_get_comp_by_id() only searches COMP_TYPE_COMPONENT devices. Buffers are COMP_TYPE_BUFFER so they were never found on IPC3, making every PROBE_POINT_ADD return -EINVAL. The subsequent dev->type != COMP_TYPE_BUFFER check was therefore unreachable. Use COMP_TYPE_ANY in probe_point_add() and probe_point_remove() to find buffers while keeping the existing type check intact. Signed-off-by: Stefan Ghetu <stefan.ghetu@nxp.com>
The Zephyr-native probe_dma_init() left dma_config and
dma_block_config uninitialized. Struct fields not explicitly
assigned (e.g. dest_address for LMEM_TO_HMEM) contain stack
garbage, which causes the Zephyr DMA driver to reject the config
call. Add {0} initializers so unused fields default to zero.
Signed-off-by: Stefan Ghetu <stefan.ghetu@nxp.com>
|
Can one of the admins verify this patch?
|
There was a problem hiding this comment.
🟡 Changes recommended
The direct-ring path can misinterpret DMA stream IDs as host addresses and overrun small host rings, creating critical memory-corruption risks.
3 open issues
What changed in this PR
This PR repairs IPC3 probe setup and adds direct host-ring extraction for i.MX8MP, paired with the linked Linux probe client.
Changes:
- Fix probe-buffer lookup and zero-initialize DMA configuration structures.
- Add direct copies into a host-provided ring with a published byte counter.
- Enable probes with up to 16 probe points on the i.MX8MP EVK.
| File | Description |
|---|---|
src/probe/probe.c |
Fixes probe setup and adds IPC3 host-ring extraction. |
app/boards/imx8mp_evk_mimx8ml8_adsp.conf |
Enables probes and configures the probe-point limit. |
Review effort: Balanced
| #if CONFIG_IPC_MAJOR_3 && CONFIG_ZEPHYR_NATIVE_DRIVERS | ||
| err = probe_host_write(&_probe->ext_dma, | ||
| (void *)_probe->ext_dma.dmapb.r_ptr, avail); |
|
@ursus161 @bhiregoudar @DINESHKUMARK1 @LongWang100 @dbaluta looks like there is an issue with recent AMD update for IPC3 probes ? My platforms use IPC4 probes so I would recommend the IPC3 probes adopt a similar host interface for tooling reuse. |
|
@lgirdwood, 2 questions as i have to see if we got this correct:
|
The request is for IPC3 users to align on the host mechanisms for IPC3 config/control of probes, and the recommendation is to make it as close to IPC4 as possible for least effort in tool reuse.
Yes. This PR changes part of that change. |
We faced issues with finding the probe points with ipc_get_comp_by_id, so we used the ipc_get_buffer_by_id. Our changes are under macro, they won't affect other platforms. |
The i.MX host DMA engine cannot transfer data to Linux RAM, so dma_reload() never delivered probe data. Instead, have the DSP write extraction packets directly into a coherent buffer whose bus address the kernel passes in the PROBE_INIT stream_tag field. Add PROBE_HOST_HDR_SIZE, three IPC3-only fields in probe_dma_ext (host_base/size/wr), probe_host_write() and wire it into probe_task() for CONFIG_IPC_MAJOR_3+ZEPHYR_NATIVE_DRIVERS. Use channel 0 in probe_dma_init() for IPC3 since stream_tag now carries an address, not a channel index. Also enable CONFIG_PROBE=y and CONFIG_PROBE_POINTS_MAX=16 for the i.MX8MP EVK ADSP board. Signed-off-by: Stefan Ghetu <stefan.ghetu@nxp.com>
c452c06 to
a638664
Compare
Yes, this is a way we could do it, at first hand I implemented it using ipc_get_comp_dev and it went OK. I am pushing hot fixes for this PR and the kernel one for problems left untreated raised by Copilot. I have tested the workflow and all went good, we could use a similar model to existing IPC4 implementation for ease for the least effort, but do you see any problems with this implementation? If yes, please give me a hard time |
Fixes IPC3 probes on i.MX8MP (Zephyr) and lets probe data reach the host.
every PROBE_POINT_ADD failed with -EINVAL.
a coherent buffer address in the PROBE_INIT stream_tag, and the firmware
memcpy()s packets into it and publishes a byte counter.
Kernel side: thesofproject/linux#6013
Tested on imx8mp-evk with the kernel PR (1 kHz tone extracted fine).