From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7005BC61D97 for ; Fri, 24 Nov 2023 15:33:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=EPMtsHQKtF5keL9M5JY59s8NdLHrfUdEnk9j6GV+Ys8=; b=WNvaD+KQ2VqY6q L/MkETaqh3l1zrMG7hZo/qYmxJR5MT4mvAvWpRXc1tTtvujHll2oQtVTcstXzIV2QbmqV9AovoH8/ ZC7LbJqD0udp05mVCxq1OeiELNSfdZwApglQ9gNIxB1u48X1+fnqVvD8FgqU+ueaD/C6iBJq+ia2S sdpSfvsB1KpF/z1WPEQ9r4iTkPtgJGJUbOMWR0kVrzzwnAioxB4nBlx9vu16l6LY2qWoROwoYS8Ia 8ARL4LSelzTrrn/edZ+wPezQpIapqlMG3h1m9eNMBHTzZWqrW2gdpwNkm3G0fwXcs3y91IANFtSm0 h8mAIoj7R41DlMUZwQiA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1r6YAo-007YUL-00; Fri, 24 Nov 2023 15:32:54 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1r6YAm-007YTs-0D for linux-arm-kernel@lists.infradead.org; Fri, 24 Nov 2023 15:32:53 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3B57B1063; Fri, 24 Nov 2023 07:33:35 -0800 (PST) Received: from [10.1.196.40] (e121345-lin.cambridge.arm.com [10.1.196.40]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 571163F73F; Fri, 24 Nov 2023 07:32:47 -0800 (PST) Message-ID: <5d33d112-32f2-466e-b542-5fd4e43ea31c@arm.com> Date: Fri, 24 Nov 2023 15:32:46 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH rdma-next 1/2] arm64/io: add memcpy_toio_64 Content-Language: en-GB To: Jason Gunthorpe Cc: Leon Romanovsky , Arnd Bergmann , Catalin Marinas , linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rdma@vger.kernel.org, llvm@lists.linux.dev, Michael Guralnik , Nathan Chancellor , Nick Desaulniers , Will Deacon References: <2fccdb30-aad0-4334-89d1-d4c86d17c9fc@arm.com> <20231124134501.GD436702@nvidia.com> From: Robin Murphy In-Reply-To: <20231124134501.GD436702@nvidia.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231124_073252_157584_0EB3C8DF X-CRM114-Status: GOOD ( 19.47 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 24/11/2023 1:45 pm, Jason Gunthorpe wrote: > On Fri, Nov 24, 2023 at 12:58:11PM +0000, Robin Murphy wrote: >>> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h >>> index 3b694511b98f..73ab91913790 100644 >>> --- a/arch/arm64/include/asm/io.h >>> +++ b/arch/arm64/include/asm/io.h >>> @@ -135,6 +135,26 @@ extern void __memset_io(volatile void __iomem *, int, size_t); >>> #define memcpy_fromio(a,c,l) __memcpy_fromio((a),(c),(l)) >>> #define memcpy_toio(c,a,l) __memcpy_toio((c),(a),(l)) >>> +static inline void __memcpy_toio_64(volatile void __iomem *to, const void *from) >>> +{ >>> + const u64 *from64 = from; >>> + >>> + /* >>> + * Newer ARM core have sensitive write combining buffers, it is >>> + * important that the stores be contiguous blocks of store instructions. >>> + * Normal memcpy does not work reliably. >>> + */ >>> + asm volatile("stp %x0, %x1, [%8, #16 * 0]\n" >>> + "stp %x2, %x3, [%8, #16 * 1]\n" >>> + "stp %x4, %x5, [%8, #16 * 2]\n" >>> + "stp %x6, %x7, [%8, #16 * 3]\n" >>> + : >>> + : "rZ"(from64[0]), "rZ"(from64[1]), "rZ"(from64[2]), >>> + "rZ"(from64[3]), "rZ"(from64[4]), "rZ"(from64[5]), >>> + "rZ"(from64[6]), "rZ"(from64[7]), "r"(to)); >> >> Is this correct for big-endian? LDP/STP are kinda tricksy in that regard. > > Uh.. I didn't think about it at all.. > > By no means do I have any skill reading the ARM documents, but I think > it is OK, it says: > > Mem[address, dbytes, AccType_NORMAL] = data1; > Mem[address+dbytes, dbytes, AccType_NORMAL] = data2; > > So I understand that as > > Mem[%8, #16 * 0, 8, AccType_NORMAL] = from64[0] > Mem[%8, #16 * 0 + 1 , 8, AccType_NORMAL] = from64[1] > Mem[%8, #16 * 1, 8, AccType_NORMAL] = from64[2] > Mem[%8, #16 * 1 + 1, 8, AccType_NORMAL] = from64[3] > .. > > Which is the same on BE/LE? > > But I don't know the pitfall to watch for here. This is memcpy so we > don't have to swap, the order of the bits in the register doesn't > matter. Indeed you're right - all the way back to Armv7 LDRD/STRD, I always get caught out by remembering the path which does an endian-dependent swap of the target registers, but forgetting that that's there to *counteract* the byteswap in Mem[] itself. Cheers, Robin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel