1. 17 1月, 2012 4 次提交
  2. 07 11月, 2011 3 次提交
    • D
      cpuidle: Single/Global registration of idle states · 46bcfad7
      Deepthi Dharwar 提交于
      This patch makes the cpuidle_states structure global (single copy)
      instead of per-cpu. The statistics needed on per-cpu basis
      by the governor are kept per-cpu. This simplifies the cpuidle
      subsystem as state registration is done by single cpu only.
      Having single copy of cpuidle_states saves memory. Rare case
      of asymmetric C-states can be handled within the cpuidle driver
      and architectures such as POWER do not have asymmetric C-states.
      
      Having single/global registration of all the idle states,
      dynamic C-state transitions on x86 are handled by
      the boot cpu. Here, the boot cpu  would disable all the devices,
      re-populate the states and later enable all the devices,
      irrespective of the cpu that would receive the notification first.
      
      Reference:
      https://lkml.org/lkml/2011/4/25/83Signed-off-by: NDeepthi Dharwar <deepthi@linux.vnet.ibm.com>
      Signed-off-by: NTrinabh Gupta <g.trinabh@gmail.com>
      Tested-by: NJean Pihet <j-pihet@ti.com>
      Reviewed-by: NKevin Hilman <khilman@ti.com>
      Acked-by: NArjan van de Ven <arjan@linux.intel.com>
      Acked-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      46bcfad7
    • B
      ACPI: Fix CONFIG_ACPI_DOCK=n compiler warning · c1056b42
      Bart Van Assche 提交于
      Recently the ACPI ops structs were constified but the inline version
      of register_hotplug_dock_device() was overlooked (see also commit
      9c8b04be, June 25 2011). Update the inline function
      register_hotplug_dock_device() that is enabled with
      CONFIG_ACPI_DOCK=n too. This patch fixes at least the following
      compiler warnings:
      
      drivers/ata/libata-acpi.c: In function .ata_acpi_associate.:
      drivers/ata/libata-acpi.c:266:11: warning: passing argument 2 of .register_hotplug_dock_device. discards qualifiers from pointer target type
      include/acpi/acpi_drivers.h:146:19: note: expected .struct acpi_dock_ops *. but argument is of type .const struct acpi_dock_ops *.
      drivers/ata/libata-acpi.c:275:11: warning: passing argument 2 of .register_hotplug_dock_device. discards qualifiers from pointer target type
      include/acpi/acpi_drivers.h:146:19: note: expected .struct acpi_dock_ops *. but argument is of type .const struct acpi_dock_ops *.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NLen Brown <len.brown@intel.com>
      c1056b42
    • R
      ACPI: Drop ACPI_NO_HARDWARE_INIT · 4505a201
      Rafael J. Wysocki 提交于
      ACPI_NO_HARDWARE_INIT is only used by acpi_early_init() and
      acpi_bus_init() when calling acpi_enable_subsystem(), but
      acpi_enable_subsystem() doesn't check that flag, so it can be
      dropped.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      4505a201
  3. 01 11月, 2011 1 次提交
  4. 15 10月, 2011 1 次提交
    • P
      PCI hotplug: acpiphp: Prevent deadlock on PCI-to-PCI bridge remove · 6af8bef1
      Prarit Bhargava 提交于
      I originally submitted a patch to workaround this by pushing all Ejection
      Requests and Device Checks onto the kacpi_hotplug queue.
      
      http://marc.info/?l=linux-acpi&m=131678270930105&w=2
      
      The patch is still insufficient in that Bus Checks also need to be added.
      
      Rather than add all events, including non-PCI-hotplug events, to the
      hotplug queue, mjg suggested that a better approach would be to modify
      the acpiphp driver so only acpiphp events would be added to the
      kacpi_hotplug queue.
      
      It's a longer patch, but at least we maintain the benefit of having separate
      queues in ACPI.  This, of course, is still only a workaround the problem.
      As Bjorn and mjg pointed out, we have to refactor a lot of this code to do
      the right thing but at this point it is a better to have this code working.
      
      The acpi core places all events on the kacpi_notify queue.  When the acpiphp
      driver is loaded and a PCI card with a PCI-to-PCI bridge is removed the
      following call sequence occurs:
      
      cleanup_p2p_bridge()
      	    -> cleanup_bridge()
      		    -> acpi_remove_notify_handler()
      			    -> acpi_os_wait_events_complete()
      				    -> flush_workqueue(kacpi_notify_wq)
      
      which is the queue we are currently executing on and the process will hang.
      
      Move all hotplug acpiphp events onto the kacpi_hotplug workqueue.  In
      handle_hotplug_event_bridge() and handle_hotplug_event_func() we can simply
      push the rest of the work onto the kacpi_hotplug queue and then avoid the
      deadlock.
      Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
      Cc: mjg@redhat.com
      Cc: bhelgaas@google.com
      Cc: linux-acpi@vger.kernel.org
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      6af8bef1
  5. 03 8月, 2011 1 次提交
  6. 27 7月, 2011 1 次提交
  7. 17 7月, 2011 1 次提交
  8. 14 7月, 2011 7 次提交
  9. 29 5月, 2011 2 次提交
  10. 10 5月, 2011 4 次提交
  11. 31 3月, 2011 1 次提交
  12. 25 3月, 2011 1 次提交
  13. 23 3月, 2011 2 次提交
  14. 22 3月, 2011 1 次提交
    • H
      ACPI, APEI, Add ERST record ID cache · 885b976f
      Huang Ying 提交于
      APEI ERST firmware interface and implementation has no multiple users
      in mind.  For example, if there is four records in storage with ID: 1,
      2, 3 and 4, if two ERST readers enumerate the records via
      GET_NEXT_RECORD_ID as follow,
      
      reader 1		reader 2
      1
      			2
      3
      			4
      -1
      			-1
      
      where -1 signals there is no more record ID.
      
      Reader 1 has no chance to check record 2 and 4, while reader 2 has no
      chance to check record 1 and 3.  And any other GET_NEXT_RECORD_ID will
      return -1, that is, other readers will has no chance to check any
      record even they are not cleared by anyone.
      
      This makes raw GET_NEXT_RECORD_ID not suitable for used by multiple
      users.
      
      To solve the issue, an in-memory ERST record ID cache is designed and
      implemented.  When enumerating record ID, the ID returned by
      GET_NEXT_RECORD_ID is added into cache in addition to be returned to
      caller.  So other readers can check the cache to get all record ID
      available.
      Signed-off-by: NHuang Ying <ying.huang@intel.com>
      Reviewed-by: NAndi Kleen <ak@linux.intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      885b976f
  15. 15 3月, 2011 1 次提交
  16. 03 3月, 2011 3 次提交
  17. 25 2月, 2011 1 次提交
    • R
      ACPI: Remove the wakeup.run_wake_count device field · 51907267
      Rafael J. Wysocki 提交于
      The wakeup.run_wake_count ACPI device field is only used by the PCI
      runtime PM code to "protect" devices from being prepared for
      generating wakeup signals more than once in a row.  However, it
      really doesn't provide any protection, because (1) all of the
      functions it is supposed to protect use their own reference counters
      effectively ensuring that the device will be set up for generating
      wakeup signals just once and (2) the PCI runtime PM code uses
      wakeup.run_wake_count in a racy way, since nothing prevents
      acpi_dev_run_wake() from being called concurrently from two different
      threads for the same device.
      
      Remove the wakeup.run_wake_count ACPI device field which is
      unnecessary, confusing and used in a wrong way.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      51907267
  18. 19 1月, 2011 2 次提交
  19. 15 1月, 2011 1 次提交
  20. 12 1月, 2011 2 次提交
    • R
      ACPI: Drop device flag wake_capable · d57d09a4
      Rafael J. Wysocki 提交于
      The wake_capable ACPI device flag is not necessary, because it is
      only used in scan.c for recording the information that _PRW is
      present for the given device.  That information is only used by
      acpi_add_single_object() to decide whether or not to call
      acpi_bus_get_wakeup_device_flags(), so the flag may be dropped
      if the _PRW check is moved to acpi_bus_get_wakeup_device_flags().
      Moreover, acpi_bus_get_wakeup_device_flags() always returns 0,
      so it really should be void.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      d57d09a4
    • R
      ACPI / PM: Drop acpi_bus_get_power() · f6767dcf
      Rafael J. Wysocki 提交于
      There are no more users of acpi_bus_get_power(), so it can be
      dropped.  Moreover, it should be dropped, because it modifies
      the device->power.state field of an ACPI device without updating
      the reference counters of the device's power resources, which is
      wrong.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      f6767dcf