1. 09 10月, 2012 2 次提交
    • W
      memory-hotplug: update memory block's state and notify userspace · e90bdb7f
      Wen Congyang 提交于
      remove_memory() will be called when hot removing a memory device.  But
      even if offlining memory, we cannot notice it.  So the patch updates the
      memory block's state and sends notification to userspace.
      
      Additionally, the memory device may contain more than one memory block.
      If the memory block has been offlined, __offline_pages() will fail.  So we
      should try to offline one memory block at a time.
      
      Thus remove_memory() also check each memory block's state.  So there is no
      need to check the memory block's state before calling remove_memory().
      Signed-off-by: NWen Congyang <wency@cn.fujitsu.com>
      Signed-off-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Jiang Liu <liuj97@gmail.com>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Minchan Kim <minchan.kim@gmail.com>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e90bdb7f
    • W
      memory-hotplug: preparation to notify memory block's state at memory hot remove · a16cee10
      Wen Congyang 提交于
      remove_memory() is called in two cases:
      1. echo offline >/sys/devices/system/memory/memoryXX/state
      2. hot remove a memory device
      
      In the 1st case, the memory block's state is changed and the notification
      that memory block's state changed is sent to userland after calling
      remove_memory().  So user can notice memory block is changed.
      
      But in the 2nd case, the memory block's state is not changed and the
      notification is not also sent to userspcae even if calling
      remove_memory().  So user cannot notice memory block is changed.
      
      For adding the notification at memory hot remove, the patch just prepare
      as follows:
      1st case uses offline_pages() for offlining memory.
      2nd case uses remove_memory() for offlining memory and changing memory block's
          state and notifing the information.
      
      The patch does not implement notification to remove_memory().
      Signed-off-by: NWen Congyang <wency@cn.fujitsu.com>
      Signed-off-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Jiang Liu <liuj97@gmail.com>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Minchan Kim <minchan.kim@gmail.com>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a16cee10
  2. 05 10月, 2012 1 次提交
  3. 04 10月, 2012 1 次提交
    • L
      firmware: teach the kernel to load firmware files directly from the filesystem · abb139e7
      Linus Torvalds 提交于
      This is a first step in allowing people to by-pass udev for loading
      device firmware.  Current versions of udev will deadlock (causing us to
      block for the 30 second timeout) under some circumstances if the
      firmware is loaded as part of the module initialization path, and this
      is causing problems for media drivers in particular.
      
      The current patch hardcodes the firmware path that udev uses by default,
      and will fall back to the legacy udev mode if the firmware cannot be
      found there.  We'd like to add support for both configuring the paths
      and the fallback behaviour, but in the meantime this hopefully fixes the
      immediate problem, while also giving us a way forward.
      
      [ v2: Some VFS layer interface cleanups suggested by Al Viro ]
      [ v3: use the default udev paths suggested by Kay Sievers ]
      Suggested-by: NIvan Kalvachev <ikalvachev@gmail.com>
      Acked-by: NGreg KH <gregkh@linuxfoundation.org>
      Acked-by: NAl Viro <viro@zeniv.linux.org.uk>
      Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
      Cc: Kay Sievers <kay@redhat.com>
      Cc: Ming Lei <ming.lei@canonical.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      abb139e7
  4. 02 10月, 2012 1 次提交
  5. 27 9月, 2012 1 次提交
  6. 25 9月, 2012 1 次提交
  7. 23 9月, 2012 1 次提交
    • K
      PM / Runtime: let rpm_resume() succeed if RPM_ACTIVE, even when disabled, v2 · 6f3c77b0
      Kevin Hilman 提交于
      There are several drivers where the return value of
      pm_runtime_get_sync() is used to decide whether or not it is safe to
      access hardware and that don't provide .suspend() callbacks for system
      suspend (but may use late/noirq callbacks.)  If such a driver happens
      to call pm_runtime_get_sync() during system suspend, after the core
      has disabled runtime PM, it will get the error code and will decide
      that the hardware should not be accessed, although this may be a wrong
      conclusion, depending on the state of the device when runtime PM was
      disabled.
      
      Drivers might work around this problem by using a test like:
      
         ret = pm_runtime_get_sync(dev);
         if (!ret || (ret == -EACCES && driver_private_data(dev)->suspended)) {
            /* access hardware */
         }
      
      where driver_private_data(dev)->suspended is a flag set by the
      driver's .suspend() method (that would have to be added for this
      purpose).  However, that potentially would need to be done by multiple
      drivers which means quite a lot of duplicated code and bloat.
      
      To avoid that we can use the observation that the core sets
      dev->power.is_suspended before disabling runtime PM and use that
      instead of the driver's private flag.  Still, potentially many drivers
      would need to repeat that same check in quite a few places, so it's
      better to let the core do it.
      
      Then we can be a bit smarter and check whether or not runtime PM was
      disabled by the core only (disable_depth == 1) or by someone else in
      addition to the core (disable_depth > 1).  In the former case
      rpm_resume() can return 1 if the runtime PM status is RPM_ACTIVE,
      because it means the device was active when the core disabled runtime
      PM.  In the latter case it should still return -EACCES, because it
      isn't clear why runtime PM has been disabled.
      
      Tested on AM3730/Beagle-xM where a wakeup IRQ firing during the late
      suspend phase triggers runtime PM activity in the I2C driver since the
      wakeup IRQ is on an I2C-connected PMIC.
      
      [rjw: Modified whitespace to follow the file's convention.]
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      6f3c77b0
  8. 21 9月, 2012 1 次提交
  9. 20 9月, 2012 1 次提交
    • A
      PM: Prevent runtime suspend during system resume · 88d26136
      Alan Stern 提交于
      This patch (as1591) moves the pm_runtime_get_noresume() and
      pm_runtime_put_sync() calls from __device_suspend() and
      device_resume() to device_prepare() and device_complete() in the PM
      core.
      
      The reason for doing this is to make sure that parent devices remain
      at full power (i.e., don't go into runtime suspend) while their
      children are being resumed from a system sleep.
      
      The PCI core already contained equivalent code to serve the same
      purpose.  The patch removes the duplicated code, since it is no longer
      needed.  One of the comments from the PCI core gets moved into the PM
      core, and a second comment is added to explain whe the _get_noresume
      and _put_sync calls are present.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      88d26136
  10. 19 9月, 2012 2 次提交
  11. 17 9月, 2012 3 次提交
  12. 11 9月, 2012 1 次提交
  13. 10 9月, 2012 1 次提交
  14. 09 9月, 2012 1 次提交
  15. 07 9月, 2012 5 次提交
  16. 04 9月, 2012 13 次提交
    • R
      PM / Domains: Operations related to cpuidle using domain names · 74a2799a
      Rafael J. Wysocki 提交于
      Make it possible to use domain names in operations connecting cpuidle
      to and disconnecting it from a PM domain.  This is useful on
      platforms where PM domain objects are organized in such a way that
      the names of the domains are easier to use than the addresses of
      those objects.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      74a2799a
    • R
      PM / Domains: Document cpuidle-related functions and change their names · 40114447
      Rafael J. Wysocki 提交于
      The names of the cpuidle-related functions in
      drivers/base/power/domain.c are inconsistent with the names of the
      other exported functions in that file (the "pm_" prefix is missing
      from them) and they are missing kerneldoc comments.
      
      Fix that by adding the missing "pm_" prefix to the names of those
      functions and add kerneldoc comments documenting them.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      40114447
    • R
      PM / Domains: Add power-on function using names to identify domains · 8bc0251d
      Rafael J. Wysocki 提交于
      It sometimes is necessary to turn on a given PM domain when only
      the name of it is known and the domain pointer is not readily
      available.  For this reason, add a new helper function,
      pm_genpd_name_poweron(), allowing the caller to turn on a PM domain
      using its name for identification.  To avoid code duplication,
      move the domain lookup code to a separate function.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      8bc0251d
    • R
      PM / Domains: Make it possible to use names when adding subdomains · fb7268be
      Rafael J. Wysocki 提交于
      Add a new helper function, pm_genpd_add_subdomain_names(), allowing
      the caller to add a subdomain to a generic PM domain using names for
      domain identification (both domains have to be initialized before).
      
      This function is useful for adding subdomains to PM domains whose
      representations are stored in tables, when the caller doesn't know
      the indices of the domain to add the subdomain to and of the
      subdomain itself, but it knows the domains' names.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      fb7268be
    • R
      PM / Domains: Make it possible to use domain names when adding devices · b5abb085
      Rafael J. Wysocki 提交于
      Add a new helper function __pm_genpd_name_add_device() allowing
      a device to be added to a (registered) generic PM domain identified
      by name.  Add a wrapper around it, pm_genpd_name_add_device(),
      passing NULL as the last argument and reorganize pm_domains.h for the
      new functions to be defined consistently with the existing ones.
      
      These functions are useful for adding devices to PM domains whose
      representations are stored in tables, when the caller doesn't know
      the index of the domain to add the device to, but it knows the
      domain's name.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      b5abb085
    • R
      PM: Do not use the syscore flag for runtime PM · feb70af0
      Rafael J. Wysocki 提交于
      The syscore device PM flag used to mark the devices (belonging to
      PM domains) that should never be turned off, except for the system
      core (syscore) suspend/hibernation and resume stages, need not be
      accessed by the runtime PM core functions, because all of the devices
      it is set for need to be marked as "irq safe" anyway and are
      protected from being turned off by runtime PM by ensuring that their
      usage counters are always set.
      
      For this reason, make the syscore flag system-wide PM-specific
      and simplify the code used for manipulating it, because it need not
      acquire the device's power.lock any more.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      feb70af0
    • R
      PM / Domains: Do not measure start time for "irq safe" devices · e2e3e4e5
      Rafael J. Wysocki 提交于
      The genpd_start_dev() routine used by pm_genpd_runtime_resume()
      to put "irq safe" devices into the full power state measures the
      time necessary to "start" the device and updates its PM QoS timing
      data if necessary.  This may lead to a deadlock if the given device
      is a clock source and genpd_start_dev() is invoked from within the
      clock source's .enable() routine, which will happen if that routine
      uses pm_runtime_get_sync(), for example, to ensure that the device
      is operational.
      
      For this reason, introduce a special routine analogous to
      genpd_start_dev(), called genpd_start_dev_no_timing(), that doesn't
      carry out the time measurement, and make pm_genpd_runtime_resume()
      use it instead of genpd_start_dev() to power up "irq safe" devices.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      e2e3e4e5
    • R
      PM / Domains: Move syscore flag from subsys data to struct device · dbf37414
      Rafael J. Wysocki 提交于
      The syscore device PM flag is used to mark the devices (belonging to
      a PM domain) that should never be turned off, except for the system
      core (syscore) suspend/hibernation and resume stages.  That flag is
      stored in the device's struct pm_subsys_data object whose address is
      available from struct device.  However, in some situations it may be
      convenient to set that flag before the device is added to a PM
      domain, so it is better to move it directly to the "power" member of
      struct device.  Then, it can be checked by the routines in
      drivers/base/power/runtime.c and drivers/base/power/main.c, which is
      more straightforward.
      
      This also reduces the number of dev_gpd_data() invocations in the
      generic PM domains framework, so the overhead related to the syscore
      flag is slightly smaller.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NMagnus Damm <damm@opensource.se>
      dbf37414
    • R
      PM / Domains: Rename the always_on device flag to syscore · 6fb28bad
      Rafael J. Wysocki 提交于
      The always_on device flag is used to mark the devices (belonging to
      a PM domain) that should never be turned off, except for the system
      core (syscore) suspend/hibernation and resume stages.  Change name
      of that flag to "syscore" to better reflect its purpose.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NMagnus Damm <damm@opensource.se>
      6fb28bad
    • R
      PM / Runtime: Allow helpers to be called by early platform drivers · bed2b42d
      Rafael J. Wysocki 提交于
      Runtime PM helper functions, like pm_runtime_get_sync(), cannot be
      called by early platform device drivers, because the devices' power
      management locks are not initialized at that time.  This is quite
      inconvenient, so modify early_platform_add_devices() to initialize
      the devices power management locks as appropriate and make sure that
      they won't be initialized more than once if an early platform
      device is going to be used as a regular one later.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      bed2b42d
    • R
      PM: Reorganize device PM initialization · e91c11b1
      Rafael J. Wysocki 提交于
      Make the device power management initialization more straightforward
      by moving the initialization of common (i.e. used by both runtime PM
      and system suspend) fields to a separate routine.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      e91c11b1
    • R
      PM / Domains: Add power off/on function for system core suspend stage · 77f827de
      Rafael J. Wysocki 提交于
      Introduce function pm_genpd_syscore_switch() and two wrappers around
      it, pm_genpd_syscore_poweroff() and pm_genpd_syscore_poweron(),
      allowing the callers to let the generic PM domains framework know
      that the given device is not necessary any more and its PM domain
      can be turned off (the former) or that the given device will be
      required immediately, so its PM domain has to be turned on (the
      latter) during the system core (syscore) stage of system suspend
      (or hibernation) and resume.
      
      These functions will be used for handling devices registered as
      clock sources and clock event devices that belong to PM domains.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      77f827de
    • R
      PM / Domains: Introduce simplified power on routine for system resume · 802d8b49
      Rafael J. Wysocki 提交于
      Introduce function pm_genpd_sync_poweron() for restoring domain power
      during resume from system suspend and hibernation.  It can be much
      simpler than pm_genpd_poweron(), because it doesn't have to care
      about locking and it can skip many checks done by the latter.
      
      Modify pm_genpd_resume_noirq() and pm_genpd_restore_noirq() to use
      the new function.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      802d8b49
  17. 31 8月, 2012 1 次提交
  18. 29 8月, 2012 1 次提交
  19. 19 8月, 2012 1 次提交
  20. 18 8月, 2012 1 次提交
    • T
      PM / Sleep: Print name of wakeup source that aborts suspend · a938da06
      Todd Poynor 提交于
      A driver or app may repeatedly request a wakeup source while the system
      is attempting to enter suspend, which may indicate a bug or at least
      point out a highly active system component that is responsible for
      decreased battery life on a mobile device.  Even when the incidence
      of suspend abort is not severe, identifying wakeup sources that
      frequently abort suspend can be a useful clue for power management
      analysis.
      
      In some cases the existing stats can point out the offender where there is
      an unexpectedly high activation count that stands out from the others, but
      in other cases the wakeup source frequently taken just after the rest of
      the system thinks its time to suspend might not stand out in the overall
      stats.
      
      It is also often useful to have information about what's been happening
      recently, rather than totals of all activity for the system boot.
      
      It's suggested to dump a line about which wakeup source
      aborted suspend to aid analysis of these situations.
      Signed-off-by: NTodd Poynor <toddpoynor@google.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      a938da06