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