From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Lyude Paul <lyude@redhat.com>
Cc: Lukas Wunner <lukas@wunner.de>,
Bjorn Helgaas <bhelgaas@google.com>,
Kai-Heng Feng <kai.heng.feng@canonical.com>,
Karol Herbst <kherbst@redhat.com>,
Patrick Volkerding <volkerdi@gmail.com>,
Ben Skeggs <bskeggs@redhat.com>,
linux-pci@vger.kernel.org
Subject: Re: [PATCH] PCI/PM: Assume ports without DLL Link Active train links in 100 ms
Date: Fri, 21 Aug 2020 12:32:24 +0300 [thread overview]
Message-ID: <20200821093224.GN1375436@lahna.fi.intel.com> (raw)
In-Reply-To: <825a566040de2eedc81350cc914dd38dcc3ba4ff.camel@redhat.com>
Hi,
On Thu, Aug 20, 2020 at 11:36:37AM -0400, Lyude Paul wrote:
> On Thu, 2020-08-20 at 10:13 +0200, Lukas Wunner wrote:
> > On Wed, Aug 19, 2020 at 04:06:25PM +0300, Mika Westerberg wrote:
> > > Sec 7.5.3.6 requires such Ports to support DLL Link Active reporting, but
> > > at least the Intel JHL6240 Thunderbolt 3 Bridge [8086:15c0] and the Intel
> > > JHL7540 Thunderbolt 3 Bridge [8086:15ea] do not.
> > [...]
> > > + * Also do the same for devices that have power management disabled
> > > + * by their driver and are completely power managed through the
> > > + * root port power resource instead. This is a special case for
> > > + * nouveau.
> > > */
> > > - if (!pci_is_pcie(dev)) {
> > > + if (!pci_is_pcie(dev) || !child->pm_cap) {
> >
> > It sounds like the above-mentioned Thunderbolt controllers are broken,
> > not the Nvidia cards, so to me (as an outside observer) it would seem
> > more logical that a quirk for the former is needed. The code comment
> > suggests that nouveau somehow has a problem, but that doesn't seem to
> > be the case (IIUC). Also, it's a little ugly to have references to
> > specific drivers in PCI core code.
> >
> > Maybe this can be fixed with quirks for the Thunderbolt controllers
> > which set a flag, and that flag causes the 1000 msec wait to be skipped?
>
> Sorry, some stuff came up yesterday so I didn't get the time to go through my
> laptops and test them. I do agree with this though - I'd be worried as well that
> nouveau might not be the only driver out there that needs this kind of delay
I actually expect that nouveau is the only one because it is doing some
PM tricks to get the runtime PM working, which is that it leaves the GPU
device in D0 and puts the parent root port into D3cold. The BIOS ASL
code has some assumptions there and I think this 1000 ms delay just
works that around by luck ;-)
IIRC Bjorn suggested quirking the affected downstream ports when I
originally sent the patch but I thought we could make this solution more
generic. Which of course, did not work too well.
I can look into the quirk solution instead if this is what people
prefer.
next prev parent reply other threads:[~2020-08-21 9:32 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-19 13:06 [PATCH] PCI/PM: Assume ports without DLL Link Active train links in 100 ms Mika Westerberg
2020-08-19 16:58 ` Lyude Paul
2020-08-19 17:20 ` Mika Westerberg
2020-08-20 8:13 ` Lukas Wunner
2020-08-20 15:36 ` Lyude Paul
2020-08-21 9:32 ` Mika Westerberg [this message]
2020-08-21 23:09 ` Lyude Paul
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=20200821093224.GN1375436@lahna.fi.intel.com \
--to=mika.westerberg@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=bskeggs@redhat.com \
--cc=kai.heng.feng@canonical.com \
--cc=kherbst@redhat.com \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=lyude@redhat.com \
--cc=volkerdi@gmail.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