From owner-freebsd-bluetooth@FreeBSD.ORG Fri Jan 16 01:08:05 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C339A1065673; Fri, 16 Jan 2009 01:08:05 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by mx1.freebsd.org (Postfix) with ESMTP id 7FE728FC0C; Fri, 16 Jan 2009 01:08:05 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1391043rvf.43 for ; Thu, 15 Jan 2009 17:08:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZOYCXI9Ei+OkJhDeQRxIEffW6MIhzmO7EsbmpuaEkuI=; b=H5KQo/hVIRFa7prqnntCahnfjBIuyHyRiU1Ni/rXcse0gFLsYZO78f+qhyYq8LHbr9 4SMeLc9PcBV7ipEoETgF23RB2rfKOYGQVVGYG7LYNi8fBNGILXg+spsua35C52ibQVI+ gFxDbTSd6MBWTQLNEeEhC522HxPpmxKE4Bp40= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=n3Nf89xOGVA9scpLPZHwQGzEVanXchaljrGoryBBGRJCJa0a0gykjK3GCUkGZM02i2 HiZ7LpNJw6CjA+JcqYcom8uUfmRQ8hG0gweqTS/Kiqc0pp1eU0zZsOJjsOFdOWWDAOah kkuWbXb4RDQImCCiz2rCJ6AdWITNR057W5U+Y= MIME-Version: 1.0 Received: by 10.140.147.5 with SMTP id u5mr903645rvd.292.1232068085261; Thu, 15 Jan 2009 17:08:05 -0800 (PST) In-Reply-To: <200901152225.19150.hselasky@c2i.net> References: <200901150954.11454.hselasky@c2i.net> <200901152225.19150.hselasky@c2i.net> Date: Thu, 15 Jan 2009 17:08:05 -0800 Message-ID: From: Maksim Yevmenkin To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" , Alfred Perlstein Subject: Re: USB2: ng_ubt2 patch X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2009 01:08:06 -0000 On Thu, Jan 15, 2009 at 1:25 PM, Hans Petter Selasky wrote: > On Thursday 15 January 2009, Maksim Yevmenkin wrote: >> On Thu, Jan 15, 2009 at 12:54 AM, Hans Petter Selasky > 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