Hi,
Rob Weber <rob@xxxxxxxxxxx> writes:
>> >> > them to the Tx path between the SoC and the redriver. We only have these
>> >> > caps on the Tx path between the redriver and the connector. Our EE will
>> >> > be running a test to add coupling caps to see if this helps the issue.
>> >> >
>> >> > After further analysis of this 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.
>>
>> That's great too, also can be ruled out.
>
> Yeah, overall we're feeling relatively confident in our design. A nice
> eye diagram would be the last piece of evidence we need to rule out
> hardware.
indeed, I agree with you.
>> >> > 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
>>
>> Great! Now we can confirm that the problem is indeed because of a
>> failure in U2 exit.
>>
>> > reached out to Cypress and Intel about the issue and they noticed the
>> > same issue and asked about the same recommendation. The unfortunate part
>>
>> Interesting. Who are you in touch with?
>
> We usually just open up support tickets with our FAE. A different
> support engineer usually responds to our questions for each issue.
> Jerry, a support specialist, responded to this particular request.
> I do not have Jerry's email or other identifier. If you would like
> to find out, I could send you our Intel Premiere Support Case number
> In a private thread if that helps you find our who it is.
please do. You can use felipe.balbi@xxxxxxxxx for that :-)
>> > 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.
>>
>> Completely agree. That was just a simple test to pin-point the problem
>> area.
>>
>> > 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.
>>
>> If I were to guess, I'd say the PHY is getting confused.
>
> Which PHY are you referring to? The dwc3?
That's correct
>> > 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
>>
>> This is something you have already done. Your board seems to be fine
>> from a signal quality perspective.
>>
>> > - 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
>>
>> I'd say this is pretty pointless. We can't expect you to provide a list
>> of which hosts your product will work against.
>>
>> > - 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?
>>
>> modphy is the USB PHY integrated in your SoC. There's no control for
>> that from OS side, only BIOS unfortunately. There is, however, one thing
>> we can try. DWC3 has several quirk flags for known quirky PHYs; perhaps
>> CHT needs one of those. Can you try with this patch and let me know
>> whether it helps?
>
> Sure thing, I will try tomorrow. Could you possibly explain what a quirk
> is as it relates to the kernel? I see this all over the source tree but
> never knew how it was used. Does the dwc3 also know about "quirks" and
> these particular flags? or are these flags just specific to the kernel
> and its functionality?
>
>> modified drivers/usb/dwc3/dwc3-pci.c
>> @@ -105,6 +105,8 @@ static int dwc3_byt_enable_ulpi_refclock(struct pci_dev *pci)
>> static const struct property_entry dwc3_pci_intel_properties[] = {
>> PROPERTY_ENTRY_STRING("dr_mode", "peripheral"),
>> PROPERTY_ENTRY_BOOL("linux,sysdev_is_parent"),
>> + PROPERTY_ENTRY_BOOL("snps,dis_u3_susphy_quirk"),
>> + PROPERTY_ENTRY_BOOL("snps,dis_u2_susphy_quirk"),
>> {}
>> };
>>
>> These two quirks will PHY suspend. There are other relevant quirk flags
^^^^^^^^
will DISABLE phy suspend :-)
> What do you mean by PHY suspend? Will it disable U2/U3 for the dwc3? I
No, no. DWC3 can still enter U1/U2/U3, but the PHY will not enter the
matching P1/P2/P3 state.
> see it modified the DWC3_GUSB2PHYCFG_SUSPHY bit in the configuration
> register, but I don't have access to the dwc3 databook to dig deeper
> into this.
The second quirk flag (snps,dis_u2_susphy_quirk) will tell dwc3 to *NOT*
request USB2 PHY to enter low power state. While the first flag
(snps,dis_u3_susphy_quirk) will tell dwc3 to *NOT* request USB3 PHY to
enter low power state.
In reality, they are a single block of HW but they _can_ be different
and even if they are a single block, they _can_ have separate clock
domains and we _may_ be able to control them separately. I haven't read
documentation for modphy because the OS doesn't touch that. If
necessary, I can try to find out more details about it, but I will
probably take some time to find the correct documentation.
>> which we can try in case these two don't help. I'd like to figure out
>> exactly which quirk flag helps (if any). After that, we would need to
>> check if a similar problem happens on any CHT system or just your
>> design.
>>
>> If it happens on any other system, then I can make sure we add a quirk
>> flag to all CHTs.
>
> Sounds good!
>
> Thanks for taking the time to answer my questions! It's definitely
> helpful for my understanding of USB. I'm learning quite a bit of
> new information with each email and it's pretty awesome.
No problems at all, happy to help.
--
balbi
Attachment:
signature.asc
Description: PGP signature
