From owner-freebsd-mips@FreeBSD.ORG Sun Aug 26 23:15:30 2012 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFF291065670 for ; Sun, 26 Aug 2012 23:15:30 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 637438FC12 for ; Sun, 26 Aug 2012 23:15:30 +0000 (UTC) Received: by ialo14 with SMTP id o14so8781100ial.13 for ; Sun, 26 Aug 2012 16:15:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=iYEhywsT8AYLxmmanrymiKw7wLde2oh04bmK21Zf8Ko=; b=N9JGq+hS2L+QUV6SIhGPcUBfFd326O3Uso9z0jXWUFdo3cCXteGsV64LkC8In0Fxhg BlZO8wk474f24/YhCOnm2IBWXG/RgiTOmRdm2YC5DfMDnoEmLs+RYhycxeSkCMw6Jra1 ywdXdQFOwVADEBkJAPOUs7ZM7T+JV/BjgCE7E2E4LBjLYwEZ3fVXueTraGiET6HiJoZJ rtdzTnNLusN+1bMT2UH2PZzStWvT9ClNtjit7DEL5UcFI0Gk0b8D3nM6/0FC5Xpz7zJf 4u2DWxPMMq5na+RNx0l6G5bRDrDF+xBfL2TdYHoxrIRtKTp1XaLbLOgDspKhP6tjc9bH Aw2A== Received: by 10.50.195.169 with SMTP id if9mr2347874igc.62.1346022930007; Sun, 26 Aug 2012 16:15:30 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id s2sm9413489igb.5.2012.08.26.16.15.27 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 26 Aug 2012 16:15:28 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warner Losh In-Reply-To: Date: Sun, 26 Aug 2012 17:15:26 -0600 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: Tim Kientzle X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQlRJnkl6+SWuV2JJhKTohXlcqDGseazaCaCoETwoCdVvXj2x47oLFqT4TtUl1gWJW8sFhum Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org, "arch@" Subject: Re: Partial cacheline flush problems on ARM and MIPS X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 23:15:30 -0000 On Aug 26, 2012, at 12:53 PM, Tim Kientzle wrote: >=20 > 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. >=20 >=20 > As someone who is just tinkering with driver code for > the first time, I applaud any attempts to better document > this area! ;-) >=20 >> 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. >=20 >=20 > 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. >=20 >> * 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. >=20 >=20 > PREREAD|POSTREAD doesn't sound useful to me, but > why would it be explicitly forbidden? It could be useful when DMAing from multiple devices. Let's say I have = a buffer that I want to get data from two different DMA operations. = Wouldn't this be how you'd specify it? > 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?) This could be useful for some zero-copy things, no? Warner > Tim >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"