Re: [RESEND PATCH 4/5] cpufreq: qcom-cpufreq-nvmem: Rename qcs404 data to cpr_genpd

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 29, 2022 at 02:03:02PM +0100, Bryan O'Donoghue wrote:
> At the moment the CPR genpd based code is named after the qcs404 however
> msm8936, msm8939 and other antecedent processors of the qcs404 can also
> make use of this data.
> 
> Rename it to reflect a more generic use.
> 
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@xxxxxxxxxx>

There is another power domain that needs to be scaled together with the
CPU frequency on MSM8916 and MSM8939: (VDD)MX. How do you handle that?

In downstream this is part of the CPR driver and specified as follows:

	qcom,vdd-mx-corner-map = <4 5 7>;
	qcom,vdd-mx-vmin-method = <4>;
	vdd-mx-supply = <&pm8916_l3_corner_ao>;
	qcom,vdd-mx-vmax = <7>;
	qcom,cpr-corner-map = <1 1 2 2 3 3 3 3 3>; /* MSM8916 */
	qcom,cpr-corner-map = <1 1 1 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3
			       3 3 3 3 3 3 3 3>; /* MSM8939 */

On MSM8916 this means to vote for MX corner 4 (&rpmpd_opp_svs_soc) for
the first two frequencies, then corner 5 (&rpmpd_opp_nominal) and corner 7
(&rpmpd_opp_super_turbo) for the remaining CPU frequencies. It's similar
for MSM8939, you just have more OPPs there.

There was a semi-related discussion about this in [1] (a bit mixed with
potential ways how to do CPU frequency scaling without CPR). It's been a
while but I think the conclusion back then was that it's easiest to
attach both "mx" and "cpr" in this driver and then scale it as part of
the OPP table.

[1]: https://lore.kernel.org/linux-arm-msm/20200403013119.GB20625@xxxxxxxxxxx/

I'll attach an excerpt of the changes that I used on MSM8916 at the end
of the mail. Note that it does not actually work as-is: IIRC at the
moment there is still nothing that actually enables the power domains
listed for CPUs. The CPR driver does not check that, but rpmpd does and
just ignores the votes.

I submitted a possible patch for this but it just got stuck at some
point because of all the complexity involved:
https://lore.kernel.org/linux-pm/20200826093328.88268-1-stephan@xxxxxxxxxxx/

Shortly said: I think you do not just want "cpr" here but also "mx".

Thanks,
Stephan

static const char *msm8916_genpd_names[] = { "mx", "cpr", NULL };

cpu@0 {
	power-domains = <&CPU_PD0>, <&rpmpd MSM8916_VDDMX_AO>, <&cpr>;
	power-domain-names = "psci", "mx", "cpr";
};

cpu_opp_table: cpu-opp-table {
	compatible = "operating-points-v2-kryo-cpu";
	opp-shared;

	opp-200000000 {
		opp-hz = /bits/ 64 <200000000>;
		required-opps = <&rpmpd_opp_svs_soc>, <&cpr_opp1>;
	};
	opp-400000000 {
		opp-hz = /bits/ 64 <400000000>;
		required-opps = <&rpmpd_opp_svs_soc>, <&cpr_opp2>;
	};
	opp-533333000 {
		opp-hz = /bits/ 64 <533333000>;
		required-opps = <&rpmpd_opp_nominal>, <&cpr_opp3>;
	};
	opp-800000000 {
		opp-hz = /bits/ 64 <800000000>;
		required-opps = <&rpmpd_opp_nominal>, <&cpr_opp4>;
	};
	opp-998400000 {
		opp-hz = /bits/ 64 <998400000>;
		required-opps = <&rpmpd_opp_super_turbo>, <&cpr_opp5>;
	};
	opp-1094400000 {
		opp-hz = /bits/ 64 <1094400000>;
		required-opps = <&rpmpd_opp_super_turbo>, <&cpr_opp6>;
	};
	opp-1152000000 {
		opp-hz = /bits/ 64 <1152000000>;
		required-opps = <&rpmpd_opp_super_turbo>, <&cpr_opp7>;
	};
	opp-1209600000 {
		opp-hz = /bits/ 64 <1209600000>;
		required-opps = <&rpmpd_opp_super_turbo>, <&cpr_opp8>;
	};
	opp-1363200000 {
		opp-hz = /bits/ 64 <1363200000>;
		required-opps = <&rpmpd_opp_super_turbo>, <&cpr_opp9>;
	};
};



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux