On Thu, Jun 30, 2022 at 05:05:59AM +0100, Bryan O'Donoghue wrote: > On 29/06/2022 20:11, Stephan Gerhold wrote: > > 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? > > > > Short answer, in another series to enable CPR on 5.x > > We have code for CPR in a 4.19 tree that works but, it needs more work to be > upstream-fit on 5.x. > > CPR is deliberately omitted here to be submitted later. > I agree with this decision (doing CPR properly is way too complicated to block the entire msm8939.dtsi with this). > In this series I'm just switching away from the default cpufreq-dt-platdev > which breaks booting to qcom-cpufreq-nvmem. > > Fair enough ? ... but then I don't understand: Why do you need this patch set? You only need to attach the "cpr" power domain in qcom-cpufreq-nvmem if you're actually using CPR. I would recommend adding MSM8939 in a similar way to MSM8916, so without using qcom-cpufreq-nvmem for now. Then we can add CPR on both platforms in a similar way later. Thanks, Stephan
