Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit d57d3943 authored by Linus Torvalds's avatar Linus Torvalds
Browse files
Pull power management updates from Rafael Wysocki:
 "The majority of changes go into the cpufreq subsystem this time.

  To me, quite obviously, the biggest ticket item is the new "schedutil"
  governor.  Interestingly enough, it's the first new cpufreq governor
  since the beginning of the git era (except for some out-of-the-tree
  ones).

  There are two main differences between it and the existing governors.
  First, it uses the information provided by the scheduler directly for
  making its decisions, so it doesn't have to track anything by itself.
  Second, it can invoke drivers (supporting that feature) to adjust CPU
  performance right away without having to spawn work items to be
  executed in process context or similar.  Currently, the acpi-cpufreq
  driver is the only one supporting that mode of operation, but then it
  is used on a large number of systems.

  The "schedutil" governor as included here is very simple and mostly
  regarded as a foundation for future work on the integration of the
  scheduler with CPU power management (in fact, there is work in
  progress on top of it already).  Nevertheless it works and the
  preliminary results obtained with it are encouraging.

  There also is some consolidation of CPU frequency management for ARM
  platforms that can add their machine IDs the the new stub dt-platdev
  driver now and that will take care of creating the requisite platform
  device for cpufreq-dt, so it is not necessary to do that in platform
  code any more.  Several ARM platforms are switched over to using this
  generic mechanism.

  In addition to that, the intel_pstate driver is now going to respect
  CPU frequency limits set by the platform firmware (or a BMC) and
  provided via the ACPI _PPC object.

  The devfreq subsystem is getting a new "passive" governor for SoCs
  subsystems that will depend on somebody else to manage their voltage
  rails and its support for Samsung Exynos SoCs is consolidated.

  The rest is support for new hardware (Intel Broxton support in
  intel_idle for one example), bug fixes, optimizations and cleanups in
  a number of places.

  Specifics:

   - New cpufreq "schedutil" governor (making decisions based on CPU
     utilization information provided by the scheduler and capable of
     switching CPU frequencies right away if the underlying driver
     supports that) and support for fast frequency switching in the
     acpi-cpufreq driver (Rafael Wysocki)

   - Consolidation of CPU frequency management on ARM platforms allowing
     them to get rid of some platform-specific boilerplate code if they
     are going to use the cpufreq-dt driver (Viresh Kumar, Finley Xiao,
     Marc Gonzalez)

   - Support for ACPI _PPC and CPU frequency limits in the intel_pstate
     driver (Srinivas Pandruvada)

   - Fixes and cleanups in the cpufreq core and generic governor code
     (Rafael Wysocki, Sai Gurrappadi)

   - intel_pstate driver optimizations and cleanups (Rafael Wysocki,
     Philippe Longepe, Chen Yu, Joe Perches)

   - cpufreq powernv driver fixes and cleanups (Akshay Adiga, Shilpasri
     Bhat)

   - cpufreq qoriq driver fixes and cleanups (Jia Hongtao)

   - ACPI cpufreq driver cleanups (Viresh Kumar)

   - Assorted cpufreq driver updates (Ashwin Chaugule, Geliang Tang,
     Javier Martinez Canillas, Paul Gortmaker, Sudeep Holla)

   - Assorted cpufreq fixes and cleanups (Joe Perches, Arnd Bergmann)

   - Fixes and cleanups in the OPP (Operating Performance Points)
     framework, mostly related to OPP sharing, and reorganization of
     OF-dependent code in it (Viresh Kumar, Arnd Bergmann, Sudeep Holla)

   - New "passive" governor for devfreq (for SoC subsystems that will
     rely on someone else for the management of their power resources)
     and consolidation of devfreq support for Exynos platforms, coding
     style and typo fixes for devfreq (Chanwoo Choi, MyungJoo Ham)

   - PM core fixes and cleanups, mostly to make it work better with the
     generic power domains (genpd) framework, and updates for that
     framework (Ulf Hansson, Thierry Reding, Colin Ian King)

   - Intel Broxton support for the intel_idle driver (Len Brown)

   - cpuidle core optimization and fix (Daniel Lezcano, Dave Gerlach)

   - ARM cpuidle cleanups (Jisheng Zhang)

   - Intel Kabylake support for the RAPL power capping driver (Jacob
     Pan)

   - AVS (Adaptive Voltage Switching) rockchip-io driver update (Heiko
     Stuebner)

   - Updates for the cpupower tool (Arjun Sreedharan, Colin Ian King,
     Mattia Dongili, Thomas Renninger)"

* tag 'pm-4.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (112 commits)
  intel_pstate: Clean up get_target_pstate_use_performance()
  intel_pstate: Use sample.core_avg_perf in get_avg_pstate()
  intel_pstate: Clarify average performance computation
  intel_pstate: Avoid unnecessary synchronize_sched() during initialization
  cpufreq: schedutil: Make default depend on CONFIG_SMP
  cpufreq: powernv: del_timer_sync when global and local pstate are equal
  cpufreq: powernv: Move smp_call_function_any() out of irq safe block
  intel_pstate: Clean up intel_pstate_get()
  cpufreq: schedutil: Make it depend on CONFIG_SMP
  cpufreq: governor: Fix handling of special cases in dbs_update()
  PM / OPP: Move CONFIG_OF dependent code in a separate file
  cpufreq: intel_pstate: Ignore _PPC processing under HWP
  cpufreq: arm_big_little: use generic OPP functions for {init, free}_opp_table
  PM / OPP: add non-OF versions of dev_pm_opp_{cpumask_, }remove_table
  cpufreq: tango: Use generic platdev driver
  PM / OPP: pass cpumask by reference
  cpufreq: Fix GOV_LIMITS handling for the userspace governor
  cpupower: fix potential memory leak
  PM / devfreq: style/typo fixes
  PM / devfreq: exynos: Add the detailed correlation for Exynos5422 bus
  ..
parents 3e21e5dd 27c4a1c5
Loading
Loading
Loading
Loading
+26 −0
Original line number Diff line number Diff line

* Samsung Exynos NoC (Network on Chip) Probe device

The Samsung Exynos542x SoC has NoC (Network on Chip) Probe for NoC bus.
NoC provides the primitive values to get the performance data. The packets
that the Network on Chip (NoC) probes detects are transported over
the network infrastructure to observer units. You can configure probes to
capture packets with header or data on the data request response network,
or as traffic debug or statistic collectors. Exynos542x bus has multiple
NoC probes to provide bandwidth information about behavior of the SoC
that you can use while analyzing system performance.

Required properties:
- compatible: Should be "samsung,exynos5420-nocp"
- reg: physical base address of each NoC Probe and length of memory mapped region.

Optional properties:
- clock-names : the name of clock used by the NoC Probe, "nocp"
- clocks : phandles for clock specified in "clock-names" property

Example : NoC Probe nodes in Device Tree are listed below.

	nocp_mem0_0: nocp@10CA1000 {
		compatible = "samsung,exynos5420-nocp";
		reg = <0x10CA1000 0x200>;
	};
+409 −0
Original line number Diff line number Diff line
* Generic Exynos Bus frequency device

The Samsung Exynos SoC has many buses for data transfer between DRAM
and sub-blocks in SoC. Most Exynos SoCs share the common architecture
for buses. Generally, each bus of Exynos SoC includes a source clock
and a power line, which are able to change the clock frequency
of the bus in runtime. To monitor the usage of each bus in runtime,
the driver uses the PPMU (Platform Performance Monitoring Unit), which
is able to measure the current load of sub-blocks.

The Exynos SoC includes the various sub-blocks which have the each AXI bus.
The each AXI bus has the owned source clock but, has not the only owned
power line. The power line might be shared among one more sub-blocks.
So, we can divide into two type of device as the role of each sub-block.
There are two type of bus devices as following:
- parent bus device
- passive bus device

Basically, parent and passive bus device share the same power line.
The parent bus device can only change the voltage of shared power line
and the rest bus devices (passive bus device) depend on the decision of
the parent bus device. If there are three blocks which share the VDD_xxx
power line, Only one block should be parent device and then the rest blocks
should depend on the parent device as passive device.

	VDD_xxx |--- A block (parent)
		|--- B block (passive)
		|--- C block (passive)

There are a little different composition among Exynos SoC because each Exynos
SoC has different sub-blocks. Therefore, such difference should be specified
in devicetree file instead of each device driver. In result, this driver
is able to support the bus frequency for all Exynos SoCs.

Required properties for all bus devices:
- compatible: Should be "samsung,exynos-bus".
- clock-names : the name of clock used by the bus, "bus".
- clocks : phandles for clock specified in "clock-names" property.
- operating-points-v2: the OPP table including frequency/voltage information
  to support DVFS (Dynamic Voltage/Frequency Scaling) feature.

Required properties only for parent bus device:
- vdd-supply: the regulator to provide the buses with the voltage.
- devfreq-events: the devfreq-event device to monitor the current utilization
  of buses.

Required properties only for passive bus device:
- devfreq: the parent bus device.

Optional properties only for parent bus device:
- exynos,saturation-ratio: the percentage value which is used to calibrate
			the performance count against total cycle count.
- exynos,voltage-tolerance: the percentage value for bus voltage tolerance
			which is used to calculate the max voltage.

Detailed correlation between sub-blocks and power line according to Exynos SoC:
- In case of Exynos3250, there are two power line as following:
	VDD_MIF |--- DMC

	VDD_INT |--- LEFTBUS (parent device)
		|--- PERIL
		|--- MFC
		|--- G3D
		|--- RIGHTBUS
		|--- PERIR
		|--- FSYS
		|--- LCD0
		|--- PERIR
		|--- ISP
		|--- CAM

- In case of Exynos4210, there is one power line as following:
	VDD_INT |--- DMC (parent device)
		|--- LEFTBUS
		|--- PERIL
		|--- MFC(L)
		|--- G3D
		|--- TV
		|--- LCD0
		|--- RIGHTBUS
		|--- PERIR
		|--- MFC(R)
		|--- CAM
		|--- FSYS
		|--- GPS
		|--- LCD0
		|--- LCD1

- In case of Exynos4x12, there are two power line as following:
	VDD_MIF |--- DMC

	VDD_INT |--- LEFTBUS (parent device)
		|--- PERIL
		|--- MFC(L)
		|--- G3D
		|--- TV
		|--- IMAGE
		|--- RIGHTBUS
		|--- PERIR
		|--- MFC(R)
		|--- CAM
		|--- FSYS
		|--- GPS
		|--- LCD0
		|--- ISP

- In case of Exynos5422, there are two power line as following:
	VDD_MIF |--- DREX 0 (parent device, DRAM EXpress controller)
	        |--- DREX 1

	VDD_INT |--- NoC_Core (parent device)
		|--- G2D
		|--- G3D
		|--- DISP1
		|--- NoC_WCORE
		|--- GSCL
		|--- MSCL
		|--- ISP
		|--- MFC
		|--- GEN
		|--- PERIS
		|--- PERIC
		|--- FSYS
		|--- FSYS2

Example1:
	Show the AXI buses of Exynos3250 SoC. Exynos3250 divides the buses to
	power line (regulator). The MIF (Memory Interface) AXI bus is used to
	transfer data between DRAM and CPU and uses the VDD_MIF regulator.

	- MIF (Memory Interface) block
	: VDD_MIF |--- DMC (Dynamic Memory Controller)

	- INT (Internal) block
	: VDD_INT |--- LEFTBUS (parent device)
		  |--- PERIL
		  |--- MFC
		  |--- G3D
		  |--- RIGHTBUS
		  |--- FSYS
		  |--- LCD0
		  |--- PERIR
		  |--- ISP
		  |--- CAM

	- MIF bus's frequency/voltage table
	-----------------------
	|Lv| Freq   | Voltage |
	-----------------------
	|L1| 50000  |800000   |
	|L2| 100000 |800000   |
	|L3| 134000 |800000   |
	|L4| 200000 |825000   |
	|L5| 400000 |875000   |
	-----------------------

	- INT bus's frequency/voltage table
	----------------------------------------------------------
	|Block|LEFTBUS|RIGHTBUS|MCUISP |ISP    |PERIL  ||VDD_INT |
	| name|       |LCD0    |       |       |       ||        |
	|     |       |FSYS    |       |       |       ||        |
	|     |       |MFC     |       |       |       ||        |
	----------------------------------------------------------
	|Mode |*parent|passive |passive|passive|passive||        |
	----------------------------------------------------------
	|Lv   |Frequency                               ||Voltage |
	----------------------------------------------------------
	|L1   |50000  |50000   |50000  |50000  |50000  ||900000  |
	|L2   |80000  |80000   |80000  |80000  |80000  ||900000  |
	|L3   |100000 |100000  |100000 |100000 |100000 ||1000000 |
	|L4   |134000 |134000  |200000 |200000 |       ||1000000 |
	|L5   |200000 |200000  |400000 |300000 |       ||1000000 |
	----------------------------------------------------------

Example2 :
	The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi
	is listed below:

	bus_dmc: bus_dmc {
		compatible = "samsung,exynos-bus";
		clocks = <&cmu_dmc CLK_DIV_DMC>;
		clock-names = "bus";
		operating-points-v2 = <&bus_dmc_opp_table>;
		status = "disabled";
	};

	bus_dmc_opp_table: opp_table1 {
		compatible = "operating-points-v2";
		opp-shared;

		opp@50000000 {
			opp-hz = /bits/ 64 <50000000>;
			opp-microvolt = <800000>;
		};
		opp@100000000 {
			opp-hz = /bits/ 64 <100000000>;
			opp-microvolt = <800000>;
		};
		opp@134000000 {
			opp-hz = /bits/ 64 <134000000>;
			opp-microvolt = <800000>;
		};
		opp@200000000 {
			opp-hz = /bits/ 64 <200000000>;
			opp-microvolt = <825000>;
		};
		opp@400000000 {
			opp-hz = /bits/ 64 <400000000>;
			opp-microvolt = <875000>;
		};
	};

	bus_leftbus: bus_leftbus {
		compatible = "samsung,exynos-bus";
		clocks = <&cmu CLK_DIV_GDL>;
		clock-names = "bus";
		operating-points-v2 = <&bus_leftbus_opp_table>;
		status = "disabled";
	};

	bus_rightbus: bus_rightbus {
		compatible = "samsung,exynos-bus";
		clocks = <&cmu CLK_DIV_GDR>;
		clock-names = "bus";
		operating-points-v2 = <&bus_leftbus_opp_table>;
		status = "disabled";
	};

	bus_lcd0: bus_lcd0 {
		compatible = "samsung,exynos-bus";
		clocks = <&cmu CLK_DIV_ACLK_160>;
		clock-names = "bus";
		operating-points-v2 = <&bus_leftbus_opp_table>;
		status = "disabled";
	};

	bus_fsys: bus_fsys {
		compatible = "samsung,exynos-bus";
		clocks = <&cmu CLK_DIV_ACLK_200>;
		clock-names = "bus";
		operating-points-v2 = <&bus_leftbus_opp_table>;
		status = "disabled";
	};

	bus_mcuisp: bus_mcuisp {
		compatible = "samsung,exynos-bus";
		clocks = <&cmu CLK_DIV_ACLK_400_MCUISP>;
		clock-names = "bus";
		operating-points-v2 = <&bus_mcuisp_opp_table>;
		status = "disabled";
	};

	bus_isp: bus_isp {
		compatible = "samsung,exynos-bus";
		clocks = <&cmu CLK_DIV_ACLK_266>;
		clock-names = "bus";
		operating-points-v2 = <&bus_isp_opp_table>;
		status = "disabled";
	};

	bus_peril: bus_peril {
		compatible = "samsung,exynos-bus";
		clocks = <&cmu CLK_DIV_ACLK_100>;
		clock-names = "bus";
		operating-points-v2 = <&bus_peril_opp_table>;
		status = "disabled";
	};

	bus_mfc: bus_mfc {
		compatible = "samsung,exynos-bus";
		clocks = <&cmu CLK_SCLK_MFC>;
		clock-names = "bus";
		operating-points-v2 = <&bus_leftbus_opp_table>;
		status = "disabled";
	};

	bus_leftbus_opp_table: opp_table1 {
		compatible = "operating-points-v2";
		opp-shared;

		opp@50000000 {
			opp-hz = /bits/ 64 <50000000>;
			opp-microvolt = <900000>;
		};
		opp@80000000 {
			opp-hz = /bits/ 64 <80000000>;
			opp-microvolt = <900000>;
		};
		opp@100000000 {
			opp-hz = /bits/ 64 <100000000>;
			opp-microvolt = <1000000>;
		};
		opp@134000000 {
			opp-hz = /bits/ 64 <134000000>;
			opp-microvolt = <1000000>;
		};
		opp@200000000 {
			opp-hz = /bits/ 64 <200000000>;
			opp-microvolt = <1000000>;
		};
	};

	bus_mcuisp_opp_table: opp_table2 {
		compatible = "operating-points-v2";
		opp-shared;

		opp@50000000 {
			opp-hz = /bits/ 64 <50000000>;
		};
		opp@80000000 {
			opp-hz = /bits/ 64 <80000000>;
		};
		opp@100000000 {
			opp-hz = /bits/ 64 <100000000>;
		};
		opp@200000000 {
			opp-hz = /bits/ 64 <200000000>;
		};
		opp@400000000 {
			opp-hz = /bits/ 64 <400000000>;
		};
	};

	bus_isp_opp_table: opp_table3 {
		compatible = "operating-points-v2";
		opp-shared;

		opp@50000000 {
			opp-hz = /bits/ 64 <50000000>;
		};
		opp@80000000 {
			opp-hz = /bits/ 64 <80000000>;
		};
		opp@100000000 {
			opp-hz = /bits/ 64 <100000000>;
		};
		opp@200000000 {
			opp-hz = /bits/ 64 <200000000>;
		};
		opp@300000000 {
			opp-hz = /bits/ 64 <300000000>;
		};
	};

	bus_peril_opp_table: opp_table4 {
		compatible = "operating-points-v2";
		opp-shared;

		opp@50000000 {
			opp-hz = /bits/ 64 <50000000>;
		};
		opp@80000000 {
			opp-hz = /bits/ 64 <80000000>;
		};
		opp@100000000 {
			opp-hz = /bits/ 64 <100000000>;
		};
	};


	Usage case to handle the frequency and voltage of bus on runtime
	in exynos3250-rinato.dts is listed below:

	&bus_dmc {
		devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
		vdd-supply = <&buck1_reg>;	/* VDD_MIF */
		status = "okay";
	};

	&bus_leftbus {
		devfreq-events = <&ppmu_leftbus_3>, <&ppmu_rightbus_3>;
		vdd-supply = <&buck3_reg>;
		status = "okay";
	};

	&bus_rightbus {
		devfreq = <&bus_leftbus>;
		status = "okay";
	};

	&bus_lcd0 {
		devfreq = <&bus_leftbus>;
		status = "okay";
	};

	&bus_fsys {
		devfreq = <&bus_leftbus>;
		status = "okay";
	};

	&bus_mcuisp {
		devfreq = <&bus_leftbus>;
		status = "okay";
	};

	&bus_isp {
		devfreq = <&bus_leftbus>;
		status = "okay";
	};

	&bus_peril {
		devfreq = <&bus_leftbus>;
		status = "okay";
	};

	&bus_mfc {
		devfreq = <&bus_leftbus>;
		status = "okay";
	};
+3 −1
Original line number Diff line number Diff line
@@ -37,8 +37,10 @@ Required properties:
  - "rockchip,rk3368-pmu-io-voltage-domain" for rk3368 pmu-domains
  - "rockchip,rk3399-io-voltage-domain" for rk3399
  - "rockchip,rk3399-pmu-io-voltage-domain" for rk3399 pmu-domains
- rockchip,grf: phandle to the syscon managing the "general register files"

Deprecated properties:
- rockchip,grf: phandle to the syscon managing the "general register files"
    Systems should move the io-domains to a sub-node of the grf simple-mfd.

You specify supplies using the standard regulator bindings by including
a phandle the relevant regulator.  All specified supplies must be able
+5 −0
Original line number Diff line number Diff line
@@ -1671,6 +1671,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
		hwp_only
			Only load intel_pstate on systems which support
			hardware P state control (HWP) if available.
		support_acpi_ppc
			Enforce ACPI _PPC performance limits. If the Fixed ACPI
			Description Table, specifies preferred power management
			profile as "Enterprise Server" or "Performance Server",
			then this feature is turned on by default.

	intremap=	[X86-64, Intel-IOMMU]
			on	enable Interrupt Remapping (default)
+10 −0
Original line number Diff line number Diff line
@@ -1322,6 +1322,7 @@ F: drivers/rtc/rtc-armada38x.c
F:	arch/arm/boot/dts/armada*
F:	arch/arm/boot/dts/kirkwood*
F:	arch/arm64/boot/dts/marvell/armada*
F:	drivers/cpufreq/mvebu-cpufreq.c


ARM/Marvell Berlin SoC support
@@ -3539,6 +3540,15 @@ F: drivers/devfreq/devfreq-event.c
F:	include/linux/devfreq-event.h
F:	Documentation/devicetree/bindings/devfreq/event/

BUS FREQUENCY DRIVER FOR SAMSUNG EXYNOS
M:	Chanwoo Choi <cw00.choi@samsung.com>
L:	linux-pm@vger.kernel.org
L:	linux-samsung-soc@vger.kernel.org
T:	git git://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git
S:	Maintained
F:	drivers/devfreq/exynos-bus.c
F:	Documentation/devicetree/bindings/devfreq/exynos-bus.txt

DEVICE NUMBER REGISTRY
M:	Torben Mathiasen <device@lanana.org>
W:	http://lanana.org/docs/device-list/index.html
Loading