Date: Thu, 08 Jul 2004 00:15:17 -0600 From: Scott Long <scottl@samsco.org> To: Julian Elischer <julian@elischer.org> Cc: ticso@cicely.de Subject: Re: speeding up ugen by an order of magnitude. Message-ID: <40ECE675.2090307@samsco.org> In-Reply-To: <Pine.BSF.4.21.0407071615260.84004-100000@InterJet.elischer.org> References: <Pine.BSF.4.21.0407071615260.84004-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > > On Wed, 7 Jul 2004, Scott Long wrote: > > >>On Wed, 7 Jul 2004, Poul-Henning Kamp wrote: >> >>>In message <200407072129.15095.mycroft@netbsd.org>, "Charles M. Hannum" writes: >>> >>>>On Wednesday 07 July 2004 20:46, Charles M. Hannum wrote: >>>> >>>>>1) You'll need to add an interface for assigning pipes for read and write, >>>>>since there may be more than just bulk pipes (and may be more than one bulk >>>>>pipe in each direction), and we only have have device node to work with. >>>> >>>>Seems I misspoke there. That part looks fine. >>>> >>>>I think you're going to be screwed by the buffer alignment, though. This also >>>>causes some issues with umass if you're not using a bounce buffer. >>> >>>We've already had that issue with ATA for the b�rked Geode controller: >>>physio does nothing for alignment and relies on userland doing something >>>sensible. >>> >>>I think this is pretty reasonable for the kind of hardware-near >>>work that physio is usually employed in (including if we use it for >>>ugen). >>> >>>Obviously, if the alignment is not OK, EINVAL should be returned, >>>and that means that the driver should explicitly check the alignment. >> >>Note that busdma can handle alignment now for loaded buffers by using >>bounce pages. > > > Since we have a relatively highly weighted priority on keeping this > code common with teh NetBSD version, how does that go for NetBSD? > > > >>Scott > > > I honestly don't know if NetBSD busdma honors alignment when loading segments. However, I believe that our usb code has the busdma functionality completely broken out from the common code (in usb_mem.c, IIRC), so it's of little consequence to portability. I was going to mention that different semantics of bus_dmamap_load() between FreeBSD and NetBSD might still cause problems here, but it looks like our usb code still allocates static busdma buffers and copies the packets in/out of these. Wasn't this fixed a while back? Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40ECE675.2090307>