Commit 42654eba authored by Mauro Carvalho Chehab's avatar Mauro Carvalho Chehab
Browse files

Merge tag 'media/v4.12-2' into patchwork 



media fixes for v4.12-rc4

* tag 'media/v4.12-2': (598 commits)
  [media] rc-core: race condition during ir_raw_event_register()
  [media] cec: drop MEDIA_CEC_DEBUG
  [media] cec: rename MEDIA_CEC_NOTIFIER to CEC_NOTIFIER
  [media] cec: select CEC_CORE instead of depend on it
  [media] rainshadow-cec: ensure exit_loop is intialized
  [media] atomisp: don't treat warnings as errors
  Linux 4.12-rc3
  x86/ftrace: Make sure that ftrace trampolines are not RWX
  x86/mm/ftrace: Do not bug in early boot on irqs_disabled in cpu_flush_range()
  selftests/ftrace: Add a testcase for many kprobe events
  kprobes/x86: Fix to set RWX bits correctly before releasing trampoline
  ftrace: Fix memory leak in ftrace_graph_release()
  ipv4: add reference counting to metrics
  net: ethernet: ax88796: don't call free_irq without request_irq first
  ip6_tunnel, ip6_gre: fix setting of DSCP on encapsulated packets
  sctp: fix ICMP processing if skb is non-linear
  net: llc: add lock_sock in llc_ui_bind to avoid a race condition
  PCI/msi: fix the pci_alloc_irq_vectors_affinity stub
  blk-mq: Only register debugfs attributes for blk-mq queues
  x86/timers: Move simple_udelay_calibration past init_hypervisor_platform
  ...

Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
parents 6fb05e0d 963761a0

Documentation/acpi/acpi-lid.txt

+12 −4
Original line number 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"

events and the unreliable initial state notification, Linux users can use

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

   initial lid state as "opened" and whether the "opened"/"closed" events

   are paired fully relies on the firmware implementation.

   This may fix some platforms where the returning value of the _LID

   control method is not reliable and 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.



If the userspace has been prepared to ignore the unreliable "opened" events

and the unreliable initial state notification, Linux users should always

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

   initial lid state and there is a compensation mechanism implemented to

   ensure that the reliable "closed" notifications can always be delievered

Documentation/admin-guide/pm/cpufreq.rst

+10 −9
Original line number Diff line number Diff line 
.. |struct cpufreq_policy| replace:: :c:type:`struct cpufreq_policy <cpufreq_policy>`

.. |intel_pstate| replace:: :doc:`intel_pstate <intel_pstate>`



=======================

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,

platform-independent way.  For this reason, ``CPUFreq`` allows scaling drivers

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
@@ -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

``->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.

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

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

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

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


``scaling_available_governors``

	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

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

	limitations).



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

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

	information more precisely reflecting the current CPU frequency through

	this attribute, but that still may not be the exact current CPU

	frequency as seen by the hardware at the moment.
@@ -284,13 +285,13 @@ are the following: 


``scaling_governor``

	The scaling governor currently attached to this policy or (if the

	``intel_pstate`` scaling driver is in use) the scaling algorithm

	|intel_pstate| scaling driver is in use) the scaling algorithm

	provided by the driver that is currently applied to this policy.



	This attribute is read-write and writing to it will cause a new scaling

	governor to be attached to this policy or a new scaling algorithm

	provided by the scaling driver to be applied to it (in the

	``intel_pstate`` case), as indicated by the string written to this

	|intel_pstate| case), as indicated by the string written to this

	attribute (which must be one of the names listed by the

	``scaling_available_governors`` attribute described above).
@@ -619,7 +620,7 @@ This file is located under :file:`/sys/devices/system/cpu/cpufreq/` and controls 
the "boost" setting for the whole system.  It is not present if the underlying

scaling driver does not support the frequency boost mechanism (or supports it,

but provides a driver-specific interface for controlling it, like

``intel_pstate``).

|intel_pstate|).



If the value in this file is 1, the frequency boost mechanism is enabled.  This

means that either the hardware can be put into states in which it is able to

Documentation/admin-guide/pm/index.rst

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



   cpufreq

   intel_pstate



.. only::  subproject and html

CRA Git | Maintained and supported by SUSTech CRA and CCSE