Yes, I'm looking at the top of trunk xhci.h from the master branch. There is no definition for bit 8 of the HCCPARAMS1 register. Also, in looking at the latest kernel xhci.c I don't see any reference to the PAE bit.
With USB NIC cards if the buffer spans a 64K boundary and the data fits in the first half, I get two event responses. The first is a short packet, but the length is based only on the first TRB and a second success event is also received. We have also seen stability problems in the Linux kernel which we now suspect is due to this.
-Aaron
On Friday, September 6, 2019 8:59:00 PM PDT Bin Meng wrote:
External Email
Hi Aaron,
On Sat, Sep 7, 2019 at 11:08 AM Aaron Williams awilliams@marvell.com
wrote:
Hi,
I am seeing crashes in our XHCI implementation based on a Designware USB 3.1 core. One thing I noticed is that this core sets the PAE bit in the HCCparams. The result of this is that when there is a short packet and there are two TDs, then when PAE is set there will be two responses with the second one being success. I'm still not sure if the length field I'm seeing is correct or not, but it appears that neither Linux nor U-Boot can handle HCs with the PAE bit set. See the eXtendable Host Controller Interface 1.1 sections 4.10.1.1 and 5.3.6.
It looks this PAE bit was introduced in spec 1.1. U-Boot xHCI driver was ported from an earlier version of Linux xHCI driver, and I doubt it could correctly handle it. But you mentioned that Linux could not handle HCs with PAE set. Did you try the latest kernel?
With short packets with the PAE bit set with to TRBs I get two responses when the data fits in the first TRB. The first event TRB contains a short packet response with the length set to the amount of space within the first TRB that is actually used. The second TRB event is a success completion code, as is described in section 4.10.1.1.1.
Personally I find this PAE bit a major pain in the arse that causes more trouble than it's worth.
Regards, Bin