1. 23 Feb, 2017 1 commit
  2. 24 Sep, 2014 1 commit
  3. 10 Feb, 2014 3 commits
    • Rafael J. Wysocki's avatar
      PM / QoS: Add type to dev_pm_qos_add_ancestor_request() arguments · 71d821fd
      Rafael J. Wysocki authored
      Rework dev_pm_qos_add_ancestor_request() so that device PM QoS type
      is passed to it as the third argument and make it support the
      DEV_PM_QOS_LATENCY_TOLERANCE device PM QoS type (in addition to
      DEV_PM_QOS_RESUME_LATENCY).
      
      That will allow the drivers of devices without latency tolerance
      hardware support to use their ancestors having it as proxies for
      their latency tolerance requirements.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      71d821fd
    • Rafael J. Wysocki's avatar
      PM / QoS: Introcuce latency tolerance device PM QoS type · 2d984ad1
      Rafael J. Wysocki authored
      Add a new latency tolerance device PM QoS type to be use for
      specifying active state (RPM_ACTIVE) memory access (DMA) latency
      tolerance requirements for devices.  It may be used to prevent
      hardware from choosing overly aggressive energy-saving operation
      modes (causing too much latency to appear) for the whole platform.
      
      This feature reqiures hardware support, so it only will be
      available for devices having a new .set_latency_tolerance()
      callback in struct dev_pm_info populated, in which case the
      routine pointed to by it should implement whatever is necessary
      to transfer the effective requirement value to the hardware.
      
      Whenever the effective latency tolerance changes for the device,
      its .set_latency_tolerance() callback will be executed and the
      effective value will be passed to it.  If that value is negative,
      which means that the list of latency tolerance requirements for
      the device is empty, the callback is expected to switch the
      underlying hardware latency tolerance control mechanism to an
      autonomous mode if available.  If that value is PM_QOS_LATENCY_ANY,
      in turn, and the hardware supports a special "no requirement"
      setting, the callback is expected to use it.  That allows software
      to prevent the hardware from automatically updating the device's
      latency tolerance in response to its power state changes (e.g. during
      transitions from D3cold to D0), which generally may be done in the
      autonomous latency tolerance control mode.
      
      If .set_latency_tolerance() is present for the device, a new
      pm_qos_latency_tolerance_us attribute will be present in the
      devivce's power directory in sysfs.  Then, user space can use
      that attribute to specify its latency tolerance requirement for
      the device, if any.  Writing "any" to it means "no requirement, but
      do not let the hardware control latency tolerance" and writing
      "auto" to it allows the hardware to be switched to the autonomous
      mode if there are no other requirements from the kernel side in the
      device's list.
      
      This changeset includes a fix from Mika Westerberg.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2d984ad1
    • Rafael J. Wysocki's avatar
      PM / QoS: Rename device resume latency QoS items · b02f6695
      Rafael J. Wysocki authored
      Rename symbols, variables, functions and structure fields related do
      the resume latency device PM QoS type so that it is clear where they
      belong (in particular, to avoid confusion with the latency tolerance
      device PM QoS type introduced by a subsequent changeset).
      
      Update the PM QoS documentation to better reflect its current state.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      b02f6695
  4. 22 Jun, 2013 1 commit
  5. 22 Oct, 2012 1 commit
    • Rafael J. Wysocki's avatar
      PM / QoS: Introduce PM QoS device flags support · ae0fb4b7
      Rafael J. Wysocki authored
      Modify the device PM QoS core code to support PM QoS flags requests.
      
      First, add a new field of type struct pm_qos_flags called "flags"
      to struct dev_pm_qos for representing the list of PM QoS flags
      requests for the given device.  Accordingly, add a new "type" field
      to struct dev_pm_qos_request (along with an enum for representing
      request types) and a new member called "flr" to its data union for
      representig flags requests.
      
      Second, modify dev_pm_qos_add_request(), dev_pm_qos_update_request(),
      the internal routine apply_constraint() used by them and their
      existing callers to cover flags requests as well as latency
      requests.  In particular, dev_pm_qos_add_request() gets a new
      argument called "type" for specifying the type of a request to be
      added.
      
      Finally, introduce two routines, __dev_pm_qos_flags() and
      dev_pm_qos_flags(), allowing their callers to check which PM QoS
      flags have been requested for the given device (the caller is
      supposed to pass the mask of flags to check as the routine's
      second argument and examine its return value for the result).
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: default avatarJean Pihet <j-pihet@ti.com>
      Reviewed-by: default avatarmark gross <markgross@thegnar.org>
      ae0fb4b7
  6. 04 Oct, 2011 1 commit
  7. 10 May, 2010 1 commit
    • Mark Gross's avatar
      PM QOS update · ed77134b
      Mark Gross authored
      This patch changes the string based list management to a handle base
      implementation to help with the hot path use of pm-qos, it also renames
      much of the API to use "request" as opposed to "requirement" that was
      used in the initial implementation.  I did this because request more
      accurately represents what it actually does.
      
      Also, I added a string based ABI for users wanting to use a string
      interface.  So if the user writes 0xDDDDDDDD formatted hex it will be
      accepted by the interface.  (someone asked me for it and I don't think
      it hurts anything.)
      
      This patch updates some documentation input I got from Randy.
      Signed-off-by: default avatarmarkgross <mgross@linux.intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      ed77134b
  8. 05 Aug, 2008 1 commit
  9. 12 Mar, 2008 1 commit
  10. 05 Feb, 2008 1 commit
    • Mark Gross's avatar
      pm qos infrastructure and interface · d82b3518
      Mark Gross authored
      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: default avatarmark 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d82b3518