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
