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>, 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>
index | next in thread | previous in thread | raw e-mail
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êcik wrote: >>>>> 1) My analysis: Only the data areas are being flushed/ >>>>> invalidated. No >>>>> transfer descriptors are flushed/invalidated. I see no cache >>>>> operations >>>>> happening on any DMA control structures, even though there are >>>>> calls from >>>>> EHCI to xxx_pc_flush() and xxx_pc_invalidate(). >>>> >>> >>>> Probaby you see more on your AT91 device as you know USB stack >>>> 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- >>> 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 >> for the release since USB is currently broken on at least three ARM >> 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 appreciated. Please see the beginning of this thread (originated on usb@ ML), where a quick fix was proposed by Piotr. That patch works around the problems for us (also for some MIPS and noncoherent PPC), but the problem here is that we believe that using bus dma for the purpose of cache synchronization is improper in principle, and cpu- specific calls should be used instead, although Hans is rather 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 >> will be pushed into SVN shortly. In case you'd like to apply the >> 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 release :-) I will be following up on that pmap-related stuff, but am waiting for confirmation from stas@ there are no regressions on AT91 with this patch. Rafalhelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B8FCBB1F-F294-4252-82AE-1466631E548F>