Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 Sep 2014 15:31:22 +0900 (JST)
From:      Kohji Okuno <okuno.kohji@jp.panasonic.com>
To:        hps@selasky.org
Cc:        freebsd-current@freebsd.org, freebsd-usb@freebsd.org
Subject:   Re: Does the xHCI driver has a spec violation?
Message-ID:  <20140922.153122.2173639902447525862.okuno.kohji@jp.panasonic.com>
In-Reply-To: <541FBB84.6050508@selasky.org>
References:  <20140922.135800.1954695532570247771.okuno.kohji@jp.panasonic.com> <541FBB84.6050508@selasky.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi HPS,

Could you refer to the following document (4.6.6 Configure Endpoint:P.99)?
This document shows:

If the Drop Context flag is `1' and the Add Context flag is `1', the xHC shall:
o Release the current Resources and Bandwidth allocated to the
  endpoint and assign the new Resources and Bandwidth requested for
  the endpoint.

Regards,
 Kohji Okuno.

> On 09/22/14 06:58, Kohji Okuno wrote:
>> Hi,
>>
>> I encountered a issue for USB mic.
>>
>> In fist time, my host controller (xHCI) sends single IN-tokens every
>> 8-SOFs. This is expected action. But, after I open, close and open, my
>> host controller sends plural IN-tokens between SOF and SOF.
>>
>> In Intel Lynx Point, I could not reproduce this issue.
>> I'm sorry. Unfortunately, I can't explain details about my proprietary
>> host controler.
>>
>> I found the following explanation in the xHCI 1.1 specification
>> http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/extensible-host-controler-interface-usb-xhci.pdf
>>
>> In 4.8.3 Endpoint Context State,
>>    6. The Configure Endpoint Command (Add (A) = `1' and Drop (D) =`1')
>>       shall transition an endpoint, except the Default Control
>>       Endpoint, from the Stopped to the Running state.'
>>
>>
>> So, I modify as the following, then I can run expectedly.
>> What do you think about this change?
> 
> Hi,
> 
> I think we should issue the context drop separately. Are we certain that if
> both drop and add bits are set at the same time, that the drop bit will be
> processed before the add?
> 
> This might be a bug in your hardware, which apparently doesn't check if the
> context has already been added or not. I'll be glad to make a workaround for
> it once we have settled on a solution.
> 
> Can you test the attached patch using both your hardware and the Lynx Point.
> 
> Thank you!
> 
> --HPS
> 
>>
>> Best regards,
>>   Kohji Okuno
> 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140922.153122.2173639902447525862.okuno.kohji>