| Message ID | 20210118130937.164650-1-kai.heng.feng@canonical.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | ALSA: hda: Balance runtime/system PM if direct-complete is disabled | expand |
On Mon, 18 Jan 2021 14:09:36 +0100, Kai-Heng Feng wrote: > > HDA controller can't be runtime-suspended after commit 215a22ed31a1 > ("ALSA: hda: Refactor codjc PM to use direct-complete optimization"), > which enables direct-complete for HDA codec. > > The HDA codec driver didn't expect direct-complete will be disabled > after it returns a positive value from prepare() callback. However, > there are some places that PM core can disable direct-complete. For > instance, system hibernation or when codec has subordinates like LEDs. Hmm. This sounds rather like the approach using the direct-complete isn't well suited for the purpose? The increasing number of regression reports worries me. > So if a device is prepared for direct-complete but PM core still calls > codec's suspend or freeze callback, resume the device to keep PM > operations balanced. I find the ping-pong of the resume/suspend there a bit odd. It's no refcount management but it invokes the real resume there, which is involved with lots of operations. Can we rather skip the hda_codec_suspend() call instead (while changing dev->power.power_state)? thanks, Takashi > Reported-by: Kenneth R. Crudup <kenny@panix.com> > Fixes: 215a22ed31a1 ("ALSA: hda: Refactor codec PM to use direct-complete optimization") > Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> > --- > sound/pci/hda/hda_codec.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c > index 687216e74526..0afbced979df 100644 > --- a/sound/pci/hda/hda_codec.c > +++ b/sound/pci/hda/hda_codec.c > @@ -2997,6 +2997,9 @@ static void hda_codec_pm_complete(struct device *dev) > > static int hda_codec_pm_suspend(struct device *dev) > { > + if (pm_runtime_status_suspended(dev)) > + pm_runtime_resume(dev); > + > dev->power.power_state = PMSG_SUSPEND; > return hda_codec_suspend(dev); > } > @@ -3009,6 +3012,9 @@ static int hda_codec_pm_resume(struct device *dev) > > static int hda_codec_pm_freeze(struct device *dev) > { > + if (pm_runtime_status_suspended(dev)) > + pm_runtime_resume(dev); > + > dev->power.power_state = PMSG_FREEZE; > return hda_codec_suspend(dev); > } > -- > 2.29.2 >
On Mon, Jan 18, 2021 at 9:21 PM Takashi Iwai <tiwai@suse.de> wrote: > > On Mon, 18 Jan 2021 14:09:36 +0100, > Kai-Heng Feng wrote: > > > > HDA controller can't be runtime-suspended after commit 215a22ed31a1 > > ("ALSA: hda: Refactor codjc PM to use direct-complete optimization"), > > which enables direct-complete for HDA codec. > > > > The HDA codec driver didn't expect direct-complete will be disabled > > after it returns a positive value from prepare() callback. However, > > there are some places that PM core can disable direct-complete. For > > instance, system hibernation or when codec has subordinates like LEDs. > > Hmm. This sounds rather like the approach using the direct-complete > isn't well suited for the purpose? The increasing number of > regression reports worries me. Direct-complete works fine on HDA controller but so far not so on HDA codec. I think the main reason is that the codec doesn't have the middle layer to handle the detail, while HDA controller has PCI bus to deal with them. > > > So if a device is prepared for direct-complete but PM core still calls > > codec's suspend or freeze callback, resume the device to keep PM > > operations balanced. > > I find the ping-pong of the resume/suspend there a bit odd. It's no > refcount management but it invokes the real resume there, which is > involved with lots of operations. Yes. I'll find a better approach to address this. > > Can we rather skip the hda_codec_suspend() call instead (while > changing dev->power.power_state)? Maybe we can revert the most of the commit, and just leave hda_codec_pm_complete(), which is the most relevant part of the patch. Let me test a bit and send a new patch. Let me know if you don't like this approach. A question a bit unrelated to the discussion - how does snd_hdac_power_up_pm() work for concurrent resume? It can work for recursive call, but what if there are concurrent resume request, but pm_runtime_get_sync() is still running? The second call may access the codec which hasn't completed resume. Kai-Heng > > > thanks, > > Takashi > > > Reported-by: Kenneth R. Crudup <kenny@panix.com> > > Fixes: 215a22ed31a1 ("ALSA: hda: Refactor codec PM to use direct-complete optimization") > > Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> > > --- > > sound/pci/hda/hda_codec.c | 6 ++++++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c > > index 687216e74526..0afbced979df 100644 > > --- a/sound/pci/hda/hda_codec.c > > +++ b/sound/pci/hda/hda_codec.c > > @@ -2997,6 +2997,9 @@ static void hda_codec_pm_complete(struct device *dev) > > > > static int hda_codec_pm_suspend(struct device *dev) > > { > > + if (pm_runtime_status_suspended(dev)) > > + pm_runtime_resume(dev); > > + > > dev->power.power_state = PMSG_SUSPEND; > > return hda_codec_suspend(dev); > > } > > @@ -3009,6 +3012,9 @@ static int hda_codec_pm_resume(struct device *dev) > > > > static int hda_codec_pm_freeze(struct device *dev) > > { > > + if (pm_runtime_status_suspended(dev)) > > + pm_runtime_resume(dev); > > + > > dev->power.power_state = PMSG_FREEZE; > > return hda_codec_suspend(dev); > > } > > -- > > 2.29.2 > >
diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index 687216e74526..0afbced979df 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -2997,6 +2997,9 @@ static void hda_codec_pm_complete(struct device *dev) static int hda_codec_pm_suspend(struct device *dev) { + if (pm_runtime_status_suspended(dev)) + pm_runtime_resume(dev); + dev->power.power_state = PMSG_SUSPEND; return hda_codec_suspend(dev); } @@ -3009,6 +3012,9 @@ static int hda_codec_pm_resume(struct device *dev) static int hda_codec_pm_freeze(struct device *dev) { + if (pm_runtime_status_suspended(dev)) + pm_runtime_resume(dev); + dev->power.power_state = PMSG_FREEZE; return hda_codec_suspend(dev); }
HDA controller can't be runtime-suspended after commit 215a22ed31a1 ("ALSA: hda: Refactor codjc PM to use direct-complete optimization"), which enables direct-complete for HDA codec. The HDA codec driver didn't expect direct-complete will be disabled after it returns a positive value from prepare() callback. However, there are some places that PM core can disable direct-complete. For instance, system hibernation or when codec has subordinates like LEDs. So if a device is prepared for direct-complete but PM core still calls codec's suspend or freeze callback, resume the device to keep PM operations balanced. Reported-by: Kenneth R. Crudup <kenny@panix.com> Fixes: 215a22ed31a1 ("ALSA: hda: Refactor codec PM to use direct-complete optimization") Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> --- sound/pci/hda/hda_codec.c | 6 ++++++ 1 file changed, 6 insertions(+)