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=-5.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 73B9FC433DF for ; Fri, 16 Oct 2020 12:50:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F08E7207E8 for ; Fri, 16 Oct 2020 12:50:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="Clni0cNl" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2407876AbgJPMue (ORCPT ); Fri, 16 Oct 2020 08:50:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38932 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2405632AbgJPMud (ORCPT ); Fri, 16 Oct 2020 08:50:33 -0400 Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 80384C061755 for ; Fri, 16 Oct 2020 05:50:33 -0700 (PDT) Received: by mail-wm1-x342.google.com with SMTP id q5so2857271wmq.0 for ; Fri, 16 Oct 2020 05:50:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=CrMlB8wZnz1QSRMDLaaqihjuRkl23NGRAQ7yTr/KKgU=; b=Clni0cNlsKDQqQNx9Z1oea1qbI5trbL18Iwm/RppeJEeDU5onspHP+KN+DucCmqcpr 83zcVFENnk98nG7FAfwFElxxybgV2pzT2pSgM81VeOQzDSMxo3KvK/oBUr6gZENqPREC Qkfm1jEKyT9XhdjMCrNsYLL4T+qZTbXTOOm+PYNIyqgd9H+V5BiMUcGSlQBkNyj9kBHS HJu9xFj7y65JJdwxs8rQkmrNYeKw8u6w4LcCr+IKygGQmg6FCDKpfEsjYX58XNWbY+MS fznHd8MrGWW6vLo0g1BieoHkqw4Rk9MDTCiFEdSwEsYwURoaoU9zpKfa4hxH3a57OMDJ 9kBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=CrMlB8wZnz1QSRMDLaaqihjuRkl23NGRAQ7yTr/KKgU=; b=ds+WjQXgLsj1G8COmuXvJBv5Vi87aUz5g9stcopi4SmkuW/aFeUPpx1byOfIzwQYYo a+oacrWK8mpxLYjnYOXKe6SZrYsgqt3erIJ9i24AOzDdRHKNoN2hUiA1LzGrliUJjQ7R MoImUnMOPTDUmX1/Ud4Hs0nBfUUaDS3jU587sIYfk9GYS9EMHyawkxYdieViszdPmUpm FZzFUlZWB9K0qHwCUkGgxvgWWPv7/RmUeAPo0SfsY5HMZ0ePI+5U12jsefUehoYgTWjJ pIQF+XIUXlyiIu1PFcFgj9/6jfcjGzjYGReP2sRgNcmNQbvlypNC0j9x4zTV9ut4JtnK jQqw== X-Gm-Message-State: AOAM532zIQiWNo3iG7dx1ahKwvggGrzB1chFt+ZqNbB9KWL3ADiryXRd kUt1KEl/+jrfzB4HwNn7FGij3g== X-Google-Smtp-Source: ABdhPJwc6OQCnkD3OpBg2RnakL6syJWoFj3OemWf0bJrqBo0e6K5q4D9gFKaC16wyZgW5X4c9QHMMw== X-Received: by 2002:a1c:495:: with SMTP id 143mr3543475wme.63.1602852631989; Fri, 16 Oct 2020 05:50:31 -0700 (PDT) Received: from ?IPv6:2a01:e34:ed2f:f020:c9d8:1700:5168:39b? ([2a01:e34:ed2f:f020:c9d8:1700:5168:39b]) by smtp.googlemail.com with ESMTPSA id 14sm2610405wmf.27.2020.10.16.05.50.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Oct 2020 05:50:31 -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: "Rafael J. Wysocki" , Lukasz Luba , "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: <765e6603-b614-fb72-64ff-248b42474803@linaro.org> <55d3fb0f-f7d8-63c5-2bdb-53eaa62380e0@linaro.org> <3e3dd42c-48ac-7267-45c5-ca88205611bd@arm.com> <00ceec64-3273-bb4a-6f38-22de8d877ab5@linaro.org> <20201016121844.GA2420691@google.com> From: Daniel Lezcano Message-ID: Date: Fri, 16 Oct 2020 14:50:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20201016121844.GA2420691@google.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 16/10/2020 14:18, Quentin Perret wrote: > On Friday 16 Oct 2020 at 13:48:33 (+0200), Daniel Lezcano wrote: >> If the SCMI is returning abstract numbers, the thermal IPA governor will >> use these numbers as a reference to mitigate the temperature at the >> specified sustainable power which is expressed in mW in the DT. So it >> does not work and we can not detect such conflict. >> >> That is why I'm advocating to keep mW for the energy model and make the >> SCMI and DT power numbers incompatible. > > I think it's fair to say SCMI-provided number should only be compared to > other SCMI-provided numbers, so +1 on that. But what I don't understand > is why specifying the EM in mW helps with that? It is already specified in mW. I'm just saying to not add the 'scale'/'abstract'/'bogoWatt' in the documentation. > Can we not let the providers specify the unit? Yes, it is possible but the provider must give the 'unit' and the energy model must store this information along with the "power" numbers, so we can compare apple with apple. Today, the energy model is using the mW unit only and the providers are not telling the 'unit', so both are missing. Because both are missing, it does not make sense to talk about 'abstract' values in the energy model documentation until the above is fixed. -- Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog