1. 11 12月, 2012 1 次提交
    • A
      mmc: sdhci-acpi: enable runtime-pm for device HID INT33C6 · e5571397
      Adrian Hunter 提交于
      sdhci-acpi supports ACPI devices which have compatibility ID
      PNP0D40, however it is not possible to know if those devices
      will all work correctly with runtime-pm, so that must be configured
      per hardware ID.
      
      For INT33C6, several related quirks, capabilities and flags are set:
      
      	MMC_CAP_NONREMOVABLE
      		The SDIO card will never be removable
      
      	SDHCI_ACPI_RUNTIME_PM
      		Enable runtime-pm of the host controller
      
      	MMC_CAP_POWER_OFF_CARD
      		Enable runtime-pm of the SDIO card
      
      	MMC_PM_KEEP_POWER
      		SDIO card has the capability to remain powered up
      		during system suspend
      
      	SDHCI_QUIRK2_HOST_OFF_CARD_ON
      		Always do a full reset during system resume
      		because the card may be already initialized having
      		not been powered off.
      
      Wake-ups from the INT33C6 host controller are not supported, so the
      following capability must *not* be set:
      
      	MMC_PM_WAKE_SDIO_IRQ
      		Enable wake on card interrupt
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Acked-by: NChris Ball <cjb@laptop.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e5571397
  2. 08 12月, 2012 2 次提交
  3. 30 11月, 2012 2 次提交
  4. 27 11月, 2012 4 次提交
  5. 26 11月, 2012 1 次提交
  6. 24 11月, 2012 3 次提交
  7. 23 11月, 2012 1 次提交
  8. 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
  9. 21 11月, 2012 3 次提交
    • R
      ACPI / platform: Initialize ACPI handles of platform devices in advance · 863f9f30
      Rafael J. Wysocki 提交于
      The current platform device creation and registration code in
      acpi_create_platform_device() is quite convoluted.  This function
      takes an ACPI device node as an argument and eventually calls
      platform_device_register_resndata() to create and register a
      platform device object on the basis of the information contained
      in that code.  However, it doesn't associate the new platform
      device with the ACPI node directly, but instead it relies on
      acpi_platform_notify(), called from within device_add(), to find
      that ACPI node again with the help of acpi_platform_find_device()
      and acpi_platform_match() and then attach the new platform device
      to it.  This causes an additional ACPI namespace walk to happen and
      is clearly suboptimal.
      
      Use the observation that it is now possible to initialize the ACPI
      handle of a device before calling device_add() for it to make this
      code more straightforward.  Namely, add a new field to struct
      platform_device_info allowing us to pass the ACPI handle of interest
      to platform_device_register_full(), which will then use it to
      initialize the new device's ACPI handle before registering it.
      This will cause acpi_platform_notify() to use the ACPI handle from
      the device structure directly instead of using the .find_device()
      routine provided by the device's bus type.  In consequence,
      acpi_platform_bus, acpi_platform_find_device(), and
      acpi_platform_match() are not necessary any more, so remove them.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      863f9f30
    • R
      ACPI / driver core: Introduce struct acpi_dev_node and related macros · 95f8a082
      Rafael J. Wysocki 提交于
      To avoid adding an ACPI handle pointer to struct device on
      architectures that don't use ACPI, or generally when CONFIG_ACPI is
      not set, in which cases that pointer is useless, define struct
      acpi_dev_node that will contain the handle pointer if CONFIG_ACPI is
      set and will be empty otherwise and use it to represent the ACPI
      device node field in struct device.
      
      In addition to that define macros for reading and setting the ACPI
      handle of a device that don't generate code when CONFIG_ACPI is
      unset.  Modify the ACPI subsystem to use those macros instead of
      referring to the given device's ACPI handle directly.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      95f8a082
    • R
      ACPI: Allow ACPI handles of devices to be initialized in advance · f3fd0c8a
      Rafael J. Wysocki 提交于
      Currently, the ACPI handles of devices are initialized from within
      device_add(), by acpi_bind_one() called from acpi_platform_notify()
      which first uses the .find_device() routine provided by the device's
      bus type to find the matching device node in the ACPI namespace.
      This is a source of some computational overhead and, moreover, the
      correctness of the result depends on the implementation of
      .find_device() which is known to fail occasionally for some bus types
      (e.g. PCI).  In some cases, however, the corresponding ACPI device
      node is known already before calling device_add() for the given
      struct device object and the whole .find_device() dance in
      acpi_platform_notify() is then simply unnecessary.
      
      For this reason, make it possible to initialize the ACPI handles of
      devices before calling device_add() for them.  Modify
      acpi_platform_notify() to call acpi_bind_one() in advance to check
      the device's existing ACPI handle and skip the .find_device()
      search if that is successful.  Change acpi_bind_one() accordingly.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      f3fd0c8a
  10. 17 11月, 2012 1 次提交
  11. 16 11月, 2012 1 次提交
  12. 15 11月, 2012 20 次提交