From owner-freebsd-mips@FreeBSD.ORG Fri Aug 24 03:56:25 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 485C7106566C for ; Fri, 24 Aug 2012 03:56:25 +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 00D5E8FC08 for ; Fri, 24 Aug 2012 03:56:24 +0000 (UTC) Received: by ialo14 with SMTP id o14so3229653ial.13 for ; Thu, 23 Aug 2012 20:56:24 -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=A8ZRIPSNaFjBDKLw6gxuyEvrrxkJ3KqudBpGidIaZTY=; b=pVCpliFzUAmj29kjdv+US97KVdyi5ImOuqoQrN4DmLuU5i3pQqIwV6wMDSd/gDR4Ja kpCKL4yrcOy3go36RnGR48TmpevR5Cww4fsG+lqJUnGj63GoG4AMqtVMtmAh0A+xME/W dS7bi4MoxP4ZrCaRp7MjGuaSXm2LRd1k6qXS3x5vYNAi+qADMxrDDSUY2vHUgyeO34/J 1YigYznfRoaFiPWHfVYgN2qHhYT3b/VmD68fSJKD6G0cJG6Zhss2kUR5HP0dC96U1+Lh quNvrjQL5hUCUZCcDGuqPLyQG85rehyoEQ5HaK6xRYFJ05JukhMFdQaQ/MBDEiR1/DSc 5SRA== Received: by 10.50.34.131 with SMTP id z3mr649492igi.45.1345780584053; Thu, 23 Aug 2012 20:56:24 -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 va9sm1181375igb.17.2012.08.23.20.56.22 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Aug 2012 20:56:22 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1345765503.27688.602.camel@revolution.hippie.lan> Date: Thu, 23 Aug 2012 21:56:21 -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> To: Ian Lepore X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmjnduhkKMiTmQRXljKd62NU3Zue7JhFw0vTwpE8wZzkkzUlSYi7dzKJPN4GcoelXY404uw Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org, freebsd-arch@freebsd.org 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: Fri, 24 Aug 2012 03:56:25 -0000 On Aug 23, 2012, at 5:45 PM, Ian Lepore wrote: > On Thu, 2012-08-23 at 17:26 -0600, Warner Losh wrote: >>> On Aug 23, 2012, at 3:28 PM, Ian Lepore wrote: >>> Now we have a new type of constraint, I think of it as = "granularity". >>> In effect, we have a DMA system that can only do DMA in cacheline = sized >>> chunks. Even when the IO size -- and thus the number of "bits on = the >>> wire" -- is less than the cacheline size, at the end of the DMA >>> operation (which includes the software-assisted coherency = operations) >>> the number of bytes in memory that may be modified is the size of a >>> cacheline. This is because "the DMA system" is not just the engine = that >>> moves bytes around, it's the combination of hardware and software = that >>> work together to maintain cache coherency. >> But this isn't new. It is an alignment requirement, which carries >> with it an implicit size requirement. If you enforce the alignment, >> and force all 'sub buffers' to have this alignment, you don't need = the >> new thing.=20 >=20 > So do you think it's safe to assume that any given dma tag that has an > alignment constraint also implicitly has a buffer size constraint that > the size must be a multiple of the alignment? Yes. If something must be aligned to N bits, chances are it doesn't = decode the lower N bits which implies a size constraint. > What if we have a platform with a 32-byte cacheline / DMA granularity, > and then we have a builtin device on that SoC which can only do DMA on = a > 64K alignment (which its tag would reflect), but the hardware can move > as little as 1 byte at a time? Children of that bridge device come > along and allocate little 16-byte buffers that eat 16 pages each. It > doesn't seem all that far-fetched to me. This would be a very odd hardware. DMA aligned to 64k that can only = move one byte seems far fetched. How useful would such a design be? = How would you do scatter gather on such a design? But this isn't what I'm saying. If the cache line size is 32, then for = DMA we only ever give out chunks of 32 or larger. In that case, the = split cache line situation you gave as an example can't happen.=