[IPC4] make sure not to modify host memory window contents

[lyakh]

Data, sent by the host to the DSP via the memory window should be read-only

[lyakh]

Also the wording "have to make sure ... window isn't modified by DSP" might need to be extended. This itself is not forbidden, but given our current design how we handle IPCs, the code does assume invalidation is only needed when IPCs are received. E.g. this data is read-only to DSP.

@kv2019i is there a good reason to modify that window in SOF? If in the IPC4 protocol that memory is only used for the host->DSP direction, then we better don't write to it. Not sure if the same window is used for the opposite direction IPCs. AFAIU it isn't.

[lyakh]

CI: a single expected sof-logger failure with IPC4 https://sof-ci.01.org/sofpr/PR6426/build1956/devicetest/?model=TGLU_RVP_NOCODEC_IPC4ZPH&testcase=check-sof-logger

[kv2019i]

Code and check results look good. @lgirdwood @dbaluta @mmaka1 @marcinszkudlinski @abonislawski @ranj063 @RanderWang et al, please prioritize review of this PR. We need to merge this quickly as it affects so many files and lines.

[kv2019i]

@lyakh can you give a summary of the most recent push? It's very hard to see from such a long patchset what has changed since last time. And is the series now ok w.r.t. module_adapter users?

[lgirdwood]

@lyakh maybe best to split this PR into smaller chunks, i.e so that less controversial patches can be merged.

[lyakh]

@lyakh maybe best to split this PR into smaller chunks, i.e so that less controversial patches can be merged.

@lgirdwood it might be easier technically but it wouldn't be very useful logically - if you make that area const, you want it const everywhere, not just in some cases. After we merge #6473 this PR will become 2 commits shorted

[lgirdwood]

@jxstelter @dbaluta are the updates good for you ?

[lgirdwood]

@dbaluta can you try this with your DMA based scheduling ?