Question about snd_soc_card_register()
Hi Takashi,
While working on implementing the probes features in SOF using a separate card for the probe DAI links, I noticed that calling snd_soc_register_card() results in incrementing the usage_count for the device that registers the card by 2 and it is not decremented until the card is freed.
Is this the expected behaviour? Typically, we register a separate platform device for the Intel machines which in turn register the card and none of them ever enable runtime PM. So this has no impact on the parent device's runtime PM status.
I'd like to avoid creating a separate platform device just to register the card if possible while also enabling runtime PM . But when I do this today, the device cannot enter runtime suspend at all. Could you please shed some light on this?
Thanks, Ranjani
On Thu, 16 Apr 2020 07:52:45 +0200, Sridharan, Ranjani wrote:
Hi Takashi,
While working on implementing the probes features in SOF using a separate card for the probe DAI links, I noticed that calling snd_soc_register_card() results in incrementing the usage_count for the device that registers the card by 2 and it is not decremented until the card is freed.
Is this the expected behaviour? Typically, we register a separate platform device for the Intel machines which in turn register the card and none of them ever enable runtime PM. So this has no impact on the parent device's runtime PM status.
I'd like to avoid creating a separate platform device just to register the card if possible while also enabling runtime PM . But when I do this today, the device cannot enter runtime suspend at all. Could you please shed some light on this?
It's not clear how you see the things. Which device are you looking at? Typically a card object points to two different devices, one is the real device that the chip belongs to (card->dev), and another the own device object for managing the device files (card.card_dev). And in general, snd_soc_card_register() or snd_card_register() don't manipulate the runtime PM stuff by itself at all.
thanks,
Takashi
On Thu, 2020-04-16 at 09:04 +0200, Takashi Iwai wrote:
On Thu, 16 Apr 2020 07:52:45 +0200, Sridharan, Ranjani wrote:
Hi Takashi,
While working on implementing the probes features in SOF using a separate card for the probe DAI links, I noticed that calling snd_soc_register_card() results in incrementing the usage_count for the device that registers the card by 2 and it is not decremented until the card is freed.
Is this the expected behaviour? Typically, we register a separate platform device for the Intel machines which in turn register the card and none of them ever enable runtime PM. So this has no impact on the parent device's runtime PM status.
I'd like to avoid creating a separate platform device just to register the card if possible while also enabling runtime PM . But when I do this today, the device cannot enter runtime suspend at all. Could you please shed some light on this?
It's not clear how you see the things. Which device are you looking at? Typically a card object points to two different devices, one is the real device that the chip belongs to (card->dev), and another the own device object for managing the device files (card.card_dev). And in general, snd_soc_card_register() or snd_card_register() don't manipulate the runtime PM stuff by itself at all.
Its the card->dev that I am looking at. This is the device that calls devm_snd_soc_register_card(). In my tests, the usage_count for this device is 0 before calling devm_snd_soc_register_card and it is 2 after the card registration is complete.
Thanks, Ranjani
On Thu, 2020-04-16 at 06:18 -0700, Ranjani Sridharan wrote:
On Thu, 2020-04-16 at 09:04 +0200, Takashi Iwai wrote:
On Thu, 16 Apr 2020 07:52:45 +0200, Sridharan, Ranjani wrote:
Hi Takashi,
While working on implementing the probes features in SOF using a separate card for the probe DAI links, I noticed that calling snd_soc_register_card() results in incrementing the usage_count for the device that registers the card by 2 and it is not decremented until the card is freed.
Is this the expected behaviour? Typically, we register a separate platform device for the Intel machines which in turn register the card and none of them ever enable runtime PM. So this has no impact on the parent device's runtime PM status.
I'd like to avoid creating a separate platform device just to register the card if possible while also enabling runtime PM . But when I do this today, the device cannot enter runtime suspend at all. Could you please shed some light on this?
It's not clear how you see the things. Which device are you looking at? Typically a card object points to two different devices, one is the real device that the chip belongs to (card->dev), and another the own device object for managing the device files (card.card_dev). And in general, snd_soc_card_register() or snd_card_register() don't manipulate the runtime PM stuff by itself at all.
Its the card->dev that I am looking at. This is the device that calls devm_snd_soc_register_card(). In my tests, the usage_count for this device is 0 before calling devm_snd_soc_register_card and it is 2 after the card registration is complete.
I dug a bit deeper and found that this happens only if the card-
dapm.idle_bias_off is not set to true.
To be honest, I dont quite understand what the idle_bas_off setting is meant for exactly but it does prevent card->dev 's being runtime resumed in dapm_pre_sequence_async() and solves my issue.
I dont see this being set for most of the cards in the Intel machine drivers and they all manifest the same symptom I was seeing. But, it hasnt really caused any real problems because runtime PM for these platform devices is never enabled.
Thanks, Ranjani
On Thu, 16 Apr 2020 19:34:50 +0200, Ranjani Sridharan wrote:
On Thu, 2020-04-16 at 06:18 -0700, Ranjani Sridharan wrote:
On Thu, 2020-04-16 at 09:04 +0200, Takashi Iwai wrote:
On Thu, 16 Apr 2020 07:52:45 +0200, Sridharan, Ranjani wrote:
Hi Takashi,
While working on implementing the probes features in SOF using a separate card for the probe DAI links, I noticed that calling snd_soc_register_card() results in incrementing the usage_count for the device that registers the card by 2 and it is not decremented until the card is freed.
Is this the expected behaviour? Typically, we register a separate platform device for the Intel machines which in turn register the card and none of them ever enable runtime PM. So this has no impact on the parent device's runtime PM status.
I'd like to avoid creating a separate platform device just to register the card if possible while also enabling runtime PM . But when I do this today, the device cannot enter runtime suspend at all. Could you please shed some light on this?
It's not clear how you see the things. Which device are you looking at? Typically a card object points to two different devices, one is the real device that the chip belongs to (card->dev), and another the own device object for managing the device files (card.card_dev). And in general, snd_soc_card_register() or snd_card_register() don't manipulate the runtime PM stuff by itself at all.
Its the card->dev that I am looking at. This is the device that calls devm_snd_soc_register_card(). In my tests, the usage_count for this device is 0 before calling devm_snd_soc_register_card and it is 2 after the card registration is complete.
I dug a bit deeper and found that this happens only if the card-
dapm.idle_bias_off is not set to true.
To be honest, I dont quite understand what the idle_bas_off setting is meant for exactly but it does prevent card->dev 's being runtime resumed in dapm_pre_sequence_async() and solves my issue.
I dont see this being set for most of the cards in the Intel machine drivers and they all manifest the same symptom I was seeing. But, it hasnt really caused any real problems because runtime PM for these platform devices is never enabled.
Hrm, that's puzzling behavior indeed.
And it seems that Intel byt drivers are the only machine drivers that set idle_bias_off. I guess those set the flag for some workaround?
Takashi
On Fri, 2020-04-17 at 11:11 +0200, Takashi Iwai wrote:
On Thu, 16 Apr 2020 19:34:50 +0200, Ranjani Sridharan wrote:
On Thu, 2020-04-16 at 06:18 -0700, Ranjani Sridharan wrote:
On Thu, 2020-04-16 at 09:04 +0200, Takashi Iwai wrote:
On Thu, 16 Apr 2020 07:52:45 +0200, Sridharan, Ranjani wrote:
Hi Takashi,
While working on implementing the probes features in SOF using a separate card for the probe DAI links, I noticed that calling snd_soc_register_card() results in incrementing the usage_count for the device that registers the card by 2 and it is not decremented until the card is freed.
Is this the expected behaviour? Typically, we register a separate platform device for the Intel machines which in turn register the card and none of them ever enable runtime PM. So this has no impact on the parent device's runtime PM status.
I'd like to avoid creating a separate platform device just to register the card if possible while also enabling runtime PM . But when I do this today, the device cannot enter runtime suspend at all. Could you please shed some light on this?
It's not clear how you see the things. Which device are you looking at? Typically a card object points to two different devices, one is the real device that the chip belongs to (card->dev), and another the own device object for managing the device files (card.card_dev). And in general, snd_soc_card_register() or snd_card_register() don't manipulate the runtime PM stuff by itself at all.
Its the card->dev that I am looking at. This is the device that calls devm_snd_soc_register_card(). In my tests, the usage_count for this device is 0 before calling devm_snd_soc_register_card and it is 2 after the card registration is complete.
I dug a bit deeper and found that this happens only if the card-
dapm.idle_bias_off is not set to true.
To be honest, I dont quite understand what the idle_bas_off setting is meant for exactly but it does prevent card->dev 's being runtime resumed in dapm_pre_sequence_async() and solves my issue.
I dont see this being set for most of the cards in the Intel machine drivers and they all manifest the same symptom I was seeing. But, it hasnt really caused any real problems because runtime PM for these platform devices is never enabled.
Hrm, that's puzzling behavior indeed.
And it seems that Intel byt drivers are the only machine drivers that set idle_bias_off. I guess those set the flag for some workaround?
I have two theories about this: 1. Some of the BYT machine drivers that set this, do it in their codec init functions. My guess is this is likely to prevent the codec from being permanently runtime active. 2. Others are simply copy/paste's and probably not needed.
I can investigate further and confirm my thoeries. But do you foresee any issues with setting the idle_bias_off for the card's DAPM context?
Thanks, Ranjani
On Fri, 17 Apr 2020 17:50:39 +0200, Ranjani Sridharan wrote:
On Fri, 2020-04-17 at 11:11 +0200, Takashi Iwai wrote:
On Thu, 16 Apr 2020 19:34:50 +0200, Ranjani Sridharan wrote:
On Thu, 2020-04-16 at 06:18 -0700, Ranjani Sridharan wrote:
On Thu, 2020-04-16 at 09:04 +0200, Takashi Iwai wrote:
On Thu, 16 Apr 2020 07:52:45 +0200, Sridharan, Ranjani wrote:
Hi Takashi,
While working on implementing the probes features in SOF using a separate card for the probe DAI links, I noticed that calling snd_soc_register_card() results in incrementing the usage_count for the device that registers the card by 2 and it is not decremented until the card is freed.
Is this the expected behaviour? Typically, we register a separate platform device for the Intel machines which in turn register the card and none of them ever enable runtime PM. So this has no impact on the parent device's runtime PM status.
I'd like to avoid creating a separate platform device just to register the card if possible while also enabling runtime PM . But when I do this today, the device cannot enter runtime suspend at all. Could you please shed some light on this?
It's not clear how you see the things. Which device are you looking at? Typically a card object points to two different devices, one is the real device that the chip belongs to (card->dev), and another the own device object for managing the device files (card.card_dev). And in general, snd_soc_card_register() or snd_card_register() don't manipulate the runtime PM stuff by itself at all.
Its the card->dev that I am looking at. This is the device that calls devm_snd_soc_register_card(). In my tests, the usage_count for this device is 0 before calling devm_snd_soc_register_card and it is 2 after the card registration is complete.
I dug a bit deeper and found that this happens only if the card-
dapm.idle_bias_off is not set to true.
To be honest, I dont quite understand what the idle_bas_off setting is meant for exactly but it does prevent card->dev 's being runtime resumed in dapm_pre_sequence_async() and solves my issue.
I dont see this being set for most of the cards in the Intel machine drivers and they all manifest the same symptom I was seeing. But, it hasnt really caused any real problems because runtime PM for these platform devices is never enabled.
Hrm, that's puzzling behavior indeed.
And it seems that Intel byt drivers are the only machine drivers that set idle_bias_off. I guess those set the flag for some workaround?
I have two theories about this:
- Some of the BYT machine drivers that set this, do it in their codec
init functions. My guess is this is likely to prevent the codec from being permanently runtime active. 2. Others are simply copy/paste's and probably not needed.
I can investigate further and confirm my thoeries. But do you foresee any issues with setting the idle_bias_off for the card's DAPM context?
I don't think so. The fact that most others never need to set the flag already smells fishy. The proper runtime PM could have been done for those BYT drivers in another way, I guess.
thanks,
Takashi
participants (3)
-
Ranjani Sridharan -
Sridharan, Ranjani -
Takashi Iwai