Linux-USB Archive on lore.kernel.org
 help / color / Atom feed
* xHCI Driver Compliance Test Support
@ 2019-06-19 19:03 Rob Weber
  2019-06-24  6:15 ` Mathias Nyman
  0 siblings, 1 reply; 3+ messages in thread
From: Rob Weber @ 2019-06-19 19:03 UTC (permalink / raw)
  To: mathias.nyman; +Cc: linux-usb

Hi Mathias,

I am working on running our custom USB dual-role product through some
compliance testing. It seems that the SoC and host controller are
not responding to the LFPS signaling and timeout that is supposed to
automatically begin the compliance test sequence.

I'm currently running a 4.9.115 kernel, and I'm afraid I might be
missing some critical patches for compliance test support. I noticed
these two patches came up in a google search:

https://patchwork.kernel.org/patch/10415345/
https://www.spinics.net/lists/linux-usb/msg160002.html

Besides these patches, is there anything else that comes to mind that I
might need to do to start compliance testing? I'm about to build a more
recent kernel to see if that improves my situation as well.

Just for reference, our product uses an intel atom z8550 SoC that uses
an xHCI host controller and a dwc3 device controller. Our platform also
uses a USB 3.0 redriver. The datasheet for this redriver (tusb542)
indicates that it's internal LFPS controller supports full USB 3.0
compliance requirements.

Thanks in advance for your guidance!

Cheers,
Rob Weber

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: xHCI Driver Compliance Test Support
  2019-06-19 19:03 xHCI Driver Compliance Test Support Rob Weber
@ 2019-06-24  6:15 ` Mathias Nyman
  2019-06-24 20:09   ` Rob Weber
  0 siblings, 1 reply; 3+ messages in thread
From: Mathias Nyman @ 2019-06-24  6:15 UTC (permalink / raw)
  To: Rob Weber, mathias.nyman; +Cc: linux-usb

Hi

On 19.6.2019 22.03, Rob Weber wrote:
> Hi Mathias,
> 
> I am working on running our custom USB dual-role product through some
> compliance testing. It seems that the SoC and host controller are
> not responding to the LFPS signaling and timeout that is supposed to
> automatically begin the compliance test sequence.
> 
> I'm currently running a 4.9.115 kernel, and I'm afraid I might be
> missing some critical patches for compliance test support. I noticed
> these two patches came up in a google search:
> 
> https://patchwork.kernel.org/patch/10415345/
> https://www.spinics.net/lists/linux-usb/msg160002.html
> 
> Besides these patches, is there anything else that comes to mind that I
> might need to do to start compliance testing? I'm about to build a more
> recent kernel to see if that improves my situation as well.

If xHC hw has a "Compliance Transition Capability" (CTC) bit set in the
HCCPARAMS2 register then ports won't go to compliance unless software
specifically allows it.

see xhci spec section 4.19.1.2.4.1 for more details.

Compliance can be allowed either with a SetPortFeature(PORT_LINK_STATE) request,
or via debugfs.

To allow compliance using debugfs, first check port is in disabled state:

# cat /sys/kernel/debug/usb/xhci/0000:00:15.0/ports/port01/portsc
Powered Not-connected Disabled Link:RxDetect PortSpeed:0 Change: Wake:

enable compliance by writing "compliance" to the port:
# echo compliance > /sys/kernel/debug/usb/xhci/0000:00:15.0/ports/port01/portsc

This needs to be done for that specific port, and after every port warm reset.

After 1st LFPS timeout the port should go to compliance, can be read from portsc

Also make sure you don't have XHCI_COMP_MODE_QUIRK or XHCI_MISSING_CAS quirks set,
these try to recover ports that accidentally enter compliance mode in normal use.

> 
> Just for reference, our product uses an intel atom z8550 SoC that uses
> an xHCI host controller and a dwc3 device controller. Our platform also
> uses a USB 3.0 redriver. The datasheet for this redriver (tusb542)
> indicates that it's internal LFPS controller supports full USB 3.0
> compliance requirements.
> 

z8550 is Cherry Trail? I unfortunately don't have those around anymore.

-Mathias

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: xHCI Driver Compliance Test Support
  2019-06-24  6:15 ` Mathias Nyman
@ 2019-06-24 20:09   ` Rob Weber
  0 siblings, 0 replies; 3+ messages in thread
From: Rob Weber @ 2019-06-24 20:09 UTC (permalink / raw)
  To: Mathias Nyman; +Cc: mathias.nyman, linux-usb

Hello,

On Mon, Jun 24, 2019 at 09:15:24AM +0300, Mathias Nyman wrote:
> On 19.6.2019 22.03, Rob Weber wrote:
> > I am working on running our custom USB dual-role product through some
> > compliance testing. It seems that the SoC and host controller are
> > not responding to the LFPS signaling and timeout that is supposed to
> > automatically begin the compliance test sequence.
> > 
> > I'm currently running a 4.9.115 kernel, and I'm afraid I might be
> > missing some critical patches for compliance test support. I noticed
> > these two patches came up in a google search:
> > 
> > https://patchwork.kernel.org/patch/10415345/
> > https://www.spinics.net/lists/linux-usb/msg160002.html
> > 
> > Besides these patches, is there anything else that comes to mind that I
> > might need to do to start compliance testing? I'm about to build a more
> > recent kernel to see if that improves my situation as well.
> 
> If xHC hw has a "Compliance Transition Capability" (CTC) bit set in the
> HCCPARAMS2 register then ports won't go to compliance unless software
> specifically allows it.
> 
> see xhci spec section 4.19.1.2.4.1 for more details.
> 
> Compliance can be allowed either with a SetPortFeature(PORT_LINK_STATE) request,
> or via debugfs.
> 
> To allow compliance using debugfs, first check port is in disabled state:
> 
> # cat /sys/kernel/debug/usb/xhci/0000:00:15.0/ports/port01/portsc
> Powered Not-connected Disabled Link:RxDetect PortSpeed:0 Change: Wake:
> 
> enable compliance by writing "compliance" to the port:
> # echo compliance > /sys/kernel/debug/usb/xhci/0000:00:15.0/ports/port01/portsc
> 
> This needs to be done for that specific port, and after every port warm reset.
> 
> After 1st LFPS timeout the port should go to compliance, can be read from portsc
> 
> Also make sure you don't have XHCI_COMP_MODE_QUIRK or XHCI_MISSING_CAS quirks set,
> these try to recover ports that accidentally enter compliance mode in normal use.

Thanks for the tip! I will try this approach with a newer kernel soon. I
learned that the port enters compliance mode after the 1st LFPS polling
timeout last week after watching the port become "disabled" after
the first connection. We're currently doing a full power cycle to
correct this state, but unbinding and re-binding the pci device with the
xhci_hcd driver has also been successful at resetting the xHC. The portsc
register and warm_reset file will help improve our workflow for compliance
testing.

> > Just for reference, our product uses an intel atom z8550 SoC that uses
> > an xHCI host controller and a dwc3 device controller. Our platform also
> > uses a USB 3.0 redriver. The datasheet for this redriver (tusb542)
> > indicates that it's internal LFPS controller supports full USB 3.0
> > compliance requirements.
> > 
> 
> z8550 is Cherry Trail? I unfortunately don't have those around anymore.

Yeah, they are increasingly hard to come by. But so far your description
aligns with our findings and research about the xHCI implementation in
this SoC. Thanks for your help!

Cheers,
Rob Weber

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, back to index

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-19 19:03 xHCI Driver Compliance Test Support Rob Weber
2019-06-24  6:15 ` Mathias Nyman
2019-06-24 20:09   ` Rob Weber

Linux-USB Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-usb/0 linux-usb/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-usb linux-usb/ https://lore.kernel.org/linux-usb \
		linux-usb@vger.kernel.org linux-usb@archiver.kernel.org
	public-inbox-index linux-usb


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-usb


AGPL code for this site: git clone https://public-inbox.org/ public-inbox