Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp1209534pxb; Wed, 4 Nov 2020 03:00:42 -0800 (PST) X-Google-Smtp-Source: ABdhPJwkqp/Ae/KXgK/YJSGL4Kf3mtC0Yygv7sI8cI6hBjtTu0Ohs/Obl3Rfc2kDRs/a1w6fQU2m X-Received: by 2002:a17:906:4753:: with SMTP id j19mr22748030ejs.65.1604487641909; Wed, 04 Nov 2020 03:00:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604487641; cv=none; d=google.com; s=arc-20160816; b=CR+2aB3kmvIf6V79Z6eRMUA8eIPQ83/3UnHTO3B/LvGgGgt9264TARBUv8LcYAJsK7 oRjV285geSysDz6XLAHhC+KAaamUj1RG8FSGsEQx59USYzxMllaMtyvSLJwi6ymVmo0S dG+K/qx36OG5SXsO0lChZ/ChpaPqDQmPpfTq2Mgc9jsjIFuoZgABNHsrhdU56wryVZs5 WodIkIHBYMQXnytYLj/vEIvr/XcJ78lKHfU8qQ2Gu1Xh+39PPV2vyidPOiewLOD9osTk ko73uOpGrN6xatqgnwnFcswoh9J6ulB4mQ0TUy7uUYG7j4PK/2yJnoRK0RlF00qG2r0v BnPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=KLwlstrQFVZcDYfg713BJD/TBR7hk+5iSTzkuFQSdFo=; b=VH/ShYQgtiarka1nXfC+2dDLFfQH8Zk7bCbfxwKAbbrG8+uSPYHUzzAU1fWHCdY17O /sdAJeF71JdOUoM+NMNhjkz5MhsKUoSOpJUGItbVZ372fri2dNoq5+mcSDgx6nnmpOhB t83NEscI/zuklboIg8zqsCBpEEg+N22RsE6t/nwJr1x6ExYhXpurE8pmDYoCvCaaYvEu h1KrTg61YqX9ab0JbhNII4bY50aRo1QKsz3sRhXU1tTIiCyuSPP+0rrmCoOm302nPu6z WY9Yv4zdyQfp93OHKDzEt5rsMdxiS3jlJvojEeX0sJguj/nfYbMgCPhTOrOw/KvmF47m uZWw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id by24si1161893ejc.347.2020.11.04.03.00.18; Wed, 04 Nov 2020 03:00:41 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729631AbgKDK64 (ORCPT + 99 others); Wed, 4 Nov 2020 05:58:56 -0500 Received: from foss.arm.com ([217.140.110.172]:35264 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726344AbgKDK64 (ORCPT ); Wed, 4 Nov 2020 05:58:56 -0500 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 503241474; Wed, 4 Nov 2020 02:58:55 -0800 (PST) Received: from [10.57.20.87] (unknown [10.57.20.87]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3EF4A3F718; Wed, 4 Nov 2020 02:58:45 -0800 (PST) Subject: Re: [PATCH v4 0/4] Clarify abstract scale usage for power values in Energy Model, EAS and IPA To: rafael@kernel.org Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-doc@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, robh+dt@kernel.org, amitk@kernel.org, corbet@lwn.net, daniel.lezcano@linaro.org, Dietmar.Eggemann@arm.com, morten.rasmussen@arm.com, qperret@google.com, dianders@chromium.org, mka@chromium.org, rnayak@codeaurora.org, sudeep.holla@arm.com, viresh.kumar@linaro.org, sboyd@kernel.org, nm@ti.com References: <20201103090600.29053-1-lukasz.luba@arm.com> From: Lukasz Luba Message-ID: <9382ea70-cc50-7b78-f5de-716678bdefbf@arm.com> Date: Wed, 4 Nov 2020 10:58:43 +0000 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: <20201103090600.29053-1-lukasz.luba@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Rafael, On 11/3/20 9:05 AM, Lukasz Luba wrote: > Hi all, > > The Energy Model supports power values expressed in an abstract scale. > This has an impact on Intelligent Power Allocation (IPA) and should be > documented properly. Kernel sub-systems like EAS, IPA and DTPM > (new comming PowerCap framework) would use the new flag to capture > potential miss-configuration where the devices have registered different > power scales, thus cannot operate together. > > There was a discussion below v2 of this patch series, which might help > you to get context of these changes [2]. > > The agreed approach is to have the DT as a source of power values expressed > always in milli-Watts and the only way to submit with abstract scale values > is via the em_dev_register_perf_domain() API. > > Changes: > v4: > - change bool to int type for 'miliwatts' in struct em_perf_domain > (suggested by Quentin) > - removed one sentence from patch 2/4 in IPA doc power_allocator.rst > (suggested by Quentin) > - added reviewed-by from Quentin to 1/4, 3/4, 4/4 patches There was no major objections in the v3 and this v4 just addressed minor comments. The important discussions mostly happen in v2. Could you take the patches via your tree, please? Regards, Lukasz