Received: by 10.192.165.156 with SMTP id m28csp214526imm; Tue, 17 Apr 2018 08:58:17 -0700 (PDT) X-Google-Smtp-Source: AIpwx48LHCQI1y5dsSC+dCIfXFmSlESSaAdTGnSn5z57pXrdYvnNo2O1pvXXACWRcDWKbFy4TVsD X-Received: by 10.101.87.136 with SMTP id b8mr2256496pgr.282.1523980697397; Tue, 17 Apr 2018 08:58:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523980697; cv=none; d=google.com; s=arc-20160816; b=Z+PJNN1EThOrxuAVIlCoFBhrMVBxLdRVPhaFd/kwnCz5ZDnn+NCzBVU1ECwQ9V/6LW vhy9s7kRKo6sO0qCbapXAkK1b/bso48ULsfZtHuwhZnBTPlFVKKoCOKaZukwU6rMlyyE S6DBEkS3xD95bzXyiP00uKooHPKbEepPdUPlJjGkDjDpMdc4VGRHaPhq1TnljXJxqi0C qUOU/Q1sIpdou4YCKKlkQe4tj2KQX8IQxi8LQ4K7jZ/6zjWvR9fOEZB6VTFfQ7U/l5y3 15gJS5s8beWB1LVt1hFfPLVv7plpK8KYNrKFetr90zP1S8PuZ0p+tya50d4mtzQ4pEMS Hung== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :dkim-signature:arc-authentication-results; bh=LMTzPy6jABguNYoMCZlOZ86me0wrd2UcWgB4weit2S0=; b=oM1Lpkz3m/n/5zXjntBLY8tdoKBPZAYvdrVFiJYFPfTHPlWk8Zl1YDzhJ4Ac79Qq5V fLmYcQB7KD110Rayxlb3z86fAqUd035HEYP3Bj76tAwyMBZxO5jqY/g5gX5frAdVH6l+ UcrhuvjZ1ERaHlRDE1fJnBOh0fDutKniPoazy4bJcLXMp6Ph+PZ+bbfNtvkvJwXRpFBh JihHYSkrlDIU/KyetSfd01BRrJF2Gl6caPhx0Tzq2fiY58dlPfF7xQpqL04ZG6Sgcc7a DxYQbRaKm9kLJmBa4fo8Zul/j2NZrPRcwIy5+aDYGf1FVdSAsLrx0WElKJw1PpXRH8fH 7Yug== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@hansenpartnership.com header.s=20151216 header.b=t9JGPo+Z; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=hansenpartnership.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e1si11869453pgu.537.2018.04.17.08.58.03; Tue, 17 Apr 2018 08:58:17 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@hansenpartnership.com header.s=20151216 header.b=t9JGPo+Z; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=hansenpartnership.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753541AbeDQPzT (ORCPT + 99 others); Tue, 17 Apr 2018 11:55:19 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:53062 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753068AbeDQPzP (ORCPT ); Tue, 17 Apr 2018 11:55:15 -0400 Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id 4F4278EE264; Tue, 17 Apr 2018 08:55:14 -0700 (PDT) Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifHtN0GTqz5B; Tue, 17 Apr 2018 08:55:14 -0700 (PDT) Received: from [10.1.129.202] (unknown [141.170.9.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id 1E53C8EE0E2; Tue, 17 Apr 2018 08:55:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=20151216; t=1523980514; bh=v/UKIDc/Pi/LuunlBslGSY3xfDh38867K6ajo5obXpY=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=t9JGPo+ZuMGFj79AHMsOoDscZIQN3bSCHCgq0NWFZ2zxhTju1Tlk1PmYlXuUZjztq cLA04UrxHwZ1GMs0c9y3BX4KOcDkvJHx6TG4oRiPZQfAjzO8tgXLmQPGIwDyu0CsPB 8Eqvm3VxZoUqWCJD2fS9guSUDamvLZxj53s+DH8Q= Message-ID: <1523980508.3310.9.camel@HansenPartnership.com> Subject: Re: [PATCH v2 2/2] parisc: define stronger ordering for the default readX() From: James Bottomley To: Sinan Kaya , linux-parisc@vger.kernel.org, arnd@arndb.de, timur@codeaurora.org, sulrich@codeaurora.org Cc: linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Helge Deller , Philippe Ombredanne , Kate Stewart , Thomas Gleixner , Greg Kroah-Hartman , linux-kernel@vger.kernel.org Date: Tue, 17 Apr 2018 16:55:08 +0100 In-Reply-To: <38a1d4e3-cabe-6c39-4355-8d8111637382@codeaurora.org> References: <1523938133-3224-1-git-send-email-okaya@codeaurora.org> <1523938133-3224-2-git-send-email-okaya@codeaurora.org> <1523957852.3250.9.camel@HansenPartnership.com> <38a1d4e3-cabe-6c39-4355-8d8111637382@codeaurora.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2018-04-17 at 10:13 -0400, Sinan Kaya wrote: > Hi James, > > > > > Perhaps if you gave an example of the actual problem you're trying > > to fix we could assess if it affects parisc. > > Let me clarify myself here. Maybe, there is a better solution. > > /* assign ownership */ > desc->status = DEVICE_OWN; > > /* notify device of new descriptors */ > writel(DESC_NOTIFY, doorbell); > > The difference between writel() and writel_relax() is writel() > guarantees memory transactions to be flushed to the device before the > register write. Um, no it doesn't, at least not in PCI. It guarantees the write will be issued by the memory system, but it may still be cached (called posting) in the PCI bridge. So it doesn't guarantee the write reaches the device by the time it returns. > writel_relaxed() does not provide any guarantees about the memory > and IO operations. > > Similarly, readl() provides following code to observe the DMA result > while readl_relaxed() does not provide this guarantee. Right, the relaxed operator provides no guarantee of ordering between the memory and IO domains. However, it's only really a problem on multiple memory controller systems (i.e. NUMA). Parisc (except superdome, which we don't support) doesn't have this problem. We also turn of CPU stream reordering, so compile order is retire order on our CPUs (which makes life a lot simpler). > Ideally, you want to embed rmb() and wmb() into the writel() and > readl() to provide this guarantee. > > PA-RISC doesn't seem to support neither one of the barrier types. If > you are familiar with the architecture, maybe you could guide us > here. > > Is __raw_writeX() enough to provide this guarantee for this > architecture? Well, with the volatile address it is. The current implementations provide the expected semantics: namely the position in the instruction stream is compile (retire) ordered and issued from memory once retired. We still do have the write posting problem, but you'll find additional reads in the drivers to flush the posted writes, so I don't actually believe we need anything changing. James