USB2: ng_ubt2 patch
Maksim Yevmenkin
maksim.yevmenkin at gmail.com
Thu Jan 15 17:08:06 PST 2009
On Thu, Jan 15, 2009 at 1:25 PM, Hans Petter Selasky <hselasky at c2i.net> wrote:
> On Thursday 15 January 2009, Maksim Yevmenkin wrote:
>> On Thu, Jan 15, 2009 at 12:54 AM, Hans Petter Selasky <hselasky at 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
More information about the freebsd-bluetooth
mailing list