Merge 4.12-rc5 into staging-next (7bf1e44f) · Commits · e / devices / android_kernel_fairphone_FP4

Documentation/acpi/acpi-lid.txt

+12 −4

Original line number	Original line	Diff line number	Diff line
	@@ -59,20 +59,28 @@ button driver uses the following 3 modes in order not to trigger issues.
	If the userspace hasn't been prepared to ignore the unreliable "opened"		If the userspace hasn't been prepared to ignore the unreliable "opened"
	events and the unreliable initial state notification, Linux users can use		events and the unreliable initial state notification, Linux users can use
	the following kernel parameters to handle the possible issues:		the following kernel parameters to handle the possible issues:
	A. button.lid_init_state=open:		A. button.lid_init_state=method:
			When this option is specified, the ACPI button driver reports the
			initial lid state using the returning value of the _LID control method
			and whether the "opened"/"closed" events are paired fully relies on the
			firmware implementation.
			This option can be used to fix some platforms where the returning value
			of the _LID control method is reliable but the initial lid state
			notification is missing.
			This option is the default behavior during the period the userspace
			isn't ready to handle the buggy AML tables.
			B. button.lid_init_state=open:
	When this option is specified, the ACPI button driver always reports the		When this option is specified, the ACPI button driver always reports the
	initial lid state as "opened" and whether the "opened"/"closed" events		initial lid state as "opened" and whether the "opened"/"closed" events
	are paired fully relies on the firmware implementation.		are paired fully relies on the firmware implementation.
	This may fix some platforms where the returning value of the _LID		This may fix some platforms where the returning value of the _LID
	control method is not reliable and the initial lid state notification is		control method is not reliable and the initial lid state notification is
	missing.		missing.
	This option is the default behavior during the period the userspace
	isn't ready to handle the buggy AML tables.

	If the userspace has been prepared to ignore the unreliable "opened" events		If the userspace has been prepared to ignore the unreliable "opened" events
	and the unreliable initial state notification, Linux users should always		and the unreliable initial state notification, Linux users should always
	use the following kernel parameter:		use the following kernel parameter:
	B. button.lid_init_state=ignore:		C. button.lid_init_state=ignore:
	When this option is specified, the ACPI button driver never reports the		When this option is specified, the ACPI button driver never reports the
	initial lid state and there is a compensation mechanism implemented to		initial lid state and there is a compensation mechanism implemented to
	ensure that the reliable "closed" notifications can always be delievered		ensure that the reliable "closed" notifications can always be delievered

Documentation/admin-guide/kernel-parameters.txt

+9 −0

Original line number	Original line	Diff line number	Diff line
	@@ -866,6 +866,15 @@

	dscc4.setup= [NET]		dscc4.setup= [NET]

			dt_cpu_ftrs= [PPC]
			Format: {"off" \| "known"}
			Control how the dt_cpu_ftrs device-tree binding is
			used for CPU feature discovery and setup (if it
			exists).
			off: Do not use it, fall back to legacy cpu table.
			known: Do not pass through unknown features to guests
			or userspace, only those that the kernel is aware of.

	dump_apple_properties [X86]		dump_apple_properties [X86]
	Dump name and content of EFI device properties on		Dump name and content of EFI device properties on
	x86 Macs. Useful for driver authors to determine		x86 Macs. Useful for driver authors to determine

Documentation/admin-guide/pm/cpufreq.rst

+10 −9

Documentation/admin-guide/pm/index.rst

+1 −0

Original line number	Original line	Diff line number	Diff line
	@@ -6,6 +6,7 @@ Power Management
	:maxdepth: 2		:maxdepth: 2

	cpufreq		cpufreq
			intel_pstate

	.. only:: subproject and html		.. only:: subproject and html

Documentation/admin-guide/pm/intel_pstate.rst

0 → 100644

+755 −0

File added.

Preview size limit exceeded, changes collapsed.

Original line number	Original line	Diff line number	Diff line
	.. \|struct cpufreq_policy\| replace:: :c:type:`struct cpufreq_policy <cpufreq_policy>`		.. \|struct cpufreq_policy\| replace:: :c:type:`struct cpufreq_policy <cpufreq_policy>`
			.. \|intel_pstate\| replace:: :doc:`intel_pstate <intel_pstate>`

	=======================		=======================
	CPU Performance Scaling		CPU Performance Scaling
	@@ -75,7 +76,7 @@ feedback registers, as that information is typically specific to the hardware
	interface it comes from and may not be easily represented in an abstract,		interface it comes from and may not be easily represented in an abstract,
	platform-independent way. For this reason, ``CPUFreq`` allows scaling drivers		platform-independent way. For this reason, ``CPUFreq`` allows scaling drivers
	to bypass the governor layer and implement their own performance scaling		to bypass the governor layer and implement their own performance scaling
	algorithms. That is done by the ``intel_pstate`` scaling driver.		algorithms. That is done by the \|intel_pstate\| scaling driver.


	``CPUFreq`` Policy Objects		``CPUFreq`` Policy Objects
	@@ -174,13 +175,13 @@ necessary to restart the scaling governor so that it can take the new online CPU
	into account. That is achieved by invoking the governor's ``->stop`` and		into account. That is achieved by invoking the governor's ``->stop`` and
	``->start()`` callbacks, in this order, for the entire policy.		``->start()`` callbacks, in this order, for the entire policy.

	As mentioned before, the ``intel_pstate`` scaling driver bypasses the scaling		As mentioned before, the \|intel_pstate\| scaling driver bypasses the scaling
	governor layer of ``CPUFreq`` and provides its own P-state selection algorithms.		governor layer of ``CPUFreq`` and provides its own P-state selection algorithms.
	Consequently, if ``intel_pstate`` is used, scaling governors are not attached to		Consequently, if \|intel_pstate\| is used, scaling governors are not attached to
	new policy objects. Instead, the driver's ``->setpolicy()`` callback is invoked		new policy objects. Instead, the driver's ``->setpolicy()`` callback is invoked
	to register per-CPU utilization update callbacks for each policy. These		to register per-CPU utilization update callbacks for each policy. These
	callbacks are invoked by the CPU scheduler in the same way as for scaling		callbacks are invoked by the CPU scheduler in the same way as for scaling
	governors, but in the ``intel_pstate`` case they both determine the P-state to		governors, but in the \|intel_pstate\| case they both determine the P-state to
	use and change the hardware configuration accordingly in one go from scheduler		use and change the hardware configuration accordingly in one go from scheduler
	context.		context.

	@@ -257,7 +258,7 @@ are the following:

	``scaling_available_governors``		``scaling_available_governors``
	List of ``CPUFreq`` scaling governors present in the kernel that can		List of ``CPUFreq`` scaling governors present in the kernel that can
	be attached to this policy or (if the ``intel_pstate`` scaling driver is		be attached to this policy or (if the \|intel_pstate\| scaling driver is
	in use) list of scaling algorithms provided by the driver that can be		in use) list of scaling algorithms provided by the driver that can be
	applied to this policy.		applied to this policy.

	@@ -274,7 +275,7 @@ are the following:
	the CPU is actually running at (due to hardware design and other		the CPU is actually running at (due to hardware design and other
	limitations).		limitations).

	Some scaling drivers (e.g. ``intel_pstate``) attempt to provide		Some scaling drivers (e.g. \|intel_pstate\|) attempt to provide