From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 68C7FC432C0 for ; Thu, 21 Nov 2019 11:32:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3D17B20714 for ; Thu, 21 Nov 2019 11:32:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1574335931; bh=ojiuDFiYTw8I726hFOqmkuUZ2H/Y8Yt0mV9sqr8BO0o=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=OAyBJ9dU9zGysc1w+chhKz572Y6dNc/ohGG7ukCDqlPEc8NRQvDLf68ZtOu9WREbs zRIFUN+y+TEpjrI4M/fN5ZJ7K0vh3/FXtLMznAW+XsFQbWn30d3T9GAmv4DvglHHRF lQIP7Nbcf3RER8sW8Qsi0XkKKhKXH83b1h5LdkVA= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726197AbfKULcK (ORCPT ); Thu, 21 Nov 2019 06:32:10 -0500 Received: from mail-ot1-f68.google.com ([209.85.210.68]:36589 "EHLO mail-ot1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726170AbfKULcK (ORCPT ); Thu, 21 Nov 2019 06:32:10 -0500 Received: by mail-ot1-f68.google.com with SMTP id f10so2620315oto.3; Thu, 21 Nov 2019 03:32:09 -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=f3k4Aw80bkAO/6lAcOnkrOVE0ZhJFwvrlGzBabrShVQ=; b=Kv1F6bEUhx6XQilNyRp5ccDX97+jKHY04dGPtgnXkkNmN1nLCsZet1HBp6NxiFTCog LFD0D3/jhQrn3W+nMSAx+K7SiH3b7BUp6boLA4Uils2pfjlE4o3TCsknqqVYMD80hAw7 BgDVuUgWkXW8nOUM/tAavm4mCsW1TeHPJdU2VqLKkwazZ27TFUIrsjssF3fNVThU0pJ5 z1qjBToEZMIIYuTX9F8ubmlrBHK+Bxvn4ujWxg5FuoMCbvgzUJW6nWLHA1u1F2dzaXfj lT85jmnalnuQ5yGCQPiD0paYorzZqOJvKqVsibm9e8jPhpJEuFcMbPpupdgK2n30PZq2 srpQ== X-Gm-Message-State: APjAAAXqIg6oIv7uJUPnZvBy0m/fv6zw9IXiur2wEVxHpIDmdM6TuYmt N3ph8zTqmHJE/KZz1+H9V+mLPUHvkRiGQdB9FTY= X-Google-Smtp-Source: APXvYqyCvKoq/cebzpfoCwlOfAUaYaxdKEecqatFjILqmn5JZJGCEgUqfxdBRzz6K72JW/bHFhwWpS917aNaWsJQbzY= X-Received: by 2002:a9d:4c85:: with SMTP id m5mr5838389otf.118.1574335929309; Thu, 21 Nov 2019 03:32:09 -0800 (PST) MIME-Version: 1.0 References: <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> <20191121111739.GT11621@lahna.fi.intel.com> In-Reply-To: <20191121111739.GT11621@lahna.fi.intel.com> From: "Rafael J. Wysocki" Date: Thu, 21 Nov 2019 12:31:57 +0100 Message-ID: Subject: Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges To: Mika Westerberg Cc: "Rafael J. Wysocki" , Karol Herbst , 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-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org On Thu, Nov 21, 2019 at 12:17 PM Mika Westerberg wrote: > > On Thu, Nov 21, 2019 at 12:03:52PM +0100, 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? > > Yes, I know what it does :) I was just thinking that maybe it's still > the link that does not come up when we go back to D0 I guess that's not > the case here. I'm not sure why that would be related to putting the device into, say, PCI D3 before invoking AML to remove power from it. If it is not in PCI D3 at this point, the AML still runs and still removes power from it IIUC, so on the way back the situation is the same regardless: the device has no power which (again) needs to be restored by AML. That (in principle) should not depend on what happened to the device before it lost power.