Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp2537327ybi; Thu, 18 Jul 2019 09:56:04 -0700 (PDT) X-Google-Smtp-Source: APXvYqwsTdHVtvFmJgzndehzgGaPsWLMdmNeJvklrgYBIWEXRfzbxLljulJTyI0Tw2NpfLOk3AuC X-Received: by 2002:a63:2c8:: with SMTP id 191mr48101393pgc.139.1563468964522; Thu, 18 Jul 2019 09:56:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563468964; cv=none; d=google.com; s=arc-20160816; b=Z7cRlxe1lioU/9wV/NvSD5aDWuO9J5Hm7Od+LZV1NyMtRYY3wMmJozo/miUiH69dGv JT1htUOXrUZDeRGoSyFlEECOroQwE1OzouGjlgnAEPUM55tvdtFdJstd/tMcoVEUzAKo neDqzKSqvjrmFBEnoBAiZBkrFJ4kkmDXDmcs8JAOjWjVVbGrYsuh5oyrDD8CbQNXIIG4 WpxcvkTaLzBwT2YjK8iB0mCCd2sz/7uN9kXHYiEvyKxhXfOmTsgZYh59pqVO3Ey04vkX PFDRU+0HNOVetJkoqs9x+Jlq5xJp24jJy3qZH7YshaC5eJFbc9HPgvNDQeW16LxkWSCI geRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=UbJA1LvVSBKZi34z8EvemKhQnL5/c6wyw0dFUXsJ7H4=; b=soW/h25DLJjIGXTExanWd1iaClL+DLdwvkfzOMffMQ81Ua4hf+X0f6CFK5m1pkAwyS VLujc4CAwEbamXZuWLpPdqps/AK+iHq4Ade3POByvHUU8DgdOZuLflmA2vjg8EntwfQt F9uq6p/0vfhkffTSB9KggVgrXogDjMsxctDpN++HaQROI0TCtWrqAh8ITE0E+4W/BBz6 eRtRKmBP7SEjLB3qJU+gPDXjH/UJ3EgS5fzDZfP+ybAhLaJe1g++oVdjK79JPc3AulxL OCscAPgoTI3cRar+/gT1i9EiX2TIVwWQwzHcoW1ljXrRZJxuC5kHy7+6CjNgt5BY6y+T UNbw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=v+KXmWJJ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id ci23si24666378pjb.106.2019.07.18.09.55.48; Thu, 18 Jul 2019 09:56:04 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=v+KXmWJJ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729945AbfGRQza (ORCPT + 99 others); Thu, 18 Jul 2019 12:55:30 -0400 Received: from mail-vs1-f65.google.com ([209.85.217.65]:40355 "EHLO mail-vs1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727623AbfGRQz3 (ORCPT ); Thu, 18 Jul 2019 12:55:29 -0400 Received: by mail-vs1-f65.google.com with SMTP id a186so17969211vsd.7 for ; Thu, 18 Jul 2019 09:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UbJA1LvVSBKZi34z8EvemKhQnL5/c6wyw0dFUXsJ7H4=; b=v+KXmWJJHgzxhzH/ByzH+UGInDESBlyCnkXDLOYXkFL108hatd/9puy+QFFba3m5WD bhtTKrLRw2YAQnFRC5M36S3T5i8Oe9gGBtNFE7ZdCJ/1I4gLyUmnIjKdORLB/9odeMnw FhmH4wyOwzolrzleyGwIui2FQ8MLa67j+7E28mZP0dcFPtbM1CXxugMkHsdZeP6VkJ9g pXT21JDk/94eK4JtwLYOUv7st8v723fVliWhRYVAZKpLQy8dM/d+IyfGekDqo5K749U+ kzXKq432p3MGhIBhb+v8kvOZnTcKOkNOpxCcu9VamQd7Pt/FKJqG22ZTWj0nzsbngz0X 0K4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UbJA1LvVSBKZi34z8EvemKhQnL5/c6wyw0dFUXsJ7H4=; b=UkzdQiyFWGyOV5IKdodfaphsyMmm7Ri7d75kfp/woAmAtNwb/VkmaPrnrYYs793ogQ 5oCSKCf0DNpvfIZHY2Qbk6kVkog1SS4l7FrLYEeicj+A5bzRswdNTr5umUp2p/nFzuR5 68jDJtmBFUZXOgBU+0LSR/BXy2OGaBvIIpWWPaGYvgmr60HMPZ2c20SCy11vtkjw6ABe znT39c3w07vYOgn5EHa+SKtac2L4Z6fY+50AlHMGYEHZdzpEd1AR7DaxvNOgei8ryQ/P k0Q2nPyFEhultuVD3OZcwqZu6eAk8fkfBpgZY9GwSVmJESPv3CkuCurBYmaroaKXv1r+ 1o7w== X-Gm-Message-State: APjAAAVYJ3F64kvY1QIOAFcyDKbHPefsIoqN1ykETmupdbIxQMGEigLj rlue/QBIyDEM3IohFoH687TfryqnO/XnrfujdCZCIw== X-Received: by 2002:a67:61c7:: with SMTP id v190mr28723774vsb.165.1563468928660; Thu, 18 Jul 2019 09:55:28 -0700 (PDT) MIME-Version: 1.0 References: <20190513192300.653-1-ulf.hansson@linaro.org> <20190513192300.653-15-ulf.hansson@linaro.org> <20190716155317.GB32490@e121166-lin.cambridge.arm.com> <20190718133053.GA27222@e121166-lin.cambridge.arm.com> In-Reply-To: <20190718133053.GA27222@e121166-lin.cambridge.arm.com> From: Ulf Hansson Date: Thu, 18 Jul 2019 18:54:52 +0200 Message-ID: Subject: Re: [PATCH 14/18] drivers: firmware: psci: Manage runtime PM in the idle path for CPUs To: Lorenzo Pieralisi Cc: Sudeep Holla , Mark Rutland , Linux ARM , "Rafael J . Wysocki" , Daniel Lezcano , "Raju P . L . S . S . S . N" , Amit Kucheria , Bjorn Andersson , Stephen Boyd , Niklas Cassel , Tony Lindgren , Kevin Hilman , Viresh Kumar , Lina Iyer , Vincent Guittot , Geert Uytterhoeven , Souvik Chakravarty , Linux PM , linux-arm-msm , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 18 Jul 2019 at 15:31, Lorenzo Pieralisi wrote: > > On Thu, Jul 18, 2019 at 12:35:07PM +0200, Ulf Hansson wrote: > > On Tue, 16 Jul 2019 at 17:53, Lorenzo Pieralisi > > wrote: > > > > > > On Mon, May 13, 2019 at 09:22:56PM +0200, Ulf Hansson wrote: > > > > When the hierarchical CPU topology layout is used in DT, let's allow the > > > > CPU to be power managed through its PM domain, via deploying runtime PM > > > > support. > > > > > > > > To know for which idle states runtime PM reference counting is needed, > > > > let's store the index of deepest idle state for the CPU, in a per CPU > > > > variable. This allows psci_cpu_suspend_enter() to compare this index with > > > > the requested idle state index and then act accordingly. > > > > > > I do not see why a system with two CPU CPUidle states, say CPU retention > > > and CPU shutdown, should not be calling runtime PM on CPU retention > > > entry. > > > > If the CPU idle governor did select the CPU retention for the CPU, it > > was probably because the target residency for the CPU shutdown state > > could not be met. > > The kernel does not know what those cpu states represent, so, this is an > assumption you are making and it must be made clear that this code works > as long as your assumption is valid. > > If eg a "cluster" retention state has lower target_residency than > the deepest CPU idle state this assumption is wrong. Good point, you are right. I try to find a place to document this assumption. > > And CPUidle and genPD governor decisions are not synced anyway so, > again, this is an assumption, not a certainty. > > > In this case, there is no point in allowing any other deeper idle > > states for cluster/package/system, since those have even greater > > residencies, hence calling runtime PM doesn't make sense. > > On the systems you are testing on. So what you are saying typically means, that if all CPUs in the same cluster have entered the CPU retention state, on some system the cluster may also put into a cluster retention state (assuming the target residency is met)? Do you know of any systems that has these characteristics? [...] Kind regards Uffe