Re: [PATCH v2 0/6] Runtime PM support (hda/tegra)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 22 Jan 2019 08:33:15 +0100,
Sameer Pujar wrote:
> 
> 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

Applied all patches now.  Thanks.


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel



[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux