From: Karol Herbst <kherbst@redhat.com> To: Mika Westerberg <mika.westerberg@intel.com> Cc: "Rafael J. Wysocki" <rafael@kernel.org>, 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: Wed, 20 Nov 2019 16:37:14 +0100 [thread overview] Message-ID: <CACO55tvo3rbPtYJcioEgXCEQqVXcVAm-iowr9Nim=bgTdMjgLw@mail.gmail.com> (raw) In-Reply-To: <20191120151542.GH11621@lahna.fi.intel.com> On Wed, Nov 20, 2019 at 4:15 PM Mika Westerberg <mika.westerberg@intel.com> wrote: > > On Wed, Nov 20, 2019 at 01:11:52PM +0100, Karol Herbst wrote: > > On Wed, Nov 20, 2019 at 1:09 PM Mika Westerberg > > <mika.westerberg@intel.com> wrote: > > > > > > On Wed, Nov 20, 2019 at 12:58:00PM +0100, Karol Herbst wrote: > > > > overall, what I really want to know is, _why_ does it work on windows? > > > > > > So do I ;-) > > > > > > > Or what are we doing differently on Linux so that it doesn't work? If > > > > anybody has any idea on how we could dig into this and figure it out > > > > on this level, this would probably allow us to get closer to the root > > > > cause? no? > > > > > > Have you tried to use the acpi_rev_override parameter in your system and > > > does it have any effect? > > > > > > Also did you try to trace the ACPI _ON/_OFF() methods? I think that > > > should hopefully reveal something. > > > > > > > I think I did in the past and it seemed to have worked, there is just > > one big issue with this: it's a Dell specific workaround afaik, and > > this issue plagues not just Dell, but we've seen it on HP and Lenovo > > laptops as well, and I've heard about users having the same issues on > > Asus and MSI laptops as well. > > Maybe it is not a workaround at all but instead it simply determines > whether the system supports RTD3 or something like that (IIRC Windows 8 > started supporting it). Maybe Dell added check for Linux because at that > time Linux did not support it. > the point is, it's not checking it by default, so by default you still run into the windows 8 codepath. > In case RTD3 is supported it invokes LKDS() which probably does the L2 > or L3 entry and this is for some reason does not work the same way in > Linux than it does with Windows 8+. > > I don't remember if this happens only with nouveau or with the > proprietary driver as well but looking at the nouveau runtime PM suspend > hook (assuming I'm looking at the correct code): > > static int > nouveau_pmops_runtime_suspend(struct device *dev) > { > struct pci_dev *pdev = to_pci_dev(dev); > struct drm_device *drm_dev = pci_get_drvdata(pdev); > int ret; > > if (!nouveau_pmops_runtime()) { > pm_runtime_forbid(dev); > return -EBUSY; > } > > nouveau_switcheroo_optimus_dsm(); > ret = nouveau_do_suspend(drm_dev, true); > pci_save_state(pdev); > pci_disable_device(pdev); > pci_ignore_hotplug(pdev); > pci_set_power_state(pdev, PCI_D3cold); > drm_dev->switch_power_state = DRM_SWITCH_POWER_DYNAMIC_OFF; > return ret; > } > > Normally PCI drivers leave the PCI bus PM things to PCI core but here > the driver does these. So I wonder if it makes any difference if we let > the core handle all that: > > static int > nouveau_pmops_runtime_suspend(struct device *dev) > { > struct pci_dev *pdev = to_pci_dev(dev); > struct drm_device *drm_dev = pci_get_drvdata(pdev); > int ret; > > if (!nouveau_pmops_runtime()) { > pm_runtime_forbid(dev); > return -EBUSY; > } > > nouveau_switcheroo_optimus_dsm(); > ret = nouveau_do_suspend(drm_dev, true); > pci_ignore_hotplug(pdev); > drm_dev->switch_power_state = DRM_SWITCH_POWER_DYNAMIC_OFF; > return ret; > } > > and similar for the nouveau_pmops_runtime_resume(). > yeah, I tried that at some point and it didn't help either. The reason we call those from inside Nouveau is to support systems pre _PR where nouveau invokes custom _DSM calls on its own. We could potentially check for that though.
WARNING: multiple messages have this Message-ID (diff)
From: Karol Herbst <kherbst@redhat.com> To: Mika Westerberg <mika.westerberg@intel.com> Cc: "Rafael J. Wysocki" <rafael@kernel.org>, Linux PCI <linux-pci@vger.kernel.org>, Linux PM <linux-pm@vger.kernel.org>, "Rafael J . Wysocki" <rjw@rjwysocki.net>, LKML <linux-kernel@vger.kernel.org>, dri-devel <dri-devel@lists.freedesktop.org>, Mario Limonciello <Mario.Limonciello@dell.com>, 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: Wed, 20 Nov 2019 16:37:14 +0100 [thread overview] Message-ID: <CACO55tvo3rbPtYJcioEgXCEQqVXcVAm-iowr9Nim=bgTdMjgLw@mail.gmail.com> (raw) In-Reply-To: <20191120151542.GH11621@lahna.fi.intel.com> On Wed, Nov 20, 2019 at 4:15 PM Mika Westerberg <mika.westerberg@intel.com> wrote: > > On Wed, Nov 20, 2019 at 01:11:52PM +0100, Karol Herbst wrote: > > On Wed, Nov 20, 2019 at 1:09 PM Mika Westerberg > > <mika.westerberg@intel.com> wrote: > > > > > > On Wed, Nov 20, 2019 at 12:58:00PM +0100, Karol Herbst wrote: > > > > overall, what I really want to know is, _why_ does it work on windows? > > > > > > So do I ;-) > > > > > > > Or what are we doing differently on Linux so that it doesn't work? If > > > > anybody has any idea on how we could dig into this and figure it out > > > > on this level, this would probably allow us to get closer to the root > > > > cause? no? > > > > > > Have you tried to use the acpi_rev_override parameter in your system and > > > does it have any effect? > > > > > > Also did you try to trace the ACPI _ON/_OFF() methods? I think that > > > should hopefully reveal something. > > > > > > > I think I did in the past and it seemed to have worked, there is just > > one big issue with this: it's a Dell specific workaround afaik, and > > this issue plagues not just Dell, but we've seen it on HP and Lenovo > > laptops as well, and I've heard about users having the same issues on > > Asus and MSI laptops as well. > > Maybe it is not a workaround at all but instead it simply determines > whether the system supports RTD3 or something like that (IIRC Windows 8 > started supporting it). Maybe Dell added check for Linux because at that > time Linux did not support it. > the point is, it's not checking it by default, so by default you still run into the windows 8 codepath. > In case RTD3 is supported it invokes LKDS() which probably does the L2 > or L3 entry and this is for some reason does not work the same way in > Linux than it does with Windows 8+. > > I don't remember if this happens only with nouveau or with the > proprietary driver as well but looking at the nouveau runtime PM suspend > hook (assuming I'm looking at the correct code): > > static int > nouveau_pmops_runtime_suspend(struct device *dev) > { > struct pci_dev *pdev = to_pci_dev(dev); > struct drm_device *drm_dev = pci_get_drvdata(pdev); > int ret; > > if (!nouveau_pmops_runtime()) { > pm_runtime_forbid(dev); > return -EBUSY; > } > > nouveau_switcheroo_optimus_dsm(); > ret = nouveau_do_suspend(drm_dev, true); > pci_save_state(pdev); > pci_disable_device(pdev); > pci_ignore_hotplug(pdev); > pci_set_power_state(pdev, PCI_D3cold); > drm_dev->switch_power_state = DRM_SWITCH_POWER_DYNAMIC_OFF; > return ret; > } > > Normally PCI drivers leave the PCI bus PM things to PCI core but here > the driver does these. So I wonder if it makes any difference if we let > the core handle all that: > > static int > nouveau_pmops_runtime_suspend(struct device *dev) > { > struct pci_dev *pdev = to_pci_dev(dev); > struct drm_device *drm_dev = pci_get_drvdata(pdev); > int ret; > > if (!nouveau_pmops_runtime()) { > pm_runtime_forbid(dev); > return -EBUSY; > } > > nouveau_switcheroo_optimus_dsm(); > ret = nouveau_do_suspend(drm_dev, true); > pci_ignore_hotplug(pdev); > drm_dev->switch_power_state = DRM_SWITCH_POWER_DYNAMIC_OFF; > return ret; > } > > and similar for the nouveau_pmops_runtime_resume(). > yeah, I tried that at some point and it didn't help either. The reason we call those from inside Nouveau is to support systems pre _PR where nouveau invokes custom _DSM calls on its own. We could potentially check for that though. _______________________________________________ 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-20 15:37 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 [this message] 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 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='CACO55tvo3rbPtYJcioEgXCEQqVXcVAm-iowr9Nim=bgTdMjgLw@mail.gmail.com' \ --to=kherbst@redhat.com \ --cc=Mario.Limonciello@dell.com \ --cc=airlied@gmail.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=helgaas@kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pci@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=lyude@redhat.com \ --cc=mika.westerberg@intel.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.