Hi,

Bin Liu <b-...@ti.com> writes:
>> Bin Liu <b-...@ti.com> writes:
>> >> >> > > BTY, the issue I am trying to debug is when reading bulk IN data 
>> >> >> > > from a
>> >> >> > > USB2.0 device, if the device doesn't have data to transmit and 
>> >> >> > > NAKs the
>> >> >> > > IN packet, after 4 pairs of IN-NAK transactions, xhci stops sending
>> >> >> > > further IN tokens until the next SOF, which leaves ~90us gape on 
>> >> >> > > the
>> >> >> > > bus.
>> >> >> > >
>> >> >> > > But when reading data from a USB2.0 thumb drive, this issue doesn't
>> >> >> > > happen, even if the device NAKs the IN tokens, xhci still keeps 
>> >> >> > > sending
>> >> >> > > IN tokens, which is way more than 4 pairs of IN-NAK transactions.
>> >> >> > 
>> >> >> > Thumb drive has Bulk endpoints, what is the other device's transfer 
>> >> >> > type?
>> >> >> 
>> >> >> It is bulk too. I asked for device descriptors. This is a remote debug
>> >> >> effort for me, I don't have that device...
>> >> >> 
>> >> >> > 
>> >> >> > > Any one has a clue on what causes xhci to stop sending IN tokens 
>> >> >> > > after
>> >> >> > > the device NAK'd 4 times?
>> >> >
>> >> > By accident, I reproduced the issue if addng a hub in the middle...
>> >> > any comments about why a hub changes this xhci behavior is appreciated.
>> >> 
>> >> none off the top of my head. Maybe Mathias can suggest something.
>> >
>> > The issue seems to be not related to how many bulk IN-NAK pairs before
>> > host stops sending IN token, but the host stops IN token if 1) the
>> > device ever NAK'd an bulk IN token, and 2) there is about 90~100us left
>> > to the next SOF. Then all the rest of bandwidth is wasted.
>> >
>> > Is it about xhci bandwidth schduling? /me started reading...
>> 
>> is this AM4 or AM5? Perhaps go after Synopsys' known errata list?
>
> I see the issue on both AM4 & AM5. I don't have access to the errata
> list, I guess I should talk to TI internal for the list?

Right, your HW folks should have a pointer. Dave K may be a good
starting contact ;-)

-- 
balbi

Attachment: signature.asc
Description: PGP signature

Reply via email to