Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp2129664ybc; Wed, 20 Nov 2019 09:19:55 -0800 (PST) X-Google-Smtp-Source: APXvYqzoLh5CnrjOPZaBc78EKP6PJvnpjxd0UxgXEiaeGDK18X6WBomRdCmO5Oo7xq0Nh9oAsvQw X-Received: by 2002:a5d:448a:: with SMTP id j10mr5128544wrq.79.1574270395027; Wed, 20 Nov 2019 09:19:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574270395; cv=none; d=google.com; s=arc-20160816; b=NLJ3cP3avaXKag1cGWHz7+eVVQc0gE0uomMDunrz6YKoQn2RU9jQ6RvTNX+wvOMjxM VB33hnY+26X0VGHoumfVbCEiYgLFJ5n5AGkIjZKlaNshYr/K0lXM1DikEDVC/o01Gq5Z Pk3hf/xmr1bYFuIm9kkf6gUUMV2s575LzvSFDJzRQJ4y8V1EPVSl0V3ktZqdC2EwHApO BE/XlPCr0MFnVBaKIsCReEGuux7bRyOWJR69zvDXZpeNMkAjJkCQC746j0bcJKg700Vi LDa3VxP1erM9WApyW1kRtODgzGkBpTpNoqt8ZBHH3WLt1sUNyBqJXuzjm1b1xsCM39/H 5yHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:organization:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=ycpN0I2kVNOMhc6hLQpMUicFTEt6kINDdGnmLPsbTgA=; b=lJf0lNJcWwD8JcJtyM211cfDzt3da5GKIV8SCAACmhFRcjLwJzpqGiRquduGwPAUZS lzFX09i76kEzpyhW7Csa5uJF+BVFnDNgGCQRj7QQVYTW/ULg68VgF5dI+CIPQBrNg+22 RntN5eLLGiowNS9s9DNaO2FlBO7lk5/b7OIu4mOEJbV7ErNXyBwUe5SqeV17Go+q1dco 3uFjZCD3Yhgwg28l+LXwsuxXqv1PC/SctZu4Djtx6dUy69PJYC+8dMGjIJBqGOZeIz7j DrEh3U1zf6UCW88lS5uZoJCmcSw+hjSl1rwPkGP3W7ZPGT1Sq/ZfKVpB25WVTESopEQv cd7A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w7si5467edj.96.2019.11.20.09.19.31; Wed, 20 Nov 2019 09:19:55 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728391AbfKTPPt (ORCPT + 99 others); Wed, 20 Nov 2019 10:15:49 -0500 Received: from mga07.intel.com ([134.134.136.100]:50323 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726771AbfKTPPt (ORCPT ); Wed, 20 Nov 2019 10:15:49 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Nov 2019 07:15:47 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,222,1571727600"; d="scan'208";a="215831473" Received: from lahna.fi.intel.com (HELO lahna) ([10.237.72.163]) by fmsmga001.fm.intel.com with SMTP; 20 Nov 2019 07:15:43 -0800 Received: by lahna (sSMTP sendmail emulation); Wed, 20 Nov 2019 17:15:42 +0200 Date: Wed, 20 Nov 2019 17:15:42 +0200 From: Mika Westerberg To: Karol Herbst Cc: "Rafael J. Wysocki" , Bjorn Helgaas , LKML , Lyude Paul , "Rafael J . Wysocki" , Linux PCI , Linux PM , dri-devel , nouveau , Dave Airlie , Mario Limonciello Subject: Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges Message-ID: <20191120151542.GH11621@lahna.fi.intel.com> References: <20191119214955.GA223696@google.com> <20191120101816.GX11621@lahna.fi.intel.com> <20191120112212.GA11621@lahna.fi.intel.com> <20191120115127.GD11621@lahna.fi.intel.com> <20191120120913.GE11621@lahna.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.12.1 (2019-06-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 20, 2019 at 01:11:52PM +0100, Karol Herbst wrote: > On Wed, Nov 20, 2019 at 1:09 PM Mika Westerberg > 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. 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().