From owner-freebsd-arm@FreeBSD.ORG Sat Jul 25 03:36:13 2009 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6020D106566B; Sat, 25 Jul 2009 03:36:13 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 1F6498FC20; Sat, 25 Jul 2009 03:36:13 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id n6P3XQV2003836; Fri, 24 Jul 2009 21:33:27 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 24 Jul 2009 23:34:04 -0400 (EDT) Message-Id: <20090724.233404.-399282844.imp@bsdimp.com> To: hselasky@c2i.net From: "M. Warner Losh" In-Reply-To: <200907232209.47729.hselasky@c2i.net> References: <3E1658AF-67C6-4E61-B6E7-BEF528C3FF4D@mac.com> <200907232209.47729.hselasky@c2i.net> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org, usb@freebsd.org Subject: Re: About the "USB Cache and busdma usage in USB" thread 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: Sat, 25 Jul 2009 03:36:13 -0000 In message: <200907232209.47729.hselasky@c2i.net> Hans Petter Selasky writes: : On Thursday 23 July 2009 20:53:06 Marcel Moolenaar wrote: : > All, : > : > I went over the thread and this is what I have to say about it: : > : > Using busdma to manage/control CPU caches is wrong for the : > following simple reason: bus_dmamap_sync() has the side-effect : > of copying to and from the bounce buffer (if applicable). : > : > CPU caches should be kept coherent by using an appropriate API. : > We already have cpu_flush_dcache(). All we have to do is add : > cpu_inval_dcache() and let the MD code determine how best to : > do this -- even if they decide to use busdma. : > : > In general: D-cache and I-cache control/handling should not be : > hidden from MI code. It should not be treated as an artifact of : > some platform. It should not be implemented by banking on some : > side-effect of other function(s). We only achieve efficient : > cache control if MI code calls appropriate APIs so that we can : > precisely express what we need to achieve at that point. : > : > For example: when we write a breakpoint into the text segment : > of some process by using ptrace(2), the ptrace(2) code must : > call an appropriate API to make sure that the I-cache is made : > coherent with memory. This may require a previous D-cache : > flush! We should not kluge uiomove(9) like we did on PowerPC : > to deal with this. Note ARM and ia64 are still broken in this : > respect. : : Hi, : : I would be fine with a solution where cpufunctions are used directly in USB. : The only problem is that if bounce pages are used, which happens in the case : of loading kernel virtual data into DMA, then busdma sync calls would still be : required. They are needed on i386 kernels with more than 4GB of ram... Or ram located above 4GB... Warner