From owner-freebsd-drivers@freebsd.org Fri Oct 9 15:38:55 2015 Return-Path: Delivered-To: freebsd-drivers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 81E879D23F8 for ; Fri, 9 Oct 2015 15:38:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk0-f174.google.com (mail-qk0-f174.google.com [209.85.220.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 43B447A7 for ; Fri, 9 Oct 2015 15:38:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by qkap81 with SMTP id p81so34186570qka.2 for ; Fri, 09 Oct 2015 08:38:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=B879xi6dGWi8UxzfQ5TgaJNriVa6dhcieVrUi6jkej4=; b=HYZawQrUWnJoO6KZUvgKxagQ8KmiZL5YFofrYV2jyfQvQ85h7x+DwQvT6I+qT9+6WI 85tduO0B9tT4GzhjzXDoE7K2EPA8eihDR1OfVJ8zxxxFkK33sCwh3FzdnGKNA5P+jCM8 W/Op2E8hjVSoB2pEaH6wk4wohQInfxZdqZnZmO0wsaeup49kvAxSCcpgcbZbEtdmvyQJ acYzAmolPh/u3aakvWF2yOgRS8XU2wk1Gg1eu1YD4CPyFR2jxYaR7v4ZCCRGTni7CPTz KWCi+OfUBqzz8ssRYwSeTja66OdSDIvyeZp5zxK8+Cuk7jW7VxY8kRmLT7AiaEycJ1+y lLKw== X-Gm-Message-State: ALoCoQkJDwRb07B/fKPRTaO7KXZJfxS/sBjwC5TVgB4R3jdMf3an50Rmg+0LQxZhybqeD9mnRCzW MIME-Version: 1.0 X-Received: by 10.55.24.6 with SMTP id j6mr15851251qkh.93.1444405127842; Fri, 09 Oct 2015 08:38:47 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.140.80.167 with HTTP; Fri, 9 Oct 2015 08:38:47 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <1444392942.1258.YahooMailBasic@web120801.mail.ne1.yahoo.com> References: <20151008223935.GH67524@funkthat.com> <1444392942.1258.YahooMailBasic@web120801.mail.ne1.yahoo.com> Date: Fri, 9 Oct 2015 09:38:47 -0600 X-Google-Sender-Auth: WPa_jV2GJ0R3ejCyTmkNJujcKLg Message-ID: Subject: Re: Memory barrier From: Warner Losh To: Leonardo Fogel Cc: John-Mark Gurney , "freebsd-drivers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 15:38:55 -0000 On Fri, Oct 9, 2015 at 6:15 AM, Leonardo Fogel wrote: > On Thu, 10/8/15, John-Mark Gurney wrote: > > > If this is a PCI device, you need to do a read from the device before > > it is guaranteed that all the bridges have flushed the writes to the > > device... A barrier only guarantees from the processor's perspective > > that the write "has completed", but not that it will reach the device.. > > > > If this is a different bus, then the rules are probably different... > > Good points. I've ignored them. > It is a System-on-Chip based on ARM, which has different buses and > bridges. Device registers are memory-mapped (MMIO). > The formal definition of memory barriers is quite obscure; in simple > terms: memory accesses before the barrier are "observed" before memory > accesses after the barrier. However, the definition of an "observer" is not > provided. Since the device registers are memory-mapped, I've assumed that a > write before the barrier would reach the device before a write after the > barrier. But, on a second thought, the buses and bridges might reorder > them. I really don't know, but, to be on the safe side, I'll include the > read. > Thanks for your attention. > Yes, memory barriers are CPU artifacts. They tell you nothing about what any bridges or other bus technology has done before it reaches the actual device. If you need write ordering in the actual device, you almost certainly need to do a read to act as a write barrier. Warner