* [alsa-devel] Question about runtime PM for HDA codecs
@ 2020-01-15 18:15 Sridharan, Ranjani
2020-01-15 19:39 ` Takashi Iwai
0 siblings, 1 reply; 6+ messages in thread
From: Sridharan, Ranjani @ 2020-01-15 18:15 UTC (permalink / raw)
To: Linux-ALSA, Takashi Iwai
Cc: Vehmanen, Kai, Uimonen, Jaska, Pierre-louis Bossart
Hi Takashi,
Can I please bother you with a question about how to handle the situation
with runtime PM for HDA codec on one of the Intel CML-based platforms with
an ALC285 codec.
Basically, the problem we're facing is that when using the SOF driver,
jack detection doesn't seem to work as intended because the codec gets
suspended right after the headset is plugged in.
After a bit of experimenting, what we found was that calling
snd_hda_set_power_save() with a delay of 0 or something > 0, both help with
fixing the problem.
But, I have a basic question about this. What is the expectation for
enabling the codec runtime PM?
I see that the legacy driver calls snd_hda_set_power_save() based on the
CONFIG_SND_HDA_POWER_SAVE_DEFAULT value. In the case of SOF, we do not
explicitly set this value so it is 0 by default. Also, when the codec is
registered, the runtime PM for the codec is enabled by default without
checking if the power_save delay is set to 0 or not. And later when the
snd_hda_set_power_save() is called from the legacy HDA driver probe, it
sets the use of auto suspend and the delay to be used based on the config.
Would it be correct to remove the pm_runtime_enable() call
in snd_hda_codec_register() and let the codec runtime PM enabling be set
with the call to snd_hda_set_power_save() for both the legacy HDA driver
and the SOF driver?
Thanks,
Ranjani
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [alsa-devel] Question about runtime PM for HDA codecs
2020-01-15 18:15 [alsa-devel] Question about runtime PM for HDA codecs Sridharan, Ranjani
@ 2020-01-15 19:39 ` Takashi Iwai
2020-01-15 20:28 ` Sridharan, Ranjani
0 siblings, 1 reply; 6+ messages in thread
From: Takashi Iwai @ 2020-01-15 19:39 UTC (permalink / raw)
To: Sridharan, Ranjani
Cc: Vehmanen, Kai, Linux-ALSA, Uimonen, Jaska, Pierre-louis Bossart
On Wed, 15 Jan 2020 19:15:40 +0100,
Sridharan, Ranjani wrote:
>
> Hi Takashi,
>
> Can I please bother you with a question about how to handle the situation
> with runtime PM for HDA codec on one of the Intel CML-based platforms with
> an ALC285 codec.
> Basically, the problem we're facing is that when using the SOF driver,
> jack detection doesn't seem to work as intended because the codec gets
> suspended right after the headset is plugged in.
The codec going to the runtime suspend is actually the right
behavior. Even the bus goes down if the codec has AC_PWRST_CLKSTOP
and AC_PWRST_EPSS capabilities, the link goes also down. But this
means that the irq is still triggered upon the jack detection event
even in D3 state.
I guess this implementation is missing in SOF DSP side.
> After a bit of experimenting, what we found was that calling
> snd_hda_set_power_save() with a delay of 0 or something > 0, both help with
> fixing the problem.
>
> But, I have a basic question about this. What is the expectation for
> enabling the codec runtime PM?
> I see that the legacy driver calls snd_hda_set_power_save() based on the
> CONFIG_SND_HDA_POWER_SAVE_DEFAULT value. In the case of SOF, we do not
> explicitly set this value so it is 0 by default. Also, when the codec is
> registered, the runtime PM for the codec is enabled by default without
> checking if the power_save delay is set to 0 or not. And later when the
> snd_hda_set_power_save() is called from the legacy HDA driver probe, it
> sets the use of auto suspend and the delay to be used based on the config.
The runtime setup purely depends on the user's configuration. As
default, kernel may set to certain value via Kconfig, and some codecs
(e.g. HDMI) prefer the runtime PM enablement as default. Other than
that, it's supposed to be set explicitly via sysfs, typically from
udev rules.
The driver initial code does set up some default value from historical
reasons, but basically the setup is done from user-space.
> Would it be correct to remove the pm_runtime_enable() call
> in snd_hda_codec_register() and let the codec runtime PM enabling be set
> with the call to snd_hda_set_power_save() for both the legacy HDA driver
> and the SOF driver?
The basic problem isn't about how the runtime PM is set. It can be
changed at any time, and the driver should work no matter how it is
set.
thanks,
Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [alsa-devel] Question about runtime PM for HDA codecs
2020-01-15 19:39 ` Takashi Iwai
@ 2020-01-15 20:28 ` Sridharan, Ranjani
2020-01-16 7:03 ` Takashi Iwai
0 siblings, 1 reply; 6+ messages in thread
From: Sridharan, Ranjani @ 2020-01-15 20:28 UTC (permalink / raw)
To: Takashi Iwai
Cc: Vehmanen, Kai, Linux-ALSA, Uimonen, Jaska, Pierre-louis Bossart
On Wed, Jan 15, 2020 at 11:40 AM Takashi Iwai <tiwai@suse.de> wrote:
> On Wed, 15 Jan 2020 19:15:40 +0100,
> Sridharan, Ranjani wrote:
> >
> > Hi Takashi,
> >
> > Can I please bother you with a question about how to handle the situation
> > with runtime PM for HDA codec on one of the Intel CML-based platforms
> with
> > an ALC285 codec.
> > Basically, the problem we're facing is that when using the SOF driver,
> > jack detection doesn't seem to work as intended because the codec gets
> > suspended right after the headset is plugged in.
>
> The codec going to the runtime suspend is actually the right
> behavior. Even the bus goes down if the codec has AC_PWRST_CLKSTOP
> and AC_PWRST_EPSS capabilities, the link goes also down. But this
> means that the irq is still triggered upon the jack detection event
> even in D3 state.
> I guess this implementation is missing in SOF DSP side.
>
We do have the WAKEEN feature implemented in SOF for capturing the jack
detecting events when the SOF device is in D3. We have this feature working
as expected on some previous platforms.
The problem specific to the ALC285 codec.
>
> > After a bit of experimenting, what we found was that calling
> > snd_hda_set_power_save() with a delay of 0 or something > 0, both help
> with
> > fixing the problem.
> >
> > But, I have a basic question about this. What is the expectation for
> > enabling the codec runtime PM?
> > I see that the legacy driver calls snd_hda_set_power_save() based on the
> > CONFIG_SND_HDA_POWER_SAVE_DEFAULT value. In the case of SOF, we do not
> > explicitly set this value so it is 0 by default. Also, when the codec is
> > registered, the runtime PM for the codec is enabled by default without
> > checking if the power_save delay is set to 0 or not. And later when the
> > snd_hda_set_power_save() is called from the legacy HDA driver probe, it
> > sets the use of auto suspend and the delay to be used based on the
> config.
>
> The runtime setup purely depends on the user's configuration. As
> default, kernel may set to certain value via Kconfig, and some codecs
> (e.g. HDMI) prefer the runtime PM enablement as default. Other than
> that, it's supposed to be set explicitly via sysfs, typically from
> udev rules.
>
> The driver initial code does set up some default value from historical
> reasons, but basically the setup is done from user-space.
>
> > Would it be correct to remove the pm_runtime_enable() call
> > in snd_hda_codec_register() and let the codec runtime PM enabling be set
> > with the call to snd_hda_set_power_save() for both the legacy HDA driver
> > and the SOF driver?
>
> The basic problem isn't about how the runtime PM is set. It can be
> changed at any time, and the driver should work no matter how it is
> set.
In this case then, I suppose it is up to the SOF driver to set the auto
suspend delay to define the expected default behaviour?
Thanks,
Ranjani
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [alsa-devel] Question about runtime PM for HDA codecs
2020-01-15 20:28 ` Sridharan, Ranjani
@ 2020-01-16 7:03 ` Takashi Iwai
2020-01-16 7:42 ` Jaska Uimonen
0 siblings, 1 reply; 6+ messages in thread
From: Takashi Iwai @ 2020-01-16 7:03 UTC (permalink / raw)
To: Sridharan, Ranjani
Cc: Vehmanen, Kai, Linux-ALSA, Uimonen, Jaska, Pierre-louis Bossart
On Wed, 15 Jan 2020 21:28:20 +0100,
Sridharan, Ranjani wrote:
>
> [1 <text/plain; UTF-8 (7bit)>]
>
> On Wed, Jan 15, 2020 at 11:40 AM Takashi Iwai <tiwai@suse.de> wrote:
>
> On Wed, 15 Jan 2020 19:15:40 +0100,
> Sridharan, Ranjani wrote:
> >
> > Hi Takashi,
> >
> > Can I please bother you with a question about how to handle the
> situation
> > with runtime PM for HDA codec on one of the Intel CML-based platforms
> with
> > an ALC285 codec.
> > Basically, the problem we're facing is that when using the SOF driver,
> > jack detection doesn't seem to work as intended because the codec gets
> > suspended right after the headset is plugged in.
>
> The codec going to the runtime suspend is actually the right
> behavior. Even the bus goes down if the codec has AC_PWRST_CLKSTOP
> and AC_PWRST_EPSS capabilities, the link goes also down. But this
> means that the irq is still triggered upon the jack detection event
> even in D3 state.
> I guess this implementation is missing in SOF DSP side.
>
> We do have the WAKEEN feature implemented in SOF for capturing the jack
> detecting events when the SOF device is in D3. We have this feature working as
> expected on some previous platforms.
Which codec was it?
> The problem specific to the ALC285 codec.
AFAIK, there is no specific change to ALC285 that is relevant with
runtime PM.
> > After a bit of experimenting, what we found was that calling
> > snd_hda_set_power_save() with a delay of 0 or something > 0, both help
> with
> > fixing the problem.
> >
> > But, I have a basic question about this. What is the expectation for
> > enabling the codec runtime PM?
> > I see that the legacy driver calls snd_hda_set_power_save() based on the
> > CONFIG_SND_HDA_POWER_SAVE_DEFAULT value. In the case of SOF, we do not
> > explicitly set this value so it is 0 by default. Also, when the codec is
> > registered, the runtime PM for the codec is enabled by default without
> > checking if the power_save delay is set to 0 or not. And later when the
> > snd_hda_set_power_save() is called from the legacy HDA driver probe, it
> > sets the use of auto suspend and the delay to be used based on the
> config.
>
> The runtime setup purely depends on the user's configuration. As
> default, kernel may set to certain value via Kconfig, and some codecs
> (e.g. HDMI) prefer the runtime PM enablement as default. Other than
> that, it's supposed to be set explicitly via sysfs, typically from
> udev rules.
>
> The driver initial code does set up some default value from historical
> reasons, but basically the setup is done from user-space.
>
> > Would it be correct to remove the pm_runtime_enable() call
> > in snd_hda_codec_register() and let the codec runtime PM enabling be set
> > with the call to snd_hda_set_power_save() for both the legacy HDA driver
> > and the SOF driver?
>
> The basic problem isn't about how the runtime PM is set. It can be
> changed at any time, and the driver should work no matter how it is
> set.
>
> In this case then, I suppose it is up to the SOF driver to set the auto
> suspend delay to define the expected default behaviour?
Yes and no. User can still set the value and the driver still needs
to behave correctly no matter what value is set.
thanks,
Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [alsa-devel] Question about runtime PM for HDA codecs
2020-01-16 7:03 ` Takashi Iwai
@ 2020-01-16 7:42 ` Jaska Uimonen
2020-01-16 9:20 ` Takashi Iwai
0 siblings, 1 reply; 6+ messages in thread
From: Jaska Uimonen @ 2020-01-16 7:42 UTC (permalink / raw)
To: Takashi Iwai, Sridharan, Ranjani
Cc: Vehmanen, Kai, Linux-ALSA, Uimonen, Jaska, Pierre-louis Bossart
On Thu, 2020-01-16 at 08:03 +0100, Takashi Iwai wrote:
> On Wed, 15 Jan 2020 21:28:20 +0100,
> Sridharan, Ranjani wrote:
> > [1 <text/plain; UTF-8 (7bit)>]
> >
> > On Wed, Jan 15, 2020 at 11:40 AM Takashi Iwai <tiwai@suse.de>
> > wrote:
> >
> > On Wed, 15 Jan 2020 19:15:40 +0100,
> > Sridharan, Ranjani wrote:
> > >
> > > Hi Takashi,
> > >
> > > Can I please bother you with a question about how to handle
> > the
> > situation
> > > with runtime PM for HDA codec on one of the Intel CML-based
> > platforms
> > with
> > > an ALC285 codec.
> > > Basically, the problem we're facing is that when using the
> > SOF driver,
> > > jack detection doesn't seem to work as intended because the
> > codec gets
> > > suspended right after the headset is plugged in.
> >
> > The codec going to the runtime suspend is actually the right
> > behavior. Even the bus goes down if the codec has
> > AC_PWRST_CLKSTOP
> > and AC_PWRST_EPSS capabilities, the link goes also down. But
> > this
> > means that the irq is still triggered upon the jack detection
> > event
> > even in D3 state.
> > I guess this implementation is missing in SOF DSP side.
> >
> > We do have the WAKEEN feature implemented in SOF for capturing the
> > jack
> > detecting events when the SOF device is in D3. We have this feature
> > working as
> > expected on some previous platforms.
>
> Which codec was it?
>
> > The problem specific to the ALC285 codec.
>
> AFAIK, there is no specific change to ALC285 that is relevant with
> runtime PM.
>
>
> > > After a bit of experimenting, what we found was that calling
> > > snd_hda_set_power_save() with a delay of 0 or something > 0,
> > both help
> > with
> > > fixing the problem.
> > >
> > > But, I have a basic question about this. What is the
> > expectation for
> > > enabling the codec runtime PM?
> > > I see that the legacy driver calls snd_hda_set_power_save()
> > based on the
> > > CONFIG_SND_HDA_POWER_SAVE_DEFAULT value. In the case of SOF,
> > we do not
> > > explicitly set this value so it is 0 by default. Also, when
> > the codec is
> > > registered, the runtime PM for the codec is enabled by
> > default without
> > > checking if the power_save delay is set to 0 or not. And
> > later when the
> > > snd_hda_set_power_save() is called from the legacy HDA driver
> > probe, it
> > > sets the use of auto suspend and the delay to be used based
> > on the
> > config.
> >
> > The runtime setup purely depends on the user's configuration.
> > As
> > default, kernel may set to certain value via Kconfig, and some
> > codecs
> > (e.g. HDMI) prefer the runtime PM enablement as default. Other
> > than
> > that, it's supposed to be set explicitly via sysfs, typically
> > from
> > udev rules.
> >
> > The driver initial code does set up some default value from
> > historical
> > reasons, but basically the setup is done from user-space.
> >
> > > Would it be correct to remove the pm_runtime_enable() call
> > > in snd_hda_codec_register() and let the codec runtime PM
> > enabling be set
> > > with the call to snd_hda_set_power_save() for both the legacy
> > HDA driver
> > > and the SOF driver?
> >
> > The basic problem isn't about how the runtime PM is set. It
> > can be
> > changed at any time, and the driver should work no matter how
> > it is
> > set.
> >
> > In this case then, I suppose it is up to the SOF driver to set the
> > auto
> > suspend delay to define the expected default behaviour?
>
> Yes and no. User can still set the value and the driver still needs
> to behave correctly no matter what value is set.
>
Takashi, AFAIK with legacy Intel HDA you are always setting
suspend_delay to 0 ("PM off") or some value in seconds. So I don't
even know how you would configure immeadiate suspend with legacy HDA.
With SOF we we're able to cause this immediate suspend for the codec by
not calling any HDA delay setting function (sof probe vs. intel hda
probe).
This has been working so far, but we noticed that Mic Jack detection
with some codecs didn't like this immediate suspend and we also got
some informal info from Realtek folks that the reason could be the
quick suspend. And indeed if I set HDA suspend delay from SOF
to SOF default 2s or 0 (PM off) the Mic Jack starts to work.
So setting the delay from SOF solves the Mic Jack issue, but there is
static "default power save" function in hda_intel.c, which involves
PM quirks and value set in CONFIG_SND_HDA_POWER_SAVE_DEFAULT. So I
would like to call this function and not duplicate the quirks in SOF
code. Not sure if these platforms in the quirks will ever run SOF
though...
br,
Jaska
>
> thanks,
>
> Takashi
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [alsa-devel] Question about runtime PM for HDA codecs
2020-01-16 7:42 ` Jaska Uimonen
@ 2020-01-16 9:20 ` Takashi Iwai
0 siblings, 0 replies; 6+ messages in thread
From: Takashi Iwai @ 2020-01-16 9:20 UTC (permalink / raw)
To: Jaska Uimonen
Cc: Vehmanen, Kai, Uimonen, Jaska, Linux-ALSA, Sridharan, Ranjani,
Pierre-louis Bossart
On Thu, 16 Jan 2020 08:42:24 +0100,
Jaska Uimonen wrote:
>
> On Thu, 2020-01-16 at 08:03 +0100, Takashi Iwai wrote:
> > On Wed, 15 Jan 2020 21:28:20 +0100,
> > Sridharan, Ranjani wrote:
> > > [1 <text/plain; UTF-8 (7bit)>]
> > >
> > > On Wed, Jan 15, 2020 at 11:40 AM Takashi Iwai <tiwai@suse.de>
> > > wrote:
> > >
> > > On Wed, 15 Jan 2020 19:15:40 +0100,
> > > Sridharan, Ranjani wrote:
> > > >
> > > > Hi Takashi,
> > > >
> > > > Can I please bother you with a question about how to handle
> > > the
> > > situation
> > > > with runtime PM for HDA codec on one of the Intel CML-based
> > > platforms
> > > with
> > > > an ALC285 codec.
> > > > Basically, the problem we're facing is that when using the
> > > SOF driver,
> > > > jack detection doesn't seem to work as intended because the
> > > codec gets
> > > > suspended right after the headset is plugged in.
> > >
> > > The codec going to the runtime suspend is actually the right
> > > behavior. Even the bus goes down if the codec has
> > > AC_PWRST_CLKSTOP
> > > and AC_PWRST_EPSS capabilities, the link goes also down. But
> > > this
> > > means that the irq is still triggered upon the jack detection
> > > event
> > > even in D3 state.
> > > I guess this implementation is missing in SOF DSP side.
> > >
> > > We do have the WAKEEN feature implemented in SOF for capturing the
> > > jack
> > > detecting events when the SOF device is in D3. We have this feature
> > > working as
> > > expected on some previous platforms.
> >
> > Which codec was it?
> >
> > > The problem specific to the ALC285 codec.
> >
> > AFAIK, there is no specific change to ALC285 that is relevant with
> > runtime PM.
> >
> >
> > > > After a bit of experimenting, what we found was that calling
> > > > snd_hda_set_power_save() with a delay of 0 or something > 0,
> > > both help
> > > with
> > > > fixing the problem.
> > > >
> > > > But, I have a basic question about this. What is the
> > > expectation for
> > > > enabling the codec runtime PM?
> > > > I see that the legacy driver calls snd_hda_set_power_save()
> > > based on the
> > > > CONFIG_SND_HDA_POWER_SAVE_DEFAULT value. In the case of SOF,
> > > we do not
> > > > explicitly set this value so it is 0 by default. Also, when
> > > the codec is
> > > > registered, the runtime PM for the codec is enabled by
> > > default without
> > > > checking if the power_save delay is set to 0 or not. And
> > > later when the
> > > > snd_hda_set_power_save() is called from the legacy HDA driver
> > > probe, it
> > > > sets the use of auto suspend and the delay to be used based
> > > on the
> > > config.
> > >
> > > The runtime setup purely depends on the user's configuration.
> > > As
> > > default, kernel may set to certain value via Kconfig, and some
> > > codecs
> > > (e.g. HDMI) prefer the runtime PM enablement as default. Other
> > > than
> > > that, it's supposed to be set explicitly via sysfs, typically
> > > from
> > > udev rules.
> > >
> > > The driver initial code does set up some default value from
> > > historical
> > > reasons, but basically the setup is done from user-space.
> > >
> > > > Would it be correct to remove the pm_runtime_enable() call
> > > > in snd_hda_codec_register() and let the codec runtime PM
> > > enabling be set
> > > > with the call to snd_hda_set_power_save() for both the legacy
> > > HDA driver
> > > > and the SOF driver?
> > >
> > > The basic problem isn't about how the runtime PM is set. It
> > > can be
> > > changed at any time, and the driver should work no matter how
> > > it is
> > > set.
> > >
> > > In this case then, I suppose it is up to the SOF driver to set the
> > > auto
> > > suspend delay to define the expected default behaviour?
> >
> > Yes and no. User can still set the value and the driver still needs
> > to behave correctly no matter what value is set.
> >
> Takashi, AFAIK with legacy Intel HDA you are always setting
> suspend_delay to 0 ("PM off") or some value in seconds. So I don't
> even know how you would configure immeadiate suspend with legacy HDA.
>
> With SOF we we're able to cause this immediate suspend for the codec by
> not calling any HDA delay setting function (sof probe vs. intel hda
> probe).
>
> This has been working so far, but we noticed that Mic Jack detection
> with some codecs didn't like this immediate suspend and we also got
> some informal info from Realtek folks that the reason could be the
> quick suspend. And indeed if I set HDA suspend delay from SOF
> to SOF default 2s or 0 (PM off) the Mic Jack starts to work.
OK, point taken. So the same problem could happen on the legacy
HD-audio if user sets it up in that way. (You can still override the
autosuspend_delay_ms value via sysfs after the driver setup.)
> So setting the delay from SOF solves the Mic Jack issue, but there is
> static "default power save" function in hda_intel.c, which involves
> PM quirks and value set in CONFIG_SND_HDA_POWER_SAVE_DEFAULT. So I
> would like to call this function and not duplicate the quirks in SOF
> code. Not sure if these platforms in the quirks will ever run SOF
> though...
Yeah, that sounds feasible.
It would be good if we can set the min value, but as far as I read the
code, the runtime PM base code simply allows any value as is, so there
is no way to set the lower limit.
BTW, this reminds me of another similar topic: currently, most systems
use power_save option and sysfs interface to adjust the runtime PM
behavior dynamically. This feature will be lost on SOF.
Though, nowadays there is little merit to disable power-saving and I
don't know whether there is any requirement for this feature.
thanks,
Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-01-16 9:21 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-15 18:15 [alsa-devel] Question about runtime PM for HDA codecs Sridharan, Ranjani
2020-01-15 19:39 ` Takashi Iwai
2020-01-15 20:28 ` Sridharan, Ranjani
2020-01-16 7:03 ` Takashi Iwai
2020-01-16 7:42 ` Jaska Uimonen
2020-01-16 9:20 ` Takashi Iwai
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.