Question about snd_soc_card_register()

Question about snd_soc_card_register()

[Sridharan, Ranjani]

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

Re: Question about snd_soc_card_register()

[Takashi Iwai]

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

Re: Question about snd_soc_card_register()

[Ranjani Sridharan]

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

Re: Question about snd_soc_card_register()

[Ranjani Sridharan]

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

Re: Question about snd_soc_card_register()

[Takashi Iwai]

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

Re: Question about snd_soc_card_register()

[Ranjani Sridharan]

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

Re: Question about snd_soc_card_register()

[Takashi Iwai]

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:
> 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?

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