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
