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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1869BC433F5 for ; Tue, 11 Jan 2022 19:49:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238704AbiAKTtK (ORCPT ); Tue, 11 Jan 2022 14:49:10 -0500 Received: from mail-qt1-f172.google.com ([209.85.160.172]:46698 "EHLO mail-qt1-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239066AbiAKTtJ (ORCPT ); Tue, 11 Jan 2022 14:49:09 -0500 Received: by mail-qt1-f172.google.com with SMTP id v7so413051qtw.13 for ; Tue, 11 Jan 2022 11:49:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TeFVIYnmoZ2Wtzy9Qa2fKz0J7zlV2F1damFAkkMLnBA=; b=jibjirF4Qhp8pa/LDqTmRbnJA0U3PMAVykmhoxHbSpLtDl7hlWghuwe8jZtIgeDu4Z YKUxvEAHKYCTcfZlYIhg0ABd6ck2jGdMBILQVOxk3/E/1jiQb5IXB+TnX0GSLIo783Lk 0Al6YL9aqJeAeScnIXUdVmIEXPmBppqqFDSq4TEan+0orvvBp+MeG2Y7SrTzz+tqh+VU Pu4xYBrWlmF3JhH+/xVrZhzkANxnRG83YhDNCpSgmKKowF0la13/SMSUfxO8ecnOziG6 PAU85dKnRAhtOP+rzA4+Rw+QjSG7YuMR0hTC7pDqo1FXfeq2F6WIZQ66Hcmw2paYRn6R 9AVQ== X-Gm-Message-State: AOAM533PlSre33HPhiPqrtqnDHvT/oGhQ03C6nWiSBOp1upaZyz4iJpB TDV2Bg6uQTu9ARPnDBtpjXWTGM5RnnX9lNKvy1Mb65Xf X-Google-Smtp-Source: ABdhPJxxSiwAGKbCXrXrDjouWrOweCiOh4JDzf2iVURY/dpXsJdht2gFxUh7gg3saFe21+3G1r+5QTna4UlkcA+ZWZY= X-Received: by 2002:ac8:5991:: with SMTP id e17mr5116440qte.344.1641930549095; Tue, 11 Jan 2022 11:49:09 -0800 (PST) MIME-Version: 1.0 References: <20220105193910.25678-1-mario.limonciello@amd.com> <3e09ef49-6645-59d8-5e66-1640c4ca91de@amd.com> In-Reply-To: <3e09ef49-6645-59d8-5e66-1640c4ca91de@amd.com> From: "Rafael J. Wysocki" Date: Tue, 11 Jan 2022 20:48:58 +0100 Message-ID: Subject: Re: [PATCH 0/3] On AMD platforms only offer s2idle w/ proper FW To: "Limonciello, Mario" Cc: "Rafael J. Wysocki" , "Deucher, Alexander" , "Rafael J . Wysocki" , ACPI Devel Maling List , "S-k, Shyam-sundar" , "Natikar, Basavaraj" , "bjoern.daase@gmail.com" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Tue, Jan 11, 2022 at 8:35 PM Limonciello, Mario wrote: > > >> > >> That's why I thought my patch series made sense. > >> > >> I guess another (antisocial) response would be to to return false when > >> the suspend callback for amdgpu happens and dev_err mentioning that > >> firmware support is needed for suspend. > > > > If you want to avoid exposing s2idle at all in some cases, you need to > > change the sysfs I/F in /sys/power/ so that it doesn't expose "s2idle" > > in mem_sleep or "freeze" in state at all. > > Right now they make it so that s2idle isn't exposed in "mem_sleep", but > "freeze" is still exposed in "state". > > I'd be worried about breaking userspace with taking "freeze" out of state. > > > That's much more intrusive > > than just failing every s2idle attempt (which is what the patches do > > AFAICS) > As they stand right now when the BIOS is set to S3: > # cat /sys/power/mem_sleep > [deep] > > # echo freeze > /sys/power/state > Returns a failure though. > > And then when it's set to Modern Standby : > > # cat /sys/power/mem_sleep > [s2idle] > > # echo freeze > /sys/power/state > Works > > > > > Do you want to do that for platforms supporting S3, or for platforms > > that don't support any kind of suspend at all? > > You know since this series went out > 6dc8265f9803ccb7e5da804e01601f0c14f270e0 was merged. This will probably > have cleaned up the problem state that Bjoern found in the first place. > > So this is really a philosophical discussion now if it's worth offering > s2idle in /sys/power/mem_sleep on AMD systems. Well, if "freeze" is present in "state", then "s2idle" needs to be there in "mem_sleep", because they are clearly documented as alternative paths to the same functionality. > Admittedly this has been an APU notebook oriented discussion. Platforms > that don't support any kind of suspend (like servers) will get caught up > in this and could no longer do s2idle either. > > With the assumption that 6dc8265f9803ccb7e5da804e01601f0c14f270e0 helps > the problem state I'm leaning back on we should add some warnings to let > people know how to help themselves for power consumption if they did this. > > We can probably put those in amdgpu though. Sounds like a better direction to me, honestly.