From patchwork Mon Sep 21 23:10:55 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alex Deucher X-Patchwork-Id: 1368659 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org (client-ip=23.128.96.18; helo=vger.kernel.org; envelope-from=linux-pci-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20161025 header.b=QKBdO2Hy; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by ozlabs.org (Postfix) with ESMTP id 4BwKtk3T2Gz9sSt for ; Tue, 22 Sep 2020 09:11:10 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728662AbgIUXLI (ORCPT ); Mon, 21 Sep 2020 19:11:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37362 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726457AbgIUXLI (ORCPT ); Mon, 21 Sep 2020 19:11:08 -0400 Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DECA3C061755 for ; Mon, 21 Sep 2020 16:11:07 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id x14so14831175wrl.12 for ; Mon, 21 Sep 2020 16:11:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=mHoruSCyZR4aICiJOK7Oyc3GUtCT1YETmG8eqkML2Gg=; b=QKBdO2HyWrFJo0anOE7p59d0SMUl1Koh7vCzMjNiTV/igqaVwQVASeyxy7LbSu4Z0e yUV+lnGb+iHCzrfW8UVJnirCFDBCLgcQUGPRUFNCUIResuZFZRlIfgEIQBFoq3Ae7OXI uyS23b2h4r3XgsyPViV64KPWY6WF6HHakbFBnJv7VcrtkYJavMXN1DAbfA9Ztq9TH00G pX7Wci2C67rRWCX7xZAtKcHMNNgW1PYSVsPFbkBb9CcSMuPQ7g4CrMammYwzQMf3D7a/ a6JGc4uOD9tONtBOP3+L/ezkLRegnPyaXTTDgEN4Wpuir3vSOVdE7b7neO/uul00g8Zu EZzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=mHoruSCyZR4aICiJOK7Oyc3GUtCT1YETmG8eqkML2Gg=; b=hCExcjVQjZNBg0c6e2wxveUNx33D07xr/OLvfH5P3VdCeksjr0a06Bkk5wz6RgP7IJ HtXXLq0Rk7eH2req8dcNmHGp95T0SyFcjVmdjzaU/4yoVGH+iJuxF7VTTGeAVl2EpGuf wm41MOvSyiCV87VeLc42Us5zS+ghewtQdVGsStysakxc9yAjx/0Se4IoXqHWiCdPWMv/ adIJTvW5Ift/tvroqwneGkrpcRrpY2Ucv1MQ8pUCdbUNaQPRv0q4fDS52b3KGRJ4s/p5 sJcHtB1xtvcaS3QLBlQZEYBkkS+cd9nKkA0rjQGZefXBW0+DQrEVIRkMYT/EMpfDdAhX CHwA== X-Gm-Message-State: AOAM5316WquCvdfZtYw2RDZMWDaT3cAFYRBiLcunHLWKtNevx0zLe1n8 mE+hqqVz3Lsem6rRt/pH0/V1rG5JoZnCYXU/c6IP/eOvO7Q= X-Google-Smtp-Source: ABdhPJxtWOG/4ajINBRKKkNt712x8PYq4hQ3wl1GTbaZnR6+3sZrcv6ERqQp8RkkA9frdw0fq9gZd3lOj0sz1bFoeBw= X-Received: by 2002:adf:dd82:: with SMTP id x2mr2145851wrl.419.1600729866335; Mon, 21 Sep 2020 16:11:06 -0700 (PDT) MIME-Version: 1.0 From: Alex Deucher Date: Mon, 21 Sep 2020 19:10:55 -0400 Message-ID: Subject: Enabling d3 support on hotplug bridges To: Linux PCI , Lukas Wunner , Bjorn Helgaas , "Rafael J. Wysocki" Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org Hi, Recent AMD laptops which have iGPU + dGPU have been non-functional on Linux. The issue is that the laptops rely on ACPI to control the dGPU power and that is not happening because the bridges are hotplug capable, and the current pci code does not allow runtime pm on hotplug capable bridges. This worked on previous laptops presumably because the bridges did not support hotplug or they hit one of the allowed cases. The driver enables runtime power management, but since the dGPU does not actually get powered down via the platform ACPI controls, no power is saved, and things fall apart on resume leading to an unusable GPU or a system hang. To work around this users can currently disable runtime pm in the GPU driver or specify pcie_port_pm=force to force d3 on bridges. I'm not sure what the best solution for this is. I'd rather not have to add device IDs to a whitelist every time we release a new platform. Suggestions? What about something like the attached patch work? Alex From 3a08cb6ac38c47b921b8b6f31b03fcd8f13c4018 Mon Sep 17 00:00:00 2001 From: Alex Deucher Date: Mon, 21 Sep 2020 18:07:27 -0400 Subject: [PATCH] pci: allow d3 on hotplug bridges after 2018 Newer AMD laptops have hotplug capabe bridges with dGPUs behind them. If d3 is disabled on the bridge, the dGPU is never powered down even though the dGPU driver may think it is because power is handled by the pci core. Things fall apart when the driver attempts to resume a dGPU that was not properly powered down which leads to hangs. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1252 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1222 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1304 Signed-off-by: Alex Deucher --- drivers/pci/pci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index a458c46d7e39..12927d5df4b9 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -2856,7 +2856,7 @@ bool pci_bridge_d3_possible(struct pci_dev *bridge) * by vendors for runtime D3 at least until 2018 because there * was no OS support. */ - if (bridge->is_hotplug_bridge) + if (bridge->is_hotplug_bridge && (dmi_get_bios_year() <= 2018)) return false; if (dmi_check_system(bridge_d3_blacklist)) -- 2.25.4