Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp3090307ybc; Thu, 21 Nov 2019 03:12:41 -0800 (PST) X-Google-Smtp-Source: APXvYqxWjqRPAmXZ69RTNQ0iZEedCSHlyqRlUIduI1qlBvOfJ1UEs8KmInU07H2UU/O0AEz1bkQ5 X-Received: by 2002:a17:906:f24d:: with SMTP id gy13mr13109428ejb.159.1574334761315; Thu, 21 Nov 2019 03:12:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574334761; cv=none; d=google.com; s=arc-20160816; b=SibPNfRcjMcseXCdXgbEqyV+nh/Q2AI52ot4P8zBEd7SeeoG+JAT/4ncP1ObDrIyzE nuOBBuxEzqR/xgIX0N5A75j2acP79H9MFB4shsGWPCxThr/M5t+zrRwdQrc+nAOrNese 7G8mLX0WF9WB0QCURPjCCfrM5NNq39XsSOvZUsy+GbUvag3sl4Ln+xEueZcOiCcop7jM DiXKmAZu/017Q7jEpenikB6hErFfCLK8PDjDE7q8x4VutcbRWuDbl661evLDia3Coy4D Kuy0npfeybThqm75Nbhagu8r8hfGZjvDJyWqQ14/FmuZsiSLNchYkzTAtLBsZI8iWumD yogg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=J3Cy3tfrJiIUlL+D9Jr0kFLFrHhJQwh4Hdb4cuVFpa8=; b=eGsx/5X0YAkY3BRe66nOJ3snwXQLb6kPk8JSEyVqEe91pKkANeDj/pslzXNwMZUo2A 3kl7qdJ5uQhxnfxEAGBJVLEI/JcmN5jKqiWJ2qKpI9LcB4Ym2A0kjTGfxGjZoy0ls2Oz iMhCqvB6MF1CPtN5kZDAmVEOwNAKBu2IQBdShEJMwkZoHbCu9/kdj6nxPWFyP3rxBJih CNLfXV//Y356an7J4MgP1Nl92Y9ETH5Qx7kGQHHwS3wip189pvUWSwW9rg7HIXnM9MwY lbO/ycoQLHEGWwJljv3j7AZBsGwR2WiyY9GJ5MhA5jJ96o/u08KaE2eDE/IR6BQYG9Hi Qcmg== 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p12si1544861ejz.131.2019.11.21.03.12.16; Thu, 21 Nov 2019 03:12:41 -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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726948AbfKULIo (ORCPT + 99 others); Thu, 21 Nov 2019 06:08:44 -0500 Received: from mail-oi1-f194.google.com ([209.85.167.194]:45296 "EHLO mail-oi1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726343AbfKULIo (ORCPT ); Thu, 21 Nov 2019 06:08:44 -0500 Received: by mail-oi1-f194.google.com with SMTP id 14so2763941oir.12; Thu, 21 Nov 2019 03:08:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=J3Cy3tfrJiIUlL+D9Jr0kFLFrHhJQwh4Hdb4cuVFpa8=; b=t7izMp7L9m/mc+anZp95DTBPCpW00kdy7F08hqeD+CGRnja1NdfKf05/DPU3sk1eiX 95bD/kg33gi6jU3uBcDk8T63IlASiPOsto3+B4N0peXSJxpLgB0/Ewb7NMnsOLfZFSK5 SSs3K2dluw0O+F9ZkA4VJYo6HC7DtsniL9H3DEFngXLe/GkUUseyMdimjAYIjsN5y7Bl 3W6oBgNF3AxYL9aZ0i7aGzLEjOK+XPUPTem7vS5yqpSoy5lxELXCFEDhiz+BH7o1E9OB HtmzbsQ3O/V18GP0XVsdvuQ3daRYh5cqw5FGWNOaSPDZnlXBWI1AZHz5/1CqJmj1whu4 7e8A== X-Gm-Message-State: APjAAAUjdM2BHdEJLbRv1zRTm6QwvVBU72iAJiPpqiFoKLD53eAXVX/f 5/PfBJ3RA9uf3tazvyVQz2bbnpHLak01agRCSL4= X-Received: by 2002:a05:6808:901:: with SMTP id w1mr7358488oih.57.1574334523139; Thu, 21 Nov 2019 03:08:43 -0800 (PST) MIME-Version: 1.0 References: <20191120115127.GD11621@lahna.fi.intel.com> <20191120120913.GE11621@lahna.fi.intel.com> <20191120151542.GH11621@lahna.fi.intel.com> <20191120155301.GL11621@lahna.fi.intel.com> <20191120162306.GM11621@lahna.fi.intel.com> <20191121101423.GQ11621@lahna.fi.intel.com> In-Reply-To: From: "Rafael J. Wysocki" Date: Thu, 21 Nov 2019 12:08:31 +0100 Message-ID: Subject: Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges To: Mika Westerberg Cc: Karol Herbst , "Rafael J. Wysocki" , Bjorn Helgaas , LKML , Lyude Paul , "Rafael J . Wysocki" , Linux PCI , Linux PM , dri-devel , nouveau , Dave Airlie , Mario Limonciello Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 21, 2019 at 12:03 PM Rafael J. Wysocki wrote: > > On Thu, Nov 21, 2019 at 11:14 AM Mika Westerberg > wrote: > > > > On Wed, Nov 20, 2019 at 10:36:31PM +0100, Karol Herbst wrote: > > > with the branch and patch applied: > > > https://gist.githubusercontent.com/karolherbst/03c4c8141b0fa292d781badfa186479e/raw/5c62640afbc57d6e69ea924c338bd2836e770d02/gistfile1.txt > > > > Thanks for testing. Too bad it did not help :( I suppose there is no > > change if you increase the delay to say 1s? > > Well, look at the original patch in this thread. > > What it does is to prevent the device (GPU in this particular case) > from going into a PCI low-power state before invoking AML to power it > down (the AML is still invoked after this patch AFAICS), so why would > that have anything to do with the delays? > > The only reason would be the AML running too early, but that doesn't > seem likely. IMO more likely is that the AML does something which > cannot be done to a device in a PCI low-power state. BTW, I'm wondering if anyone has tried to skip the AML instead of skipping the PCI PM in this case (as of 5.4-rc that would be a similar patch to skip the invocations of __pci_start/complete_power_transition() in pci_set_power_state() for the affected device).