Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp490452pxb; Wed, 13 Apr 2022 06:32:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzw+XkLicEHc9WytHb9xZ9G8t+DRZ+6f0D4wYYAluquhUpkPLKO/+Dys71aBXFUInWlM34o X-Received: by 2002:a17:90b:1b03:b0:1c7:778b:d4ce with SMTP id nu3-20020a17090b1b0300b001c7778bd4cemr10900850pjb.128.1649856747199; Wed, 13 Apr 2022 06:32:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649856747; cv=none; d=google.com; s=arc-20160816; b=nAlpd7ET6wY0O9zuGqnkAXD73avVf7CfpIpFsnYRMqCpN7UHc9bLKNi9j9bJjImydt RZfVh8LID45+LG0GyZPdQmW8RfgYuD7tuVBW/1SyoV2MqTSmnqYM1AKjPy0yO5EtBbNm ekhMrEkxBXCHKUqxRbemD03nl/ELOh3R1LKwvYgvB98wAv7IuKjsdCltUai12EM944zA II21i7NORAFcd+DB0EPl8hUIg5wNT2Rtscql+UIsfEtr3im7Nc6avF8kNZ7x3V6/TfFq x0PCkOXAcpkAsDLNvOkynmO0GbrfwN8N2sizbDw/AjgIFcgnj6/tpDzsJxMzSd9XikoB ZnfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=0+L1oFdXUso9G3KHnx7FO574tWUilVPchMr2ubMIpSs=; b=VMvV33tJvFHb68aXicaG9lGjCGCvEWnWtHi+CPmp0EMfFZRa59EE1j64r6hSqNOLsV PVLTRGKKEmIDYBuTRAJtmZDWKrmp2zelcRHVDx7a37b25I2UCtHvw2Lyjkydi7MLTPvB StGUP4U/Q1g8zUf4pS5Ri7fceCdM9sPaYGDNjTESwEfARzWoO44Xtc2w/RVyGH7WLXp/ 6rakdT5lRD5iAN0pvEdJjrgH0C4rNwtW2XZfh4z5lXkMnu7lJlOFaypsEkD86p8puFbS dAoT+rqzwtDUWrfhaR5hMqkQ24Umkd2iiShKtZP0EoZSBTZdNo6qud4AmAuka2jhbZvC RPqg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u16-20020a17090341d000b001577e9cfa99si7106661ple.600.2022.04.13.06.31.45; Wed, 13 Apr 2022 06:32:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233449AbiDMHqR (ORCPT + 99 others); Wed, 13 Apr 2022 03:46:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40520 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233435AbiDMHqK (ORCPT ); Wed, 13 Apr 2022 03:46:10 -0400 Received: from mx1.molgen.mpg.de (mx3.molgen.mpg.de [141.14.17.11]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6932E63E7 for ; Wed, 13 Apr 2022 00:43:49 -0700 (PDT) Received: from [192.168.0.2] (ip5f5ae908.dynamic.kabel-deutschland.de [95.90.233.8]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: pmenzel) by mx.molgen.mpg.de (Postfix) with ESMTPSA id 9BE2661EA192C; Wed, 13 Apr 2022 09:43:46 +0200 (CEST) Message-ID: Date: Wed, 13 Apr 2022 09:43:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [PATCHv4] drm/amdgpu: disable ASPM on Intel Alder Lake based systems Content-Language: en-US To: Richard Gong Cc: alexander.deucher@amd.com, christian.koenig@amd.com, xinhui.pan@amd.com, airlied@linux.ie, daniel@ffwll.ch, amd-gfx@lists.freedesktop.org, kernel test robot , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, mario.limonciello@amd.com References: <20220412215000.897344-1-richard.gong@amd.com> From: Paul Menzel In-Reply-To: <20220412215000.897344-1-richard.gong@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dear Richard, Thank you for sending out v4. Am 12.04.22 um 23:50 schrieb Richard Gong: > Active State Power Management (ASPM) feature is enabled since kernel 5.14. > There are some AMD GFX cards (such as WX3200 and RX640) that won't work > with ASPM-enabled Intel Alder Lake based systems. Using these GFX cards as > video/display output, Intel Alder Lake based systems will hang during > suspend/resume. I am still not clear, what “hang during suspend/resume” means. I guess suspending works fine? During resume (S3 or S0ix?), where does it hang? The system is functional, but there are only display problems? > The issue was initially reported on one system (Dell Precision 3660 with > BIOS version 0.14.81), but was later confirmed to affect at least 4 Alder > Lake based systems. > > Add extra check to disable ASPM on Intel Alder Lake based systems. > > Fixes: 0064b0ce85bb ("drm/amd/pm: enable ASPM by default") > Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1885 > Reported-by: kernel test robot This tag is a little confusing. Maybe clarify that it was for an issue in a previous patch iteration? > Signed-off-by: Richard Gong > --- > v4: s/CONFIG_X86_64/CONFIG_X86 > enhanced check logic > v3: s/intel_core_asom_chk/aspm_support_quirk_check > correct build error with W=1 option > v2: correct commit description > move the check from chip family to problematic platform > --- > drivers/gpu/drm/amd/amdgpu/vi.c | 17 ++++++++++++++++- > 1 file changed, 16 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c > index 039b90cdc3bc..b33e0a9bee65 100644 > --- a/drivers/gpu/drm/amd/amdgpu/vi.c > +++ b/drivers/gpu/drm/amd/amdgpu/vi.c > @@ -81,6 +81,10 @@ > #include "mxgpu_vi.h" > #include "amdgpu_dm.h" > > +#if IS_ENABLED(CONFIG_X86) > +#include > +#endif > + > #define ixPCIE_LC_L1_PM_SUBSTATE 0x100100C6 > #define PCIE_LC_L1_PM_SUBSTATE__LC_L1_SUBSTATES_OVERRIDE_EN_MASK 0x00000001L > #define PCIE_LC_L1_PM_SUBSTATE__LC_PCI_PM_L1_2_OVERRIDE_MASK 0x00000002L > @@ -1134,13 +1138,24 @@ static void vi_enable_aspm(struct amdgpu_device *adev) > WREG32_PCIE(ixPCIE_LC_CNTL, data); > } > > +static bool aspm_support_quirk_check(void) > +{ > + if (IS_ENABLED(CONFIG_X86)) { > + struct cpuinfo_x86 *c = &cpu_data(0); > + > + return !(c->x86 == 6 && c->x86_model == INTEL_FAM6_ALDERLAKE); > + } > + > + return true; > +} > + > static void vi_program_aspm(struct amdgpu_device *adev) > { > u32 data, data1, orig; > bool bL1SS = false; > bool bClkReqSupport = true; > > - if (!amdgpu_device_should_use_aspm(adev)) > + if (!amdgpu_device_should_use_aspm(adev) || !aspm_support_quirk_check()) > return; Can users still forcefully enable ASPM with the parameter `amdgpu.aspm`? > > if (adev->flags & AMD_IS_APU || If I remember correctly, there were also newer cards, where ASPM worked with Intel Alder Lake, right? Can only the problematic generations for WX3200 and RX640 be excluded from ASPM? Kind regards, Paul