From: "Loïc Yhuel" <loic.yhuel@gmail.com>
To: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: linux-usb@vger.kernel.org
Subject: Re: ASM2142 issues
Date: Tue, 8 Oct 2019 01:37:02 +0200 [thread overview]
Message-ID: <CANMwUkgBKfdbQ36FYycApdQ-UxVdj7HyEmqhVOUuMF3HuM5U3Q@mail.gmail.com> (raw)
In-Reply-To: <CANMwUkioh3QoYfWiTO7z9Pi54z=_+a=H01sHFL2HaJYut5RLuw@mail.gmail.com>
Le mar. 24 sept. 2019 à 17:50, Loïc Yhuel <loic.yhuel@gmail.com> a écrit :
> > Looks like the xHCI PCI controller wasn't fully powered up to D0 state yet
> > when xhci_resume was called. Looks similar to what is discussed in thread:
> >
> > https://marc.info/?l=linux-usb&m=156681068319529&w=2
In fact the kernel keeps the device, port, and the two bridges in D0 state.
On suspend :
[ 860.578478] xhci_hcd 0000:08:00.0: PME# enabled
[ 860.578511] xhci_hcd 0000:08:00.0: PCI PM: Suspend power state: D0
...
[ 860.580329] pcieport 0000:02:09.0: PCI PM: Suspend power state: D0
...
[ 860.603786] pcieport 0000:01:00.2: PCI PM: Suspend power state: D0
[ 860.603836] pcieport 0000:00:01.1: PCI PM: Suspend power state: D0
On resume :
<restoring config space for 0000:02:09.0, then 0000:08:00.0>
...
[ 861.135868] xhci_hcd 0000:08:00.0: PME# disabled
[ 861.135934] xhci_hcd 0000:08:00.0: enabling bus mastering
...
[ 861.235966] xhci_hcd 0000:08:00.0: WARN: xHC restore state timeout
[ 861.235972] xhci_hcd 0000:08:00.0: PCI post-resume error -110!
[ 861.235973] xhci_hcd 0000:08:00.0: HC died; cleaning up
[ 861.235981] PM: dpm_run_callback(): pci_pm_resume+0x0/0x90 returns -110
[ 861.235984] PM: Device 0000:08:00.0 failed to resume async: error -110
Setting the XHCI_RESET_ON_RESUME quirk avoids the issue.
But the real problem might be the device being marked as only supporting D0,
which seems strange for suspend.
> On my machine, the PCIe "port" is supposed to support 8GT/s (but the
> controller is on the motherboard,
> so there is no official specification about how the internal
> peripherals are linked), the device too,
> but it's always in 5GT/s mode (in Windows too), so perhaps it changes
> the delays.
This is unrelated to the other problems, but if someone else has the same HW,
I found I can enable 8GT/s :
setpci -v -s 0000:08:00.0 CAP_EXP+0x30.w=0x0003:0x000f
setpci -v -s 0000:02:09.0 CAP_EXP+0x30.w=0x0003:0x000f
setpci -v -s 0000:02:09.0 CAP_EXP+0x10.w=0x0020:0x0020
prev parent reply other threads:[~2019-10-07 23:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-16 2:41 No SuperSpeedPlus on ASM2142 Loïc Yhuel
2019-09-16 12:59 ` Mathias Nyman
2019-09-16 15:19 ` Loïc Yhuel
2019-09-16 20:53 ` Loïc Yhuel
2019-09-24 7:57 ` Mathias Nyman
2019-09-24 15:50 ` Loïc Yhuel
2019-10-07 23:37 ` Loïc Yhuel [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CANMwUkgBKfdbQ36FYycApdQ-UxVdj7HyEmqhVOUuMF3HuM5U3Q@mail.gmail.com \
--to=loic.yhuel@gmail.com \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).