All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kai-Heng Feng <kai.heng.feng@canonical.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: tiwai@suse.com, Jaroslav Kysela <perex@perex.cz>,
	Kai Vehmanen <kai.vehmanen@linux.intel.com>,
	Alex Deucher <alexander.deucher@amd.com>,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	"moderated list:SOUND" <alsa-devel@alsa-project.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/4] ALSA: hda: Refactor controller PM to use direct-complete optimization
Date: Fri, 23 Oct 2020 21:02:35 +0800	[thread overview]
Message-ID: <98CFD5BD-3BA0-4A7A-8C24-D6004F019CDF@canonical.com> (raw)
In-Reply-To: <s5hh7ql898j.wl-tiwai@suse.de>



> On Oct 23, 2020, at 19:36, Takashi Iwai <tiwai@suse.de> wrote:
> 
> On Fri, 23 Oct 2020 12:23:37 +0200,
> Kai-Heng Feng wrote:
>> @@ -1103,10 +1096,8 @@ static int azx_runtime_suspend(struct device *dev)
>> 	chip = card->private_data;
>> 
>> 	/* enable controller wake up event */
>> -	if (snd_power_get_state(card) == SNDRV_CTL_POWER_D0) {
>> -		azx_writew(chip, WAKEEN, azx_readw(chip, WAKEEN) |
>> -			   STATESTS_INT_MASK);
>> -	}
>> +	azx_writew(chip, WAKEEN, azx_readw(chip, WAKEEN) |
>> +		   STATESTS_INT_MASK);
> 
> Hrm, this doesn't look safe.  Applying WAKEEN unconditionally means
> that the machine may get woken up from the system suspend, and we
> don't want that.

Yes, WAKEEN should be enabled for runtime suspend and disabled for system suspend.
In principle we should always do runtime-resume -> suspend flow when runtime and system PM requires different wakeup settings.

That also means HDA controllers can't use direct-complete at all.

However, I did some testing on keeping WAKEEN enabled for graphics card's audio controller, and they didn't wake system up.
But yes, in principle they are not safe, I'll change it in v2.

Kai-Heng

> 
> 
> thanks,
> 
> Takashi


WARNING: multiple messages have this Message-ID (diff)
From: Kai-Heng Feng <kai.heng.feng@canonical.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: "moderated list:SOUND" <alsa-devel@alsa-project.org>,
	Kai Vehmanen <kai.vehmanen@linux.intel.com>,
	open list <linux-kernel@vger.kernel.org>,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	tiwai@suse.com, Alex Deucher <alexander.deucher@amd.com>
Subject: Re: [PATCH 3/4] ALSA: hda: Refactor controller PM to use direct-complete optimization
Date: Fri, 23 Oct 2020 21:02:35 +0800	[thread overview]
Message-ID: <98CFD5BD-3BA0-4A7A-8C24-D6004F019CDF@canonical.com> (raw)
In-Reply-To: <s5hh7ql898j.wl-tiwai@suse.de>



> On Oct 23, 2020, at 19:36, Takashi Iwai <tiwai@suse.de> wrote:
> 
> On Fri, 23 Oct 2020 12:23:37 +0200,
> Kai-Heng Feng wrote:
>> @@ -1103,10 +1096,8 @@ static int azx_runtime_suspend(struct device *dev)
>> 	chip = card->private_data;
>> 
>> 	/* enable controller wake up event */
>> -	if (snd_power_get_state(card) == SNDRV_CTL_POWER_D0) {
>> -		azx_writew(chip, WAKEEN, azx_readw(chip, WAKEEN) |
>> -			   STATESTS_INT_MASK);
>> -	}
>> +	azx_writew(chip, WAKEEN, azx_readw(chip, WAKEEN) |
>> +		   STATESTS_INT_MASK);
> 
> Hrm, this doesn't look safe.  Applying WAKEEN unconditionally means
> that the machine may get woken up from the system suspend, and we
> don't want that.

Yes, WAKEEN should be enabled for runtime suspend and disabled for system suspend.
In principle we should always do runtime-resume -> suspend flow when runtime and system PM requires different wakeup settings.

That also means HDA controllers can't use direct-complete at all.

However, I did some testing on keeping WAKEEN enabled for graphics card's audio controller, and they didn't wake system up.
But yes, in principle they are not safe, I'll change it in v2.

Kai-Heng

> 
> 
> thanks,
> 
> Takashi


  reply	other threads:[~2020-10-23 13:02 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-23 10:23 [PATCH 1/4] ALSA: hda: Refactor codec PM to use direct-complete optimization Kai-Heng Feng
2020-10-23 10:23 ` Kai-Heng Feng
2020-10-23 10:23 ` [PATCH 2/4] ALSA: hda: Stop mangling PCI MSI Kai-Heng Feng
2020-10-23 10:23   ` Kai-Heng Feng
2020-10-23 11:34   ` Takashi Iwai
2020-10-23 11:34     ` Takashi Iwai
2020-10-23 12:53     ` Kai-Heng Feng
2020-10-23 12:53       ` Kai-Heng Feng
2020-10-23 12:59       ` Takashi Iwai
2020-10-23 12:59         ` Takashi Iwai
2020-10-23 10:23 ` [PATCH 3/4] ALSA: hda: Refactor controller PM to use direct-complete optimization Kai-Heng Feng
2020-10-23 10:23   ` Kai-Heng Feng
2020-10-23 11:36   ` Takashi Iwai
2020-10-23 11:36     ` Takashi Iwai
2020-10-23 13:02     ` Kai-Heng Feng [this message]
2020-10-23 13:02       ` Kai-Heng Feng
2020-10-23 15:31   ` kernel test robot
2020-10-23 15:31     ` kernel test robot
2020-10-23 15:31     ` kernel test robot
2020-10-23 10:23 ` [PATCH 4/4] ALSA: hda: Reinstate runtime_allow() for all hda controllers Kai-Heng Feng
2020-10-23 10:23   ` Kai-Heng Feng
2020-10-23 11:32 ` [PATCH 1/4] ALSA: hda: Refactor codec PM to use direct-complete optimization Takashi Iwai
2020-10-23 11:32   ` Takashi Iwai
2020-10-23 12:44   ` Kai-Heng Feng
2020-10-23 12:44     ` Kai-Heng Feng
2020-10-23 13:04     ` Takashi Iwai
2020-10-23 13:04       ` Takashi Iwai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=98CFD5BD-3BA0-4A7A-8C24-D6004F019CDF@canonical.com \
    --to=kai.heng.feng@canonical.com \
    --cc=alexander.deucher@amd.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=kai.vehmanen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=tiwai@suse.com \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.