Date: Tue, 14 Jul 2009 19:20:22 +0200 From: Rafal Jaworowski <raj@semihalf.com> To: Marcel Moolenaar <xcllnt@mac.com> Cc: Marcel Moolenaar <marcel@freebsd.org>, =?ISO-8859-2?Q?Piotr_Zi=EAcik?= <kosmo@semihalf.com>, freebsd-usb@freebsd.org, freebsd-arm@freebsd.org, thompsa@freebsd.org Subject: Re: CPU Cache and busdma usage in USB Message-ID: <B8FCBB1F-F294-4252-82AE-1466631E548F@semihalf.com> In-Reply-To: <E4BEDDE0-2872-4934-9A53-4121E33390B5@mac.com> References: <200906231035.43096.kosmo@semihalf.com> <200907091834.42462.hselasky@c2i.net> <200907141031.11185.kosmo@semihalf.com> <200907141036.44652.hselasky@c2i.net> <FB60465B-D714-4534-B07F-890C72A9CB33@semihalf.com> <E4BEDDE0-2872-4934-9A53-4121E33390B5@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2009-07-14, at 18:58, Marcel Moolenaar wrote: > On Jul 14, 2009, at 2:21 AM, Rafal Jaworowski wrote: > >> >> On 2009-07-14, at 10:36, Hans Petter Selasky wrote: >> >>> On Tuesday 14 July 2009 10:31:10 Piotr Zi=EAcik wrote: >>>>> 1) My analysis: Only the data areas are being flushed/=20 >>>>> invalidated. No >>>>> transfer descriptors are flushed/invalidated. I see no cache =20 >>>>> operations >>>>> happening on any DMA control structures, even though there are =20 >>>>> calls from >>>>> EHCI to xxx_pc_flush() and xxx_pc_invalidate(). >>>> >>> >>>> Probaby you see more on your AT91 device as you know USB stack =20 >>>> internals. >>>> Have you tried to bring up OHCI on you ARM board ? >>> >>> Not yet. I'm terribly busy with some LibUSB stuff headed for the 8-=20= >>> current >>> release. As soon as I find time I will fire off a build and debug. >> >> Please note these problems should be considered as a showstopper =20 >> for the release since USB is currently broken on at least three ARM =20= >> platforms in the tree (Marvell). > > Rafal, > > Anything I can do to help? > (as a reminder: I have an Orion board) Your input on the desired final solution to these issues would be =20 appreciated. Please see the beginning of this thread (originated on =20 usb@ ML), where a quick fix was proposed by Piotr. That patch works =20 around the problems for us (also for some MIPS and noncoherent PPC), =20 but the problem here is that we believe that using bus dma for the =20 purpose of cache synchronization is improper in principle, and cpu-=20 specific calls should be used instead, although Hans is rather =20 reluctant to embracing the latter path. >>> BTW: Has pmap been fixed for ARM in 8-current? >> >> Seems like the most critical problems (panics) are resolved and =20 >> will be pushed into SVN shortly. In case you'd like to apply the =20 >> fix directly, see: = http://people.freebsd.org/~raj/patches/arm/pmap-fixes.diff > > Good! I was about to start a discussion about reverting > rev. 194459 for now. We're about to start BETA-2 and it > helps (at least Juniper :-) to have 8.0-RELEASE not be > DOA :-) No worries, we're also looking forward to 8.0 as a great ARM =20 release :-) I will be following up on that pmap-related stuff, but am =20= waiting for confirmation from stas@ there are no regressions on AT91 =20 with this patch. Rafal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B8FCBB1F-F294-4252-82AE-1466631E548F>