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=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 2280BC433ED for ; Mon, 26 Apr 2021 13:14:03 +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 6BD4B6052B for ; Mon, 26 Apr 2021 13:14:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6BD4B6052B 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-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=eIoN4tPfG5DUORYEO3FwMTqpazZxRleedGviePaVfYY=; b=QMKBxAWOPYzLZUrFWF6k3NCpQ 1czt2o+Xr68FeqM+ckhHAhtvB9l2Q8aGa3XGf7Hq6Wam0Wn5iZimDyiJhLTbBpTn523ZaiwxbGnbS dhsSZzAE5aC2Bi1Oh6QuQctxgaQEySzXo07SO5fkNjL/Unric4CSAAhuikHGLvvxpTWsPfBAH1/ym i6KiOLThe7Yb5HMk391gPpxwQFrfYaC3Bjl3gK17WbRSYIswHP4PwRp2PSwUW5SMqQYyqm6syGPho GpyGt7y0NISKp87Nlrp4XVvkf1lUwbGjMS1lEtu1Y9st9aUfn1uvlYyrmOWkMnnguP70XyPRGNOqW 2GCSeNjig==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lb124-007gIN-GG; Mon, 26 Apr 2021 13:12:12 +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 1lb123-007gIG-1X for linux-arm-kernel@desiato.infradead.org; Mon, 26 Apr 2021 13:12:11 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Eb9YN0Wg3kfSVwRQBL1tgKaPjQ63BbYVZIG4SeoEa2o=; b=iUUlAmoK257ycPi5K97QQvW23N 9ifb4pPggnZqgdnS50t2PWV2xXssYLi/LiXLMGVtqXuJ4o5556gdnorYQ85izjqH5CYlBNwnD5v6P RkP+R4P8a9FkCsMbMKXJ5zbldbFV+DZrKQ2h3Y7KrRUhGmEaHNQ9RTcg5sEQaVdnH2vRWlE1J0y1E 7Q1sjqI7S+x/hw9uJ6Xu1vCkS7XRJ2/PniH+zfiqNHQlmiSZSoD5ogtFqMQ/uuOgkQE2T3p1p8pKZ O3kpkUIpEFUZazh9I84pDuYmXC1GLcX4HW+jAQdTESHXgSEcUfP2SJzNv6zI/2uwvKRMPvfaGCGuD Q/XjXPdQ==; Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lb120-00Fyb3-1i for linux-arm-kernel@lists.infradead.org; Mon, 26 Apr 2021 13:12: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 A63F331B; Mon, 26 Apr 2021 06:12:04 -0700 (PDT) Received: from e123083-lin (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 41D853F70D; Mon, 26 Apr 2021 06:12:02 -0700 (PDT) Date: Mon, 26 Apr 2021 15:11:50 +0200 From: Morten Rasmussen To: Sowjanya Komatineni Cc: Lukasz Luba , 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 Subject: Re: [RFC PATCH 0/4] Support for passing runtime state idle time to TF-A Message-ID: <20210426131150.GA36549@e123083-lin> References: <1619123448-10138-1-git-send-email-skomatineni@nvidia.com> <064341f7-dce3-5ad4-e69b-9568115035c1@arm.com> <486856be-1e66-fd77-e306-949b91bcdb1d@nvidia.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <486856be-1e66-fd77-e306-949b91bcdb1d@nvidia.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210426_061208_233544_E59A0681 X-CRM114-Status: GOOD ( 38.82 ) 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, On Fri, Apr 23, 2021 at 03:24:51PM -0700, Sowjanya Komatineni wrote: > On 4/23/21 1:16 PM, Lukasz Luba wrote: > > 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? > > it could also be in few ms depending on when next cpu event/activity might > happen which is not transparent to MCE firmware. > > > > > 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. > C6 is the only deepest state for Tegra194 Carmel CPU that we support in > addition to C1 (WFI) idle state. > > MCE firmware gets state crossover thresholds for C1 to C6 transition from > TF-A and uses it along with state idle time to decide on C6 state entry > based on its background work. > > Assuming for now if we use min_residency as state idle time which is static > value from DT, then it enters into deepest state C6 always as we use > min_residency value we use is always higher than state crossover threshold. > > But MCE firmware is not aware of when next cpu event can happen to predict > if next event can take longer than state min_residency time. > > Using min residency in such case is very conservative where MCE firmware > exits C6 state early where we may not have better power saving. > > But with MCE firmware being aware of when next event can happen it can use > that to stay in C6 state without early exit for better power savings. > > > 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. > We only support C6 state through DT as C6 is the only deepest state for > Tegra194 carmel CPU. WFI idle state is completely handled by kernel and does > not require MCE sequences for entry/exit. I think Lukasz's point is that you can encode the predicted idle time by having multiple idle_state entries with different min_residency mapping to the same actual idle-state. So you would several variants of C6 with different min_residencies and if the OS picks one with longer min_residency firmware would have a better estimate of the predicted idle residency. I'm not convinced it is the right way to work around passing this information on to firmware. I would rather see an example of how well this works (best with numbers) and have a proper solution. Morten _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel