readme: add high level detail around IPC#10592
readme: add high level detail around IPC#10592lgirdwood wants to merge 9 commits intothesofproject:mainfrom
Conversation
High level information about how IPC works and some specifics for IPC3 and IPC4 protocols. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
There was a problem hiding this comment.
Pull request overview
Adds new high-level documentation for the IPC core layer plus separate architecture overviews for IPC3 and IPC4, intended to help readers understand how mailbox interrupts are routed and how protocol-specific handlers process messages.
Changes:
- Added
src/ipc/readme.mddescribing the core IPC layer responsibilities and processing flows. - Added
src/ipc/ipc3/readme.mddocumenting IPC3 command routing and example flows. - Added
src/ipc/ipc4/readme.mddocumenting IPC4 dispatch, pipeline state handling, module binding, and compound messages.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 11 comments.
| File | Description |
|---|---|
| src/ipc/readme.md | New core IPC architecture/flow documentation with diagrams and helper object notes. |
| src/ipc/ipc4/readme.md | New IPC4-specific overview covering dispatch, pipelines, binding, and compound messaging. |
| src/ipc/ipc3/readme.md | New IPC3-specific overview covering command routing, stream trigger, DAI config, and mailbox validation. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| subgraph Module Handler | ||
| Mod --> InitMod[ipc4_init_module_instance] | ||
| Mod --> SetMod[ipc4_set_module_params] | ||
| Mod --> GetMod[ipc4_get_module_params] | ||
| Mod --> Bind[ipc4_bind] | ||
| Mod --> Unbind[ipc4_unbind] | ||
| end |
There was a problem hiding this comment.
Several function names in this dispatch diagram don’t exist in the IPC4 implementation (ipc4_bind, ipc4_unbind, ipc4_set_module_params, ipc4_get_module_params). The actual handlers are named ipc4_bind_module_instance, ipc4_unbind_module_instance, and config is handled via ipc4_set_get_config_module_instance / ipc4_get_large_config_module_instance (etc.). Please update the diagram labels to match real symbols or make them intentionally generic (e.g., “bind module instance”).
There was a problem hiding this comment.
@copilot open a new pull request to apply changes based on this feedback
| IPC3->>IPC3: ipc_get_comp_dev(stream_id) | ||
| IPC3->>Pipe: pipeline_trigger(COMP_TRIGGER_START) |
There was a problem hiding this comment.
The sequence diagram calls ipc_get_comp_dev(stream_id), but the actual call in ipc_stream_trigger() is ipc_get_comp_by_id(ipc, stream.comp_id) (and ipc_get_comp_dev has a different signature). Please adjust the diagram to match the implementation or keep it function-name-agnostic.
There was a problem hiding this comment.
@copilot open a new pull request to apply changes based on this feedback
The doc references sof_task items, but there’s no sof_task symbol/type in this repository. Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Liam Girdwood <lgirdwood@gmail.com>
ipc_get_ppl_comp is described as using “upstream/downstream connection strings”, but the implementation takes a pipeline_id and a direction flag and walks the component/buffer graph (no string-based lookup). Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Liam Girdwood <lgirdwood@gmail.com>
The send-flow diagram references ipc_copy_msg_to_host(), but that symbol doesn’t exist in the codebase. Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Liam Girdwood <lgirdwood@gmail.com>
Typo: “Device Loopup” should be “Device Lookup”. Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Liam Girdwood <lgirdwood@gmail.com>
Grammar: “Routing incoming platform interrupts into the Zephyr or SOF thread domains schedule” reads incorrectly ("schedule" is a noun/verb mismatch).
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Signed-off-by: Liam Girdwood <lgirdwood@gmail.com>
This describes ipc4_process_glb_message() as the primary entry point, but the IPC4 handler entry point is ipc_cmd() (which then dispatches to ipc4_process_glb_message() for FW_GEN messages). Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Liam Girdwood <lgirdwood@gmail.com>
In the ipc4_bind sequence diagram, the steps call comp_set_sink() / comp_set_source(), but these functions don’t exist in the codebase (binding is done via buffer/graph connect + comp_bind/comp_buffer_connect flows). Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Liam Girdwood <lgirdwood@gmail.com>
ipc_cmd_handler() is referenced as the initial routing function, but there is no such symbol in IPC3; the handler entry point is ipc_cmd() Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Liam Girdwood <lgirdwood@gmail.com>
High level information about how IPC works and some specifics for IPC3 and IPC4 protocols.