From owner-freebsd-usb@FreeBSD.ORG Thu Jul 23 19:53:32 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 0E8EF106564A; Thu, 23 Jul 2009 19:53:31 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout028.mac.com (asmtpout028.mac.com [17.148.16.103]) by mx1.freebsd.org (Postfix) with ESMTP id F07AA8FC19; Thu, 23 Jul 2009 19:53:30 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp028.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KN900GM60GISN10@asmtp028.mac.com>; Thu, 23 Jul 2009 11:53:07 -0700 (PDT) From: Marcel Moolenaar Date: Thu, 23 Jul 2009 11:53:06 -0700 Message-id: <3E1658AF-67C6-4E61-B6E7-BEF528C3FF4D@mac.com> To: arm@freebsd.org, usb@freebsd.org X-Mailer: Apple Mail (2.1071.1) Cc: Subject: 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 19:53:32 -0000 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. My $0.02... -- Marcel Moolenaar xcllnt@mac.com