On Thu, 24 Jan 2019 20:01:13 +0100, Sameer Pujar wrote:
On 1/25/2019 12:13 AM, Takashi Iwai wrote:
On Thu, 24 Jan 2019 19:15:12 +0100, Sameer Pujar wrote:
On 1/24/2019 9:34 PM, Takashi Iwai wrote:
On Thu, 24 Jan 2019 16:57:11 +0100, Sameer Pujar wrote:
The runtime PM count is incremented and set to active during hda codec device init, but it is decremented and set to suspend during exit only. Hence the runtime PM status is always active and hda device cannot be put to runtime suspend. Keeping device usage active for entire period, though nothing really happening on the device, seems unnecessary.
This patch avoides incrementing runtime PM usage count of the device.
Signed-off-by: Sameer Pujar spujar@nvidia.com Reviewed-by: Ravindra Lokhande rlokhande@nvidia.com Reviewed-by: Mohan Kumar D mkumard@nvidia.com
This breaks the existing things, I'm afraid. Did you really test and verify the behavior...?
The runtime PM refcount is decremented at snd_hda_codec_register(), and that's the place to let runtime suspend of the codec really effective. (It's not about the controller, though.)
It worked fine at my end. I could put the device to runtime suspend and resume it back multiple times. Since you are suggesting it could break things, let me rework on the patch and dig up a little more to see if there is better way to fix this.
Well, I don't see what you want to "fix". Do you see any bug?
I was expecting the device to be runtime suspended, once probe is finished, until I playback something on it. But it appears that rutntime PM is always active and runtime PM suspend callback never happens.
Does the behavior really appear? If so, it's a bug.
The current design is to enable the runtime PM *after* the device registration. Otherwise it makes no sense -- the problem doesn't finish yet before that point.
thanks,
Takashi