From owner-freebsd-arm@FreeBSD.ORG Mon Aug 27 16:53:31 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9B291106566B; Mon, 27 Aug 2012 16:53:31 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2CDD38FC15; Mon, 27 Aug 2012 16:53:31 +0000 (UTC) Received: by obbun3 with SMTP id un3so11293602obb.13 for ; Mon, 27 Aug 2012 09:53:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=gJHpHTLGok1mdDMngy2k8DW11dnWPLHSjDIlGfmoy5o=; b=ezk1B4AI/J8/l3RTz+S6U95QsnA6aZcxymJbdAgyM5BlQwkdg/RMBmt4Dgjwh2l70q z/1AXux2Ac7RLCGrdDiGhpsbFyAXLMgynAst11zcozzCEGe2BmW/T+8NgIQ1VIjc8x76 cB8Cqif38GOFiNDnLq5VZIpqzgLUJf7Q9RhpESC5G9idEgjqMRxOUt7ZT7n7bBJUuwna dO6mfIgIAo6YJzw2pa7mLjUDpbH+X4sCC4+wqByxReoiWrIVX+bmntHNLgTRI72lwwnr Uf/WlLRWeWQj6Ri5/BINCkEi2RKCcBJGA0lnFjgFj1ngZxTbdwJXxuFy890xokaJcrBf 3CFQ== MIME-Version: 1.0 Received: by 10.182.0.13 with SMTP id 13mr10283841oba.55.1346086410479; Mon, 27 Aug 2012 09:53:30 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.76.8.98 with HTTP; Mon, 27 Aug 2012 09:53:29 -0700 (PDT) In-Reply-To: <1346083716.1140.212.camel@revolution.hippie.lan> 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> <6D83AF9D-577B-4C83-84B7-C4E3B32695FC@bsdimp.com> <1346083716.1140.212.camel@revolution.hippie.lan> Date: Mon, 27 Aug 2012 09:53:29 -0700 X-Google-Sender-Auth: _mn46Ck_2vyos8KJFH_aDJV2o8M Message-ID: From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm@freebsd.org, freebsd-arch@freebsd.org, freebsd-mips@freebsd.org, Hans Petter Selasky Subject: Re: Partial cacheline flush problems on ARM and MIPS X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 16:53:31 -0000 On 27 August 2012 09:08, Ian Lepore wrote: > If two DMAs are going on concurrently in the same buffer, one is going > to finish before the other, leading to a POSTxxxx sync op happening for > one DMA operation while the other is still in progress. The unit of > granularity for sync operations is the mapped region, so now you're > syncing access to a region which still has active DMA happening within > it. Right. But the enforced idea is "DMA up to this point should be flushed to memory." > While I think it's really an API definition issue, think about it in > terms of a potential implementation... What if the CPU had to access the > memory as part of the sync for the first DMA that completes, while the > second is still running? Now you've got pretty much exactly the same > situation as when a driver subdivides a buffer without knowing about the > cache alignment; you end up with the CPU and DMA touching data in the > same cachline and no sequence of flush/invalidate can be g'teed to > preserve all data correctly. Right. So you realise at that point you can't win and you stick each of those pieces in a different cache line. Adrian