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=-11.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 C14BCC433DF for ; Fri, 16 Oct 2020 12:18:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5D7BB20874 for ; Fri, 16 Oct 2020 12:18:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="BRCGCazZ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2407411AbgJPMSu (ORCPT ); Fri, 16 Oct 2020 08:18:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33974 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2407407AbgJPMSu (ORCPT ); Fri, 16 Oct 2020 08:18:50 -0400 Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B98E9C0613D4 for ; Fri, 16 Oct 2020 05:18:49 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id i1so2655398wro.1 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=qOSXx5PI8C1pfYaM9Xi+H+HUjrcXZAopnYQb6zzGaxcEaByIINBqnwrV/8/E1avX/c cPtJPJFcYJ2c6ht6PdXngC4mr4KuqPZBbZy7eRC/N0NINvRA6KE3hj5FfsHWV0l+H9kz tQxVVw9BaU+dCN6njlDzy7+zUYNpxORBpH4R8jle4pLJPrzHYromx3NVqlB9hqM3RiYv 7GZtOYco6KhhzvjkFFsXK8lKHHOSBjMWhz/9Eqs3Hx3b+xce25wji062zkhQJ3UkXHXY N43t9/SqwZcXvD7rZ4jR+KWcgIgda3XhUqX5/ShBgADhcSYMYMR1HMbR3oUN4wTRHYsA P/Qw== X-Gm-Message-State: AOAM533//jGoAyUDPDSa5qlO1nhm+Q1Nscc/mr9H4T8wG5fiXXC5uDzf qb0gatFw+W5kAYxYd6vpmoeM8Q== X-Google-Smtp-Source: ABdhPJynsLog2SBXEjNnrjD188QPZKXARHTTCwJpoH5mJt1b6bt+GnFTOCBbSDzlQUbUzWRgybvrog== 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: devicetree@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