Re: Question about snd_soc_card_register()

[Takashi Iwai <tiwai@suse.de>]

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