1. 24 1月, 2013 1 次提交
  2. 20 1月, 2013 1 次提交
  3. 17 1月, 2013 5 次提交
    • R
      ACPI / PM: Common string representations of device power states · 96bfd3ce
      Rafael J. Wysocki 提交于
      The function returning string representations of ACPI device power
      states, state_string((), is now static, because it is only used
      internally in drivers/acpi/bus.c.  However, it will be used outside
      of that file going forward, so rename it to
      acpi_power_state_string(), add a kerneldoc comment to it and add its
      header to acpi_bus.h.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      96bfd3ce
    • R
      ACPI / PM: More visible function for retrieving device power states · ad0c3b0e
      Rafael J. Wysocki 提交于
      The function used for retrieving ACPI device power states,
      __acpi_bus_get_power(), is now static, because it is only used
      internally in drivers/acpi/bus.c.  However, it will be used
      outside of that file going forward, so rename it to
      acpi_device_get_power(), in analogy with acpi_device_set_power(),
      add a kerneldoc comment to it and add its header to acpi_bus.h.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      ad0c3b0e
    • R
      ACPI / PM: Take order attribute of wakeup power resources into account · 993cbe59
      Rafael J. Wysocki 提交于
      ACPI power resources have an order attribute that should be taken
      into account when turning them on and off, but it is not used now.
      
      Modify the power resources management code to preserve the
      spec-compliant ordering of wakeup power resources.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      993cbe59
    • R
      ACPI / PM: Take order attribute of power resources into account · 0b224527
      Rafael J. Wysocki 提交于
      ACPI power resources have an order attribute that should be taken
      into account when turning them on and off, but it is not used now.
      
      Modify the power resources management code to preserve the
      spec-compliant ordering of power resources that power states of
      devices depend on (analogous changes will be done separately for
      power resources used for wakeup).
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0b224527
    • R
      ACPI / PM: Rework the handling of devices depending on power resources · bc9b6407
      Rafael J. Wysocki 提交于
      Commit 0090def6 (ACPI: Add interface to register/unregister device
      to/from power resources) made it possible to indicate to the ACPI
      core that if the given device depends on any power resources, then
      it should be resumed as soon as all of the power resources required
      by it to transition to the D0 power state have been turned on.
      
      Unfortunately, however, this was a mistake, because all devices
      depending on power resources should be treated this way (i.e. they
      should be resumed when all power resources required by their D0
      state have been turned on) and for the majority of those devices
      the ACPI core can figure out by itself which (physical) devices
      depend on what power resources.
      
      For this reason, replace the code added by commit 0090def6 with a
      new, much more straightforward, mechanism that will be used
      internally by the ACPI core and remove all references to that code
      from kernel subsystems using ACPI.
      
      For the cases when there are (physical) devices that should be
      resumed whenever a not directly related ACPI device node goes into
      D0 as a result of power resources configuration changes, like in
      the SATA case, add two new routines, acpi_dev_pm_add_dependent()
      and acpi_dev_pm_remove_dependent(), allowing subsystems to manage
      such dependencies.  Convert the SATA subsystem to use the new
      functions accordingly.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      bc9b6407
  4. 15 1月, 2013 3 次提交
  5. 14 1月, 2013 1 次提交
  6. 03 1月, 2013 9 次提交
    • B
      ACPI: Remove unused struct acpi_pci_root.id member · e0ebda2e
      Bjorn Helgaas 提交于
      This member is never initialized and never referenced, so remove it.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e0ebda2e
    • R
      ACPI: Drop ACPI device .bind() and .unbind() callbacks · 3eec5f7a
      Rafael J. Wysocki 提交于
      Drop the .bind() and .unbind() that have no more users from
      struct acpi_device_ops and remove all of the code referring to
      them from drivers/acpi/scan.c.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      3eec5f7a
    • R
      ACPI: Add .setup() and .cleanup() callbacks to struct acpi_bus_type · 11909ca1
      Rafael J. Wysocki 提交于
      Add two new callbacks,.setup() and .cleanup(), struct acpi_bus_type
      and modify acpi_platform_notify() to call .setup() after executing
      acpi_bind_one() successfully and acpi_platform_notify_remove() to
      call .cleanup() before running acpi_unbind_one().  This will allow
      the users of struct acpi_bus_type, PCI in particular, to specify
      operations to be executed right after the given device has been
      associated with a companion struct acpi_device and right before
      it's going to be detached from that companion, respectively.
      
      The main motivation is to be able to get rid of acpi_pci_bind()
      and acpi_pci_unbind(), which are horrible horrible stuff.  [In short,
      there are three problems with them: The way they populate the .bind()
      and .unbind() callbacks of ACPI devices is rather less than
      straightforward, they require special hotplug-specific paths to be
      present in the ACPI namespace scanning code and by the time
      acpi_pci_unbind() is called the PCI device object in question may
      not exist any more.]
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      11909ca1
    • R
      ACPI: Make acpi_bus_scan() and acpi_bus_add() take only one argument · 0cd6ac52
      Rafael J. Wysocki 提交于
      The callers of acpi_bus_add() usually assume that if it has
      succeeded, then a struct acpi_device object has been attached to
      the handle passed as the first argument.  Unfortunately, however,
      this assumption is wrong, because acpi_bus_scan(), and acpi_bus_add()
      too as a result, may return a pointer to a different struct
      acpi_device object on success (it may be an object corresponding to
      one of the descendant ACPI nodes in the namespace scope below that
      handle).
      
      For this reason, the callers of acpi_bus_add() who care about
      whether or not a struct acpi_device object has been created for
      its first argument need to check that using acpi_bus_get_device()
      anyway, so the second argument of acpi_bus_add() is not really
      useful for them.  The same observation applies to acpi_bus_scan()
      executed directly from acpi_scan_init().
      
      Therefore modify the relevant callers of acpi_bus_add() to check the
      existence of the struct acpi_device in question with the help of
      acpi_bus_get_device() and drop the no longer necessary second
      argument of acpi_bus_add().  Accordingly, modify acpi_scan_init() to
      use acpi_bus_get_device() to get acpi_root and drop the no longer
      needed second argument of acpi_bus_scan().
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      0cd6ac52
    • R
      ACPI: Replace ACPI device add_type field with a match_driver flag · 209d3b17
      Rafael J. Wysocki 提交于
      After the removal of the second argument of acpi_bus_scan() there is
      no difference between the ACPI_BUS_ADD_MATCH and ACPI_BUS_ADD_START
      add types, so the add_type field in struct acpi_device may be
      replaced with a single flag.  Do that calling the flag match_driver.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      209d3b17
    • R
      ACPI: Remove the arguments of acpi_bus_add() that are not used · 636458de
      Rafael J. Wysocki 提交于
      Notice that acpi_bus_add() uses only 2 of its 4 arguments and
      redefine its header to match the body.  Update all of its callers as
      necessary and observe that this leads to quite a number of removed
      lines of code (Linus will like that).
      
      Add a kerneldoc comment documenting acpi_bus_add() and wonder how
      its callers make wrong assumptions about the second argument (make
      note to self to take care of that later).
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      636458de
    • R
      ACPI: Remove acpi_start_single_object() and acpi_bus_start() · 02f57c67
      Rafael J. Wysocki 提交于
      The ACPI PCI root bridge driver was the only ACPI driver implementing
      the .start() callback, which isn't used by any ACPI drivers any more
      now.
      
      For this reason, acpi_start_single_object() has no purpose any more,
      so remove it and all references to it.  Also remove
      acpi_bus_start_device(), whose only purpose was to call
      acpi_start_single_object().
      
      Moreover, since after the removal of acpi_bus_start_device() the
      only purpose of acpi_bus_start() remains to call
      acpi_update_all_gpes(), move that into acpi_bus_add() and drop
      acpi_bus_start() too, remove its header from acpi_bus.h and
      update all of its former users accordingly.
      
      This change was previously proposed in a different from by
      Yinghai Lu.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      02f57c67
    • R
      ACPI: Replace struct acpi_bus_ops with enum type · a2d06a1a
      Rafael J. Wysocki 提交于
      Notice that one member of struct acpi_bus_ops, acpi_op_add, is not
      used anywhere any more and the relationship between its remaining
      members, acpi_op_match and acpi_op_start, is such that it doesn't
      make sense to set the latter without setting the former at the same
      time.  Therefore, replace struct acpi_bus_ops with new a enum type,
      enum acpi_bus_add_type, with three values, ACPI_BUS_ADD_BASIC,
      ACPI_BUS_ADD_MATCH, ACPI_BUS_ADD_START, corresponding to
      both acpi_op_match and acpi_op_start unset, acpi_op_match set and
      acpi_op_start unset, and both acpi_op_match and acpi_op_start set,
      respectively.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      a2d06a1a
    • R
      ACPI: Separate adding ACPI device objects from probing ACPI drivers · 805d410f
      Rafael J. Wysocki 提交于
      Split the ACPI namespace scanning for devices into two passes, such
      that struct acpi_device objects are registerd in the first pass
      without probing ACPI drivers and the drivers are probed against them
      directly in the second pass.
      
      There are two main reasons for doing that.
      
      First, the ACPI PCI root bridge driver's .add() routine,
      acpi_pci_root_add(), causes struct pci_dev objects to be created for
      all PCI devices under the given root bridge.  Usually, there are
      corresponding ACPI device nodes in the ACPI namespace for some of
      those devices and therefore there should be "companion" struct
      acpi_device objects to attach those struct pci_dev objects to.  These
      struct acpi_device objects should exist when the corresponding
      struct pci_dev objects are created, but that is only guaranteed
      during boot and not during hotplug.  This leads to a number of
      functional differences between the boot and the hotplug cases which
      are not strictly necessary and make the code more complicated.
      
      For example, this forces the ACPI PCI root bridge driver to defer the
      registration of the just created struct pci_dev objects and to use a
      special .start() callback routine, acpi_pci_root_start(), to make
      sure that all of the "companion" struct acpi_device objects will be
      present at PCI devices registration time during hotplug.
      
      If those differences can be eliminated, we will be able to
      consolidate the boot and hotplug code paths for the enumeration and
      registration of PCI devices and to reduce the complexity of that
      code quite a bit.
      
      The second reason is that, in general, it should be possible to
      resolve conflicts of resources assigned by the BIOS to different
      devices represented by ACPI namespace nodes before any drivers bind
      to them and before they are attached to "companion" objects
      representing physical devices (such as struct pci_dev).  However, for
      this purpose we first need to enumerate all ACPI device nodes in the
      given namespace scope.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      805d410f
  7. 22 11月, 2012 1 次提交
    • A
      ACPI / PM: Introduce os_accessible flag for power_state · 1399dfcd
      Aaron Lu 提交于
      Currently we have valid flag to represent if this ACPI device power
      state is valid. A device power state is valid does not necessarily
      mean we, as OSPM, has a mean to put the device into that power state,
      e.g. D3 cold is always a valid power state for any ACPI device, but if
      there is no _PS3 or _PRx for this device, we can't really put that
      device into D3 cold power state. The same is true for D0 power state.
      
      So here comes the os_accessible flag, which is only set if the device
      has provided us the required means to put it into that power state,
      e.g. if we have _PS3 or _PRx, we can put the device into D3 cold state
      and thus, D3 cold power state's os_accessible flag will be set in this
      case.
      
      And a new wrapper inline function is added to be used to check if
      firmware has provided us a way to power off the device during runtime.
      Signed-off-by: NAaron Lu <aaron.lu@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1399dfcd
  8. 21 11月, 2012 1 次提交
  9. 16 11月, 2012 1 次提交
  10. 15 11月, 2012 17 次提交