From owner-freebsd-mips@FreeBSD.ORG Mon Aug 27 01:26:09 2012 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E6B57106564A; Mon, 27 Aug 2012 01:26:09 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9BEEE8FC16; Mon, 27 Aug 2012 01:26:09 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so6609002pbb.13 for ; Sun, 26 Aug 2012 18:26:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=buRkMCmZXq3F4Cc5OBO5pchRTJfQaZIQI48CqnG/UVM=; b=PAnNo8QWePhAymqZ/mWGbYh8Urc23Jl/DWWf7mLRxsT+q8Oxkez8Ol9YphyhVM3q35 x/ASzYBiRdpuZhiL4yVUHmVmQkRfh5DgoUCSEMxG862EH+bdfqJ/t1lUxC74+V4NwP9X IMQ1/qx0CsZW79aQogmq3fkNjK/c6aBIlf1Rg8vNjATaoGxRqTsGunzWDw50lXV5K+sG 7W9419jOZyDWkUxOu483e5zgItkzYa9JddxiLzDftB90igFeVRO9mKbjHmdA+jT8lxeS LDve5jhPhL6WMxa0canqUNYzriSRFegQcasvJtHFx6zV/HjHn2eqZaRK+Gl9lyoq+Zwp h0DQ== MIME-Version: 1.0 Received: by 10.68.129.131 with SMTP id nw3mr30406099pbb.43.1346030769022; Sun, 26 Aug 2012 18:26:09 -0700 (PDT) Received: by 10.68.36.106 with HTTP; Sun, 26 Aug 2012 18:26:08 -0700 (PDT) Received: by 10.68.36.106 with HTTP; Sun, 26 Aug 2012 18:26:08 -0700 (PDT) In-Reply-To: <26F65164-EC99-483E-9FA8-916AD99CBCBC@bsdimp.com> 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> <1346011312.1140.107.camel@revolution.hippie.lan> <26F65164-EC99-483E-9FA8-916AD99CBCBC@bsdimp.com> Date: Sun, 26 Aug 2012 18:26:08 -0700 Message-ID: From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-arm@freebsd.org, "arch@" , freebsd-mips@freebsd.org, Tim Kientzle 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: Mon, 27 Aug 2012 01:26:10 -0000 Hm. So perhaps we should document the busdma assumptions with respect to alignment and coherency? So this doesnt happen again? Adrian On Aug 26, 2012 4:19 PM, "Warner Losh" wrote: > > On Aug 26, 2012, at 2:01 PM, Ian Lepore wrote: > > > On Sun, 2012-08-26 at 11:53 -0700, Tim Kientzle wrote: > >> 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. > >> > > > > I agree, I think it would be good to have something like a RATIONALE > > section in the manpage that summarizes the issues faced by various > > categories of platform (hardware coherency, software-assisted coherency, > > etc) and how they handle it. You don't want people coding to the > > implementation (some of which is going on now, and I've been guilty of > > it myself); if there were more info in the docs there'd be less > > motivation to peek at the implementation. > > More documentation is good. > > >>> * 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?) > > > > My thinking on forbidding PREREAD|POSTREAD is at least partly that it > > removes some temptation to do the wrong thing: treat the busdma API as > > if it were a general cpu cache manipulation library. > > I think it should be read as POSTREAD + PREREAD, not PREREAD + POSTREAD. > > > With the new definition of the sequences, a PREREAD|POSTREAD operation > > is nonsensical because it leaves no window during which the DMA hardware > > has access to memory; it is in effect a no-op. If you think in terms of > > implementation you might think "This would have to cause a cache > > invalidation." If you think in terms of API you should be thinking > > something more like "This marks out a time window during which the DMA > > hardware has safe access to that memory which has a duration of zero." > > Acutally, it would allow one to shift the DMA from one device to another, > if read the way I say above. > > > POSTREAD|PREWRITE is interesting. It is not a no-op in terms of the > > API. It closes the hardware access window that was opened by an earlier > > PREREAD, and it opens a new hardware access window with the PREWRITE. > > Whether it touches hardware or caches or anything in a given > > implementation isn't the point, in terms of the API it's the right thing > > to do for a pair of back to back DMA operations, without intervening CPU > > access, on the same memory. > > Right. This is useful in many cases. Consider a log structured device > that reads data into memory, and then writes it back to the tail of the log > as a defragging operation. > > > So PREREAD|POSTREAD and PREWRITE|POSTWRITE make no sense, but all other > > combos should be allowed. Maybe instead of allowing and forbidding > > specific combos, we should just advise that these two are effectively > > no-ops. > > I respectfully disagree.. > > Warner > > _______________________________________________ > 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" >