Date: Thu, 15 Jan 2009 09:55:54 -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: <bb4a86c70901150955r3d1e9e81pfddbbb194bc52043@mail.gmail.com> In-Reply-To: <200901150954.11454.hselasky@c2i.net> References: <bb4a86c70901141705s1af508e3yf79383ecf97293cf@mail.gmail.com> <200901150954.11454.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 15, 2009 at 12:54 AM, Hans Petter Selasky <hselasky@c2i.net> wrote: > On Thursday 15 January 2009, Maksim Yevmenkin wrote: >> dear bluetooth users, >> >> please find attached patch for ng_ubt2 (well it is almost a complete >> rewrite). >> >> this is an early preview and likely to have bugs. i briefly kicked the >> tires to make sure it compiles and did some very quick testing, i.e. >> run few hci commands, sdp transfers etc. >> >> this is my first attempt to write something under usb2, so any >> review/comments/suggestions/etc. are greatly appreciated. > > This looks very interesting. 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? > 2) There are some isochronous details for non-Full speed USB. UBT_ISOC_NFRAMES > must be a factor of 8 if it should work. ok. the bluetooth spec says device should be a high speed device, however, i have a bluetooth usb dongle (made by 3com) that is not a high speed device. so, if i just bump UBT_ISOC_NFRAMES to 32, this should work for both full- and high-speed devices, right? 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? > How much bluetooth functionality have you tested? like i said, i kicked the tires :) hci commands/events appear to work. acl/l2cap appears to work as well. i have not tried isoc (read my questions above). of course, i will need to run torture tests etc. > 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 thanks, max
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bb4a86c70901150955r3d1e9e81pfddbbb194bc52043>