Il 17/03/25 09:38, Jjian Zhou ha scritto:
The VCP mailbox has 5 groups. Each group has corresponding interrupts, registers, and 64 slots (each slot is 4 bytes). Since different features share one of the mailbox groups, the VCP mailbox needs to establish a send table and a receive table. The send table is used to record the feature ID, mailbox ID, and the number of slots occupied. The receive table is used to record the feature ID, mailbox ID, the number of slots occupied, and the receive options. The API setup_mbox_table in mtk-vcp-ipc.c calculates the slot offset and pin index for each feature ID based on the mailbox ID and slot number in the send and receive tables (several slots form a pin, and each pin can trigger an interrupt). These descriptions are written in the mtk-vcp-ipc.c file -- we call it the IPC layer. We have two questions: How should we describe the mailbox and IPI? Can the intermediate IPC layer be rewritten as a virtual mailbox layer?
So, for this remote processor messaging system you have: - Dynamic channel allocation - Each channel has its own endpoint - Each channel has its own interrupt - Data send operation - Both with and without ACK indication from the remote processor - To channel -> endpoint - Data receive operation - From channel <- endpoint - When interrupt fires - Could use polling to avoid blocking in a few cases - A custom message structure not adhering to any standard Check drivers/rpmsg/ :-) On MediaTek platforms, there are many IPI to handle in many subsystems for all of the remote processors that are integrated in the SoC and, at this point, you might as well just aggregate all of the inter processor communication stuff in one place, having an API that is made just exactly for that, instead of keeping to duplicate the IPI stuff over and over (and yes I know that for each remote processor the TX/RX is slightly different). If you aggregate the IPI messaging in one place, maintenance is going to be easier, and we stop getting duplication... more or less like it was done with the mtk_scp IPI and mtk-vcodec .. and that's also something that is partially handled as RPMSG because, well, it is a remote processor messaging driver. Just to make people understand *how heavily* MediaTek SoCs rely on IPI, there's a *partial* list of SoC IPs that use IPI communcation: thermal, ccu, ccd, tinysys, vcp, atsp, sspm, slbc, mcupm, npu, mvpu, aps, mdla, qos, audio, cm_mgr.... and... again, it's a partial list! That said... any other opinion from anyone else? Cheers, Angelo
Example of send and recve table: Operation | mbox_id | ipi_id | msg_size | align_size | slot_ofs | pin_index | notes send 0 0 18 18 0 0 recv 0 1 18 18 18 9 send 1 15 8 8 0 0 send 1 16 18 18 8 4 send 1 9 2 2 26 13 recv 1 15 8 8 28 14 ack of send ipi_id=15 recv 1 17 18 18 36 18 recv 1 10 2 2 54 27 ack of send ipi_id=2 send 2 11 18 18 0 0 send 2 2 2 2 18 9 send 2 3 3 4 20 10 send 2 32 2 2 24 12 recv 2 12 18 18 26 13 recv 2 5 1 2 44 22 recv 2 2 1 2 46 23 Recv ipi_id=2 is the ack of send ipi_id=2(The ipi_id=15 is the same.) Jjian Zhou (3): mailbox: mediatek: Add mtk-vcp-mailbox driver firmware: mediatek: Add vcp ipc protocol interface dt-bindings: mailbox: mtk,vcp-mbox: add mtk vcp-mbox document .../bindings/mailbox/mtk,mt8196-vcp-mbox.yaml | 49 ++ drivers/firmware/Kconfig | 9 + drivers/firmware/Makefile | 1 + drivers/firmware/mtk-vcp-ipc.c | 481 ++++++++++++++++++ drivers/mailbox/Kconfig | 9 + drivers/mailbox/Makefile | 2 + drivers/mailbox/mtk-vcp-mailbox.c | 179 +++++++ include/linux/firmware/mediatek/mtk-vcp-ipc.h | 151 ++++++ include/linux/mailbox/mtk-vcp-mailbox.h | 34 ++ 9 files changed, 915 insertions(+) create mode 100644 Documentation/devicetree/bindings/mailbox/mtk,mt8196-vcp-mbox.yaml create mode 100644 drivers/firmware/mtk-vcp-ipc.c create mode 100644 drivers/mailbox/mtk-vcp-mailbox.c create mode 100644 include/linux/firmware/mediatek/mtk-vcp-ipc.h create mode 100644 include/linux/mailbox/mtk-vcp-mailbox.h
