> >> Thanks in advance for reviewing the logs, Mathias! I appreciate any time
> >> and
> >> feedback you may be able to provide. Let me know if you have any further
> >> questions or need more information from me. I look forward to hearing from
> >> you
> >> soon!
> >>
> >
> > You may not enter test mode at all.
> >
> > Check flow: xhci_hub_control->xhci_enter_test_mode.
>
> The thing is that we need to enable certification test as well,
> otherwise we will never have a chance of getting linux products with a
> USB-IF logo out of vanilla mainline tree.
Absolutely. USB-IF testing is important to us and our customers, so we
would definitely like to continue working towards a solution.
Peter - you are saying that it is not possible to enter test mode, but
your explanation is unclear to me. Could you please elaborate as to why
you think this is not possible? The only issue I can see is that I'm
missing a patch that enables SetPortFeature(TEST_MODE) (see below, and
Mathias's response to this thread), but I would like to know if there
are other issues that I am not yet aware of.
> Seems to me that the only thing missing is a way to enter a particular
> test mode based on VID/PID pair.
>
> All the functionality is already in place, just this little extra hook
> is missing.
Yup! Mathias posted a nice walkthrough of the xhci_hub_control logic
that should respont to SetPortFeature(TEST_MODE), but the kernel I am
using, 4.9.115, is missing a patch.
Cheers,
Rob Weber
Hello,
On Wed, Aug 07, 2019 at 02:11:03PM +0300, Mathias Nyman wrote:
> On 7.8.2019 7.25, Rob Weber wrote:
> > Hi Everyone,
> >
> > (Pinging Mathias regarding xHCI support of the USB 2.0 test modes)
> >
> > On Mon, Aug 05, 2019 at 02:07:23PM +0800, Peter Chen wr
make sure that we are enabling the
USB 2.0 test modes according to the xHCI spec. I'm concerned that we
might be experiencing an error because we aren't setting the test mode
acording to section 4.19.6 of the xHCI specification.
Thanks in advance for reviewing the logs, Mathias! I apprec
Hello Felipe,
On Thu, Jul 11, 2019 at 10:37:11AM +0300, Felipe Balbi wrote:
> Rob Weber writes:
> > I hope you are doing well. My team and I are frequently experiencing an
> > issue with the dwc3 in our CherryTrail SoC where we encounter an LFPS
> > Polling timeout whil
ompliance mode in the
meantime?
Thanks in advance for your input!
Cheers,
Rob Weber
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 53b26e9..07d8412 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -48,6 +48,91 @@
#include "debug.h"
#define
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 t
r. 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
we still have not identified a
root cause of the issue. Intel has no known errata related to the symptoms
we are experiencing. We've done quite a bit of analysis on our design and
are pretty confident we've followed all design guidelines for USB.
Cheers,
Rob Weber
[1] https://marc.info/?
>
> >> >> > I've attached the traces and dmesg output in an archive titled
> >> >> > "gnarbox-ep0out-failure.tar.xz". Please let me know if you need more
> >> >> > information about this particular issue.
> >> >>
> >> >> I'll go over the traces, this could be something that has been fixed in
> >> >> the past.
> >> >
> >> > Did you get a chance to take a look at the tracepoints for this error?
> >> > No worries if you haven't gotten a chance yet.
> >>
> >> I did, nothing screaming wrong with them. That "can't enable ep0out"
> >> still puzzles me a bit. What we see on tracepoints is a time out:
> >>
> >>modprobe-1281 [002] d..1 246.504043: dwc3_gadget_ep_cmd: ep0out: cmd
> >> 'Set Endpoint Transfer Resource' [2] params 0001 -->
> >> status: Timed Out
> >>
> >> But I have no idea why that happens. It could be that this was fixed
> >> long ago, but we won't know unless we run a recent kernel on your
> >> setup. I, certainly, haven't seen that :-)
> >
> > One of my colleagues is currently testing kernel 5.0.5 without the patch
> > you suggested and it looks pretty good so far! We'll keep you updated if
> > this changes. With this issue in particular, it is still unclear how to
> > get our device into this state. We'll definitely keep an eye out for it
> > on 5.0.5.
>
> If 5.0.5 is working, then you could run a git bisect and find the commit
> that fixed it. If we have a failing commit and a working commit, git
> bisect will help finding the fix, then you could simply cherry-pick it.
I spoke too soon. 5.0.5 (unpatched) shows significant improvement than 4.9.115
as it
takes about 15 minutes of data transfer before the link drops from SS to
HS. We will be sticking with the patch that you provided us earlier.
It's been working very well for us on 4.9.115.
Cheers,
Rob Weber
observe
that device mode is not working.
4. modprobe -r g_mass_storage to remove the gadget driver.
5. switch back to host mode (echo host > /sys/class/usb_role/.../role)
6. switch back to device mode
7. modprobe g_mass_storage ...
8. Observe the error
I've attached the traces and dmesg out
Hello Felipe,
On Thu, Mar 28, 2019 at 08:36:12AM +0200, Felipe Balbi wrote:
> Rob Weber writes:
> >> >> Felipe Balbi writes:
> >> >> >>> Sure, that would be great. How can I download it? Any link which I
> >> >> >>> can
>
his issue, we think this might cause the
> > differential pairs to get out of sync. We also thing this might cause
>
> It could be, sure. Please re-verify your length matching and
> differential impedance (should be 90-ohm +- 15%)
We received a report from the raw PCB manufacturer that shows the SS
traces are well within our specified tolerances. We specified 85-ohm +-
10% based on Intel's recommendation, and the average differential
impedances from several samples is somewhere around 85-86 ohms. We are
acqiuring a couple of raw PCBs now to confirm, but so far the data is
looking good.
> > the host controller in the SoC to be sinking a bit of current, causing
> > the link to fail in some way.
> >
> > I'll follow up with some more detail tomorrow as well as the results of
> > the disabled LPM test. If there's a way to disable LPM from the device,
> > please let me know :)
>
> See above, but I don't know whether that will work :-)
So I used your approach to disable LPM from the host and it seems to
prevent the fall from SS to HS. Thank you for that suggestion. We also
reached out to Cypress and Intel about the issue and they noticed the
same issue and asked about the same recommendation. The unfortunate part
about this is that it doesn't seem to be a valid solution for devices in
the field. We won't be able to control the host computers the devices
are connected to and won't be able to disable LPM from the device.
Do you have any thoughts on why our board might be experiencing issues
with exiting U2? Does it seem like a timeout issue? The possibility of a
timeout is all I can come up with at the moment.
Intel also provided several other recommendations (this list is a direct quote):
- Check if CHT client system use BIOS FRC 1.2.0 version or the latest
BIOS FRC (as I remembered Modphy power gating should be disable in FRC
1.2.0 or later, however it is better to confirm it again.)
- Check if CHT(client) system can pass USB3.0 TX/RX test to make sure no
EV issue on CHT board
- Check if the host system(Win, or others) customer used can pass USB3.0
TX/RX test to make sure no EV issue on host system
- Check if Modphy power gating if disable as default in customer's CHT
system, not sure if host(XHCI) and client(XDCI) mode are same setting for
Modphy from BIOS setting. It might check with BIOS team for this.
I've asked this same question to our BIOS vendor, but do you know what
"modphy power gating" is and how it might be related to this issue?
Cheers,
Rob Weber
> already
> went wrong and we want to "disable" the device.
Does it look like something has gone wrong here? Or do you need more
information? Soon I'll be reproducing this issue and gathering xhci_hcd
tracepoints so hopefully that will provide more clarity.
Cheers,
Rob Weber
Hello,
On Mon, Mar 25, 2019 at 09:34:38AM +0200, Felipe Balbi wrote:
>
> Hi,
>
> Rob Weber writes:
> > Hi linux-usb,
> >
> > My team and I are currently grappling with an issue where our custom
> > hardware cannot maintain a SuperSpeed connection to a ho
t; Thanks for the suggestion, I'll start preparing an OS image with a 4.18
> > kernel and let you know what happens.
>
> OK.
Thank you for your help, Heikki. Migrating to kernel 4.18
has solved the problem because we were missing the
intel-xhci-usb-role-switch driver as you suspected. We're able to switch
USB modes successfuly from userspace as well.
Sorry for the delayed response. Board bring-up has been quite hectic,
but my team and I really appreciated the help.
Cheers,
Rob Weber
rd and report the results. Thanks again for the
suggestion!
Cheers,
Rob Weber
so try using kgdb to step through the
initialization process.
Thank you for taking a look into this situation! Please let me know
if you have any questions.
Cheers,
Rob Weber
# tracer: nop
#
# entries-in-buffer/entries-written: 521/521 #P:4
#
# _-=>
17 matches
Mail list logo
