From owner-freebsd-usb@FreeBSD.ORG Thu Jul 23 20:10:01 2009 Return-Path: Delivered-To: usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8D32106564A for ; Thu, 23 Jul 2009 20:10:01 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 803BC8FC25 for ; Thu, 23 Jul 2009 20:10:01 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=uXAB73GHeBQA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=n8i6e8dZgnT8OozT7QIA:9 a=xrXtKjxkOyuRuyI7wFfghJIjHEMA:4 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 229393225; Thu, 23 Jul 2009 22:10:00 +0200 From: Hans Petter Selasky To: Marcel Moolenaar Date: Thu, 23 Jul 2009 22:09:45 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <3E1658AF-67C6-4E61-B6E7-BEF528C3FF4D@mac.com> In-Reply-To: <3E1658AF-67C6-4E61-B6E7-BEF528C3FF4D@mac.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907232209.47729.hselasky@c2i.net> Cc: arm@freebsd.org, usb@freebsd.org Subject: Re: About the "USB Cache and busdma usage in USB" thread X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 20:10:02 -0000 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. --HPS