From owner-freebsd-arm@FreeBSD.ORG Mon Aug 3 15:21:18 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 9E2BE106567B; Mon, 3 Aug 2009 15:21:18 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id EC76D8FC24; Mon, 3 Aug 2009 15:21:17 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from [10.0.0.34] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 0DFECC426C; Mon, 3 Aug 2009 16:59:09 +0200 (CEST) Message-Id: <8DC8C704-F84D-4A60-A11B-2F877EB903C9@semihalf.com> From: Rafal Jaworowski To: Hans Petter Selasky In-Reply-To: <20090724.233404.-399282844.imp@bsdimp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 3 Aug 2009 17:01:37 +0200 References: <3E1658AF-67C6-4E61-B6E7-BEF528C3FF4D@mac.com> <200907232209.47729.hselasky@c2i.net> <20090724.233404.-399282844.imp@bsdimp.com> X-Mailer: Apple Mail (2.935.3) 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: Mon, 03 Aug 2009 15:21:29 -0000 On 2009-07-25, at 05:34, M. Warner Losh wrote: > 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... Hans, So how do you want to proceed with these cache sync issues? We need to fix this before 8.0. Rafal