From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Hilman Subject: Re: [Discussion] Performance levels of power domains Date: Thu, 27 Oct 2016 10:24:02 -0700 Message-ID: References: <7hvawfq6kh.fsf@baylibre.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from mail-pf0-f170.google.com ([209.85.192.170]:34133 "EHLO mail-pf0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752633AbcJ0RYT (ORCPT ); Thu, 27 Oct 2016 13:24:19 -0400 Received: by mail-pf0-f170.google.com with SMTP id n85so21427754pfi.1 for ; Thu, 27 Oct 2016 10:24:04 -0700 (PDT) In-Reply-To: (Rafael J. Wysocki's message of "Thu, 27 Oct 2016 12:11:24 +0200") Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: "Rafael J. Wysocki" Cc: Viresh Kumar , "linux-pm@vger.kernel.org" , "Rafael J. Wysocki" , Vincent Guittot , Ulf Hansson , Michael Turquette , Stephen Boyd , "Nayak, Rajendra" , Georgi Djakov , Lists linaro-kernel , Mark Brown "Rafael J. Wysocki" writes: > On Wed, Oct 26, 2016 at 9:00 PM, Kevin Hilman wrote: >> Viresh Kumar writes: >> >>> Hi Guys, >>> >>> I wanted to involve you guys to get a discussion going >>> for a problem we want to solve, and so this mail. >>> >>> >>> Platform details: >>> >>> Some of the Qualcom SoCs have the option to configure >>> the performance level of their Power Domains. The performance >>> levels are identified by integer values (lets say 0-9, 0 being the lowest). >>> >>> Another M3 core handles the *real* voltage scaling based on the input >>> received (from software) in terms of these performance levels. The M3 >>> core translates the levels into a range of voltages (corners) and selects >>> the right one by itself. >>> >>> Software needs to provide the performance level for the entire domain >>> to the M3 core and so software also needs to handle performance requests >>> from all the devices that lie in the domain X and find a Performance Level P, >>> which can satisfy all the devices (normally the highest requrested level). >>> >>> >>> Problem statement: >>> >>> As we aren't dealing with Voltages here, we can't really get the benefits >>> of the Regulators framework. The regulators are managed internally >>> by the M3 core. All we need is a way for software to comeout with inputs >>> for the M3 core. >>> >>> The OPP framework can be used to include performance levels for >>> each OPP (frequency) entry. >>> >>> But what framework can be used to select performance level of power >>> domains ? >>> >>> By name, power-domain or genpd looks to be the right choice, but until >>> now it is only managing power-on and power-off of devices and domains. >> >> genpd has also recently been extended to support multiple states, though >> those are still idle states, not active (performance) states. >> >>> Should we extend that (along with runtime PM), or do something else? >> >> Yes. As I've suggested to qcom/linaro folks (off-list discussions), I >> think extending genpd to handle performance states is a logical >> extension. Otherwise, you will be (re)inventing something that looks an >> awful lot like genpd anyways. > > On the Intel side we also have a mechanism to tell the processor about > the power/performance preference and it would be good to have a common > way to do it on all platforms and genpd doesn't look like a > particularly good place for that. > >> The other related framework is per-device PM QoS which could be used to >> set constraints on specific devices, and the genpd governors would then >> be responsible for looking at the constraints and changing states as >> needed. > > Right. > > Let's talk about this at the LPC. Sounds good. Kevin