Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp7840388rdb; Thu, 4 Jan 2024 09:12:19 -0800 (PST) X-Google-Smtp-Source: AGHT+IE0gisMTz4eUf96YDw/J910OBCMaGvLnNlV6JJxneCmm22KMlA0zKsjbRPSJdXDHGwI57/5 X-Received: by 2002:a05:622a:181b:b0:427:e961:a750 with SMTP id t27-20020a05622a181b00b00427e961a750mr1010799qtc.96.1704388338890; Thu, 04 Jan 2024 09:12:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704388338; cv=none; d=google.com; s=arc-20160816; b=0MP1sWUK9P/Mkq019wsqt58cMrrMmus1hwGFMccKmWdGGK1ue2nVe8BdgYbHEEYkU5 qcG4y9r9Yxe5T+nU+t8DJz19ZHHfTIShGF3NUOZp02LCbtN1qemR9xdhkybgdMetAS6k 0rRhqrlgqz9KXPY51Hh/7SqFg1igiAlBofmUEZ83ivu2ruPHH/LEk3hw1aJL44YXP9gq hOmVD9hOb/uTDxf2I5et4iv13IG+W+phG2PYdPl20gfOh2S0Y9g1scbtUGtmZmHKvZr0 A6DAT0gLwildU3rE66l6vBhf1oBPh40gAMH5GbuPfx8/jDwMybzGkq56l/RQHiwupD7i ZBwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id; bh=rj3zCpoJU0Jy0EH7O86LdfcnrgTNGIoIZ3vT2CrWqyM=; fh=7ruhoLg78PU3fep4tA8Zk5mJXuFerKP8OTq0Ur/uLhY=; b=uGf1/N4UpHa0Z7hkHbY/SS6iZsmxU26S0Q2lrYe3frKYyHwOOZoLXyuiaEPXP0q8cc INf6cCoBQ0/c4Ths/nYrGeHtaIDDm+gzq/pYl5SlXxLyTaQYOGlhCMcSZXzI7rlATZBS S0zfzUyGezs2J+8QHeDB74LxVXxvMxRzZ3IzvnV+NFRrmEcNj95lc2Nga12vZO4tJM7o 3JFEN+K9C4uKdS8iDoypqQPclb+RHVY4ayXC92hp5RW44Qv4DPfTbDPdsPGFJj+IqV1x UgzxZIUpp/jqWdby7P+EJN0e5C1CiR7sVkrHbsHkIkSTGG5Q2VCGmmZvPvDAH+EgJER1 GoCg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-16989-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-16989-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id f9-20020a05622a114900b00428131e3ef4si12315200qty.108.2024.01.04.09.12.18 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Jan 2024 09:12:18 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-16989-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-16989-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-16989-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id A253B1C211BE for ; Thu, 4 Jan 2024 17:12:18 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 55DED2557A; Thu, 4 Jan 2024 17:12:10 +0000 (UTC) X-Original-To: linux-kernel@vger.kernel.org Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1A5DE2556C; Thu, 4 Jan 2024 17:12:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com 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 3805BC15; Thu, 4 Jan 2024 09:12:53 -0800 (PST) Received: from [192.168.178.6] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E29513F64C; Thu, 4 Jan 2024 09:12:04 -0800 (PST) Message-ID: Date: Thu, 4 Jan 2024 18:11:56 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] OPP: Add API to update EM after adjustment of voltage for OPPs To: Lukasz Luba , Viresh Kumar Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, sboyd@kernel.org, nm@ti.com, linux-samsung-soc@vger.kernel.org, daniel.lezcano@linaro.org, rafael@kernel.org, krzysztof.kozlowski@linaro.org, alim.akhtar@samsung.com, m.szyprowski@samsung.com, xuewen.yan94@gmail.com, mhiramat@kernel.org, qyousef@layalina.io, wvw@google.com References: <20231220110339.1065505-1-lukasz.luba@arm.com> <20231220110339.1065505-2-lukasz.luba@arm.com> <20231226051228.oe7rpgf34nwgr5ah@vireshk-i7> <9c1fa923-403f-4c98-b03e-37e467366284@arm.com> Content-Language: en-US From: Dietmar Eggemann In-Reply-To: <9c1fa923-403f-4c98-b03e-37e467366284@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 04/01/2024 11:38, Lukasz Luba wrote: > Hi Viresh, > > On 12/26/23 05:12, Viresh Kumar wrote: >> On 20-12-23, 11:03, Lukasz Luba wrote: >>> There are device drivers which can modify voltage values for OPPs. It >>> could be due to the chip binning and those drivers have specific chip >>> knowledge about this. This adjustment can happen after Energy Model is >>> registered, thus EM can have stale data about power. >>> >>> Introduce new API function which can be used by device driver which >>> adjusted the voltage for OPPs. The implementation takes care about >>> calculating needed internal details in the new EM table ('cost' field). >>> It plugs in the new EM table to the framework so other subsystems would >>> use the correct data. >>> >>> Signed-off-by: Lukasz Luba >>> --- >>>   drivers/opp/of.c       | 69 ++++++++++++++++++++++++++++++++++++++++++ >>>   include/linux/pm_opp.h |  6 ++++ >>>   2 files changed, 75 insertions(+) >>> >>> diff --git a/drivers/opp/of.c b/drivers/opp/of.c >>> index 81fa27599d58..992434c0b711 100644 >>> --- a/drivers/opp/of.c >>> +++ b/drivers/opp/of.c >>> @@ -1596,3 +1596,72 @@ int dev_pm_opp_of_register_em(struct device >>> *dev, struct cpumask *cpus) >>>       return ret; >>>   } >>>   EXPORT_SYMBOL_GPL(dev_pm_opp_of_register_em); >>> + >>> +/** >>> + * dev_pm_opp_of_update_em() - Update Energy Model with new power >>> values >>> + * @dev        : Device for which an Energy Model has to be registered >>> + * >>> + * This uses the "dynamic-power-coefficient" devicetree property to >>> calculate >>> + * power values for EM. It uses the new adjusted voltage values >>> known for OPPs >>> + * which have changed after boot. >>> + */ >>> +int dev_pm_opp_of_update_em(struct device *dev) >> >> I don't see anything OPP or OF related in this function, I don't think >> it needs >> to be part of the OPP core. You just want to reuse _get_power() I >> guess, which >> can be exported then. >> >> This should really be part of the EM core instead. >> > > Thank you for having a look at this. OK, that makes sense. > When I finish the EM runtime modification core features and get them > merged, I'll continue to work on this patch set. I'll try to follow > your comment here and export that function (with a different name > probably). Just to make sure: If this is the case then you could also add em_dev_compute_costs() with this new patch instead providing it with the 'Introduce runtime modifiable Energy Model' patch-set? This would keep dev_pm_opp_of_update_em() and em_dev_compute_costs() together. IIRC, all the other new EM interfaces you already use with your 'modifiable EM' use case: '[PATCH v5 14/23] PM: EM: Support late CPUs booting and capacity adjustment'.