On Wed, Mar 14, 2018 at 09:07:14PM +0530, Anshuman Gupta wrote:

On Wed, Mar 14, 2018 at 11:53:58AM +0100, Rafael J. Wysocki wrote:

quoted

On Wed, Mar 14, 2018 at 11:38 AM, Anshuman Gupta
[off-list ref] wrote:

quoted

On Mon, Mar 12, 2018 at 12:26:53PM +0100, Rafael J. Wysocki wrote:

quoted

On Mon, Mar 12, 2018 at 12:17 PM, Anshuman Gupta
[off-list ref] wrote:

quoted

+       if (pm_runtime_status_suspended(dev))
+               return;

That, again, is somewhat fragile from the concurrency perspective.

And here you want to avoid the below if the device is still suspended.

  Yes, if we do not avoid the code below, complete callback takes about 
  3 seconds due to snd_hdac_codec_read timed out because hdac controller 
  would be in runtime suspend state.	

quoted

Why is the below code located in the ->complete callback anyway?
Shouldn't it be there in the ->resume one?

  Yes even i am also having same doubt, why these power down and power up
  sequences are part of prepare and complete callback.
  Adding driver author "Subhransu S. Prusty" to provide more inputs on this.

This driver needs a late resume as it receives a jack notification from the
i915 driver and the skl controller driver resume may not have happened and
in turn hda controller may not ready. This ensures a synchronization for
jack event during resume from S3.

I think this patch defeats the purpose.

Regards,
Subhransu

quoted

quoted

quoted

quoted

        /* Power up afg */
        snd_hdac_codec_read(hdac, hdac->afg, 0, AC_VERB_SET_POWER_STATE,
                                                        AC_PWRST_D0);
--
2.7.4

-- 
Thanks,
Anshuman

--