Messages in this thread | | | Date | Thu, 15 Mar 2018 16:12:44 +0530 | From | "Subhransu S. Prusty" <> | Subject | Re: [PATCH] [sound] hdac-codec runtime suspended at PM:Suspend. |
| |
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: > > On Wed, Mar 14, 2018 at 11:38 AM, Anshuman Gupta > > <anshuman.gupta@intel.com> wrote: > > > On Mon, Mar 12, 2018 at 12:26:53PM +0100, Rafael J. Wysocki wrote: > > >> On Mon, Mar 12, 2018 at 12:17 PM, Anshuman Gupta > > >> <anshuman.gupta@intel.com> wrote: > > >> > > > >> > + 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. > > > > 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
> > >> > /* Power up afg */ > > >> > snd_hdac_codec_read(hdac, hdac->afg, 0, AC_VERB_SET_POWER_STATE, > > >> > AC_PWRST_D0); > > >> > -- > > >> > 2.7.4 > > -- > Thanks, > Anshuman
--
| |