On Mon, 27 Jul 2020 20:05:06 +0200,
Pierre-Louis Bossart wrote:
>
>
>
> On 7/27/20 11:44 AM, Takashi Iwai wrote:
> > We've received a regression report on Intel HD-audio controller that
> > wakes up immediately after S3 suspend. The bisection leads to the
> > commit c4c8dd6ef807 ("ALSA: hda: Skip controller resume if not
> > needed"). This commit replaces the system-suspend to use
> > pm_runtime_force_suspend() instead of the direct call of
> > __azx_runtime_suspend(). However, by some really mysterious reason,
> > pm_runtime_force_suspend() causes a spurious wakeup (although it calls
> > the same __azx_runtime_suspend() internally).
>
> Right, but __azx_runtime_suspend() is called after enabling a wake-up
> event, which is fine for pm_runtime but probably not so good for S3?
That's what I doubted at the first place, too, but unfortunately no,
it isn't the cause.
> static int azx_runtime_suspend(struct device *dev)
> {
> struct snd_card *card = dev_get_drvdata(dev);
> struct azx *chip;
>
> if (!azx_is_pm_ready(card))
> return 0;
> 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);
> }
The code above contains the check of the current power state to
SNDRV_CTL_POWER_D0. And azx_suspend() sets the power state to D3hot
before calling pm_runtime_force_suspend(), hence this WAKEEN shouldn't
be called.
And we tried to comment out this WAKEEN call completely, but the
spurious wakeup still happened. Also, even after clearing WAKKEN
explicitly, the wakeup happened. Last but not least, it happened even
after disabling the runtime PM (i.e. the pm state change happens at
first at azx_suspend() call).
So it's really mysterious.
Takashi
