Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp1189137pxu; Fri, 16 Oct 2020 06:13:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwPV83o6BGXM9jsUBBauYhla3bAZ9+O6Og5pJqdMzyfRN5oda56wvlwam0AFCyVdHVNSepu X-Received: by 2002:a17:906:33c8:: with SMTP id w8mr3579892eja.233.1602854009558; Fri, 16 Oct 2020 06:13:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602854009; cv=none; d=google.com; s=arc-20160816; b=UJ06iiMhIyacLvaKQuGb2wNV+IBmXVgVbzUaYH2ZH6e5tpVHkTD7mFudVVO7oQKVY6 h17LgK5dksDOLj2Pp77aa6ERlT9zPPSCwrKb2nsKyIi4aCU66KIztaljHYbNoICN+1Qe gKlLsqPgpE5R2Nc6fKk38JlWuuvTSRNtt27KfKLss79S5czIsrvm0y5a72K0mUmGAviC Oe3yjWvXT2MZL+XoIHZziG4M5sXEZ99S37b/1TNUL3uGvh2dbeRVo0BeY0aibqOqkf3P /osMj6PGYJ6BD5tnMnLh+AiJ9zv4RdU35rlK/9+N/+ZUOVI/3AgNTQktjIpSz22FaXxJ /UfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=0pdmY6ok4ux/pRIx0LbllshB3HAtBqzH8ww+t6IFCvg=; b=PGlqrrPcZU0DWVEs8vjJSNcf6B44QQ82yz4O7exb24XPRA2OrdposrhN3EqHo9mLs/ T/SxN9I5rFVH1GPtfACn6APS+L5kevwYuqPbS+7Veqn6WCuffNfdty2Imy2DeN7TQv2b ea1LL1lf6X2vHP/e9KGlMBos/2Cve33ZCDRAchZoo0jnAE+JhPVcrgS+KfdIVaBOEqIN ve2qax0mALdPp3ngg3eXkm0y5+oP8L6aAcXAqAZOqwBP0KfC+/H9V/afV5DXCH+i9N6s ECou/EAOhwbA+/jvgxYGk/8YRCxQCEDv0gEWQnvyVLP7sTevh8of5cCsbXn1ucU1JL7E zM0Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=BRCGCazZ; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r1si1502407ejh.137.2020.10.16.06.13.03; Fri, 16 Oct 2020 06:13:29 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=BRCGCazZ; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2407413AbgJPMSu (ORCPT + 99 others); Fri, 16 Oct 2020 08:18:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33972 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2407254AbgJPMSu (ORCPT ); Fri, 16 Oct 2020 08:18:50 -0400 Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A3A0FC0613D3 for ; Fri, 16 Oct 2020 05:18:49 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id n15so2659323wrq.2 for ; Fri, 16 Oct 2020 05:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=0pdmY6ok4ux/pRIx0LbllshB3HAtBqzH8ww+t6IFCvg=; b=BRCGCazZgsunLR6jJ78OyJPB+VKA4STGJjhLL24E+nm0fiJ6C/tvZ3LCjySWqlTlCt FUHsNt9eHJHmF2gky45/dqPZGAujEldnyGBehFiP6wzx+HHPBnNvmkGo0Nva+JZ1lx+N jKwgEwvqg+M8unp+nDGAVNz0NGNRvAt7yQp9qnjJYEKOUfZ5L1WWgjTSZ4yL7ywY181w vxN+H2/4XXo5DbRolcOHaJPsqOB+4SYlIYSBhLHzpcwBI8tSBD8oK2sP9s7bovofZHsa voBX29Z23s32AgJqa77Y/uIl/lVcwzwdXFH0p+lqZvROc5zvEH40JJj5saTH1GSrfsCm NkVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=0pdmY6ok4ux/pRIx0LbllshB3HAtBqzH8ww+t6IFCvg=; b=Ya7mSLw/7/YxkKxFvigEe+wUqfi+ueySB/zEuOE0wBosXpb/4WBzkU4Jl8+/atnava Cnm2D7d3+BozX5iD01nnnam8CPU76M+V651Gj2dKGk83y1Y/1eb2eScXegUprtvslu+d xpKi6TP3N7gflUDjGYBQ0cvAxcmycT1AMOr+rDFY1ckOlr++s16yd12zqvebXkAw1fka ppw4QDRWu4cKLFibTZDO9bvM2Ji5lyjVdjBwlU7v3Sr9dWeitssm4XbzjFzTD4FQUAFG +LAzdSAbSN4UiSvVGQaFCl3rxPVJPsfjSRc9q/fHeNg7GluiaX5om+Yjo+D2KgGD7wH5 PWcg== X-Gm-Message-State: AOAM530tKtIcxYOveUEP7vpBiZJ7mCN0yIHA4qSzzCx/oo4Xf83D8AMD bAQ5RykIQa7PpuLME9H4Qd9ATPDl9bizNg== X-Received: by 2002:a5d:4144:: with SMTP id c4mr3565269wrq.311.1602850728236; Fri, 16 Oct 2020 05:18:48 -0700 (PDT) Received: from google.com ([2a00:79e0:d:110:f693:9fff:fef4:a7ef]) by smtp.gmail.com with ESMTPSA id c68sm2636719wmd.34.2020.10.16.05.18.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Oct 2020 05:18:47 -0700 (PDT) Date: Fri, 16 Oct 2020 13:18:44 +0100 From: Quentin Perret To: Daniel Lezcano 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" Subject: Re: [PATCH v2 0/3] Clarify abstract scale usage for power values in Energy Model, EAS and IPA Message-ID: <20201016121844.GA2420691@google.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? Can we not let the providers specify the unit? And then it's up to the clients to decide what they want to do. The scheduler wouldn't care, and IPA would have to check things are comparable, but all in all that should work out fine without a strong requirement on the actual unit. Also, I thought SCMI had a notion of sustained performance too, why can't we use that for IPA? Lukasz? Thanks. Quentin