1. 30 3月, 2012 3 次提交
  2. 21 3月, 2012 1 次提交
  3. 22 12月, 2011 1 次提交
    • K
      cpu: convert 'cpu' and 'machinecheck' sysdev_class to a regular subsystem · 8a25a2fd
      Kay Sievers 提交于
      This moves the 'cpu sysdev_class' over to a regular 'cpu' subsystem
      and converts the devices to regular devices. The sysdev drivers are
      implemented as subsystem interfaces now.
      
      After all sysdev classes are ported to regular driver core entities, the
      sysdev implementation will be entirely removed from the kernel.
      
      Userspace relies on events and generic sysfs subsystem infrastructure
      from sysdev devices, which are made available with this conversion.
      
      Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
      Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Borislav Petkov <bp@amd64.org>
      Cc: Tigran Aivazian <tigran@aivazian.fsnet.co.uk>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Zhang Rui <rui.zhang@intel.com>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      8a25a2fd
  4. 07 11月, 2011 4 次提交
  5. 01 11月, 2011 1 次提交
  6. 25 8月, 2011 1 次提交
  7. 04 8月, 2011 3 次提交
  8. 13 1月, 2011 4 次提交
    • T
      cpuidle/x86/perf: fix power:cpu_idle double end events and throw cpu_idle... · f77cfe4e
      Thomas Renninger 提交于
      cpuidle/x86/perf: fix power:cpu_idle double end events and throw cpu_idle events from the cpuidle layer
      
      Currently intel_idle and acpi_idle driver show double cpu_idle "exit idle"
      events -> this patch fixes it and makes cpu_idle events throwing less complex.
      
      It also introduces cpu_idle events for all architectures which use
      the cpuidle subsystem, namely:
        - arch/arm/mach-at91/cpuidle.c
        - arch/arm/mach-davinci/cpuidle.c
        - arch/arm/mach-kirkwood/cpuidle.c
        - arch/arm/mach-omap2/cpuidle34xx.c
        - arch/drivers/acpi/processor_idle.c (for all cases, not only mwait)
        - arch/x86/kernel/process.c (did throw events before, but was a mess)
        - drivers/idle/intel_idle.c (did throw events before)
      
      Convention should be:
      Fire cpu_idle events inside the current pm_idle function (not somewhere
      down the the callee tree) to keep things easy.
      
      Current possible pm_idle functions in X86:
      c1e_idle, poll_idle, cpuidle_idle_call, mwait_idle, default_idle
      -> this is really easy is now.
      
      This affects userspace:
      The type field of the cpu_idle power event can now direclty get
      mapped to:
      /sys/devices/system/cpu/cpuX/cpuidle/stateX/{name,desc,usage,time,...}
      instead of throwing very CPU/mwait specific values.
      This change is not visible for the intel_idle driver.
      For the acpi_idle driver it should only be visible if the vendor
      misses out C-states in his BIOS.
      Another (perf timechart) patch reads out cpuidle info of cpu_idle
      events from:
      /sys/.../cpuidle/stateX/*, then the cpuidle events are mapped
      to the correct C-/cpuidle state again, even if e.g. vendors miss
      out C-states in their BIOS and for example only export C1 and C3.
      -> everything is fine.
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      CC: Robert Schoene <robert.schoene@tu-dresden.de>
      CC: Jean Pihet <j-pihet@ti.com>
      CC: Arjan van de Ven <arjan@linux.intel.com>
      CC: Ingo Molnar <mingo@elte.hu>
      CC: Frederic Weisbecker <fweisbec@gmail.com>
      CC: linux-pm@lists.linux-foundation.org
      CC: linux-acpi@vger.kernel.org
      CC: linux-kernel@vger.kernel.org
      CC: linux-perf-users@vger.kernel.org
      CC: linux-omap@vger.kernel.org
      Signed-off-by: NLen Brown <len.brown@intel.com>
      f77cfe4e
    • L
      cpuidle: delete NOP CPUIDLE_FLAG_POLL · d247632c
      Len Brown 提交于
      it serves no purpose
      Signed-off-by: NLen Brown <len.brown@intel.com>
      d247632c
    • T
      cpuidle: Rename X86 specific idle poll state[0] from C0 to POLL · 720f1c30
      Thomas Renninger 提交于
      C0 means and is well know as "not idle".
      All documentation out there uses this term as "running"/"not idle"
      state. Also Linux userspace tools (e.g. cpufreq-aperf and turbostat)
      show C0 residency which there is correct, but means something totally
      else than cpuidle "POLL" state.
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      720f1c30
    • R
      cpuidle: Make cpuidle_enable_device() call poll_idle_init() · d8c216cf
      Rafael J. Wysocki 提交于
      The following scenario is possible with the current cpuidle code and
      the ACPI cpuidle driver:
      (1) acpi_processor_cst_has_changed() is called,
      (2) cpuidle_disable_device() is called,
      (3) cpuidle_remove_state_sysfs() is called to remove the (presumably
          outdated) states info from sysfs,
      (3) acpi_processor_get_power_info() is called, the first entry in the
          pr->power.states[] table is filled with zeros,
      (4) acpi_processor_setup_cpuidle() is called and it doesn't fill the
          first entry in pr->power.states[],
      (5) cpuidle_enable_device() is called,
      (6) __cpuidle_register_device() is _not_ called, since the device has
          already been registered,
      (7) Consequently, poll_idle_init() is _not_ called either,
      (8) cpuidle_add_state_sysfs() is called to create the sysfs attributes
          for the new states and it uses the bogus first table entry from
          acpi_processor_get_power_info() for creating state0.
      
      This problem is avoided if cpuidle_enable_device()
      unconditionally calls poll_idle_init().
      Reported-by: NLen Brown <len.brown@intel.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      cc: stable@kernel.org
      d8c216cf
  9. 04 1月, 2011 1 次提交
    • T
      perf: Clean up power events by introducing new, more generic ones · 25e41933
      Thomas Renninger 提交于
      Add these new power trace events:
      
       power:cpu_idle
       power:cpu_frequency
       power:machine_suspend
      
      The old C-state/idle accounting events:
        power:power_start
        power:power_end
      
      Have now a replacement (but we are still keeping the old
      tracepoints for compatibility):
      
        power:cpu_idle
      
      and
        power:power_frequency
      
      is replaced with:
        power:cpu_frequency
      
      power:machine_suspend is newly introduced.
      
      Jean Pihet has a patch integrated into the generic layer
      (kernel/power/suspend.c) which will make use of it.
      
      the type= field got removed from both, it was never
      used and the type is differed by the event type itself.
      
      perf timechart userspace tool gets adjusted in a separate patch.
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: NArjan van de Ven <arjan@linux.intel.com>
      Acked-by: NJean Pihet <jean.pihet@newoldbits.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: rjw@sisk.pl
      LKML-Reference: <1294073445-14812-3-git-send-email-trenn@suse.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      LKML-Reference: <1290072314-31155-2-git-send-email-trenn@suse.de>
      25e41933
  10. 17 12月, 2010 1 次提交
    • C
      drivers: Replace __get_cpu_var with __this_cpu_read if not used for an address. · 4a6f4fe8
      Christoph Lameter 提交于
      __get_cpu_var() can be replaced with this_cpu_read and will then use a single
      read instruction with implied address calculation to access the correct per cpu
      instance.
      
      However, the address of a per cpu variable passed to __this_cpu_read() cannot be
      determed (since its an implied address conversion through segment prefixes).
      Therefore apply this only to uses of __get_cpu_var where the addres of the
      variable is not used.
      
      V3->V4:
      	- Move one instance of this_cpu_inc_return to a later patch
      	  so that this one can go in without percpu infrastructrure
      	  changes.
      
      Sedat: fixed compile failure caused by an extra ')'.
      
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Sedat Dilek <sedat.dilek@gmail.com>
      Acked-by: NH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: NChristoph Lameter <cl@linux.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      4a6f4fe8
  11. 10 8月, 2010 1 次提交
    • A
      cpuidle: extend cpuidle and menu governor to handle dynamic states · 71abbbf8
      Ai Li 提交于
      On some SoC chips, HW resources may be in use during any particular idle
      period.  As a consequence, the cpuidle states that the SoC is safe to
      enter can change from idle period to idle period.  In addition, the
      latency and threshold of each cpuidle state can vary, depending on the
      operating condition when the CPU becomes idle, e.g.  the current cpu
      frequency, the current state of the HW blocks, etc.
      
      cpuidle core and the menu governor, in the current form, are geared
      towards cpuidle states that are static, i.e.  the availabiltiy of the
      states, their latencies, their thresholds are non-changing during run
      time.  cpuidle does not provide any hook that cpuidle drivers can use to
      adjust those values on the fly for the current idle period before the menu
      governor selects the target cpuidle state.
      
      This patch extends cpuidle core and the menu governor to handle states
      that are dynamic.  There are three additions in the patch and the patch
      maintains backwards-compatibility with existing cpuidle drivers.
      
      1) add prepare() to struct cpuidle_device.  A cpuidle driver can hook
         into the callback and cpuidle will call prepare() before calling the
         governor's select function.  The callback gives the cpuidle driver a
         chance to update the dynamic information of the cpuidle states for the
         current idle period, e.g.  state availability, latencies, thresholds,
         power values, etc.
      
      2) add CPUIDLE_FLAG_IGNORE as one of the state flags.  In the prepare()
         function, a cpuidle driver can set/clear the flag to indicate to the
         menu governor whether a cpuidle state should be ignored, i.e.  not
         available, during the current idle period.
      
      3) add power_specified bit to struct cpuidle_device.  The menu governor
         currently assumes that the cpuidle states are arranged in the order of
         increasing latency, threshold, and power savings.  This is true or can
         be made true for static states.  Once the state parameters are dynamic,
         the latencies, thresholds, and power savings for the cpuidle states can
         increase or decrease by different amounts from idle period to idle
         period.  So the assumption of increasing latency, threshold, and power
         savings from Cn to C(n+1) can no longer be guaranteed.
      
      It can be straightforward to calculate the power consumption of each
      available state and to specify it in power_usage for the idle period.
      Using the power_usage fields, the menu governor then selects the state
      that has the lowest power consumption and that still satisfies all other
      critieria.  The power_specified bit defaults to 0.  For existing cpuidle
      drivers, cpuidle detects that power_specified is 0 and fills in a dummy
      set of power_usage values.
      Signed-off-by: NAi Li <aili@codeaurora.org>
      Cc: Len Brown <len.brown@intel.com>
      Acked-by: NArjan van de Ven <arjan@linux.intel.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Venkatesh Pallipadi <venki@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      71abbbf8
  12. 04 8月, 2010 1 次提交
    • T
      [CPUFREQ] x86 cpufreq: Make trace_power_frequency cpufreq driver independent · 6f4f2723
      Thomas Renninger 提交于
      and fix the broken case if a core's frequency depends on others.
      
      trace_power_frequency was only implemented in a rather ungeneric way
      in acpi-cpufreq driver's target() function only.
      -> Move the call to trace_power_frequency to
         cpufreq.c:cpufreq_notify_transition() where CPUFREQ_POSTCHANGE
         notifier is triggered.
         This will support power frequency tracing by all cpufreq drivers
      
      trace_power_frequency did not trace frequency changes correctly when
      the userspace governor was used or when CPU cores' frequency depend
      on each other.
      -> Moving this into the CPUFREQ_POSTCHANGE notifier and pass the cpu
         which gets switched automatically fixes this.
      
      Robert Schoene provided some important fixes on top of my initial
      quick shot version which are integrated in this patch:
      - Forgot some changes in power_end trace (TP_printk/variable names)
      - Variable dummy in power_end must now be cpu_id
      - Use static 64 bit variable instead of unsigned int for cpu_id
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      CC: davej@redhat.com
      CC: arjan@infradead.org
      CC: linux-kernel@vger.kernel.org
      CC: robert.schoene@tu-dresden.de
      Tested-by: robert.schoene@tu-dresden.de
      Signed-off-by: NDave Jones <davej@redhat.com>
      6f4f2723
  13. 22 7月, 2010 1 次提交
    • T
      x86 cpufreq, perf: Make trace_power_frequency cpufreq driver independent · 4c21adf2
      Thomas Renninger 提交于
      and fix the broken case if a core's frequency depends on others.
      
      trace_power_frequency was only implemented in a rather ungeneric
      way in acpi-cpufreq driver's target() function only.
      
      -> Move the call to trace_power_frequency to
         cpufreq.c:cpufreq_notify_transition() where CPUFREQ_POSTCHANGE
         notifier is triggered.
         This will support power frequency tracing by all cpufreq
         drivers.
      
      trace_power_frequency did not trace frequency changes correctly
      when the userspace governor was used or when CPU cores'
      frequency depend on each other.
      
      -> Moving this into the CPUFREQ_POSTCHANGE notifier and pass the cpu
         which gets switched automatically fixes this.
      
      Robert Schoene provided some important fixes on top of my
      initial quick shot version which are integrated in this patch:
      - Forgot some changes in power_end trace (TP_printk/variable names)
      - Variable dummy in power_end must now be cpu_id
      - Use static 64 bit variable instead of unsigned int for cpu_id
      
      [akpm@linux-foundation.org: build fix]
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      Cc: davej@codemonkey.org.uk
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Cc: Dave Jones <davej@codemonkey.org.uk>
      Acked-by: NArjan van de Ven <arjan@infradead.org>
      Cc: Robert Schoene <robert.schoene@tu-dresden.de>
      Tested-by: NRobert Schoene <robert.schoene@tu-dresden.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      4c21adf2
  14. 28 5月, 2010 1 次提交
    • L
      cpuidle: make cpuidle_curr_driver static · 752138df
      Len Brown 提交于
      cpuidle_register_driver() sets cpuidle_curr_driver
      cpuidle_unregister_driver() clears cpuidle_curr_driver
      
      We should't expose cpuidle_curr_driver to
      potential modification except via these interfaces.
      So make it static and create cpuidle_get_driver() to observe it.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      752138df
  15. 29 10月, 2009 1 次提交
    • K
      cpuidle: always return with interrupts enabled · 246eb7f0
      Kevin Hilman 提交于
      In the case where cpuidle_idle_call() returns before changing state due to
      a need_resched(), it was returning with IRQs disabled.
      
      The idle path assumes that the platform specific idle code returns with
      interrupts enabled (although this too is undocumented AFAICT) and on ARM
      we have a WARN_ON(!(irqs_disabled()) when returning from the idle loop, so
      the user-visible effects were only a warning since interrupts were
      eventually re-enabled later.
      
      On x86, this same problem exists, but there is no WARN_ON() to detect it.
      As on ARM, the interrupts are eventually re-enabled, so I'm not sure of
      any actual bugs triggered by this.  It's primarily a
      correctness/consistency fix.
      
      This patch ensures IRQs are (re)enabled before returning.
      Reported-by: NHemanth V <hemanthv@ti.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Tested-by: NMartin Michlmayr <tbm@cyrius.com>
      Cc: <stable@kernel.org>		[2.6.31.x]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      246eb7f0
  16. 20 9月, 2009 1 次提交
    • A
      tracing, x86, cpuidle: Move the end point of a C state in the power tracer · 288f023e
      Arjan van de Ven 提交于
      The "end of a C state" trace point currently happens before
      the code runs that corrects the TSC for having stopped during idle.
      
      The result of this is that the timestamp of the end-of-C-state event
      is garbage on cpus where the TSC stops during idle.
      
      This patch moves the end point of the C state to after the timekeeping
      engine of the kernel has been corrected.
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Cc: Len Brown <len.brown@intel.com>
      Cc: fweisbec@gmail.com
      Cc: peterz@infradead.org
      Cc: Paul Mackerras <paulus@samba.org>
      LKML-Reference: <20090919133533.139c2a46@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      288f023e
  17. 10 11月, 2008 1 次提交
  18. 17 10月, 2008 2 次提交
  19. 11 9月, 2008 1 次提交
    • A
      hrtimer: peek at the timer queue just before going idle · 2e94d1f7
      Arjan van de Ven 提交于
      As part of going idle, we already look at the time of the next timer event to determine
      which C-state to select etc.
      
      This patch adds functionality that causes the timers that are past their
      soft expire time, to fire at this time, before we calculate the next wakeup
      time. This functionality will thus avoid wakeups by running timers before
      going idle rather than specially waking up for it.
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      2e94d1f7
  20. 28 7月, 2008 1 次提交
  21. 26 6月, 2008 1 次提交
  22. 12 6月, 2008 1 次提交
    • V
      cpuidle acpi driver: fix oops on AC<->DC · dcb84f33
      Venkatesh Pallipadi 提交于
      cpuidle and acpi driver interaction bug with the way cpuidle_register_driver()
      is called. Due to this bug, there will be oops on
      AC<->DC on some systems, where they support C-states in one DC and not in AC.
      
      The current code does
      ON BOOT:
      	Look at CST and other C-state info to see whether more than C1 is
      	supported. If it is, then acpi processor_idle does a
      	cpuidle_register_driver() call, which internally enables the device.
      
      ON CST change notification (AC<->DC) and on suspend-resume:
      	acpi driver temporarily disables device, updates the device with
      	any new C-states, and reenables the device.
      
      The problem is is on boot, there are no C2, C3 states supported and we skip
      the register. Later on AC<->DC, we may get a CST notification and we try
      to reevaluate CST and enabled the device, without actually registering it.
      This causes breakage as we try to create /sys fs sub directory, without the
      parent directory which is created at register time.
      
      Thanks to Sanjeev for reporting the problem here.
      http://bugzilla.kernel.org/show_bug.cgi?id=10394Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      dcb84f33
  23. 26 3月, 2008 2 次提交
  24. 14 2月, 2008 1 次提交
  25. 09 2月, 2008 1 次提交
    • V
      cpuidle: build fix for non-x86 · a6869cc4
      Venki Pallipadi 提交于
      The last posted version of this patch gave compile error
      on IA64. So, here goes yet another rewrite of the patch.
      
      Convert cpu_idle_wait() to cpuidle_kick_cpus() which is
      SMP-only, and gives error on non supported CPU.
      
      Changes from last patch sent by Kevin:
      Moved the definition of kick_cpus back to cpuidle.c from cpuidle.h:
      * Having it in .h gives #error on archs which includes the header file without
        actually having CPU_IDLE configured. To make it work in .h, we need one more
        #ifdef around that code which makes it messy.
      * Also, the function is only called from one file. So, it can be in declared
        statically in .c rather than making it available to everyone who includes
        the .h file.
      Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: NKevin Hilman <khilman@mvista.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      a6869cc4
  26. 07 2月, 2008 2 次提交
  27. 06 2月, 2008 1 次提交
    • M
      pm qos infrastructure and interface · d82b3518
      Mark Gross 提交于
      The following patch is a generalization of the latency.c implementation done
      by Arjan last year.  It provides infrastructure for more than one parameter,
      and exposes a user mode interface for processes to register pm_qos
      expectations of processes.
      
      This interface provides a kernel and user mode interface for registering
      performance expectations by drivers, subsystems and user space applications on
      one of the parameters.
      
      Currently we have {cpu_dma_latency, network_latency, network_throughput} as
      the initial set of pm_qos parameters.
      
      The infrastructure exposes multiple misc device nodes one per implemented
      parameter.  The set of parameters implement is defined by pm_qos_power_init()
      and pm_qos_params.h.  This is done because having the available parameters
      being runtime configurable or changeable from a driver was seen as too easy to
      abuse.
      
      For each parameter a list of performance requirements is maintained along with
      an aggregated target value.  The aggregated target value is updated with
      changes to the requirement list or elements of the list.  Typically the
      aggregated target value is simply the max or min of the requirement values
      held in the parameter list elements.
      
      >From kernel mode the use of this interface is simple:
      
      pm_qos_add_requirement(param_id, name, target_value):
      
        Will insert a named element in the list for that identified PM_QOS
        parameter with the target value.  Upon change to this list the new target is
        recomputed and any registered notifiers are called only if the target value
        is now different.
      
      pm_qos_update_requirement(param_id, name, new_target_value):
      
        Will search the list identified by the param_id for the named list element
        and then update its target value, calling the notification tree if the
        aggregated target is changed.  with that name is already registered.
      
      pm_qos_remove_requirement(param_id, name):
      
        Will search the identified list for the named element and remove it, after
        removal it will update the aggregate target and call the notification tree
        if the target was changed as a result of removing the named requirement.
      
      >From user mode:
      
        Only processes can register a pm_qos requirement.  To provide for
        automatic cleanup for process the interface requires the process to register
        its parameter requirements in the following way:
      
        To register the default pm_qos target for the specific parameter, the
        process must open one of /dev/[cpu_dma_latency, network_latency,
        network_throughput]
      
        As long as the device node is held open that process has a registered
        requirement on the parameter.  The name of the requirement is
        "process_<PID>" derived from the current->pid from within the open system
        call.
      
        To change the requested target value the process needs to write a s32
        value to the open device node.  This translates to a
        pm_qos_update_requirement call.
      
        To remove the user mode request for a target value simply close the device
        node.
      
      [akpm@linux-foundation.org: fix warnings]
      [akpm@linux-foundation.org: fix build]
      [akpm@linux-foundation.org: fix build again]
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: Nmark gross <mgross@linux.intel.com>
      Cc: "John W. Linville" <linville@tuxdriver.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Jaroslav Kysela <perex@suse.cz>
      Cc: Takashi Iwai <tiwai@suse.de>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Cc: Venki Pallipadi <venkatesh.pallipadi@intel.com>
      Cc: Adam Belay <abelay@novell.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d82b3518