1. 28 6月, 2017 4 次提交
    • R
      PCI / PM: Simplify device wakeup settings code · 0847684c
      Rafael J. Wysocki 提交于
      After previous changes it is not necessary to distinguish between
      device wakeup for run time and device wakeup from system sleep states
      any more, so rework the PCI device wakeup settings code accordingly.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: NBjorn Helgaas <bhelgaas@google.com>
      0847684c
    • R
      PCI / PM: Drop pme_interrupt flag from struct pci_dev · 8370c2dc
      Rafael J. Wysocki 提交于
      The pme_interrupt flag in struct pci_dev is set when PMEs generated
      by the device are going to be signaled via root port PME interrupts.
      
      Ironically enough, that information is only used by the code setting
      up device wakeup through ACPI which returns as soon as it sees the
      pme_interrupt flag set while setting up "remote runtime wakeup".
      That is questionable, however, because in theory there may be PCIe
      devices using out-of-band PME signaling under root ports handled
      by the native PME code or devices requiring wakeup power setup to be
      carried out by AML.  For such devices, ACPI wakeup should be invoked
      regardless of whether or not native PME signaling is used in general.
      
      For this reason, drop the pme_interrupt flag and rework the code
      using it which then allows the ACPI-based device wakeup handling
      in PCI to be consolidated to use one code path for both "runtime
      remote wakeup" and system wakeup (from sleep states).
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: NBjorn Helgaas <bhelgaas@google.com>
      8370c2dc
    • R
      ACPI / PM: Consolidate device wakeup settings code · 4d183d04
      Rafael J. Wysocki 提交于
      Currently, there are two separate ways of handling device wakeup
      settings in the ACPI core, depending on whether this is runtime
      wakeup or system wakeup (from sleep states).  However, after the
      previous commit eliminating the run_wake ACPI device wakeup flag,
      there is no difference between the two any more at the ACPI level,
      so they can be combined.
      
      For this reason, introduce acpi_pm_set_device_wakeup() to replace both
      acpi_pm_device_run_wake() and acpi_pm_device_sleep_wake() and make it
      check the ACPI device object's wakeup.valid flag to determine whether
      or not the device can be set up to generate wakeup signals.
      
      Also notice that zpodd_enable/disable_run_wake() only call
      device_set_run_wake() because acpi_pm_device_run_wake() called
      device_run_wake(), which is not done by acpi_pm_set_device_wakeup(),
      so drop the now redundant device_set_run_wake() calls from there.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: NBjorn Helgaas <bhelgaas@google.com>
      4d183d04
    • R
      ACPI / PM: Drop run_wake from struct acpi_device_wakeup_flags · a1a66393
      Rafael J. Wysocki 提交于
      The run_wake flag in struct acpi_device_wakeup_flags stores the
      information on whether or not the device can generate wakeup
      signals at run time, but in ACPI that really is equivalent to
      being able to generate wakeup signals at all.
      
      In fact, run_wake will always be set after successful executeion of
      acpi_setup_gpe_for_wake(), but if that fails, the device will not be
      able to use a wakeup GPE at all, so it won't be able to wake up the
      systems from sleep states too.  Hence, run_wake actually means that
      the device is capable of triggering wakeup and so it is equivalent
      to the valid flag.
      
      For this reason, drop run_wake from struct acpi_device_wakeup_flags
      and make sure that the valid flag is only set if
      acpi_setup_gpe_for_wake() has been successful.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: NBjorn Helgaas <bhelgaas@google.com>
      a1a66393
  2. 15 6月, 2017 2 次提交
    • R
      PCI / PM: Restore PME Enable if skipping wakeup setup · dc15e71e
      Rafael J. Wysocki 提交于
      The wakeup_prepared PCI device flag is used for preventing subsequent
      changes of PCI device wakeup settings in the same way (e.g. enabling
      device wakeup twice in a row).
      
      However, in some cases PME Enable may be updated by things like PCI
      configuration space restoration in the meantime and it may need to be
      set again even though the rest of the settings need not change, so
      modify __pci_enable_wake() to do that when it is about to return
      early.
      
      Also, it is reasonable to expect that __pci_enable_wake() will always
      clear PME Status when invoked to disable device wakeup, so make it do
      so even if it is going to return early then.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NBjorn Helgaas <bhelgaas@google.com>
      dc15e71e
    • R
      ACPI / PM: Run wakeup notify handlers synchronously · 64fd1c70
      Rafael J. Wysocki 提交于
      The work functions provided by the users of acpi_add_pm_notifier()
      should be run synchronously before re-enabling the wakeup GPE in
      case they are used to clear the status and/or disable the wakeup
      signaling at the source.  Otherwise, which is the case currently in
      the PCI bus type code, the same wakeup event may be signaled for
      multiple times while the execution of the work function in response
      to it has already been queued up.
      
      Fortunately, acpi_add_pm_notifier() is only used by PCI and by
      ACPI device PM code internally, so the change is relatively
      straightforward to make.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NBjorn Helgaas <bhelgaas@google.com>
      64fd1c70
  3. 07 6月, 2017 1 次提交
  4. 24 5月, 2017 1 次提交
  5. 23 5月, 2017 4 次提交
  6. 28 4月, 2017 5 次提交
  7. 26 4月, 2017 1 次提交
  8. 25 4月, 2017 17 次提交
  9. 22 4月, 2017 1 次提交
  10. 21 4月, 2017 2 次提交
  11. 20 4月, 2017 2 次提交