Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp3568789pxu; Mon, 19 Oct 2020 15:47:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxsHv/NPP8glxreaEzwg9zCOhCKFyQf+sw4ufMCZAUl/d2AD32p8rPHcd7X8JD/pdHmJHud X-Received: by 2002:a17:906:684c:: with SMTP id a12mr116529ejs.406.1603147622977; Mon, 19 Oct 2020 15:47:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603147622; cv=none; d=google.com; s=arc-20160816; b=AyMB7cR3VvRuifsj66VRMWLTzDY4vxaH62H0w8CwzniTUnY2kGnWG+ouKn6jlcGhLf CeyroCPkKCIZT6n+oMFLiDohE7/bP0aa1PPB1janOASdNy18ltxwYvye5HbC+CsD56H4 ammxRAmOp6sfo9/7CM4JL48Dnp5jcBy1ZK1B2JjJFoDugnjvgJyEsFMGF6XYdFigoHTl Z3Cq68ui+UI6VUwxCRfbjsoPLnEwLnstXeYO8WC0AzKpriAFaK6ljFbmf1tLCHNJjwjY u1ApqLkEKG5krsMF+XleCmv2TD5s/UNfJbHSk3W5Vh6wuQJzg03RrFA9+95aOjtczPmr FgNA== 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=Rf7ojM+HowmFxk4hEEOCp1WrW5B76hgBA/haYcm7a9Q=; b=0xlI6JgdQ28HZeF+sOCjFRt7UEER56GBrx0NzdF5aKvfvgdWJ6Jyx3TTVhDH0eUkK+ fL5qcdwcpMZae+VZ1UBZo+9JmdICxBjezuv/ea/srCxF6PK0bT+iqWiWS92E7wC/uE7B 7xrWOx4A9krsQjQ19AgiRNS9hDMD/VRdF3KS//Bgoi+ZuSDm43nalN92nxqm5l4QdZxO gCIN1Y4rQGSSRpb3W1QdFKaAbHGs0tUBDoCntnxXSrA6Z1myCtYSh/lEvMkN+z+dKM+i NPuRBj4QhxDXyrjMVPNl2QkrFjunT8S3zVwnGlLwtUePpqtn2bjapdcOpgbCFtjx0UNb AR1A== 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 p27si910989ejf.691.2020.10.19.15.46.40; Mon, 19 Oct 2020 15:47:02 -0700 (PDT) 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 S1727348AbgJSKfo (ORCPT + 99 others); Mon, 19 Oct 2020 06:35:44 -0400 Received: from foss.arm.com ([217.140.110.172]:54764 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727272AbgJSKfm (ORCPT ); Mon, 19 Oct 2020 06:35:42 -0400 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 BFEE430E; Mon, 19 Oct 2020 03:35:40 -0700 (PDT) Received: from [10.57.15.200] (unknown [10.57.15.200]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A2E623F66E; Mon, 19 Oct 2020 03:35:37 -0700 (PDT) Subject: Re: [PATCH v2 0/3] Clarify abstract scale usage for power values in Energy Model, EAS and IPA To: Quentin Perret Cc: Daniel Lezcano , "Rafael J. Wysocki" , "Rafael J. Wysocki" , Linux Kernel Mailing List , Linux PM , "open list:DOCUMENTATION" , "devicetree@vger.kernel.org" , Rob Herring , Amit Kucheria , Jonathan Corbet , Dietmar Eggemann , Doug Anderson , Matthias Kaehlcke , "Nayak, Rajendra" References: <3e3dd42c-48ac-7267-45c5-ca88205611bd@arm.com> <00ceec64-3273-bb4a-6f38-22de8d877ab5@linaro.org> <20201016121844.GA2420691@google.com> <20201016130905.GA2426638@google.com> <20201016160218.GC2426638@google.com> From: Lukasz Luba Message-ID: Date: Mon, 19 Oct 2020 11:35:26 +0100 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: <20201016160218.GC2426638@google.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 On 10/16/20 5:02 PM, Quentin Perret wrote: > On Friday 16 Oct 2020 at 15:42:57 (+0100), Lukasz Luba wrote: >> Do you mean a new entry in DT which will be always below >> 'dynamic-power-coefficient' and/or 'sustainable-power' saying the unit >> of above value? > > Yes, something like that. > >> There was discussion with Rob (and Doug) about this. I got the >> impression he was against any new DT stuff [1]. >> We don't have to, I think we all agree that DT will only support mW. > > Right, I agree this is a 'nice-to-have'. > >> I have agreed to this idea having a 'flag' inside EM [2], which >> indicates the mW or bogoWatts. It could be set via API: >> em_dev_register_perf_domain() and this new last argument. >> >> I can write that patch. There is only two usage (3rd is on LKML) of >> that function. The DT way, which is via: >> dev_pm_opp_of_register_em() will always set 'true'; >> Driver direct calls of em_dev_register_perf_domain(), will have to >> set appropriate value ('true' or 'false'). The EM struct em_perf_domain >> will have the new bool field set based on that. >> Is it make sense? > > I had something more complicated in mind, where units are arbitrary > ('milliwats', 'scmi-bogowatts', ...) as that would help if units can be > specified in the DT too, but if we don't care about that then yes I > suppose a boolean flag should do. Thank you Quentin for help in sorting this out. I'll send the v3. Regards, Lukasz > > Thanks! > Quentin >