USB vendore designations..

[Julian Elischer]

Hans Petter Selasky wrote:

>On Monday 27 December 2004 23:38, Julian Elischer wrote:
>  
>
>>Hans Petter Selasky wrote:
>>    
>>
>>>On Monday 27 December 2004 08:15, Julian Elischer wrote:
>>>      
>>>
>>>>Now, when you do the "doobell trick" as descibed in the spec,
>>>>there is one little part of it.. that is the catch.
>>>>
>>>>The spec says:
>>>>"Software should first deactivate all active qTDs, wait for the
>>>>queue head to go inactive, then remove the queue head from
>>>>the asynchronous list." 
>>>>
>>>>Note the word "all"
>>>>
>>>>Ok, so since we want to remove only SOME of the qTDs from the queue
>>>>(those corresponding to the aborting command), and we need to read
>>>>the status word to see which has been completed by whether the
>>>>active bit is set, and since we are in a race with the hardware
>>>>to clear the active bit, which of the qTDs, not in the list of
>>>>qTDs we want to remove, was completed?
>>>>        
>>>>
>>>Maybe the EHCI driver should not reuse the QH's for transfers on the same
>>>pipe, but instead like I did, have one QH for each transfer, insterted
>>>into the asynchronous schedule after that the last QH has been removed?
>>>      
>>>
>>It's an interesting idea..
>>
>>where did you do this?  In a new driver?
>>
>>    
>>
>Yes, the one I posted earlier this year:
>
>Create a new directory and download the following files and type "make 
>install" (to uninstall type "make deinstall")
>
>http://home.c2i.net/hselasky/isdn4bsd/privat/usb/Makefile
>http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.diff.bz2
>http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.tar.bz2
>  
>
>>It has the good point of being "clean"
>>It has the bad point of only allowing one transaction per interrupt cycle.
>>    
>>
>Thats the way UHCI driver is currently doing it.
>Transfer more data at a time, and the loss will be less. 
>
>How about removing the QH from the asynchronous schedule, before removing the 
>TD's and then insert the QH back into the asynchronous schedule?
>

that's what I'm doing now in my test code.. iI'll check it in today maybe.

>
>Very few drivers start more than one transfer at an asynchronous pipe at a 
>time, so most of the time there will be a short delay between transfers 
>anyway.
>  
>
yes, but why break it as a possibility? :-)


>
>Yours
>--HPS
>_______________________________________________
>freebsd-usb at freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-usb
>To unsubscribe, send any mail to "freebsd-usb-unsubscribe at freebsd.org"
>  
>