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=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 57D28C33CA9 for ; Mon, 13 Jan 2020 15:32:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2A749222C3 for ; Mon, 13 Jan 2020 15:32:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Bj1EVnuD" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728733AbgAMPcn (ORCPT ); Mon, 13 Jan 2020 10:32:43 -0500 Received: from us-smtp-1.mimecast.com ([207.211.31.81]:26934 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726163AbgAMPcn (ORCPT ); Mon, 13 Jan 2020 10:32:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1578929561; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ElsdEkFyMX9PyqBKUyWZEu82iD4Q0YddLseGJka/eAI=; b=Bj1EVnuDqJ3I4W2v+zBgT64RlM0USLfMa+ET889BKc3YG9YWv6iNSD6J/bVgaw1A74xkOn VI+w/Tfak+A/sBALLtsTvCIBluAoilIDG41gzF/ICyiJv5e+OEQShv6w34WYSwl34t9Yl8 lZu/HrhC9abGT/H/k54yeN+E4Z2ECRU= Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-165-oxp4dXMMPSGnPiFK570Log-1; Mon, 13 Jan 2020 10:32:40 -0500 X-MC-Unique: oxp4dXMMPSGnPiFK570Log-1 Received: by mail-qv1-f70.google.com with SMTP id v3so6516189qvm.2 for ; Mon, 13 Jan 2020 07:32:40 -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=ElsdEkFyMX9PyqBKUyWZEu82iD4Q0YddLseGJka/eAI=; b=I2SivU/Q1FnJJqTkwtl+PYdJ3ksNd/khMUQTyM2WKsGmWRG2Pr8KgGYNHrzPeF6x/L gQ1lLh/J4DwtYAUZ3sbyY3tmCeZa1V5Eg3T6JkTQ8926azPpePFZfv1KXl/1ZMp4rgG9 GlYz1sDQd8jvj6O0raB/jh9H+EyzFTcHT1dkmg+pmQdRpC3uzD5wuMAd0QMcq8QgHXIO 86JppmxC5A2hSfPE8LQedxSLFlsNtNXLGgBguh5yAqk6BOPgu1H/TK5jOANwSG++fZVr CJHXH0BYjeSEGI6kXrxoOmKNH3QhT+p6P4eLjJpX1rkKkXKEYPq2U4+HLzSTIVDI3dxa cWKQ== X-Gm-Message-State: APjAAAXH9S5seiyet+7Y0J4fvvize/m0OR7dSh40RoLfVIrXSeG0jRyd 5O7UU0cHmhIGAealGsZKkRiWSsHPmzzso51NZSM627/0TNYd0PGwxG4tDAWp+6DHJbnHUbDmT/A gEr766e3/bMg8yKXQYQtVtpdGlI62e8cHhmM= X-Received: by 2002:a37:9245:: with SMTP id u66mr12325303qkd.102.1578929560031; Mon, 13 Jan 2020 07:32:40 -0800 (PST) X-Google-Smtp-Source: APXvYqytL56xMC0vF1glxTM38WsY2Ix40Z1naBdqh2T+YigaQEOs8RJRhNMIOMubvldRvknv5G4xQqo3cppMYY9Rex0= X-Received: by 2002:a37:9245:: with SMTP id u66mr12325263qkd.102.1578929559700; Mon, 13 Jan 2020 07:32:39 -0800 (PST) MIME-Version: 1.0 References: <20191121112821.GU11621@lahna.fi.intel.com> <20191121114610.GW11621@lahna.fi.intel.com> <20191127114856.GZ11621@lahna.fi.intel.com> In-Reply-To: From: Karol Herbst Date: Mon, 13 Jan 2020 16:31:50 +0100 Message-ID: Subject: Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges To: Dave Airlie Cc: "Rafael J. Wysocki" , Lyude Paul , Mika Westerberg , Bjorn Helgaas , LKML , "Rafael J . Wysocki" , Linux PCI , Linux PM , dri-devel , nouveau , 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 okay.. so checking whatever is the difference with _REV being 5 (meaning the firmware uses the legacy paths) doesn't help in any way. It's using a different method to turn the link of and the other ACPI variables touched either point to undocumented registers on the PCI bridge or internal ACPI memory... so, anybody with any other ideas? I really wished the nvidia driver would enable runpm on pre turing GPUs, but that's sadly not the case and on Turing things seem to be totally different, so it wouldn't help to check there as well... *sigh* On Tue, Dec 10, 2019 at 9:49 PM Karol Herbst wrote: > > On Tue, Dec 10, 2019 at 8:58 PM Dave Airlie wrote: > > > > On Mon, 9 Dec 2019 at 21:39, Rafael J. Wysocki wrote: > > > > > > On Mon, Dec 9, 2019 at 12:17 PM Karol Herbst wrote: > > > > > > > > anybody any other ideas? > > > > > > Not yet, but I'm trying to collect some more information. > > > > > > > It seems that both patches don't really fix > > > > the issue and I have no idea left on my side to try out. The only > > > > thing left I could do to further investigate would be to reverse > > > > engineer the Nvidia driver as they support runpm on Turing+ GPUs now, > > > > but I've heard users having similar issues to the one Lyude told us > > > > about... and I couldn't verify that the patches help there either in a > > > > reliable way. > > > > > > It looks like the newer (8+) versions of Windows expect the GPU driver > > > to prepare the GPU for power removal in some specific way and the > > > latter fails if the GPU has not been prepared as expected. > > > > > > Because testing indicates that the Windows 7 path in the platform > > > firmware works, it may be worth trying to do what it does to the PCIe > > > link before invoking the _OFF method for the power resource > > > controlling the GPU power. > > > > > > > Remember the pre Win8 path required calling a DSM method to actually > > power the card down, I think by the time we reach these methods in > > those cases the card is already gone. > > > > Dave. > > > > The point was that the firmware seems to do more in the legacy paths > and maybe we just have to do those things inside the driver instead > when using the new method. Also the _DSM call just wraps around the > interfaces on newer firmware anyway. The OS check is usually what > makes the difference. I might be wrong about the _DSM call just > wrapping though, but I think I saw it at least in some firmware at > some point.