From: Mika Westerberg <mika.westerberg@intel.com> To: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Karol Herbst <kherbst@redhat.com>, Bjorn Helgaas <helgaas@kernel.org>, LKML <linux-kernel@vger.kernel.org>, Lyude Paul <lyude@redhat.com>, "Rafael J . Wysocki" <rjw@rjwysocki.net>, Linux PCI <linux-pci@vger.kernel.org>, Linux PM <linux-pm@vger.kernel.org>, dri-devel <dri-devel@lists.freedesktop.org>, nouveau <nouveau@lists.freedesktop.org>, Dave Airlie <airlied@gmail.com>, Mario Limonciello <Mario.Limonciello@dell.com> Subject: Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges Date: Thu, 21 Nov 2019 13:46:10 +0200 [thread overview] Message-ID: <20191121114610.GW11621@lahna.fi.intel.com> (raw) In-Reply-To: <CAJZ5v0hQhj5Wf+piU11abC4pF26yM=XHGHAcDv8Jsgdx04aN-w@mail.gmail.com> On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote: > On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg > <mika.westerberg@intel.com> wrote: > > > > On Wed, Nov 20, 2019 at 11:29:33PM +0100, Rafael J. Wysocki wrote: > > > > last week or so I found systems where the GPU was under the "PCI > > > > Express Root Port" (name from lspci) and on those systems all of that > > > > seems to work. So I am wondering if it's indeed just the 0x1901 one, > > > > which also explains Mikas case that Thunderbolt stuff works as devices > > > > never get populated under this particular bridge controller, but under > > > > those "Root Port"s > > > > > > It always is a PCIe port, but its location within the SoC may matter. > > > > Exactly. Intel hardware has PCIe ports on CPU side (these are called > > PEG, PCI Express Graphics, ports), and the PCH side. I think the IP is > > still the same. > > > > > Also some custom AML-based power management is involved and that may > > > be making specific assumptions on the configuration of the SoC and the > > > GPU at the time of its invocation which unfortunately are not known to > > > us. > > > > > > However, it looks like the AML invoked to power down the GPU from > > > acpi_pci_set_power_state() gets confused if it is not in PCI D0 at > > > that point, so it looks like that AML tries to access device memory on > > > the GPU (beyond the PCI config space) or similar which is not > > > accessible in PCI power states below D0. > > > > Or the PCI config space of the GPU when the parent root port is in D3hot > > (as it is the case here). Also then the GPU config space is not > > accessible. > > Why would the parent port be in D3hot at that point? Wouldn't that be > a suspend ordering violation? No. We put the GPU into D3hot first, then the root port and then turn off the power resource (which is attached to the root port) resulting the topology entering D3cold. > > I took a look at the HP Omen ACPI tables which has similar problem and > > there is also check for Windows 7 (but not Linux) so I think one > > alternative workaround would be to add these devices into > > acpi_osi_dmi_table[] where .callback is set to dmi_disable_osi_win8 (or > > pass 'acpi_osi="!Windows 2012"' in the kernel command line). > > I'd like to understand the facts that have been established so far > before deciding what to do about them. :-) Yes, I agree :)
WARNING: multiple messages have this Message-ID (diff)
From: Mika Westerberg <mika.westerberg@intel.com> To: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Karol Herbst <kherbst@redhat.com>, Linux PM <linux-pm@vger.kernel.org>, Linux PCI <linux-pci@vger.kernel.org>, Mario Limonciello <Mario.Limonciello@dell.com>, "Rafael J . Wysocki" <rjw@rjwysocki.net>, LKML <linux-kernel@vger.kernel.org>, dri-devel <dri-devel@lists.freedesktop.org>, Bjorn Helgaas <helgaas@kernel.org>, nouveau <nouveau@lists.freedesktop.org> Subject: Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges Date: Thu, 21 Nov 2019 13:46:10 +0200 [thread overview] Message-ID: <20191121114610.GW11621@lahna.fi.intel.com> (raw) Message-ID: <20191121114610.4pej9h1acfgIR4ssN2d-E1gUuMfVflmF0-rrgCUQvRo@z> (raw) In-Reply-To: <CAJZ5v0hQhj5Wf+piU11abC4pF26yM=XHGHAcDv8Jsgdx04aN-w@mail.gmail.com> On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote: > On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg > <mika.westerberg@intel.com> wrote: > > > > On Wed, Nov 20, 2019 at 11:29:33PM +0100, Rafael J. Wysocki wrote: > > > > last week or so I found systems where the GPU was under the "PCI > > > > Express Root Port" (name from lspci) and on those systems all of that > > > > seems to work. So I am wondering if it's indeed just the 0x1901 one, > > > > which also explains Mikas case that Thunderbolt stuff works as devices > > > > never get populated under this particular bridge controller, but under > > > > those "Root Port"s > > > > > > It always is a PCIe port, but its location within the SoC may matter. > > > > Exactly. Intel hardware has PCIe ports on CPU side (these are called > > PEG, PCI Express Graphics, ports), and the PCH side. I think the IP is > > still the same. > > > > > Also some custom AML-based power management is involved and that may > > > be making specific assumptions on the configuration of the SoC and the > > > GPU at the time of its invocation which unfortunately are not known to > > > us. > > > > > > However, it looks like the AML invoked to power down the GPU from > > > acpi_pci_set_power_state() gets confused if it is not in PCI D0 at > > > that point, so it looks like that AML tries to access device memory on > > > the GPU (beyond the PCI config space) or similar which is not > > > accessible in PCI power states below D0. > > > > Or the PCI config space of the GPU when the parent root port is in D3hot > > (as it is the case here). Also then the GPU config space is not > > accessible. > > Why would the parent port be in D3hot at that point? Wouldn't that be > a suspend ordering violation? No. We put the GPU into D3hot first, then the root port and then turn off the power resource (which is attached to the root port) resulting the topology entering D3cold. > > I took a look at the HP Omen ACPI tables which has similar problem and > > there is also check for Windows 7 (but not Linux) so I think one > > alternative workaround would be to add these devices into > > acpi_osi_dmi_table[] where .callback is set to dmi_disable_osi_win8 (or > > pass 'acpi_osi="!Windows 2012"' in the kernel command line). > > I'd like to understand the facts that have been established so far > before deciding what to do about them. :-) Yes, I agree :) _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-11-21 11:46 UTC|newest] Thread overview: 150+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-10-17 12:19 [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges Karol Herbst 2019-11-14 19:17 ` Karol Herbst 2019-11-14 19:17 ` Karol Herbst 2019-11-19 20:06 ` Dave Airlie 2019-11-19 20:06 ` Dave Airlie 2019-11-19 20:06 ` Dave Airlie 2019-11-19 21:49 ` Bjorn Helgaas 2019-11-19 21:49 ` Bjorn Helgaas 2019-11-19 22:26 ` Karol Herbst 2019-11-19 22:26 ` Karol Herbst 2019-11-19 22:26 ` Karol Herbst 2019-11-19 22:57 ` Bjorn Helgaas 2019-11-19 22:57 ` Bjorn Helgaas 2019-11-20 10:18 ` Mika Westerberg 2019-11-20 10:18 ` Mika Westerberg 2019-11-20 10:52 ` Rafael J. Wysocki 2019-11-20 10:52 ` Rafael J. Wysocki 2019-11-20 10:52 ` Rafael J. Wysocki 2019-11-20 11:22 ` Mika Westerberg 2019-11-20 11:22 ` Mika Westerberg 2019-11-20 11:48 ` Rafael J. Wysocki 2019-11-20 11:48 ` Rafael J. Wysocki 2019-11-20 11:51 ` Karol Herbst 2019-11-20 11:51 ` Karol Herbst 2019-11-20 12:06 ` Rafael J. Wysocki 2019-11-20 12:06 ` Rafael J. Wysocki 2019-11-20 12:06 ` Rafael J. Wysocki 2019-11-20 12:09 ` Karol Herbst 2019-11-20 12:09 ` Karol Herbst 2019-11-20 12:09 ` Karol Herbst 2019-11-20 12:14 ` Rafael J. Wysocki 2019-11-20 12:14 ` Rafael J. Wysocki 2019-11-20 12:19 ` Karol Herbst 2019-11-20 12:19 ` Karol Herbst 2019-11-20 12:11 ` Rafael J. Wysocki 2019-11-20 12:11 ` Rafael J. Wysocki 2019-11-20 11:51 ` Mika Westerberg 2019-11-20 11:51 ` Mika Westerberg 2019-11-20 11:54 ` Karol Herbst 2019-11-20 11:54 ` Karol Herbst 2019-11-20 11:54 ` Karol Herbst 2019-11-20 11:58 ` Karol Herbst 2019-11-20 11:58 ` Karol Herbst 2019-11-20 11:58 ` Karol Herbst 2019-11-20 12:09 ` Mika Westerberg 2019-11-20 12:09 ` Mika Westerberg 2019-11-20 12:11 ` Karol Herbst 2019-11-20 12:11 ` Karol Herbst 2019-11-20 12:11 ` Karol Herbst 2019-11-20 15:15 ` Mika Westerberg 2019-11-20 15:15 ` Mika Westerberg 2019-11-20 15:37 ` Karol Herbst 2019-11-20 15:37 ` Karol Herbst 2019-11-20 15:53 ` Mika Westerberg 2019-11-20 15:53 ` Mika Westerberg 2019-11-20 16:23 ` Mika Westerberg 2019-11-20 16:23 ` Mika Westerberg 2019-11-20 21:36 ` Karol Herbst 2019-11-20 21:36 ` Karol Herbst 2019-11-20 21:36 ` Karol Herbst 2019-11-21 10:14 ` Mika Westerberg 2019-11-21 10:14 ` Mika Westerberg 2019-11-21 11:03 ` Rafael J. Wysocki 2019-11-21 11:03 ` Rafael J. Wysocki 2019-11-21 11:08 ` Rafael J. Wysocki 2019-11-21 11:08 ` Rafael J. Wysocki 2019-11-21 11:08 ` Rafael J. Wysocki 2019-11-21 11:15 ` Rafael J. Wysocki 2019-11-21 11:15 ` Rafael J. Wysocki 2019-11-21 11:17 ` Mika Westerberg 2019-11-21 11:17 ` Mika Westerberg 2019-11-21 11:31 ` Rafael J. Wysocki 2019-11-21 11:31 ` Rafael J. Wysocki 2019-11-20 21:37 ` Rafael J. Wysocki 2019-11-20 21:37 ` Rafael J. Wysocki 2019-11-20 21:40 ` Karol Herbst 2019-11-20 21:40 ` Karol Herbst 2019-11-20 22:29 ` Rafael J. Wysocki 2019-11-20 22:29 ` Rafael J. Wysocki 2019-11-21 11:28 ` Mika Westerberg 2019-11-21 11:28 ` Mika Westerberg 2019-11-21 11:34 ` Rafael J. Wysocki 2019-11-21 11:34 ` Rafael J. Wysocki 2019-11-21 11:34 ` Rafael J. Wysocki 2019-11-21 11:46 ` Mika Westerberg [this message] 2019-11-21 11:46 ` Mika Westerberg 2019-11-21 12:52 ` Mika Westerberg 2019-11-21 12:52 ` Mika Westerberg 2019-11-21 12:56 ` Karol Herbst 2019-11-21 12:56 ` Karol Herbst 2019-11-21 15:43 ` Rafael J. Wysocki 2019-11-21 15:43 ` Rafael J. Wysocki 2019-11-21 15:43 ` Rafael J. Wysocki 2019-11-21 19:49 ` Mika Westerberg 2019-11-21 19:49 ` Mika Westerberg 2019-11-21 22:39 ` Rafael J. Wysocki 2019-11-21 22:39 ` Rafael J. Wysocki 2019-11-21 22:39 ` Rafael J. Wysocki 2019-11-21 22:50 ` Karol Herbst 2019-11-21 22:50 ` Karol Herbst 2019-11-22 0:13 ` Karol Herbst 2019-11-22 0:13 ` Karol Herbst 2019-11-22 9:07 ` Rafael J. Wysocki 2019-11-22 9:07 ` Rafael J. Wysocki 2019-11-22 11:30 ` Karol Herbst 2019-11-22 11:30 ` Karol Herbst 2019-11-22 11:30 ` Karol Herbst 2019-11-22 10:36 ` Mika Westerberg 2019-11-22 10:36 ` Mika Westerberg 2019-11-22 11:30 ` Rafael J. Wysocki 2019-11-22 11:30 ` Rafael J. Wysocki 2019-11-22 11:34 ` Karol Herbst 2019-11-22 11:34 ` Karol Herbst 2019-11-22 11:34 ` Karol Herbst 2019-11-22 11:54 ` Rafael J. Wysocki 2019-11-22 11:54 ` Rafael J. Wysocki 2019-11-22 11:52 ` Mika Westerberg 2019-11-22 11:52 ` Mika Westerberg 2019-11-22 12:15 ` Rafael J. Wysocki 2019-11-22 12:15 ` Rafael J. Wysocki 2019-11-21 12:52 ` Karol Herbst 2019-11-21 12:52 ` Karol Herbst 2019-11-21 15:47 ` Rafael J. Wysocki 2019-11-21 15:47 ` Rafael J. Wysocki 2019-11-21 16:06 ` Karol Herbst 2019-11-21 16:06 ` Karol Herbst 2019-11-21 16:39 ` Rafael J. Wysocki 2019-11-21 16:39 ` Rafael J. Wysocki 2019-11-26 23:10 ` Lyude Paul 2019-11-26 23:10 ` Lyude Paul 2019-11-27 11:48 ` Mika Westerberg 2019-11-27 11:48 ` Mika Westerberg 2019-11-27 11:51 ` Karol Herbst 2019-11-27 11:51 ` Karol Herbst 2019-11-27 19:51 ` Lyude Paul 2019-11-27 19:51 ` Lyude Paul 2019-12-09 11:17 ` Karol Herbst 2019-12-09 11:17 ` Karol Herbst 2019-12-09 11:38 ` Rafael J. Wysocki 2019-12-09 11:38 ` Rafael J. Wysocki 2019-12-09 11:38 ` Rafael J. Wysocki 2019-12-09 12:24 ` Karol Herbst 2019-12-09 12:24 ` Karol Herbst 2019-12-10 19:58 ` Dave Airlie 2019-12-10 19:58 ` Dave Airlie 2019-12-10 20:49 ` Karol Herbst 2019-12-10 20:49 ` Karol Herbst 2020-01-13 15:31 ` Karol Herbst 2020-01-13 15:31 ` Karol Herbst 2020-01-13 15:31 ` Karol Herbst
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=20191121114610.GW11621@lahna.fi.intel.com \ --to=mika.westerberg@intel.com \ --cc=Mario.Limonciello@dell.com \ --cc=airlied@gmail.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=helgaas@kernel.org \ --cc=kherbst@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pci@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=lyude@redhat.com \ --cc=nouveau@lists.freedesktop.org \ --cc=rafael@kernel.org \ --cc=rjw@rjwysocki.net \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.