From owner-freebsd-usb@FreeBSD.ORG Tue Jun 23 17:12:55 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E43B1065694; Tue, 23 Jun 2009 17:12:55 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe14.swip.net [212.247.155.161]) by mx1.freebsd.org (Postfix) with ESMTP id EDCAF8FC21; Tue, 23 Jun 2009 17:12:54 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=Hrwt8fWgTlIA:10 a=j+k/Ze5hWUCaCztCgEjzDQ==:17 a=oCJs8q-oAAAA:8 a=kdlGoFePcdDG4S50R14A:9 a=cV4sW9QyIsatbICQGa0QX_2l6coA:4 a=jj60i5uE5qAA:10 Received: from [81.191.55.181] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe14.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 522637706; Tue, 23 Jun 2009 19:12:53 +0200 From: Hans Petter Selasky To: Alexandr Rybalko Date: Tue, 23 Jun 2009 19:12:19 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; i386; ; ) References: <200906231035.43096.kosmo@semihalf.com> <20090623121129.d18492a3.ray@dlink.ua> In-Reply-To: <20090623121129.d18492a3.ray@dlink.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200906231912.20741.hselasky@c2i.net> Cc: freebsd-usb@freebsd.org, Rafal Jaworowski , thompsa@freebsd.org Subject: Re: CPU Cache and busdma usage in USB 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: Tue, 23 Jun 2009 17:12:56 -0000 On Tuesday 23 June 2009 11:11:29 Alexandr Rybalko wrote: > On Tue, 23 Jun 2009 10:35:42 +0200 > > Piotr Zi=C4=99cik wrote: > >> While bringing up EHCI (8-CURRENT, new USB stack) on ARM machine we > >> have found cache-related problem in the USB stack. > >> > >> The usb_pc_cpu_flush() and usb_pc_cpu_invalidate() functions are used = to > >> flush/invalidate CPU caches in various places in USB code. Internally, > >> the functions are implemented using bus_dmamap_sync(). In our case, on > >> ARM machine, flags passed to the bus_dmamap_sync() function did not > >> correspond with requested operation. We have fixed the problem by > >> changing flags passed to the bus_dmamap_sync() function (see attached > >> patch). > >> > >> My question is about general idea of bus_dma usage for cache operation= s. > >> In my opinion we should not rely on bus_dmamap_sync() behaviour as this > >> function may do different things on different architectures. This not > >> always works as expected, which is clearly visible in our case. Better > >> solution is to use cpu-specific functions implementing cache operation= s. > >> Please comment on why CPU-specific functions are not used... > >> > >> Patch fixing our problem: > >> diff --git a/sys/dev/usb/usb_busdma.c b/sys/dev/usb/usb_busdma.c > >> index 3d6a5be..69a6fff 100644 > >> --- a/sys/dev/usb/usb_busdma.c > >> +++ b/sys/dev/usb/usb_busdma.c > >> @@ -658,8 +658,7 @@ usb_pc_cpu_invalidate(struct usb_page_cache *pc) > >> /* nothing has been loaded into this page cache! */ > >> return; > >> } > >> - bus_dmamap_sync(pc->tag, pc->map, > >> - BUS_DMASYNC_POSTWRITE | BUS_DMASYNC_POSTREAD); > >> + bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREREAD); > >> } > >> > >>=20 > >> /*--------------------------------------------------------------------= =2D- > >>--* @@ -672,8 +671,7 @@ usb_pc_cpu_flush(struct usb_page_cache *pc) /* > >> nothing has been loaded into this page cache! */ return; > >> } > >> - bus_dmamap_sync(pc->tag, pc->map, > >> - BUS_DMASYNC_PREWRITE | BUS_DMASYNC_PREREAD); > >> + bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREWRITE); > >> } > >> > >>=20 > >> /*--------------------------------------------------------------------= =2D- > >>--* > >> > > Great thanks Piotr! > I work on MIPS BCM5354 and BCM5836 and after apply your patch USB work > correct. We are currently investigating if your patch is correct. Thanks for your pa= tch=20 suggestion! BTW: Have you tried out the new device side mode support in the FreeBSD 8- current USB stack? =2D-HPS