Re: [RFC PATCH 0/4] Support for passing runtime state idle time to TF-A

From: Lukasz Luba <lukasz.luba@arm.com>
To: Sowjanya Komatineni <skomatineni@nvidia.com>
Cc: sudeep.holla@arm.com, souvik.chakravarty@arm.com,
	thierry.reding@gmail.com, mark.rutland@arm.com,
	lorenzo.pieralisi@arm.com, daniel.lezcano@linaro.org,
	robh+dt@kernel.org, jonathanh@nvidia.com, ksitaraman@nvidia.com,
	sanjayc@nvidia.com, linux-arm-kernel@lists.infradead.org,
	linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-pm@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [RFC PATCH 0/4] Support for passing runtime state idle time to TF-A
Date: Fri, 23 Apr 2021 21:16:57 +0100	[thread overview]
Message-ID: <064341f7-dce3-5ad4-e69b-9568115035c1@arm.com> (raw)
In-Reply-To: <1619123448-10138-1-git-send-email-skomatineni@nvidia.com>

Hi Sowjanya,

On 4/22/21 9:30 PM, Sowjanya Komatineni wrote:
> Tegra194 and Tegra186 platforms use separate MCE firmware for CPUs which is
> in charge of deciding on state transition based on target state, state idle
> time, and some other Tegra CPU core cluster states information.
> 
> Current PSCI specification don't have function defined for passing runtime
> state idle time predicted by governor (based on next events and state target
> residency) to ARM trusted firmware.

Do you have some numbers from experiments showing that these idle
governor prediction values, which are passed from kernel to MCE
firmware, are making a good 'guess'?
How much precision (1us? 1ms?) in the values do you need there?

IIRC (probably Rafael's presentations) predicting in the kernel
something like CPU idle time residency is not a trivial thing.

Another idea (depending on DT structure and PSCI bits):
Could this be solved differently, but just having a knowledge that if
the governor requested some C-state, this means governor 'predicted'
an idle residency to be greater that min_residency attached to this
C-state?
Then, when that request shows up in your FW, you know that it must be at
least min_residency because of this C-state id.
It would depend on number of available states, max_residency, scale
that you would choose while assigning values from [0, max_residency]
to each state.
IIRC there can be many state IDs for idle, so it would depend on
number of bits encoding this state, and your needs. Example of
linear scale:
4-bits encoding idle state and max predicted residency 10msec,
that means 10000us / 16 states = 625us/state.
The max_residency might be split differently, using different than
linear function, to have some rage more precised.

Open question is if these idle states must be all represented
in DT, or there is a way of describing a 'set of idle states'
automatically.

Regards,
Lukasz