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