linux-kernel - Re: [PATCH] [sound] hdac-codec runtime suspended at PM:Suspend.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <s5hr2o770pv.wl-tiwai@suse.de>
Date:   Mon, 26 Mar 2018 09:30:36 +0200
From:   Takashi Iwai <tiwai@...e.de>
To:     " Subhransu S. Prusty " <subhransu.s.prusty@...el.com>
Cc:     "Anshuman Gupta" <anshuman.gupta@...el.com>,
        "moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM..." 
        <alsa-devel@...a-project.org>,
        "Liam Girdwood" <lgirdwood@...il.com>,
        "Mark Brown" <broonie@...nel.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        "Jaroslav Kysela" <perex@...ex.cz>,
        "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
        "Linux PM" <linux-pm@...r.kernel.org>
Subject: Re: [PATCH] [sound] hdac-codec runtime suspended at PM:Suspend.

On Mon, 26 Mar 2018 09:03:55 +0200,
 Subhransu S. Prusty  wrote:
> 
> On Thu, Mar 15, 2018 at 09:02:30PM +0530, Anshuman Gupta wrote:
> > On Thu, Mar 15, 2018 at 04:12:44PM +0530, Subhransu S. Prusty wrote:
> > > 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@...el.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@...el.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.
> >   Let me give you insight of the issue, this driver blocks the direct complete
> >   of hda controller PCI 00:1f.3, sometimes it takes 280ms to resume hda controller
> >   from S3 and s2idle. So it does not make sense to suspend/resume hda controller 
> >   when it is already in runtime suspend.
> 
> I get it now. I think this patch needs rework to address both the issues. 
> 
> > > 
> > > I think this patch defeats the purpose.
> >   Here in this case PCI driver may kick the direct complete for hda controller
> >   https://elixir.bootlin.com/linux/latest/source/drivers/pci/pci-driver.c#L691
> >   But hdac hdmi codec driver is blocking it.
> >   So i think it will be ok to keep this codec and hda controller in runtime 
> >   suspend while entering S3 or s2idle, both can resume by runtime PM as well,
> >   will it brake any audio functionality?
> 
> There was some PM and jack detection issues (I don't recollect now) because
> of which this was added. This was due to the gfx display power and hda
> controller synchronization. The rework may be required in both hdac_hdmi
> and skylake drivers.

If it's about the power well issue, it had been fixed in multiple
ways.  In i915 side, every relevant component callback is wrapped with
power domain get/put.  And, at least HD-audio legacy side, such a
spurious notification is filtered out in the eld notifier:

static void intel_pin_eld_notify(void *audio_ptr, int port, int pipe)
{
	....
	/* skip notification during system suspend (but not in runtime PM);
	 * the state will be updated at resume
	 */
	if (snd_power_get_state(codec->card) != SNDRV_CTL_POWER_D0)
		return;
	/* ditto during suspend/resume process itself */
	if (atomic_read(&(codec)->core.in_pm))
		return;

	snd_hdac_i915_set_bclk(&codec->bus->core);
	check_presence_and_report(codec, pin_nid, dev_id);
}

Last but not least, the jack state is explicitly updated via reading
the ELD at resume callback.

In that way, we can live with the standard suspend/resume procedure.


Takashi