Date: Fri, 16 Jan 2009 10:12:23 +0100 From: Hans Petter Selasky <hselasky@c2i.net> To: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> Cc: "freebsd-bluetooth@freebsd.org" <freebsd-bluetooth@freebsd.org>, Alfred Perlstein <alfred@freebsd.org> Subject: Re: USB2: ng_ubt2 patch Message-ID: <200901161012.24544.hselasky@c2i.net> In-Reply-To: <bb4a86c70901151708u5e633e8bkbcb530646b22ca3c@mail.gmail.com> References: <bb4a86c70901141705s1af508e3yf79383ecf97293cf@mail.gmail.com> <200901152225.19150.hselasky@c2i.net> <bb4a86c70901151708u5e633e8bkbcb530646b22ca3c@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 16 January 2009, Maksim Yevmenkin wrote: > 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 If isochronous is being used, then I recommend you have two transfers running at any time in both directions. If there is nothing to send you send zero length frames. Else you end up with glitches in the isochronous stream when you change from one transfer to the other! Both isochronous transfers should be queued all the time! > >> usb2_transfer_start() and > >> usb2_start_hardware() and when one should use former or later? usb2_transfer_start() kicks the callback. usb2_start_hardware() kicks the hardware. I don't recomment calling usb2_start_hardware() outside the callback, but if you check with "usb2_transfer_pending()" then it is possible. > > > > 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. Yes, see "usb2_transfer_pending()". --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200901161012.24544.hselasky>