Date: Thu, 15 Jan 2009 17:08:05 -0800 From: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> To: Hans Petter Selasky <hselasky@c2i.net> Cc: "freebsd-bluetooth@freebsd.org" <freebsd-bluetooth@freebsd.org>, Alfred Perlstein <alfred@freebsd.org> Subject: Re: USB2: ng_ubt2 patch Message-ID: <bb4a86c70901151708u5e633e8bkbcb530646b22ca3c@mail.gmail.com> In-Reply-To: <200901152225.19150.hselasky@c2i.net> References: <bb4a86c70901141705s1af508e3yf79383ecf97293cf@mail.gmail.com> <200901150954.11454.hselasky@c2i.net> <bb4a86c70901150955r3d1e9e81pfddbbb194bc52043@mail.gmail.com> <200901152225.19150.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 15, 2009 at 1:25 PM, Hans Petter Selasky <hselasky@c2i.net> wrote: > On Thursday 15 January 2009, Maksim Yevmenkin wrote: >> On Thu, Jan 15, 2009 at 12:54 AM, Hans Petter Selasky <hselasky@c2i.net> > wrote: >> > On Thursday 15 January 2009, Maksim Yevmenkin wrote: [...] >> thanks for taking time and looking at this. >> >> > 1) Maybe you just want to merge together all the USB config structures >> > into one? >> >> i guess, i could. since isoc transfers are going over different (from >> control, interrupt and bulk transfers) interface, i kept original code >> that had two separate usb2_config structures (i.e. one per each >> interface). for the same reason, i added separate lock for interface 1 >> (where isoc transfers are). i figured, due to the nature of isoc >> transfers, this lock will be grabbed a lot more often. it seemed like >> a good idea to use different lock so there would be less contention >> with interface 0 lock. but then again, may be i just full of it :) and >> it really does not matter. >> >> could you please tell me what is the reason for merging usb2_config >> structures? is it better for usb2? > > It will save some memory allocations. i will see what i can do. [...] >> another question is how to submit isoc. writes. recall that ubt driver >> uses multiple isoc transfers in both directions. older (usb1) code >> kept track of isoc write transfers and knew which were not active. so >> when ubt needed to write isoc frame, it simply picked inactive isoc >> transfer. so, should i simply start all isoc write transfers and let >> usb2 code to figure it out or what? also, i'm a bit confused about >> api. what is the difference between usb2_transfer_start() and >> usb2_start_hardware() and when one should use former or later? > > Two ISOC transfers are enough for double buffering. actually, could you please answer the question: is there an api that would tell me if a given transfer is in progress? i kinda hate to poke into usb2 guts and look at flags_int structure inside usb2_xfer. [...] >> > BTW: I think your patch is pretty Ok. Is what you attached the final >> > version of your patch? >> >> probably not. i'm sure there will be some tweaks to it. hopefully >> nothing too big. i'm just not sure how should i proceed at this point, >> i.e. do i >> >> 1) start committing this to -head and let you pick it up from there >> >> or >> >> 2) let you commit this into p4 (or whatever) and then let you merge it >> into -head > > Just re-send me the latest patch you've got and I'll get it in P4 and my > private SVN first. all right, i will do that. but first i need to iron out a couple of wrinkles :) thanks max
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bb4a86c70901151708u5e633e8bkbcb530646b22ca3c>