From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1A4D11C680; Wed, 20 Dec 2023 07:56:15 +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 E9CDF1FB; Tue, 19 Dec 2023 23:56:59 -0800 (PST) Received: from [10.57.82.217] (unknown [10.57.82.217]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D23B13F64C; Tue, 19 Dec 2023 23:56:12 -0800 (PST) Message-ID: <930c762f-518a-420e-8da5-54c5ab1bf578@arm.com> Date: Wed, 20 Dec 2023 07:57:19 +0000 Precedence: bulk X-Mailing-List: linux-pm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 23/23] Documentation: EM: Update with runtime modification design Content-Language: en-US To: Xuewen Yan Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, rafael@kernel.org, dietmar.eggemann@arm.com, rui.zhang@intel.com, amit.kucheria@verdurent.com, amit.kachhap@gmail.com, daniel.lezcano@linaro.org, viresh.kumar@linaro.org, len.brown@intel.com, pavel@ucw.cz, mhiramat@kernel.org, qyousef@layalina.io, wvw@google.com References: <20231129110853.94344-1-lukasz.luba@arm.com> <20231129110853.94344-24-lukasz.luba@arm.com> From: Lukasz Luba In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/20/23 02:08, Xuewen Yan wrote: > On Tue, Dec 19, 2023 at 5:31 PM Lukasz Luba wrote: >> >> >> >> On 12/19/23 06:22, Xuewen Yan wrote: >>> Hi Lukasz, >>> >>> On Wed, Nov 29, 2023 at 7:11 PM Lukasz Luba wrote: >> >> [snip] >> >>>> + >>>> + -> drivers/soc/example/example_em_mod.c >>>> + >>>> + 01 static void foo_get_new_em(struct device *dev) >>> >>> Because now some drivers use the dev_pm_opp_of_register_em() to >>> register energy model, >>> and maybe we can add a new function to update the energy model using >>> "EM_SET_ACTIVE_POWER_CB(em_cb, cb)" >>> instead of letting users set power again? >>> >> >> There are different usage of this EM feature: >> 1. Adjust power values after boot is finish and e.g. ASV in Exynos >> has adjusted new voltage values in the OPP framework. It's >> due to chip binning. I have described that in conversation >> below patch 22/23. I'm going to send a patch for that >> platform and OPP fwk later as a follow up to this series. > > I understand what you mean, what I mean is that if we can provide an > interface for changing EM of opp fwk, it will be more friendly for > those users who use opp, because then they don't have to calculate the > new EM by themselves, but only need After updating the voltage of opp, > just call this interface directly. It is the plan. Don't worry. I didn't wanted to push this in one big patch set. Exynos driver + the OPP change would do exactly this. The EM functions from drivers/opp/of.c will be re-used for this. It is too big to be made in one step. There is pattern in those more complex changes, like in Arm SCMI fwk to make the improvements gradually. This folds into the same bucket. Although, you are another person asking for similar thing, so I will send a follow-up change using this new EM API - instead of waiting to finish this review. Thanks, Lukasz