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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 671F6C2D0C0 for ; Thu, 5 Dec 2019 20:39:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3BBCC205F4 for ; Thu, 5 Dec 2019 20:39:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="KEqh5U3m" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729632AbfLEUjX (ORCPT ); Thu, 5 Dec 2019 15:39:23 -0500 Received: from mail-vs1-f65.google.com ([209.85.217.65]:44274 "EHLO mail-vs1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729587AbfLEUjX (ORCPT ); Thu, 5 Dec 2019 15:39:23 -0500 Received: by mail-vs1-f65.google.com with SMTP id p6so3404914vsj.11 for ; Thu, 05 Dec 2019 12:39:23 -0800 (PST) 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=SSvOjQkThzkjS0E5kT8izv176PiG+QeLySxW76GfG/8=; b=KEqh5U3mky5aGe7W96TiE2LasaP3xlk51SGQLcUTzI1gDcy3EH1dmJjfwPF/JMLEBM nGW8/IEwFXENSKvuLMyqJq96Kr0LfnE6z/+8Tp7EQd2fB1Df1iiwJoWw6TRgiNgTJuLZ TgrcNx9ZGBo597myzBWXph+Dsp5sIE/30gEpNX/TsvHQX0Pd5mTNnJDB53bYzEnCZTjb v3zt0XPG6g9HJjA1lnPkIYhsHqMnsI809RxuIQ8B4lEh1rFGDgcs0uBPvTw3SMsr647w a9KMvmrWdUgCDY6klznjR5FatNCjj3nUZMnQnyERTctkh5Sd+jGWTuXmjGz6YGJDfYl9 lt7A== 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=SSvOjQkThzkjS0E5kT8izv176PiG+QeLySxW76GfG/8=; b=q/wMcDmlP/g3ts/Ee8VFZXjEJbiDKN1tY5QjDw6TvtHpkge6nsBtxONt9tTXg2d39Q Lo4bGsl3q80qflZHXGPKsF/HrDAGyn0tzJijvs1GN7w9GW0lVRVv1o3zVZiTwlY1Cy5R rLHIC2hY2I0cfOBm6qAP7Av1h+xvcO37DrAp+/LGbrcc70DRjvQJDkTX/flja6/+CfSK ttNx15Ky6JUD8eCaWX9LtrGBRGEDgJJnBtVFLQmCXlKomyAdL7bOwkxF7P3wDduMqhwc XK7A0pViztQcpXnmVHB+LwU5FgEaEl24qFELSeQiIDjhShwiwKICMQlNZVsYLF3mXRdc GlzQ== X-Gm-Message-State: APjAAAXouU7KeDgRxK2JEvIcUDwKm4mXDfdiUxOtUBYJSDF0l6iO1Vmz UCtnwQqeq8f9jHgSYRkpBIhvL12SK7oc8CeISywgTg== X-Google-Smtp-Source: APXvYqwv8W+XvnbaXKWKlmbMYtOfLrbfwOBq+4ILBpgcTAHXNniAJi3G7xZyAP75rfwK/aPe4c6uig2q/Wwh9WLoeNU= X-Received: by 2002:a67:f499:: with SMTP id o25mr6993350vsn.165.1575578362421; Thu, 05 Dec 2019 12:39:22 -0800 (PST) MIME-Version: 1.0 References: <20191127102914.18729-1-ulf.hansson@linaro.org> <20191127102914.18729-11-ulf.hansson@linaro.org> <20191205183544.GB1516@e121166-lin.cambridge.arm.com> In-Reply-To: From: Ulf Hansson Date: Thu, 5 Dec 2019 21:38:45 +0100 Message-ID: Subject: Re: [PATCH v3 10/13] cpuidle: psci: Prepare to use OS initiated suspend mode via PM domains To: Lorenzo Pieralisi Cc: Sudeep Holla , Rob Herring , Linux PM , "Rafael J . Wysocki" , Daniel Lezcano , Mark Rutland , Lina Iyer , Vincent Guittot , Stephen Boyd , Andy Gross , Bjorn Andersson , Kevin Hilman , Linux ARM , linux-arm-msm , Lina Iyer Content-Type: text/plain; charset="UTF-8" Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Thu, 5 Dec 2019 at 21:25, Ulf Hansson wrote: > > On Thu, 5 Dec 2019 at 19:35, Lorenzo Pieralisi > wrote: > > > > On Wed, Nov 27, 2019 at 11:29:11AM +0100, Ulf Hansson wrote: > > > > [...] > > > > > -static int __init psci_dt_cpu_init_idle(struct device_node *cpu_node, > > > +static int __init psci_dt_cpu_init_idle(struct cpuidle_driver *drv, > > > + struct device_node *cpu_node, > > > unsigned int state_count, int cpu) > > > { > > > int i, ret = 0; > > > @@ -118,6 +152,11 @@ static int __init psci_dt_cpu_init_idle(struct device_node *cpu_node, > > > goto free_mem; > > > } > > > > > > + /* Manage the deepest state via a dedicated enter-function. */ > > > + if (dev) > > > + drv->states[state_count - 1].enter = > > > + psci_enter_domain_idle_state; > > > > > > It is unfortunate to make this arbitrary choice, it would be best > > if you could detect which states are "domain" states aka are governed > > by multiple cpus. > > The domain states are managed and selected by the genpd providers, via > using runtime PM reference counting. Please have a closer look at the > code in cpuidle-psci-domain.c and in the generic PM domain, that > should give you the needed details. > > I am overriding the enter callback for the *deepest* known idle state > of the CPU, which is according to what you requested [1]. > > So, unless I am missing your point, I think the above code does > exactly what you want, no? > > In regards to the "arbitrary choice" of what cpuidle state to use, > there are more details about why that is, in the changelog. Correction: Since I have moved patches around, I realized that the explanation is actually put in the changelog of patch11. For clarity, let me cut and paste it here as well: "The triggering point for when runtime PM reference counting should be done, has been selected to the deepest idle state for the CPU. However, from the hierarchical point view, there may be good reasons to do runtime PM reference counting even on shallower idle states, but at this point this isn't supported, mainly due to limitations set by the generic PM domain." Is that good enough or you want some of this information also in the changelog of $subject patch? Or if you have any other idea for how to make this more clear? [...] Kind regards Uffe