1. 19 7月, 2010 1 次提交
    • R
      PM: Make it possible to avoid races between wakeup and system sleep · c125e96f
      Rafael J. Wysocki 提交于
      One of the arguments during the suspend blockers discussion was that
      the mainline kernel didn't contain any mechanisms making it possible
      to avoid races between wakeup and system suspend.
      
      Generally, there are two problems in that area.  First, if a wakeup
      event occurs exactly when /sys/power/state is being written to, it
      may be delivered to user space right before the freezer kicks in, so
      the user space consumer of the event may not be able to process it
      before the system is suspended.  Second, if a wakeup event occurs
      after user space has been frozen, it is not generally guaranteed that
      the ongoing transition of the system into a sleep state will be
      aborted.
      
      To address these issues introduce a new global sysfs attribute,
      /sys/power/wakeup_count, associated with a running counter of wakeup
      events and three helper functions, pm_stay_awake(), pm_relax(), and
      pm_wakeup_event(), that may be used by kernel subsystems to control
      the behavior of this attribute and to request the PM core to abort
      system transitions into a sleep state already in progress.
      
      The /sys/power/wakeup_count file may be read from or written to by
      user space.  Reads will always succeed (unless interrupted by a
      signal) and return the current value of the wakeup events counter.
      Writes, however, will only succeed if the written number is equal to
      the current value of the wakeup events counter.  If a write is
      successful, it will cause the kernel to save the current value of the
      wakeup events counter and to abort the subsequent system transition
      into a sleep state if any wakeup events are reported after the write
      has returned.
      
      [The assumption is that before writing to /sys/power/state user space
      will first read from /sys/power/wakeup_count.  Next, user space
      consumers of wakeup events will have a chance to acknowledge or
      veto the upcoming system transition to a sleep state.  Finally, if
      the transition is allowed to proceed, /sys/power/wakeup_count will
      be written to and if that succeeds, /sys/power/state will be written
      to as well.  Still, if any wakeup events are reported to the PM core
      by kernel subsystems after that point, the transition will be
      aborted.]
      
      Additionally, put a wakeup events counter into struct dev_pm_info and
      make these per-device wakeup event counters available via sysfs,
      so that it's possible to check the activity of various wakeup event
      sources within the kernel.
      
      To illustrate how subsystems can use pm_wakeup_event(), make the
      low-level PCI runtime PM wakeup-handling code use it.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Acked-by: Nmarkgross <markgross@thegnar.org>
      Reviewed-by: NAlan Stern <stern@rowland.harvard.edu>
      c125e96f
  2. 17 7月, 2010 1 次提交
    • B
      PCI: fall back to original BIOS BAR addresses · 58c84eda
      Bjorn Helgaas 提交于
      If we fail to assign resources to a PCI BAR, this patch makes us try the
      original address from BIOS rather than leaving it disabled.
      
      Linux tries to make sure all PCI device BARs are inside the upstream
      PCI host bridge or P2P bridge apertures, reassigning BARs if necessary.
      Windows does similar reassignment.
      
      Before this patch, if we could not move a BAR into an aperture, we left
      the resource unassigned, i.e., at address zero.  Windows leaves such BARs
      at the original BIOS addresses, and this patch makes Linux do the same.
      
      This is a bit ugly because we disable the resource long before we try to
      reassign it, so we have to keep track of the BIOS BAR address somewhere.
      For lack of a better place, I put it in the struct pci_dev.
      
      I think it would be cleaner to attempt the assignment immediately when the
      claim fails, so we could easily remember the original address.  But we
      currently claim motherboard resources in the middle, after attempting to
      claim PCI resources and before assigning new PCI resources, and changing
      that is a fairly big job.
      
      Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16263Reported-by: NAndrew <nitr0@seti.kr.ua>
      Tested-by: NAndrew <nitr0@seti.kr.ua>
      Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      58c84eda
  3. 23 6月, 2010 1 次提交
  4. 19 6月, 2010 1 次提交
  5. 15 6月, 2010 3 次提交
  6. 12 6月, 2010 3 次提交
  7. 08 6月, 2010 1 次提交
  8. 22 5月, 2010 4 次提交
  9. 20 5月, 2010 1 次提交
  10. 19 5月, 2010 7 次提交
  11. 17 5月, 2010 2 次提交
  12. 13 5月, 2010 1 次提交
  13. 12 5月, 2010 14 次提交