[alsa-devel] [PATCH v2 0/6] Runtime PM support (hda/tegra)

[Sameer Pujar]

Background
==========
The device power management operations can be controlled with the help of
runtime power management (runtime PM) framework. In this case hda driver
can register runtime PM callbacks with the power management core (PM core).
Idea is to put the device in low power mode, when it is not getting used.
The clocks and power domains can be turned off when no use case is running
on the device. Current patch series adds necessary support to manage hda
device at runtime.

Change log
==========
v1:
------
  Patch-1: "ALSA: hda/tegra: runtime power management support"
    * runtime PM enable/disable added in device probe/remove
    * runtime PM calls are forbidden if AZX_DCAPS_PM_RUNTIME is not enabled
      in driver flags
    * worker thread uses pm_runtime_get_sync to invoke ->runtime_resume and
      pm_runtime_put to invoke ->runtime_suspend. The callbacks are added
      in subsequent patches
 
  Patch-2: "ALSA: hda/tegra: get clock handles early in probe"
    * Clock handles required for hda are acquired early in the probe. This
      is done to make use of runtime PM framework to enable/disable clocks
      in the callbacks.

  Patch-3: "ALSA: hda/tegra: add runtime PM callbacks"
    * adds runtime PM callbacks for ->runtime_suspend(), ->runtime_resume()
    * only skeleton for the callbacks is added, implementation is done in
      the subsequent patches

  Patch-4: "ALSA: hda/tegra: remove redundant clock enable API"
    * As worked thread is calling pm_runtime_get_sync() now, no need to
      enable the clock explicitly. This can be managed from callback.
    * Idea is to have clock enable and disable functionalities in runtime
      PM callbacks and the driver can make use of the above. Any device
      access should be preceded by ->runtime_resume() call.

  Patch-5: "ALSA: hda/tegra: implement runtime suspend/resume"
    * clock enable and controller initialization is moved to
      ->runtime_reesume() and the reverse is done during
      ->runtime_suspend()
    * Also during system wide power transitions, pm_runtime_force_resume()
      is invoked in system resume() and similarly for suspend case.

  Patch-6: "ALSA: hda/tegra: fix kernel panic"
    * kernel panic is happening befoe controller init is done
    * added a flag "probed" to indicate the completion of device init
    * this flag is checked before doing any device access.

  Patch-7: "ALSA: hda/tegra: add driver flag for runtime PM"
    * driver flag AZX_DCAPS_PM_RUNTIME is added if CONFIG_PM is enabled.
    * otherwise runtime PM calls will be forbidden and act as dummy calls

v1-->v2
-------
  Patch-1: "ALSA: hda/tegra: runtime power management support"
    * no change
  Patch-2: "ALSA: hda/tegra: get clock handles early in probe"
    * no change
  Patch-3: "ALSA: hda/tegra: add runtime PM callbacks"
    * no change
  Patch-4: "ALSA: hda/tegra: remove redundant clock enable API"
    * no change
  Patch-5: "ALSA: hda/tegra: implement runtime suspend/resume"
    * Patch-6(v1) commit is melded into this commit
    * instead of new flag "probed", chip->running status is used
      to know the completion of probe
  Patch-6: "ALSA: hda/tegra: add driver flag for runtime PM"
    * This commit is similar to Patch-7(v1)
    * AZX_DCAPS_PM_RUNTIME is unconditionally added and CONFIG_PM
      under which above flag was added is removed

=========

Sameer Pujar (6):
  ALSA: hda/tegra: runtime power management support
  ALSA: hda/tegra: get clock handles early in probe
  ALSA: hda/tegra: add runtime PM callbacks
  ALSA: hda/tegra: remove redundant clock enable API
  ALSA: hda/tegra: implement runtime suspend/resume
  ALSA: hda/tegra: add driver flag for runtime PM

 sound/pci/hda/hda_tegra.c | 120 +++++++++++++++++++++++++++++++++-------------
 1 file changed, 88 insertions(+), 32 deletions(-)

-- 
2.7.4


-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------