From owner-freebsd-arch@FreeBSD.ORG Sun Aug 26 18:53:47 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3AE0D106566C; Sun, 26 Aug 2012 18:53:47 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id E46D08FC16; Sun, 26 Aug 2012 18:53:46 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q7QIrb6b086928; Sun, 26 Aug 2012 18:53:37 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id y7e92cf8djshe4rhprsvmx2wr2; Sun, 26 Aug 2012 18:53:37 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: Date: Sun, 26 Aug 2012 11:53:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1345757300.27688.535.camel@revolution.hippie.lan> <3A08EB08-2BBF-4B0F-97F2-A3264754C4B7@bsdimp.com> <1345763393.27688.578.camel@revolution.hippie.lan> <1345765503.27688.602.camel@revolution.hippie.lan> <1345766109.27688.606.camel@revolution.hippie.lan> <1346002922.1140.56.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1278) Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org, "arch@" Subject: Re: Partial cacheline flush problems on ARM and MIPS X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 18:53:47 -0000 On Sun, Aug 26, 2012 at 12:42 PM, Ian Lepore wrote: > On Thu, 2012-08-23 at 22:00 -0600, Warner Losh wrote: >> The bottom line is that you can't mix things like that when cache >> lines are involved. >>=20 > =85. I think we should more explicitly spell out > what the appropriate sequences are. As someone who is just tinkering with driver code for the first time, I applaud any attempts to better document this area! ;-) > In particular: >=20 > * The PRE and POST operations must occur in pairs; a PREREAD must > be followed eventually by a POSTREAD and a PREWRITE must be > followed by a POSTWRITE. > * The CPU is not allowed to access the mapped memory after a PRE > sync and before the corresponding POST sync. > * The DMA hardware is not allowed to access the mapped memory > after a POST sync and before the next PRE sync. These rules sound reasonable. Good documentation might also give examples of what the PRE/POST operations might entail (e.g., from the preceding discussion, it sounds like PREREAD and PREWRITE require at least a partial cache flush on ARM). That helps folks who are coming to the docs with some hardware background. > * Read and write sync operators may be combined in a single = call, > PRE and POST operators may not be. E.G., PREREAD|PREWRITE is > allowed, PREREAD|POSTREAD is not. We should note that while > read and write operations may be combined, on some platforms > PREREAD|PREWRITE is needlessly expensive when only a read is > being performed. PREREAD|POSTREAD doesn't sound useful to me, but why would it be explicitly forbidden? Would you also forbid POSTREAD|PREWRITE? (For a buffer that has just completed a DMA read and is going to be immediately used for a DMA write?) Tim