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 X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CAA77C433B4 for ; Fri, 23 Apr 2021 20:19:16 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8504261396 for ; Fri, 23 Apr 2021 20:19:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8504261396 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=yeeMMfnQHhvGV+f2yOAd04shjjulPbWbj/Y0fiUuQno=; b=V/mYBajQFLfIV2GheEiehRRg/ j5tndITj95W4gedK+UGZFHxjE3AhTzj40vqmd/dBHeNRxzjdz7F0NGIZfBSvmyaaCtQfd++qImPLq kKsXrVkB6oanaCI2zKh6/1z3VuR9jW9vNl71XIZV2J9Nr3qofO/ZgPyH0ELchCZnEuA5BAJPg2utQ wkAZn+IK4NlFqop4rhMFuNSBag/GNZdZWNeYFNJEHP287IlaxGmzQRTDQWvmMUCLML46oqNrLcXqu nK3UBUlc+P6K5k6qAcyIbFAet4HqU4PAEY4HVlRLy0E4q0BbbjlYWDHOkWJvgL5AVas68s6gj1R1I Lmu6ML9Kg==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1la2Ej-002HJL-NT; Fri, 23 Apr 2021 20:17:16 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1la2Eg-002HJ7-UX for linux-arm-kernel@desiato.infradead.org; Fri, 23 Apr 2021 20:17:11 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Transfer-Encoding: Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To: Subject:Sender:Reply-To:Content-ID:Content-Description; bh=RnUtRlrI0oqk70vWw+WBzVY/alQ23CRHibX5gn25xQQ=; b=xW3+j76fkWfV27N7RzGiLkwztJ dMHjRkTL7Y9xWZ+lZ4dW4yDMqJWspc8siDBZVz4pIG963wNYZHB6HvI6gipncdUDxWFko0/vJz55u 966/GzgnPsPUM8A0q5iEJcCgGO2pykdUT1YIch2DFHVl5vGrsuXpUTawSY5deW9IW8d/hTO8+rxFt tqRAuFN7FGnZBIG2ZOcghd4G5FxjWlJv13yf5M7Xs4VHq2icwzvPDCvUnlHtzXdYkOa41bjsJskEX gs1xjt1qcOK6+K3YU+G5juwAcBXB1VyYiGSLMKGY2ZnzXsUAKnfZNflQPyIGOH4/Xe4XMj4VAo5OM Rj9lpFBQ==; Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1la2Ee-00EgHy-9Z for linux-arm-kernel@lists.infradead.org; Fri, 23 Apr 2021 20:17:09 +0000 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 6A89711D4; Fri, 23 Apr 2021 13:17:03 -0700 (PDT) Received: from [10.57.2.99] (unknown [10.57.2.99]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1DB0B3F73B; Fri, 23 Apr 2021 13:16:59 -0700 (PDT) Subject: Re: [RFC PATCH 0/4] Support for passing runtime state idle time to TF-A To: Sowjanya Komatineni Cc: sudeep.holla@arm.com, souvik.chakravarty@arm.com, thierry.reding@gmail.com, mark.rutland@arm.com, lorenzo.pieralisi@arm.com, daniel.lezcano@linaro.org, robh+dt@kernel.org, jonathanh@nvidia.com, ksitaraman@nvidia.com, sanjayc@nvidia.com, linux-arm-kernel@lists.infradead.org, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, devicetree@vger.kernel.org References: <1619123448-10138-1-git-send-email-skomatineni@nvidia.com> From: Lukasz Luba Message-ID: <064341f7-dce3-5ad4-e69b-9568115035c1@arm.com> Date: Fri, 23 Apr 2021 21:16:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <1619123448-10138-1-git-send-email-skomatineni@nvidia.com> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210423_131708_413957_25673343 X-CRM114-Status: GOOD ( 13.98 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Sowjanya, On 4/22/21 9:30 PM, Sowjanya Komatineni wrote: > Tegra194 and Tegra186 platforms use separate MCE firmware for CPUs which is > in charge of deciding on state transition based on target state, state idle > time, and some other Tegra CPU core cluster states information. > > Current PSCI specification don't have function defined for passing runtime > state idle time predicted by governor (based on next events and state target > residency) to ARM trusted firmware. Do you have some numbers from experiments showing that these idle governor prediction values, which are passed from kernel to MCE firmware, are making a good 'guess'? How much precision (1us? 1ms?) in the values do you need there? IIRC (probably Rafael's presentations) predicting in the kernel something like CPU idle time residency is not a trivial thing. Another idea (depending on DT structure and PSCI bits): Could this be solved differently, but just having a knowledge that if the governor requested some C-state, this means governor 'predicted' an idle residency to be greater that min_residency attached to this C-state? Then, when that request shows up in your FW, you know that it must be at least min_residency because of this C-state id. It would depend on number of available states, max_residency, scale that you would choose while assigning values from [0, max_residency] to each state. IIRC there can be many state IDs for idle, so it would depend on number of bits encoding this state, and your needs. Example of linear scale: 4-bits encoding idle state and max predicted residency 10msec, that means 10000us / 16 states = 625us/state. The max_residency might be split differently, using different than linear function, to have some rage more precised. Open question is if these idle states must be all represented in DT, or there is a way of describing a 'set of idle states' automatically. Regards, Lukasz _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel