Re: [PATCH v5 04/17] octeontx2-pf: Initialize and config queues
From: David Miller <davem@davemloft.net>
Date: 2020-01-26 11:01:05
From: sunil.kovvuri@gmail.com Date: Fri, 24 Jan 2020 23:15:42 +0530
quoted hunk ↗ jump to hunk
@@ -184,6 +192,72 @@ static inline void otx2_mbox_unlock(struct mbox *mbox) mutex_unlock(&mbox->lock); } +/* With the absence of API for 128-bit IO memory access for arm64, + * implement required operations at place. + */ +#if defined(CONFIG_ARM64) +static inline void otx2_write128(u64 lo, u64 hi, void __iomem *addr) +{ + __asm__ volatile("stp %x[x0], %x[x1], [%x[p1],#0]!" + ::[x0]"r"(lo), [x1]"r"(hi), [p1]"r"(addr)); +} + +static inline u64 otx2_atomic64_add(u64 incr, u64 *ptr) +{ + u64 result; + + __asm__ volatile(".cpu generic+lse\n" + "ldadd %x[i], %x[r], [%[b]]" + : [r]"=r"(result), "+m"(*ptr) + : [i]"r"(incr), [b]"r"(ptr) + : "memory"); + return result; +} + +#else +#define otx2_write128(lo, hi, addr) +#define otx2_atomic64_add(incr, ptr) ({ *ptr = incr; }) +#endif
So what exactly is going on here? Are these true 128-bit writes and atomic operations? Why is it named atomic64 then? Why can't the normal atomic64 kernel interfaces be used? Finally why is the #else case doing an assignment to *ptr rather than an increment like "*ptr += incr;"?