Date: Wed, 24 Jun 2009 09:15:35 +0200 From: Piotr =?iso-8859-2?q?Zi=EAcik?= <kosmo@semihalf.com> To: freebsd-usb@freebsd.org Cc: raj@semihalf.com, thompsa@freebsd.org Subject: Re: CPU Cache and busdma usage in USB Message-ID: <200906240915.36331.kosmo@semihalf.com> In-Reply-To: <20090623.115841.-1189452766.imp@bsdimp.com> References: <200906231035.43096.kosmo@semihalf.com> <200906231912.20741.hselasky@c2i.net> <20090623.115841.-1189452766.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> : > >> My question is about general idea of bus_dma usage for cache > : > >> operations. 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 operations. Please comment on why > : > >> CPU-specific functions are not used... > > I think because busdma is supposed to abstract this out. The problem > is that the usb code chose different terms to represent these > operations than is typically used. I don't think so. Bus_dmamap_sync() works in per-transfer basics. It does=20 synchronization which is required _before_ and _after_ DMA transfer. We do= =20 not know and do not want to know any details about the synchronization - th= is=20 is main idea of bus_dma subsystem. Of course, in most cases cache flush/invalidate will be preformed, but in w= e=20 do not know that without looking into bus_dma implementation on given=20 architecture. In my opinion main problem here is that bus_dmamap_sync() is not used in per-transfer basics. It is used to abstact cache operations - which is a bi= t=20 different thing. =2D-=20 Pozdrawiam. Piotr Zi=EAcik
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200906240915.36331.kosmo>