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 X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D1D31C0650F for ; Mon, 5 Aug 2019 10:39:13 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id A626820679 for ; Mon, 5 Aug 2019 10:39:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="rWbe3JVa" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A626820679 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=DJ6C954qEBH8wfhJ1TNYUwTdy9dsYKD09WlG8/EG/eU=; b=rWbe3JVa+AlrJ0 MeH5EXP8xolMEmrLpqqlhJ2uOozA16T/Eed8Jh/A0UQpy0rQRW8VO7vLILVpeP/7qE9K3gKaI3Fv/ BgsEJMkzIMfawcpKllUy4OoAmlYomZuYR0lsVzct4FR+UEK4GAbCUwpklLjrCaDpDivLzwgEGReHd 6TthI7H3lehbleW3Wc7YD/7KDExhSPvo+nOyMBwnDclupVyokgSqaL5plBjO34jrrJFinjxsOiRf7 2MO7ea2clrbK8F/EvN9T3exxZsYzYW204lh33Shy9Me4VY+UxMz5y3K6UH7bSE786DrofVeqVPCIl uaAmLtt1eYxRUa1CnZTA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1huaOW-0005zs-St; Mon, 05 Aug 2019 10:39:12 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1huaOU-0005zY-1k for linux-arm-kernel@lists.infradead.org; Mon, 05 Aug 2019 10:39:11 +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 A8FD1344; Mon, 5 Aug 2019 03:39:08 -0700 (PDT) Received: from iMac.local (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0F7453F694; Mon, 5 Aug 2019 03:39:07 -0700 (PDT) Date: Mon, 5 Aug 2019 11:39:05 +0100 From: Catalin Marinas To: Will Deacon Subject: Re: [PATCH] arm64: io: Relax implicit barriers in default I/O accessors Message-ID: <20190805103905.GC59981@iMac.local> References: <20190729170518.14271-1-will@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20190729170518.14271-1-will@kernel.org> User-Agent: Mutt/1.11.1 (2018-12-01) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190805_033910_135919_CAC207C6 X-CRM114-Status: GOOD ( 18.67 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Will Deacon , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Jul 29, 2019 at 06:05:18PM +0100, Will Deacon wrote: > As a concrete example, consider the following: > > memcpy(dma_buffer, data, bufsz); > writel(DMA_START, dev->ctrl_reg); > > A DMB ST instruction between the final write to the DMA buffer and the > write to the control register will ensure that the writes to the DMA > buffer are observed before the write to the control register by all > observers. Put another way, if an observer can see the write to the > control register, it can also see the writes to memory. I think one of the counter arguments here were that a device does not "observe" the write to the control register as that's not a master access (by the device). Do you mean that if another CPU (not the device) can observe the writel(), it would have also observed the write to the DMA buffer (assuming the DMB)? Since the device is also an observer of the DMA buffer accesses, the multi-copy atomicity ensures that the device is also seeing the buffer updates following a DMB. If I got this right, I'm fine with the patch ;). > This has always > been the case and is not sufficient to provide the ordering required by > Linux, since there is no guarantee that the master interface of the > DMA-capable device has observed either of the accesses. However, in an > other-multi-copy atomic world, we can infer two things: > > 1. A write arriving at an endpoint shared between multiple CPUs is > visible to all CPUs > > 2. A write that is visible to all CPUs is also visible to all other > observers in the shareability domain > > Pieced together, this allows us to use DMB OSHST for our default I/O > write accessors and DMB OSHLD for our default I/O read accessors (the > outer-shareability is for handling non-cacheable mappings) for shared > devices. Memory-mapped, DMA-capable peripherals that are private to a > CPU (i.e. inaccessible to other CPUs) still require the DSB, however > these are few and far between and typically require special treatment > anyway which is outside of the scope of the portable driver API (e.g. > GIC, page-table walker, SPE profiler). I think there is another class of devices which are not CPU private (USB, network). The buffer here is on-chip and the CPU can't do much other than issuing a DSB (and even this may not be sufficient). The multi-copy atomicity rule would work between CPUs here but not necessarily for the device. Not sure they rely on the barrier in writel(), I guess we can wait and fix them with the mandatory barriers afterwards. In the meantime: Reviewed-by: Catalin Marinas _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel