diff options
Diffstat (limited to 'arch/arm64/boot/dts/arm/juno-base.dtsi')
| -rw-r--r-- | arch/arm64/boot/dts/arm/juno-base.dtsi | 36 |
1 files changed, 36 insertions, 0 deletions
diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi index d2bf12d44ac6..b3729dfa7743 100644 --- a/arch/arm64/boot/dts/arm/juno-base.dtsi +++ b/arch/arm64/boot/dts/arm/juno-base.dtsi @@ -677,6 +677,42 @@ interrupt-names = "JOB", "MMU", "GPU"; clocks = <&scmi_dvfs 2>; power-domains = <&scmi_devpd 9>; + power_model { + compatible = "arm,mali-simple-power-model"; + voltage = <800>; + frequency = <500>; + static-power = <500>; + dynamic-power = <1500>; + ts = <20000 2000 (-20) 2>; + /* + * We can't have a proper GPU thermal zone because Juno + * r1 & r2 have two sensors which Linux doesn't support + * yet, and for r0 there isn't a separate sensor. + * + * We also can't create a GPU thermal zone that reuses + * the SoC sensor because of another limitation in Linux + * code that prevents sensors being used for more that + * one zone. + * + * Warning for the future: Mali contains very dubious + * code for setting up OPPs which does a global search + * of device-tree for a node called "gpu" and expects + * this to be the Mali device. So if we do the natural + * thing for a GPU thermal zone and call that node "gpu" + * then Mali OPP code will go horribly wrong. We should + * therefore call it something different or fix Mali + * code to not be so lame. + * + * With all the above in mind, we will assign here the + * GPU to the to the SoC thermal zone and hope that + * there's no recursive deadlocks that can occur. E.g. + * SoC cooling triggers Mali devfreq cooling and because + * that is in the SoC thermal zone it tries to + * recursively trigger cooling on the SoC zone. + * (This doesn't appear to happen). + */ + thermal-zone = "soc"; + }; }; smb@08000000 { |