Tomasz Leman
Tomasz Leman
Update: Leaving as **DNM** due to ongoing internal discussion about what the correct behavior should be.
I'm closing this PR. Together with the architect, I determined that the current implementation is correct and there is no reason to change it at this time.
> I still don't know why exactly this is needed - "improving the flexibility" doesn't tell me much The implementation of the IPC4_DMA_CONTROL message handling is a requirement for SOF...
> I guess we are blocked until after Zephyr merge Window ? @lgirdwood Yes, this change is blocked until the release of Zephyr LTS.
~~In internal [builds](https://sof-ci.01.org/sofpr/PR9470/build8701/build/firmware_community/tgl.log), there is a visible regression for TGL. The FW does not build with the top of the main branch of Zephyr. @lgirdwood could someone take a look...
Ok, I see how using a more generic interface is beneficial and simply the right approach. However, this interface doesn't fit our hardware and checking a checkbox is a weak...
@kv2019i wrote: > ipc_platform_send_msg() sent the whole message (header + payload) and platform drivers implemented this in different ways (on different hardware). It seems to me that you are forcibly...
> Currently, for IPC, Intel uses src/ipc/ipc-zephyr.c file which directly talks to a Intel ADSP driver interface of one particular hardware type. I think this implementation doesn't address this problem....
> I'm still not fully understanding the problem with 'len'. ```txt @param[in] len Number of bytes to send. ``` > I don't think this PR changes this and I'd assume...