Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp5357319rwb; Mon, 21 Nov 2022 21:39:30 -0800 (PST) X-Google-Smtp-Source: AA0mqf74Rnqle90RLYoVtWTcBpZYbU7/P7UKxbqs5yFrRQlA573d5lMf9/h+Q/YWp2muQaQhdVf5 X-Received: by 2002:a17:90a:2ec5:b0:213:9451:1775 with SMTP id h5-20020a17090a2ec500b0021394511775mr30640018pjs.90.1669095570582; Mon, 21 Nov 2022 21:39:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669095570; cv=none; d=google.com; s=arc-20160816; b=aj8vfvHQ0bH8CZH/TL70Xh0BbGB31ln0RtuKYhzNCxffqv4KWRonCGT1uHNvnnRy8H L2TyvAfQ2zVWmn8IV4qhYqrlvDYlov2MWh71cQeBkQDMb2324K3YbTJE1gDXqpIM0ilp t92MtyWId6yUS2gczciGVH8aFD0b1wmsrYbvV011CsHgEvH5XX4TLsZksNZn7f+yXkYN irj+oaHsOIfg1VsTAnixwusayigEbOcrBKFLNWwH+D9gll4Htjz7HOO2C+RJw9MMsvfi Lfo477qQMExvBjM8GbHN2II99dOWkNuzMLJpy3XtNIcwZNqLU+0VuNrhmvFMMcWslynQ 1Cyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=i5qyeYsVmx6XhfZt4paEL95PnVohNk27++knFv/BVmU=; b=DMFqaQol46+1LZx8BJHCro3nVXNwJseQCFri+/zPthUPaYXsVbFWoEzh4IM/ohzMv3 X84II5mGazIM2gvznueG7eahadbeNiRJ6fzXC2XiMQfJIuP4cOAGZKgBN/0OpcExcOUs micmYnp4QGSQAOdWwIbWr/WRmzTuZgAzhNNKVHLOba64RXdgJNcgdeIjRPSB071Hk045 hl5sk/h5mdzjNZCURVoJ6x15ZqopKW96SgcN6BWGLWJwDyW4OBaTLHST8/5cQiW2EgN5 DJNZ3D/SEqE2XoiBVIsCxgI9CTIvXKxOLNKy+PdYxySOhlGJ3JEUhnkSrH97C9rdf7gi v2rw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ventanamicro.com header.s=google header.b=KN63+Ohw; 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 x24-20020a63db58000000b0043a20e51026si13157522pgi.8.2022.11.21.21.39.19; Mon, 21 Nov 2022 21:39:30 -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=@ventanamicro.com header.s=google header.b=KN63+Ohw; 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 S231771AbiKVFga (ORCPT + 93 others); Tue, 22 Nov 2022 00:36:30 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45960 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231583AbiKVFg2 (ORCPT ); Tue, 22 Nov 2022 00:36:28 -0500 Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 308631DDF6 for ; Mon, 21 Nov 2022 21:36:27 -0800 (PST) Received: by mail-ot1-x330.google.com with SMTP id l42-20020a9d1b2d000000b0066c6366fbc3so8681475otl.3 for ; Mon, 21 Nov 2022 21:36:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=i5qyeYsVmx6XhfZt4paEL95PnVohNk27++knFv/BVmU=; b=KN63+OhwilsyWIs3Ix3N08+28icP335y7QajHdzDMB50KfNfdj7civnR0ceKzd2jJH JHSud1kQ9O3GDRtMVBGG5jN1CaoMhvqljkwnpJ9496AwKSTZLWEq286LHFy+Zn3NLLHy oUOyD1Awx+2wbbiyeWbyaRyB/WLstJt5KjjQ6xcZV+LJPzOVUjg7O+pxrpGoKLFz20db oOve+lxyeTYSrl0ZfrsA+uSyB4EI5IG+m6x+7MmPtKBBw8k3qcm2BaBNOzbEDbatx6T2 f2Hw4I9rt6u4MuvebLwfuxLO5knV9nK1wHqExaw4Kt4254XSny/4iOWmRqj03X+0tJf1 i/qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=i5qyeYsVmx6XhfZt4paEL95PnVohNk27++knFv/BVmU=; b=4dI7jUwsAfVEiRVIwZg3j8ZtpyVp5BDZr4cNksu3Cued5iFVyB0Cfsj87eFtqtIyW8 dxdlQ6eCxsj8XiCPA6NSYBoPBVZGaEgfKJ7g3TXWekCbnusHPBT69yYFh+b6RHPfIWfl lZnPbNsXWvePpuUvBALH6+CX0T+t+9eYZ7lOf7qXX7WSa6l67SbMdT/WXHFHVZGNoruU OPw6jRCoxlEA51BRHXC/M7TFfU929MWGgCkSVosibH09zBtyqzfdEFSxARfXIJLvSqO3 ypo4ZEls4l3E1nLnn4Sq7Sh5iY8QKNWwOzR3TQtRNgw2Ge28z69cUewnC0vgQfEmqc+A 6Gug== X-Gm-Message-State: ANoB5pmZx8GL7I/aXH+lt/rLblKGLKR0C1O5Qa8FvaONwvmGhJmuUauT ic50Pwuj/CtxVV8RHkTTd9VzED8ZfPigS9kDAQ1nJQ== X-Received: by 2002:a9d:5e0f:0:b0:662:2458:3ef7 with SMTP id d15-20020a9d5e0f000000b0066224583ef7mr11466185oti.150.1669095386364; Mon, 21 Nov 2022 21:36:26 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Anup Patel Date: Tue, 22 Nov 2022 11:06:15 +0530 Message-ID: Subject: Re: [PATCH] cpuidle: riscv-sbi: Stop using non-retentive suspend To: Palmer Dabbelt Cc: anup@brainfault.org, Conor Dooley , rafael@kernel.org, daniel.lezcano@linaro.org, Paul Walmsley , aou@eecs.berkeley.edu, linux-pm@vger.kernel.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, linux@rivosinc.com Content-Type: text/plain; charset="UTF-8" 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, SPF_HELO_NONE,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: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 22, 2022 at 10:46 AM Palmer Dabbelt wrote: > > On Mon, 21 Nov 2022 19:45:07 PST (-0800), anup@brainfault.org wrote: > > On Tue, Nov 22, 2022 at 2:27 AM Palmer Dabbelt wrote: > >> > >> From: Palmer Dabbelt > >> > >> As per [1], whether or not the core can wake up from non-retentive > >> suspend is a platform-specific detail. We don't have any way to encode > >> that, so just stop using them until we've sorted that out. > >> > >> Link: https://github.com/riscv-non-isa/riscv-sbi-doc/issues/98#issuecomment-1288564687 > >> Fixes: 6abf32f1d9c5 ("cpuidle: Add RISC-V SBI CPU idle driver") > >> Signed-off-by: Palmer Dabbelt > > > > This is just unnecessary maintenance churn and it's not the > > right way to go. Better to fix this the right way instead of having > > a temporary fix. > > > > I had already sent-out a patch series 5 months back to describe > > this in DT: > > https://lore.kernel.org/lkml/20220727114302.302201-1-apatel@ventanamicro.com/ > > > > No one has commented/suggested anything (except Samuel > > Holland and Sudeep Holla). > > I see some comments from Krzysztof here > > as well. Looks like everyone is pointing out that having our CPU nodes > encode timers is a bad idea, my guess is that they're probably right. Adding a separate timer DT node, creates a new set of compatibility issues for existing platforms. I am fine updating my series to have separate timer DT node but do we want to go in this direction ? Even if ARM has a separate timer DT node, the timers are still part of the CPU. It depends on how we see the DT bindings aligning with actual HW. > > > Please review this series. I can quickly address comments to > > make this available for Linux-6.2. Until this series is merged, > > the affected platforms can simply remove non-retentive suspend > > states from their DT. > > That leaves us with a dependency between kernel versions and DT > bindings: kernels with the current driver will result in broken systems > with the non-retentive suspend states in the DT they boot with when > those states can't wake up the CPU. This is not a new problem we are facing. Even in the ARM world, the DT bindings grew organically over time based on newer platform requirements. Now that we have a platform which does not want the time C3STOP feature, we need to first come-up with DT bindings to support this platform instead of temporarily disabling features which don't work on this platform. Regards, Anup > > > With all due respect, NACK to this patch from my side. > > > > Regards, > > Anup > > > >> > >> --- > >> > >> This should allow us to revert 232ccac1bd9b ("clocksource/drivers/riscv: > >> Events are stopped during CPU suspend"), which fixes suspend on the D1 > >> but breaks timers everywhere. > >> --- > >> drivers/cpuidle/cpuidle-riscv-sbi.c | 11 +++++++++++ > >> 1 file changed, 11 insertions(+) > >> > >> diff --git a/drivers/cpuidle/cpuidle-riscv-sbi.c b/drivers/cpuidle/cpuidle-riscv-sbi.c > >> index 05fe2902df9a..9d1063a54495 100644 > >> --- a/drivers/cpuidle/cpuidle-riscv-sbi.c > >> +++ b/drivers/cpuidle/cpuidle-riscv-sbi.c > >> @@ -214,6 +214,17 @@ static bool sbi_suspend_state_is_valid(u32 state) > >> if (state > SBI_HSM_SUSPEND_NON_RET_DEFAULT && > >> state < SBI_HSM_SUSPEND_NON_RET_PLATFORM) > >> return false; > >> + > >> + /* > >> + * Whether or not RISC-V systems deliver interrupts to harts in a > >> + * non-retentive suspend state is a platform-specific detail. This can > >> + * leave the hart unable to wake up, so just mark these states as > >> + * unsupported until we have a mechanism to expose these > >> + * platform-specific details to Linux. > >> + */ > >> + if (state & SBI_HSM_SUSP_NON_RET_BIT) > >> + return false; > >> + > >> return true; > >> } > >> > >> -- > >> 2.38.1 > >>