Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp8624pxf; Wed, 10 Mar 2021 18:54:06 -0800 (PST) X-Google-Smtp-Source: ABdhPJze783Gq0PeOnGaon0EWLlc6D+sJpP5NVTrov2GK2nxvvRTZ/hgIwdZA4f2tUmwqsKnHIDN X-Received: by 2002:aa7:d484:: with SMTP id b4mr6373154edr.63.1615431246578; Wed, 10 Mar 2021 18:54:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615431246; cv=none; d=google.com; s=arc-20160816; b=OspsjhSZAW5WS5CZa8nLQl5/MWa+5tnmkG6t2jeRTxKkP7NfUm07fdDVhWt6hIB1EL jM+bzK8y4c+Zb0ftZRmp8aslkZR1A/VPM8gYHkQxk8RFpVNd6GunI7nS6XEm/f3Xivc+ +D538TX0PJflJZKLkqinXat0jVMkNTq44LABqZXmG87JsejIdc+hiYA2abymwW0isKyT R2hpB5xwHQCaQg/Yz0cdRVhnt5iPeVkN4m78Ob4K5P5g1pRI7S+xrTMZ9tzEIFIdH2vq BBUjEH3d7vzQO1MOULvhrxM5z5Vu+80SepSAUGlZkqMUz2TLDvSBqOW7qvRQrQLGuDHG g6Kg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=+9dSfwMmTYKJmCHZeCaqvdH9qyLfoVLwPKmnOS8TUJU=; b=D2N0Tn/VrKJ/wQpEiBS8Cwn5rzOzEmRrlMZ2HAtydnYTP4H19NbXACdRhMWxQDji8O tFN1rS93Yz5/y3EdtiqVZAAshvDlVkirX/w0Jdlje7FAv23RSTTUsoorn+uID4YW4Q4m cq3S0Wcr02U74Ma70MEusrbMar09oSRSH+cjuwHWQwOTZWTCDhBuk9NF2ruKYM+T93Uy u4ITBI4sGis7wlTU8X/NWK38plzeOzi+JciWFMM2ZYo0M9WHdCInxbnQpTyLk0JGysN8 t1M5sI+soPyP7G+P/PbmV6+qyFL7rIAzORtDtajgxY1J8T1rkyHwjYzuS7cJBysfzNVX Qv3w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l13si811786edn.284.2021.03.10.18.53.44; Wed, 10 Mar 2021 18:54:06 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229851AbhCKCwu (ORCPT + 99 others); Wed, 10 Mar 2021 21:52:50 -0500 Received: from foss.arm.com ([217.140.110.172]:56834 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229624AbhCKCwa (ORCPT ); Wed, 10 Mar 2021 21:52:30 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 985A31FB; Wed, 10 Mar 2021 18:52:24 -0800 (PST) Received: from bogus (unknown [10.163.66.77]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3DC383F793; Wed, 10 Mar 2021 18:52:21 -0800 (PST) Date: Thu, 11 Mar 2021 02:52:13 +0000 From: Sudeep Holla To: Sowjanya Komatineni Cc: thierry.reding@gmail.com, jonathanh@nvidia.com, Sudeep Holla , daniel.lezcano@linaro.org, robh+dt@kernel.org, ksitaraman@nvidia.com, sanjayc@nvidia.com, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [PATCH v1 3/5] dt-bindings: arm: Add cpu-idle-states to Tegra194 CPU nodes Message-ID: <20210311025138.o4ub4j2ss725zpv4@bogus> References: <1614838092-30398-1-git-send-email-skomatineni@nvidia.com> <1614838092-30398-4-git-send-email-skomatineni@nvidia.com> <20210308043755.llvdsuz2jwvweovb@bogus> <4cebf482-a2f8-5a79-a2f6-4ccd7d31c6ad@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4cebf482-a2f8-5a79-a2f6-4ccd7d31c6ad@nvidia.com> User-Agent: NeoMutt/20171215 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 08, 2021 at 10:32:17AM -0800, Sowjanya Komatineni wrote: > > On 3/7/21 8:37 PM, Sudeep Holla wrote: > > On Wed, Mar 03, 2021 at 10:08:10PM -0800, Sowjanya Komatineni wrote: > > > This patch adds cpu-idle-states and corresponding state nodes to > > > Tegra194 CPU in dt-binding document > > > > > I see that this platform has PSCI support. Can you care to explain why > > you need additional DT bindings and driver for PSCI based CPU suspend. > > Until the reasons are convincing, consider NACK from my side for this > > driver and DT bindings. You should be really using those bindings and > > the driver may be with minor changes there. > > > MCE firmware is in charge of state transition for Tegra194 carmel CPUs. > Sure, but I assume only TF-A talks to MCE and not any OSPM/Linux kernel. > For run-time state transitions, need to provide state request along with its > residency time to MCE firmware which is running in the background. > Sounds similar to x86 mwait, perhaps we need to extend PSCI if we need to make this firmware PSCI compliant or just say it is not and implement completely independent implementation. I am not saying that is acceptable ATM but I prefer not to mix some implementation to make it look like PSCI compliant. > State min residency is updated into power_state value along with state id > that is passed to psci_cpu_suspend_enter > Sounds like a hack/workaround. I would prefer to standardise that. IIUC the power_state is more static and derived from DT. I don't like to overload that TBH. Need to check with authors of that binding. > Also states cross-over idle times need to be provided to MCE firmware. > New requirements if this has to be PSCI compliant. > MCE firmware decides on state transition based on these inputs along with > its background work load. > > So, Tegra specific CPU idle driver is required mainly to provide cross-over > thresholds from DT and run time idle state information to MCE firmware > through Tegra MCE communication APIs. > I am worried if different vendors will come up with different custom solution for this. We need to either standardise this is Linux/DT or in PSCI. > Allowing cross-over threshold through DT allows users to vary idle time > thresholds for state transitions based on different use-cases. > Sounds like policy and not platform specific to be in DT, but I will leave that to DT maintainers. -- Regards, Sudeep