Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp5867259ybl; Tue, 10 Dec 2019 12:52:25 -0800 (PST) X-Google-Smtp-Source: APXvYqylX8WcBbsfR3Rqid+AASAqND8pm1ytFrRcZf+GlZBBWLJO4U8q80PfIBz6DvsoV0xEMIsu X-Received: by 2002:a9d:7357:: with SMTP id l23mr25943348otk.10.1576011145650; Tue, 10 Dec 2019 12:52:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576011145; cv=none; d=google.com; s=arc-20160816; b=bVnl4/jfOYz9y1gfpiDzKhoD5H/sBIW4wds3ePHKsisv/CQDhjZvsCf1qOBl9KyQ9l Pm7n5JF6F/0R2CKUILtkt3SeUcNhUuSdx4DWghkS7+H2SqepOlJ08/HCVZgxah7CJ3EG UP2CgnUDvwXPYa20wYEnFHi+5fC2Ms2DP5275MTNzpVq13W6pkMBnxUyR4U+JWL0pIyM rioIBw3CpZq+9/JI/Yfb7uEhwU9cetMLrkPtmyUxWqXomJrr27cjPBsq+Hgq8FGFk4xj iwMoJJkQApq+O6B5yKPpCqAguA7xsQfvG+Xxz7VHWQXO4h3hAqeWT5cUmScfnSJLSb7V FFqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=QKUGte0LJJOC+2J/QTsxMNBL/KSTWmiIxFV3NdoEcMk=; b=kuUZQVJxavW4dvjGEdsnuTKbIWOItuD0bwLUWAnTesK9PXNmdlXhCxDBu1dCMi5b48 P4f+5qLI1LOTUhdnRD4VqAu3YP0K8YRmlyBX5gm0hB4W8zIXwU20f7jNSW4eVkFDL/td Kup2wJcE/cE5N4+WZzzcJOvxMWxlKmFzuLQ+KShuXamVQT1+l88jqMI1jWu7JTGtxTeg YGrnHlHPkODqqPg70hoCYo+cUqp6h4EmGL330FsVfoIA1YxaK806qPW6SfyfuO+MOHRf OZUvPXnO4UhHGkNCXSeBwLiQI4I6z8O0MnTksY2R0lhdmmFG674hdSCkTQ6fhWsqjYvo mODg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=P5rS1ded; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f19si2595312oti.13.2019.12.10.12.52.12; Tue, 10 Dec 2019 12:52:25 -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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=P5rS1ded; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726987AbfLJUuQ (ORCPT + 99 others); Tue, 10 Dec 2019 15:50:16 -0500 Received: from us-smtp-1.mimecast.com ([205.139.110.61]:60649 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726595AbfLJUuP (ORCPT ); Tue, 10 Dec 2019 15:50:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1576011014; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QKUGte0LJJOC+2J/QTsxMNBL/KSTWmiIxFV3NdoEcMk=; b=P5rS1dedEBxFPy5AnXGUz9ogs5rnL+G8tGqNeRh8ENhrU8wqM7+JEOWXSitLFPq2r2yrwF 4UFS4AvbtqL+Rmd/62txWgYEjsm0kVpwVZb9NxsV/grwpqgq+cyoKwoC6ievxfKo2S/NmV 1vR+S0rUYcz6LeFlakYxRRZKuD4CbXk= Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-8-Kp1i787HO8KAWrXGbgsrtA-1; Tue, 10 Dec 2019 15:50:11 -0500 Received: by mail-qt1-f198.google.com with SMTP id d9so2847299qtq.13 for ; Tue, 10 Dec 2019 12:50:10 -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=L2m4Tv+vpahKKFm5uAjvOrE573uy1RkQak8WAblX7g4=; b=AX2KGRXNK6Te/1gqR1iun1NRPRgnXEySXCnjLIaLjZKkMtEwWHNuHggiSmQWSMz0W5 b+qql14fTO0BWbd4NsVBvXzScdjVIQ8noHuCNHmcMUHf2TgPGbiRl0c5ikHkS2wUr1CI lbFCIiB27FWXI4vCSvo0gGyUhf64qOvOK29iBJ0kG7ZNWSZmMZ2bnXvxdEUhxkFbzl0T n+6d5S6oQ+39p2k4ysk7mUv5dnZXOhxWX10DAyg2b+PqthLm/GiUmia+9MbsStPkVTvt r6JYjOQddxPx7WeMfsS9ia+I0UOd0sqnZnzRepEr/7wrfDfOM6c7ybNrZ0iOFY3BY5SX 5tCQ== X-Gm-Message-State: APjAAAWKGWceNNQNEd/kCo6mnBlVADsJoqbyzhKKJgS+3BahY9KhTeVE 5XGCr5069RdJbPCj0Gy+tP25+4b5EOV7nZbdKwHY/nhv4PAFCs2W07Na7ILkXbWc7/dN5JVPVqt pjC3Z9tNdPMJsxZG1qy4FLObB64W1wRthW5Pv+Usl X-Received: by 2002:a0c:baad:: with SMTP id x45mr29886299qvf.230.1576011010489; Tue, 10 Dec 2019 12:50:10 -0800 (PST) X-Received: by 2002:a0c:baad:: with SMTP id x45mr29886279qvf.230.1576011010089; Tue, 10 Dec 2019 12:50:10 -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: Tue, 10 Dec 2019 21:49:58 +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 X-MC-Unique: Kp1i787HO8KAWrXGbgsrtA-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.