Message ID | 20221116154341.13382-1-mario.limonciello@amd.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp212058wru; Wed, 16 Nov 2022 07:45:13 -0800 (PST) X-Google-Smtp-Source: AA0mqf4EFhIpeb+LFHaWVRf2quUTINx+s0NtqAYLIRd0cuEUVFHRA73kLa53vUIddYzf8mRADdKf X-Received: by 2002:a17:902:d1d4:b0:186:9ef5:4d59 with SMTP id g20-20020a170902d1d400b001869ef54d59mr9523139plb.89.1668613513081; Wed, 16 Nov 2022 07:45:13 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1668613513; cv=pass; d=google.com; s=arc-20160816; b=A3jAsK0lH+pWkRsPhPvGXH/Ov3cxnrlyYyJa1TToFtE6/C9GtqCxdKRqfhAJep03vb 9RWEbeFJ1lUoWEzxczzZE1j1OVTFxgCO+rK45PPHf7V+VfX85/Rb7MRqmdC3rDtbW55e o+Qxdw4NzYLrnwVPGklvIsLoPlmaA/UqzOYBUtGCP/HjF1vc4ziIc15ZPuVbVBeaktAi HMFZFSK2L6nBueWzJ1h36+K5kOtCpcZ+WDY4d3WzaLC01qb2Cp0bmfhjBQaucTqe/xLn nKmucgwd2cT4ssv3jWufRuyMfGFgWkGCqhSoyPW0ahqKmter4HbjzBKv5/XOzkQ/7DQT CK2A== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=STTiHUo8HIMpX7pk6HDBH9HnJDDNVjYT7KMdGMeEF7k=; b=zIBcGoJJlMQnk95aTibvnLp9hvSzHoYx/aj/3buFqj/7z1MVf/lV/1GmmJgXoeRRN+ SFf5qN6v8+FmSsfUN3TgCm3rKSPFa2vCyPzuPAS7wGY9NrVHrBwGdvxteUVfO7+KXSkp FoUe4Ki3JvocDAAjRDaCtWVXGAQm8KWC1kWzDZ3h6UmFDGl/nfYLqm78+R/WFC37TtuF Z1ftA2gy2Zt46mkDeotRWa63RucRgHg/0NE385vHiw/tRD7wiCZH8nDE42G70mGR3bwj YXAIUG1r8C38ks+qifbOj103w6tUTalYQsHvjkzeTiYR8Crc1THjDNo1rvsbQK3C45XF 3cHw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@amd.com header.s=selector1 header.b=mx2F5EcP; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.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; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x17-20020a17090a531100b002130f3bc5ebsi2052528pjh.56.2022.11.16.07.44.58; Wed, 16 Nov 2022 07:45:13 -0800 (PST) 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; dkim=pass header.i=@amd.com header.s=selector1 header.b=mx2F5EcP; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.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; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229758AbiKPPoB (ORCPT <rfc822;just.gull.subs@gmail.com> + 99 others); Wed, 16 Nov 2022 10:44:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55530 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231313AbiKPPn4 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 16 Nov 2022 10:43:56 -0500 Received: from NAM04-MW2-obe.outbound.protection.outlook.com (mail-mw2nam04on2066.outbound.protection.outlook.com [40.107.101.66]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3776260DE; Wed, 16 Nov 2022 07:43:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JSWZGjs2+cfRJufwn8ovpsDxwQ6PNokjPeXgUAOygyvhuKvc14fVpo6D93ljkiPBjGBY31SOJB+NfDzUIShRm9qhOgvk0iMBaORxX5IOqIEKtx6DlFTSAC/Xp6LmdeoB1pRJg3ySdpr1VfroyxEgqWqWXX/2Me1noNblaUOUYxLjyw7NkYpXrqZE+izl1vk30M+R25q5O+s/3JM8rZdPyEZGg8bNQDPRaOBgc0gYmi+y2VYYg6X1SR0H3ziMZOHvucyNmwF0U+rsZmTqSshr7f2w5gqny2zXUK6TcS99ot71W3Le/GN6iTGx5iV+imc4U/m5MllR6a3HqJd689mKDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=STTiHUo8HIMpX7pk6HDBH9HnJDDNVjYT7KMdGMeEF7k=; b=ZPX7wkSDST3i1S0XVweNS8Rr4dG8pF59hTfGiirB9+r5xJhjRMXX/yhR2JBHpBcCeg4ZyU5JVPf9dVZZrSJNhwFheUXeSzWI3RhAmxTdrJ3UA0Xed9IFSlUlYH6y8I9dxXjp0asosYLSlZcQiaxcjQtex0QcwDqDG+g21bRTYKeggZcHjnhdh3k3+8RPHj567pRRbtIph6AfDaQnfhq6kR32zTp1TGUre7rDztysBtJXRqxikzcFKZmaa2P1dbmypXgmHkrqwswrllMv7J0J28zzqIfUagor08LqFUUPBhe7NiI6hawpP9mCvB9LMw4z0HW5qAldoFcYLHumkdzLUA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=redhat.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=STTiHUo8HIMpX7pk6HDBH9HnJDDNVjYT7KMdGMeEF7k=; b=mx2F5EcPUW5ix6oT4IdMWAWjRtcWs60JPVqkUvuruSZvKRVuHatSzzfGWdr0Sw1UVAWNWCe1ATerWvXsdnhHbQL8ymvBofEfLPYB4t7REI0vHiubR5si686z36JitrxBxaI4eYhOPkcBvX9ZaKj3vCrLrU6XmUFuYr0H6hu3Wpo= Received: from DS7PR03CA0121.namprd03.prod.outlook.com (2603:10b6:5:3b4::6) by DM6PR12MB4577.namprd12.prod.outlook.com (2603:10b6:5:2aa::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5813.18; Wed, 16 Nov 2022 15:43:53 +0000 Received: from DM6NAM11FT113.eop-nam11.prod.protection.outlook.com (2603:10b6:5:3b4:cafe::7c) by DS7PR03CA0121.outlook.office365.com (2603:10b6:5:3b4::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5813.17 via Frontend Transport; Wed, 16 Nov 2022 15:43:52 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Received: from SATLEXMB04.amd.com (165.204.84.17) by DM6NAM11FT113.mail.protection.outlook.com (10.13.173.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.5834.8 via Frontend Transport; Wed, 16 Nov 2022 15:43:52 +0000 Received: from AUS-LX-MLIMONCI.amd.com (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.34; Wed, 16 Nov 2022 09:43:51 -0600 From: Mario Limonciello <mario.limonciello@amd.com> To: Hans de Goede <hdegoede@redhat.com>, Shyam Sundar S K <Shyam-sundar.S-k@amd.com> CC: Mario Limonciello <mario.limonciello@amd.com>, "Mahapatra, Rajib" <Rajib.Mahapatra@amd.com>, Raul Rangel <rrangel@chromium.org>, Mark Gross <markgross@kernel.org>, <platform-driver-x86@vger.kernel.org>, <linux-kernel@vger.kernel.org> Subject: [PATCH] platform/x86/amd: pmc: Add a workaround for an s0i3 issue on Cezanne Date: Wed, 16 Nov 2022 09:43:41 -0600 Message-ID: <20221116154341.13382-1-mario.limonciello@amd.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM6NAM11FT113:EE_|DM6PR12MB4577:EE_ X-MS-Office365-Filtering-Correlation-Id: c9ede0d5-6542-4e80-141c-08dac7e95cdf X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: x10UUJ8Jx8mH6pwcy0diDKkfslVsvd/zOKOuQhgdz/Q4Oe5FQtZU2W8Peq/pV0An2KsW+yzXyZY4OtxzDDU3hLBRleZLZ9snSIfc+lUSlZCGKD2X71iWt3KC5ZuxaW1UvZfk+zKICs+IQEpZfGWlUqpHKzuCZPgpqK2qDKdhZQ6v907dlbbkwjNsykrz1nuYyZJ7iH2D6SYgf613YOQ4ex9J4QsNNQ4jYGXJNmUfTdvplc1uogcWEPv5Ol8vierxJ0kmfQqjos1WfMBFFEVF/niWnoUUQLCI9prA2M8g6Q9VIGmVa3vyZarsuUIIIe4Rxy/WjQ2Lo1HoEfJRcIbEHGRdtwDW4dLJnowctr7nJrzDuEkMIzAGaoihctOajVy5MfMWSxSrZAedFiJFtsJglC4C7bl+SqVzs0/eyp1Y14A+kTmkYm8MHdwOaNYbJEh9YYzqQwJMTPPNqZbjRaSNMH0JoBJ38y6CeMl8uAXJzXmVY/SPdpJDNNNMizTvtf+xrpOgM98GHvq+9k1nejd3JXX6Xec8PVP8wreBJr6Vj4GYp0av97Ij2GNX35IVNGKNrTObBS7Zcz7k8tRz1yNBvkZp1WiuQeM15EtBOccZQlstNLxFGAVcC7bjcM4lBsCCsNufWNqQb+3oH6HFjQt9V3sY4qqhcx8aMDgMCn1nw7eJOxRGahL6xdhJvhzWLtr88iW0Ul8ux8afjyWK7mTyOnL4ikRaQx8gueN3kDI7iDn1NV28kRUj3FybBVL95skB5uPxHb5RtxSR7RaLg08v2ZjN8IVSHRXQQXFrqptpU1DoQ4+cAegJOam3xlUvhDwF X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230022)(4636009)(346002)(39860400002)(376002)(136003)(396003)(451199015)(40470700004)(36840700001)(46966006)(86362001)(40480700001)(82310400005)(4326008)(8676002)(40460700003)(41300700001)(36756003)(16526019)(2616005)(186003)(426003)(336012)(1076003)(70206006)(70586007)(8936002)(5660300002)(44832011)(47076005)(110136005)(6666004)(26005)(7696005)(478600001)(54906003)(2906002)(82740400003)(356005)(81166007)(316002)(6636002)(36860700001)(36900700001);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Nov 2022 15:43:52.4996 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c9ede0d5-6542-4e80-141c-08dac7e95cdf X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: DM6NAM11FT113.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4577 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1749668082958705634?= X-GMAIL-MSGID: =?utf-8?q?1749668082958705634?= |
Series |
platform/x86/amd: pmc: Add a workaround for an s0i3 issue on Cezanne
|
|
Commit Message
Mario Limonciello
Nov. 16, 2022, 3:43 p.m. UTC
Cezanne platforms under the right circumstances have a synchronization
problem where attempting to enter s2idle may fail if the x86 cores are
put into HLT before hardware resume from the previous attempt has
completed.
To avoid this issue add a 10-20ms delay before entering s2idle another
time. This workaround will only be applied on interrupts that wake the
hardware but don't break the s2idle loop.
Cc: "Mahapatra, Rajib" <Rajib.Mahapatra@amd.com>
Cc: "Raul Rangel" <rrangel@chromium.org>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
drivers/platform/x86/amd/pmc.c | 6 ++++++
1 file changed, 6 insertions(+)
Comments
Hi Mario, On 11/16/22 16:43, Mario Limonciello wrote: > Cezanne platforms under the right circumstances have a synchronization > problem where attempting to enter s2idle may fail if the x86 cores are > put into HLT before hardware resume from the previous attempt has > completed. > > To avoid this issue add a 10-20ms delay before entering s2idle another > time. This workaround will only be applied on interrupts that wake the > hardware but don't break the s2idle loop. > > Cc: "Mahapatra, Rajib" <Rajib.Mahapatra@amd.com> > Cc: "Raul Rangel" <rrangel@chromium.org> > Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Thank you for your patch, I've applied this patch to my review-hans branch: https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=review-hans Please let me know if it important to get this as a fix into 6.1, I wasn't really planning on doing any more fixes pull-reqs for 6.1, but I can do one if necessary. Once I've run some tests on this branch the patches there will be added to the platform-drivers-x86/for-next branch and eventually will be included in the pdx86 pull-request to Linus for the next merge-window. Regards, Hans > --- > drivers/platform/x86/amd/pmc.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/platform/x86/amd/pmc.c b/drivers/platform/x86/amd/pmc.c > index ef4ae977b8e0..439d282aafd1 100644 > --- a/drivers/platform/x86/amd/pmc.c > +++ b/drivers/platform/x86/amd/pmc.c > @@ -739,8 +739,14 @@ static void amd_pmc_s2idle_prepare(void) > static void amd_pmc_s2idle_check(void) > { > struct amd_pmc_dev *pdev = &pmc; > + struct smu_metrics table; > int rc; > > + /* CZN: Ensure that future s0i3 entry attempts at least 10ms passed */ > + if (pdev->cpu_id == AMD_CPU_ID_CZN && !get_metrics_table(pdev, &table) && > + table.s0i3_last_entry_status) > + usleep_range(10000, 20000); > + > /* Dump the IdleMask before we add to the STB */ > amd_pmc_idlemask_read(pdev, pdev->dev, NULL); >
[Public] > -----Original Message----- > From: Hans de Goede <hdegoede@redhat.com> > Sent: Thursday, November 17, 2022 08:06 > To: Limonciello, Mario <Mario.Limonciello@amd.com>; S-k, Shyam-sundar > <Shyam-sundar.S-k@amd.com> > Cc: Mahapatra, Rajib <Rajib.Mahapatra@amd.com>; Raul Rangel > <rrangel@chromium.org>; Mark Gross <markgross@kernel.org>; platform- > driver-x86@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH] platform/x86/amd: pmc: Add a workaround for an s0i3 > issue on Cezanne > > Hi Mario, > > On 11/16/22 16:43, Mario Limonciello wrote: > > Cezanne platforms under the right circumstances have a synchronization > > problem where attempting to enter s2idle may fail if the x86 cores are > > put into HLT before hardware resume from the previous attempt has > > completed. > > > > To avoid this issue add a 10-20ms delay before entering s2idle another > > time. This workaround will only be applied on interrupts that wake the > > hardware but don't break the s2idle loop. > > > > Cc: "Mahapatra, Rajib" <Rajib.Mahapatra@amd.com> > > Cc: "Raul Rangel" <rrangel@chromium.org> > > Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> > > Thank you for your patch, I've applied this patch to my review-hans > branch: > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.k > ernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fpdx86%2Fplatform- > drivers-x86.git%2Flog%2F%3Fh%3Dreview- > hans&data=05%7C01%7Cmario.limonciello%40amd.com%7C674f8bf7a8 > 114f83a3b408dac8a4d941%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C > 0%7C638042907591739047%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C% > 7C%7C&sdata=XYwl%2FOvUFy%2Bgz9EY9oa35M%2BkLf%2Bud8PKXynQ > FlrUdoE%3D&reserved=0 > > Please let me know if it important to get this as a fix into 6.1, > I wasn't really planning on doing any more fixes pull-reqs for 6.1, > but I can do one if necessary. > AFAIK it's a corner case. I think it can wait until 6.2, but I think it should probably be Cc to 6.1 stable (which has the ability to run code in the check()) phase. > Once I've run some tests on this branch the patches there will be > added to the platform-drivers-x86/for-next branch and eventually > will be included in the pdx86 pull-request to Linus for the next > merge-window. > > Regards, > > Hans > > > > --- > > drivers/platform/x86/amd/pmc.c | 6 ++++++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/drivers/platform/x86/amd/pmc.c > b/drivers/platform/x86/amd/pmc.c > > index ef4ae977b8e0..439d282aafd1 100644 > > --- a/drivers/platform/x86/amd/pmc.c > > +++ b/drivers/platform/x86/amd/pmc.c > > @@ -739,8 +739,14 @@ static void amd_pmc_s2idle_prepare(void) > > static void amd_pmc_s2idle_check(void) > > { > > struct amd_pmc_dev *pdev = &pmc; > > + struct smu_metrics table; > > int rc; > > > > + /* CZN: Ensure that future s0i3 entry attempts at least 10ms passed > */ > > + if (pdev->cpu_id == AMD_CPU_ID_CZN && > !get_metrics_table(pdev, &table) && > > + table.s0i3_last_entry_status) > > + usleep_range(10000, 20000); > > + > > /* Dump the IdleMask before we add to the STB */ > > amd_pmc_idlemask_read(pdev, pdev->dev, NULL); > >
Hi, On 11/17/22 17:06, Limonciello, Mario wrote: > [Public] > > > >> -----Original Message----- >> From: Hans de Goede <hdegoede@redhat.com> >> Sent: Thursday, November 17, 2022 08:06 >> To: Limonciello, Mario <Mario.Limonciello@amd.com>; S-k, Shyam-sundar >> <Shyam-sundar.S-k@amd.com> >> Cc: Mahapatra, Rajib <Rajib.Mahapatra@amd.com>; Raul Rangel >> <rrangel@chromium.org>; Mark Gross <markgross@kernel.org>; platform- >> driver-x86@vger.kernel.org; linux-kernel@vger.kernel.org >> Subject: Re: [PATCH] platform/x86/amd: pmc: Add a workaround for an s0i3 >> issue on Cezanne >> >> Hi Mario, >> >> On 11/16/22 16:43, Mario Limonciello wrote: >>> Cezanne platforms under the right circumstances have a synchronization >>> problem where attempting to enter s2idle may fail if the x86 cores are >>> put into HLT before hardware resume from the previous attempt has >>> completed. >>> >>> To avoid this issue add a 10-20ms delay before entering s2idle another >>> time. This workaround will only be applied on interrupts that wake the >>> hardware but don't break the s2idle loop. >>> >>> Cc: "Mahapatra, Rajib" <Rajib.Mahapatra@amd.com> >>> Cc: "Raul Rangel" <rrangel@chromium.org> >>> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> >> >> Thank you for your patch, I've applied this patch to my review-hans >> branch: >> https://git.k ernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fpdx86%2Fplatform- >> drivers-x86.git%2Flog%2F%3Fh%3Dreview- >> hans&data=05%7C01%7Cmario.limonciello%40amd.com%7C674f8bf7a8 >> 114f83a3b408dac8a4d941%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C >> 0%7C638042907591739047%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj >> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C% >> 7C%7C&sdata=XYwl%2FOvUFy%2Bgz9EY9oa35M%2BkLf%2Bud8PKXynQ >> FlrUdoE%3D&reserved=0 >> >> Please let me know if it important to get this as a fix into 6.1, >> I wasn't really planning on doing any more fixes pull-reqs for 6.1, >> but I can do one if necessary. >> > > AFAIK it's a corner case. I think it can wait until 6.2, but I think it should probably > be Cc to 6.1 stable (which has the ability to run code in the check()) phase. Ok, I have added a: Cc: stable@vger.kernel.org # 6.1 to the commit msg. Regards, Hans >>> --- >>> drivers/platform/x86/amd/pmc.c | 6 ++++++ >>> 1 file changed, 6 insertions(+) >>> >>> diff --git a/drivers/platform/x86/amd/pmc.c >> b/drivers/platform/x86/amd/pmc.c >>> index ef4ae977b8e0..439d282aafd1 100644 >>> --- a/drivers/platform/x86/amd/pmc.c >>> +++ b/drivers/platform/x86/amd/pmc.c >>> @@ -739,8 +739,14 @@ static void amd_pmc_s2idle_prepare(void) >>> static void amd_pmc_s2idle_check(void) >>> { >>> struct amd_pmc_dev *pdev = &pmc; >>> + struct smu_metrics table; >>> int rc; >>> >>> + /* CZN: Ensure that future s0i3 entry attempts at least 10ms passed >> */ >>> + if (pdev->cpu_id == AMD_CPU_ID_CZN && >> !get_metrics_table(pdev, &table) && >>> + table.s0i3_last_entry_status) >>> + usleep_range(10000, 20000); >>> + >>> /* Dump the IdleMask before we add to the STB */ >>> amd_pmc_idlemask_read(pdev, pdev->dev, NULL); >>> >
[Public] > -----Original Message----- > From: Hans de Goede <hdegoede@redhat.com> > Sent: Thursday, November 17, 2022 10:09 > To: Limonciello, Mario <Mario.Limonciello@amd.com>; S-k, Shyam-sundar > <Shyam-sundar.S-k@amd.com> > Cc: Mahapatra, Rajib <Rajib.Mahapatra@amd.com>; Raul Rangel > <rrangel@chromium.org>; Mark Gross <markgross@kernel.org>; platform- > driver-x86@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH] platform/x86/amd: pmc: Add a workaround for an s0i3 > issue on Cezanne > > Hi, > > On 11/17/22 17:06, Limonciello, Mario wrote: > > [Public] > > > > > > > >> -----Original Message----- > >> From: Hans de Goede <hdegoede@redhat.com> > >> Sent: Thursday, November 17, 2022 08:06 > >> To: Limonciello, Mario <Mario.Limonciello@amd.com>; S-k, Shyam-sundar > >> <Shyam-sundar.S-k@amd.com> > >> Cc: Mahapatra, Rajib <Rajib.Mahapatra@amd.com>; Raul Rangel > >> <rrangel@chromium.org>; Mark Gross <markgross@kernel.org>; > platform- > >> driver-x86@vger.kernel.org; linux-kernel@vger.kernel.org > >> Subject: Re: [PATCH] platform/x86/amd: pmc: Add a workaround for an > s0i3 > >> issue on Cezanne > >> > >> Hi Mario, > >> > >> On 11/16/22 16:43, Mario Limonciello wrote: > >>> Cezanne platforms under the right circumstances have a synchronization > >>> problem where attempting to enter s2idle may fail if the x86 cores are > >>> put into HLT before hardware resume from the previous attempt has > >>> completed. > >>> > >>> To avoid this issue add a 10-20ms delay before entering s2idle another > >>> time. This workaround will only be applied on interrupts that wake the > >>> hardware but don't break the s2idle loop. > >>> > >>> Cc: "Mahapatra, Rajib" <Rajib.Mahapatra@amd.com> > >>> Cc: "Raul Rangel" <rrangel@chromium.org> > >>> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> > >> > >> Thank you for your patch, I've applied this patch to my review-hans > >> branch: > >> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.k > %2F&data=05%7C01%7Cmario.limonciello%40amd.com%7Cb3c04b4449 > 154cad4f8208dac8b61509%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C > 0%7C638042981632459900%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C% > 7C%7C&sdata=3ZzdcI0BsHknBInf8V4MfrmNCkkc2U9ygYf4IP25LJ4%3D& > amp;reserved=0 > ernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fpdx86%2Fplatform- > >> drivers-x86.git%2Flog%2F%3Fh%3Dreview- > >> > hans&data=05%7C01%7Cmario.limonciello%40amd.com%7C674f8bf7a8 > >> > 114f83a3b408dac8a4d941%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C > >> > 0%7C638042907591739047%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj > >> > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C% > >> > 7C%7C&sdata=XYwl%2FOvUFy%2Bgz9EY9oa35M%2BkLf%2Bud8PKXynQ > >> FlrUdoE%3D&reserved=0 > >> > >> Please let me know if it important to get this as a fix into 6.1, > >> I wasn't really planning on doing any more fixes pull-reqs for 6.1, > >> but I can do one if necessary. > >> > > > > AFAIK it's a corner case. I think it can wait until 6.2, but I think it should > probably > > be Cc to 6.1 stable (which has the ability to run code in the check()) phase. > > Ok, I have added a: > > Cc: stable@vger.kernel.org # 6.1 > > to the commit msg. > > Regards, > > Hans Hi Hans, I just wanted to update you on this workaround. Previously it was believed to only be a very specific set of circumstances that happened on chromebooks running coreboot and an EC running cros_ec being utilized with unfortunate timing. However it turns out that it can be "relatively" easily reproduced on UEFI machines as well though by suspending the laptop and then issuing anything that causes an ACPI event that otherwise shouldn't break the s2idle loop (such as closing the lid or unplugging the power adapter). What will happen is that the SOC enters the deepest state up until the time of that ACPI event and then never enters again. The most common case this will break I think is someone suspends the laptop in GNOME, closes the lid and then tosses it in their bag. If you examine /sys/kernel/debug/amd_pmc/* you'll see that the duration of time in deepest state matches the time between suspending in GNOME and closing the lid. I wanted to provide you that context to decide if this should still try to catch this in a 6.1 final pull request or not. Had I known how widely this helped at that time I would have advocated accordingly. Thanks! > > > > >>> --- > >>> drivers/platform/x86/amd/pmc.c | 6 ++++++ > >>> 1 file changed, 6 insertions(+) > >>> > >>> diff --git a/drivers/platform/x86/amd/pmc.c > >> b/drivers/platform/x86/amd/pmc.c > >>> index ef4ae977b8e0..439d282aafd1 100644 > >>> --- a/drivers/platform/x86/amd/pmc.c > >>> +++ b/drivers/platform/x86/amd/pmc.c > >>> @@ -739,8 +739,14 @@ static void amd_pmc_s2idle_prepare(void) > >>> static void amd_pmc_s2idle_check(void) > >>> { > >>> struct amd_pmc_dev *pdev = &pmc; > >>> + struct smu_metrics table; > >>> int rc; > >>> > >>> + /* CZN: Ensure that future s0i3 entry attempts at least 10ms passed > >> */ > >>> + if (pdev->cpu_id == AMD_CPU_ID_CZN && > >> !get_metrics_table(pdev, &table) && > >>> + table.s0i3_last_entry_status) > >>> + usleep_range(10000, 20000); > >>> + > >>> /* Dump the IdleMask before we add to the STB */ > >>> amd_pmc_idlemask_read(pdev, pdev->dev, NULL); > >>> > >
Hi Mario, On 12/6/22 00:02, Limonciello, Mario wrote: > [Public] > > > >> -----Original Message----- >> From: Hans de Goede <hdegoede@redhat.com> >> Sent: Thursday, November 17, 2022 10:09 >> To: Limonciello, Mario <Mario.Limonciello@amd.com>; S-k, Shyam-sundar >> <Shyam-sundar.S-k@amd.com> >> Cc: Mahapatra, Rajib <Rajib.Mahapatra@amd.com>; Raul Rangel >> <rrangel@chromium.org>; Mark Gross <markgross@kernel.org>; platform- >> driver-x86@vger.kernel.org; linux-kernel@vger.kernel.org >> Subject: Re: [PATCH] platform/x86/amd: pmc: Add a workaround for an s0i3 >> issue on Cezanne >> >> Hi, >> >> On 11/17/22 17:06, Limonciello, Mario wrote: >>> [Public] >>> >>> >>> >>>> -----Original Message----- >>>> From: Hans de Goede <hdegoede@redhat.com> >>>> Sent: Thursday, November 17, 2022 08:06 >>>> To: Limonciello, Mario <Mario.Limonciello@amd.com>; S-k, Shyam-sundar >>>> <Shyam-sundar.S-k@amd.com> >>>> Cc: Mahapatra, Rajib <Rajib.Mahapatra@amd.com>; Raul Rangel >>>> <rrangel@chromium.org>; Mark Gross <markgross@kernel.org>; >> platform- >>>> driver-x86@vger.kernel.org; linux-kernel@vger.kernel.org >>>> Subject: Re: [PATCH] platform/x86/amd: pmc: Add a workaround for an >> s0i3 >>>> issue on Cezanne >>>> >>>> Hi Mario, >>>> >>>> On 11/16/22 16:43, Mario Limonciello wrote: >>>>> Cezanne platforms under the right circumstances have a synchronization >>>>> problem where attempting to enter s2idle may fail if the x86 cores are >>>>> put into HLT before hardware resume from the previous attempt has >>>>> completed. >>>>> >>>>> To avoid this issue add a 10-20ms delay before entering s2idle another >>>>> time. This workaround will only be applied on interrupts that wake the >>>>> hardware but don't break the s2idle loop. >>>>> >>>>> Cc: "Mahapatra, Rajib" <Rajib.Mahapatra@amd.com> >>>>> Cc: "Raul Rangel" <rrangel@chromium.org> >>>>> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> >>>> >>>> Thank you for your patch, I've applied this patch to my review-hans >>>> branch: >>>> >> https://git.k %2F&data=05%7C01%7Cmario.limonciello%40amd.com%7Cb3c04b4449 >> 154cad4f8208dac8b61509%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C >> 0%7C638042981632459900%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj >> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C% >> 7C%7C&sdata=3ZzdcI0BsHknBInf8V4MfrmNCkkc2U9ygYf4IP25LJ4%3D& >> amp;reserved=0 >> ernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fpdx86%2Fplatform- >>>> drivers-x86.git%2Flog%2F%3Fh%3Dreview- >>>> >> hans&data=05%7C01%7Cmario.limonciello%40amd.com%7C674f8bf7a8 >>>> >> 114f83a3b408dac8a4d941%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C >>>> >> 0%7C638042907591739047%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj >>>> >> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C% >>>> >> 7C%7C&sdata=XYwl%2FOvUFy%2Bgz9EY9oa35M%2BkLf%2Bud8PKXynQ >>>> FlrUdoE%3D&reserved=0 >>>> >>>> Please let me know if it important to get this as a fix into 6.1, >>>> I wasn't really planning on doing any more fixes pull-reqs for 6.1, >>>> but I can do one if necessary. >>>> >>> >>> AFAIK it's a corner case. I think it can wait until 6.2, but I think it should >> probably >>> be Cc to 6.1 stable (which has the ability to run code in the check()) phase. >> >> Ok, I have added a: >> >> Cc: stable@vger.kernel.org # 6.1 >> >> to the commit msg. >> >> Regards, >> >> Hans > > Hi Hans, > > I just wanted to update you on this workaround. Previously it was believed to > only be a very specific set of circumstances that happened on chromebooks running > coreboot and an EC running cros_ec being utilized with unfortunate timing. > > However it turns out that it can be "relatively" easily reproduced on UEFI machines > as well though by suspending the laptop and then issuing anything that causes an > ACPI event that otherwise shouldn't break the s2idle loop (such as closing the lid or > unplugging the power adapter). > > What will happen is that the SOC enters the deepest state up until the time of that > ACPI event and then never enters again. The most common case this will break I think > is someone suspends the laptop in GNOME, closes the lid and then tosses it in their bag. > If you examine /sys/kernel/debug/amd_pmc/* you'll see that the duration of time in > deepest state matches the time between suspending in GNOME and closing the lid. > > I wanted to provide you that context to decide if this should still try to catch this in > a 6.1 final pull request or not. Had I known how widely this helped at that time I > would have advocated accordingly. Based on the above I have prepared a pull-req to Linus with just this single patch in it to get this added to 6.1 . I'll Cc you on the pull-req submission to Linus. Regards, Hans >>>>> --- >>>>> drivers/platform/x86/amd/pmc.c | 6 ++++++ >>>>> 1 file changed, 6 insertions(+) >>>>> >>>>> diff --git a/drivers/platform/x86/amd/pmc.c >>>> b/drivers/platform/x86/amd/pmc.c >>>>> index ef4ae977b8e0..439d282aafd1 100644 >>>>> --- a/drivers/platform/x86/amd/pmc.c >>>>> +++ b/drivers/platform/x86/amd/pmc.c >>>>> @@ -739,8 +739,14 @@ static void amd_pmc_s2idle_prepare(void) >>>>> static void amd_pmc_s2idle_check(void) >>>>> { >>>>> struct amd_pmc_dev *pdev = &pmc; >>>>> + struct smu_metrics table; >>>>> int rc; >>>>> >>>>> + /* CZN: Ensure that future s0i3 entry attempts at least 10ms passed >>>> */ >>>>> + if (pdev->cpu_id == AMD_CPU_ID_CZN && >>>> !get_metrics_table(pdev, &table) && >>>>> + table.s0i3_last_entry_status) >>>>> + usleep_range(10000, 20000); >>>>> + >>>>> /* Dump the IdleMask before we add to the STB */ >>>>> amd_pmc_idlemask_read(pdev, pdev->dev, NULL); >>>>> >>> >
diff --git a/drivers/platform/x86/amd/pmc.c b/drivers/platform/x86/amd/pmc.c index ef4ae977b8e0..439d282aafd1 100644 --- a/drivers/platform/x86/amd/pmc.c +++ b/drivers/platform/x86/amd/pmc.c @@ -739,8 +739,14 @@ static void amd_pmc_s2idle_prepare(void) static void amd_pmc_s2idle_check(void) { struct amd_pmc_dev *pdev = &pmc; + struct smu_metrics table; int rc; + /* CZN: Ensure that future s0i3 entry attempts at least 10ms passed */ + if (pdev->cpu_id == AMD_CPU_ID_CZN && !get_metrics_table(pdev, &table) && + table.s0i3_last_entry_status) + usleep_range(10000, 20000); + /* Dump the IdleMask before we add to the STB */ amd_pmc_idlemask_read(pdev, pdev->dev, NULL);