Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp1186920pxu; Fri, 16 Oct 2020 06:10:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJziXa/gEEiuxOCPz62pTQcVeO1Q5PR5kr+YmIccpU8l0nv7j7eYdOi/kSLAb6Rb5QoSjGJy X-Received: by 2002:a17:907:ab9:: with SMTP id bz25mr3802515ejc.90.1602853850603; Fri, 16 Oct 2020 06:10:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602853850; cv=none; d=google.com; s=arc-20160816; b=ujC4YEZqZRxRyHNLcTW11HTHWyenRKBLiIn5nTjy4lU/VXR7G1x4zSWfGaY6NWmbwW D7NvwNwh0qEXZW+wRu5vuTtZEfZfY5hRNzPoFmGzn3SRfvIL/cSPjSCKkqPTjtVJlcxP PpUiSVfbmgGokOXUle/Fmt8B+4JeuZ26vx4Cdd3RioG6G3AbS9SG4nQHcSbUVg2ejNfe wfuwTT7ARVNDLZmn9JF95/YwzMP9pc03cYV0mLuxuy1Z6UTtNQD551hSjWqFmmwKe2Xb I6FeQWAj7/SSfk6U4EEVBuS0KrXkC+bNAnZmN8Z7FqpI/29xj8ou7gz3AP5UV8L0BWK3 jL+w== 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:dkim-signature; bh=tkJ6vBaz3G5IwdB8Lg8ppojVTnQOkfwjYi/pmtrKvtY=; b=Fr9iLQ73pXj79KOZ9HFXnrLhN5vbvSyfhBJBdL3BL5j92SbZAmgV6m952lbC7IP1kc ckw9+ZqVoE7lSek5iJGECgnB83b9LvQDcYd1aaNJa453mWW6LJED6b7aTkvZIYzQQXWQ KNghKdOTXG84wBHxRKsZlZJkQZvjocdGqDE/iHWqnhXRwAkOHbvgqyL1ysYvJNCtadz1 i0JT4UVQubKt5s41oQlnuDwe9QiqTFZzrkDQEbcswHa1EZ1/NZmA55YQSOJkB5Rc+wCj a420k0K5bEw5YjQXtWh0NY8/OAKp4kgFz4zYu2wSPwIkue/MwnphPcrsGcBCzB/3FB74 6+lg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=K3AUdSrJ; 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=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h26si1762085ejd.572.2020.10.16.06.10.28; Fri, 16 Oct 2020 06:10:50 -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=@linaro.org header.s=google header.b=K3AUdSrJ; 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=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2406911AbgJPLsi (ORCPT + 99 others); Fri, 16 Oct 2020 07:48:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57496 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404594AbgJPLsi (ORCPT ); Fri, 16 Oct 2020 07:48:38 -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 A5B15C0613D5 for ; Fri, 16 Oct 2020 04:48:37 -0700 (PDT) Received: by mail-wm1-x342.google.com with SMTP id j136so2630847wmj.2 for ; Fri, 16 Oct 2020 04:48:37 -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=tkJ6vBaz3G5IwdB8Lg8ppojVTnQOkfwjYi/pmtrKvtY=; b=K3AUdSrJUNqBT+9eMbnfsnzyoaatQyFjkJArkqEqxkFZaEQX2ySi7qZuZKv9jzzBi7 docQAuack5TT+lb31NtHVnC+oiI8fWpB3sYS95ITCmIss6IyRdKsHluTXINkGuTcPLXt /nOkbXExWurUdksNsHVHin7d+mlu00PGEdplcS1+GqhjjZ8OtvewBp/7Sm1UggbrhZ3q nE7KP+vyIW7Uejuybg6KiZNsU5Rb85H5hwjLNK2nGmtCsd57eFArsC1DaxHSECGMYt1p Guu24o42dbd3i8hIe2Ql++aFiHrxCR+vC3HEjNcZA5swI6ppmjXb+e3zFuCxZXOj8Qhq x+aw== 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=tkJ6vBaz3G5IwdB8Lg8ppojVTnQOkfwjYi/pmtrKvtY=; b=F7+zCJQnnxP5kCB1sgGm36kNL5gHHONrfpeuZGBIioYpoheKT/O3xQHz7bKTDrhNHr oj52C+z8eTnUEgrA+6wPXhKwyTuhMhX4pB7+hyONOv7e017fPw2qcxaTGpWPuSmk7AUR tdoP6A0/A6r7pwKnWHrbHCFJ8kdHjTSgVn68th4oEa5TyHpjDOFQ/9QiQqG/tvZsqQSc Udq/mVZzoGCrmaBDkrfrj32jYfvVLTQecgV3eXK9Xw8oj9uYrdzzQmZ4n3jUmCrQkAIa FkUZ0HFkC9nne+6A9pBlxl46j7gV++PcJlcV4rndXMPhsO54864RPE9Y3HGNHL7XHUdE 8ZTQ== X-Gm-Message-State: AOAM5333Wtkv4/+83kkCKBsEdApuMPRyqpu6d2nZA9VDbFChcZ2cvQtI MqxkKdMfDnphlEiynhj8q8ODDA== X-Received: by 2002:a1c:2681:: with SMTP id m123mr3316003wmm.138.1602848915555; Fri, 16 Oct 2020 04:48:35 -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 24sm2467947wmg.8.2020.10.16.04.48.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Oct 2020 04:48:34 -0700 (PDT) Subject: Re: [PATCH v2 0/3] Clarify abstract scale usage for power values in Energy Model, EAS and IPA To: "Rafael J. Wysocki" Cc: 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 , Quentin Perret , Doug Anderson , Matthias Kaehlcke , "Nayak, Rajendra" References: <20201002114426.31277-1-lukasz.luba@arm.com> <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> From: Daniel Lezcano Message-ID: Date: Fri, 16 Oct 2020 13:48:33 +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: 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 15/10/2020 15:40, Rafael J. Wysocki wrote: > On Thu, Oct 15, 2020 at 12:22 PM Daniel Lezcano > wrote: [ ... ] >>> We would allow to co-exist em_dev_register_perf_domain(..., false) >>> with dev_pm_opp_of_register_em() EM devices. >>> >>> Is it make sense? >> >> Well, it does not change my opinion. We should assume the energy model >> is always milliwatts. If the SoC vendors find a way to get around with >> bogoWatts, then good to them and up to them to deal with in the future. > > That sounds fair enough, but it also means that any kernel patches > using power units different from milliwatts for the EM should be > rejected in the future, doesn't it? Actually there are two things: the units and the numbers. The energy model is expressed in mW. All the frameworks (EAS, IPA, hopefully DTPM) using the energy model should stick to the same unit, which I believe makes sense. The numbers are provided by the SoC vendor or any contributors [1][2]. The different frameworks depends on those numbers. If we specify in the documentation we support abstract numbers for the EM, then that will imply any framework using it will have to comply with that. My point is we use milliwatts as a reference. If we want to support abstract values, then the code should be changed by *explicitly* use with these values, so if the other frameworks are expecting real watts, they can detect they are not available and take another action, like the scmi scaled power numbers and the sustainable-power of the thermal which are incompatible. If the consistency across the frameworks is guarantee by identifying the kind of values (abstract or real), then we can put in the documentation we support abstract value. Unfortunately, IIUC, scmi does not tell us if the power numbers are real or abstract ... :/ I don't see how we can ensure a consistency across the framework without enforcing a strong policy. > And the existing code using different power units for the EM (if any) > should be updated/fixed accordingly, shouldn't it? Currently, the power units are expressed in mwatts for the energy model and the frameworks using it. AFAICT, no change is needed if we keep mW. If we use scaled numbers, the EAS will work correctly (but the energy values will be incorrect), but other frameworks won't. The power numbers are provided by the DT (as supposed real), or by SCMI (real or abstract). 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. -- Daniel [1] https://patchwork.kernel.org/project/linux-arm-kernel/patch/1500974575-2244-1-git-send-email-wxt@rock-chips.com/ [2] https://patchwork.kernel.org/project/linux-arm-kernel/patch/20190604165802.7338-2-daniel.lezcano@linaro.org/#22686211 -- Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog