Hi Stefano,
On 22/06/2025 23:15, Stefano Stabellini wrote:
On Thu, 19 Jun 2025, Oleksii Moisieiev wrote:
On 18/06/2025 02:22, Stefano Stabellini wrote:
On Thu, 12 Jun 2025, Oleksii Moisieiev wrote:
[1]:https://git.iliana.fyi/linux/patch/?id=d5141f37c42e0b833863f157ac4cee203b2ba3d2
Keep in mind that [0] refers specifically to access to MMIO regions. I
assume that the SCMI shared buffers are on normal memory? Regarding [1],
it makes sense if Linux is trying to support shared memory over MMIO.
Looking at one of your replies below, I am guessing the memory buffers
are actually in normal memory but the issue is that TF-A is mapping them
as uncacheable. Is that correct?
In that case, I still don't understand why a simple memcpy would not be
sufficient. Can you check?
If yes, then for now I would just simplify it down to memcpy. When
someone adds support for an SCMI server elsewhere we could look into
adding a more sophisticated memcpy and we can look at the details at
that point in time. Specifically, I am not convinced that memcpy_toio
and memcpy_fromio would work if the SCMI server is on a separate
non-coherent microcontroller.
According to the TF-A implementation SCMI memory
is mapped with the flags: MT_DEVICE (like for stm32mp1) or
MT_NON_CACHEABLE (for rpi3)
So probably you're right. I will check with simple memcpy.
There is a difference between MT_DEVICE and MT_NON_CACHEABLE: as far as
I know MT_DEVICE requires aligned accesses while MT_NON_CACHEABLE does
not.
However, as I wrote in the other email, if I am not mistaken the current
implementation of memcpy might work well for us anyway. (To be
confirmed.)
I am not entirely sure what exactly you want to confirm. I have already
mentioned several time that our memcpy() on arm64 is using unaligned
access. So it can't be used for copying data to/from device memory area.
Are you looking for a different things?
Cheers,
--
Julien Grall
