On Tue, Aug 13, 2024 at 11:07:47AM -0700, Florian Fainelli wrote:
Some shared memory areas might only support a certain access width,
such as 32-bit, which memcpy_{from,to}_io() does not adhere to at least
on ARM64 by making both 8-bit and 64-bit accesses to such memory.
Update the shmem layer to support reading from and writing to such
shared memory area using the specified I/O width in the Device Tree. The
various transport layers making use of the shmem.c code are updated
accordingly to pass the I/O accessors that they store.
Hi Florian,
I gave it ago at this on a JUNO regarding the mailbox/shmem transport
without any issue. I'll have a go later on an OPTEE/shmem scenario too.
This looks fundamentally good to me, since you moved all ops setup at
setup time and you keep the pointers per-channel instead of global...
A few remarks down below.
Signed-off-by: Florian Fainelli <florian.fainelli@xxxxxxxxxxxx>
... I may be missing a lot here...bear with me...so...
... AFAIU, as suggested by Peng, you moved away from iowrite##s and ioread##s
in favour of __raw_write/read##w so as to avoid the implicit barriers on each
loop iteration...(I suppose..)
...but should we place some sort of final io barrier (similarly to iowrite)
at the end of the loop ?
+static inline void shmem_memcpy_toio##s(volatile void __iomem *to, \
+ const void *from, \
+ size_t count) \
+{ \
+ while (count) { \
+ __raw_write##w(*(u##s *)from, to); \
+ from += amt; \
+ to += amt; \
+ count -= amt; \
+ } \
+}
...same concern here
+static struct scmi_shmem_io_ops shmem_io_ops##s = { \
+ .fromio = shmem_memcpy_fromio##s, \
+ .toio = shmem_memcpy_toio##s, \
+};
+
There are a bunch of warn/errs from checkpatch --strict, beside the volatile
here and on the previous typedefs, also about args reuse and trailing semicolon
in these macros...