On Thu, 30 Mar 2023 at 14:16, Konrad Dybcio <konrad.dybcio@xxxxxxxxxx> wrote: > > > > On 30.03.2023 13:15, Dmitry Baryshkov wrote: > > On 30/03/2023 14:06, Konrad Dybcio wrote: > >> > >> > >> On 30.03.2023 00:24, Dmitry Baryshkov wrote: > >>> Konrad brought up the topic of scaling the MX domain according to the > >>> OPP changes. Here is my RFC for this functionality. I post it as an RFC > >>> for two reasons: > >>> > >>> 1) I'm not sure that we should scale MX if we are not scaling main > >>> voltage following the CPR3 > >> It should be ok, however.. > >>> > >> [...] > >> > >>> Dmitry Baryshkov (3): > >>> dt-bindings: display/msm/gpu: allow specifying MX domain A5xx > >>> drm/msm/a5xx: scale MX domain following the frequncy changes > >> This is a stopgap solution, CPR is a child of MX. > > > > Not so sure here. Vendor kernel scales voltages and MX levels separately. Moreover, please correct me if I'm wrong here, the kernel doesn't scale VDD_GFX directly. It programs GPMU's voltage table and then GPMU handles voltage scaling according to performance levels being set. MX is handled in parallel to switching GPMU's level. > > > > I have implemented this voltage scaling locally, just need to run more tests before posting (and unfortunately it depends either on CPR3+GFX or on programming the voltages manually). > Oh no.. I forgot about the ugly goblin that we call GPMU.. I'll have > to dig into it further. Thanks for reminding me.. Let me send the fixed voltage table programming (probably on Friday). > > Konrad > > > >> > >> Konrad > >>> arm64: dts: qcom: specify power domains for the GPU > >>> > >>> .../devicetree/bindings/display/msm/gpu.yaml | 9 +++- > >>> arch/arm64/boot/dts/qcom/msm8996.dtsi | 14 ++++- > >>> drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 52 +++++++++++++++++++ > >>> drivers/gpu/drm/msm/adreno/a5xx_gpu.h | 3 ++ > >>> 4 files changed, 76 insertions(+), 2 deletions(-) > >>> > > -- With best wishes Dmitry
