Message-ID: <bc281416-e28d-4c18-2475-add92d38a554@gmail.com>
Date:   Thu, 18 Nov 2021 23:13:50 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.3.0
Content-Language: en-US
To:     Takashi Iwai <tiwai@suse.de>
Cc:     alsa-devel@alsa-project.org, Linux PM <linux-pm@vger.kernel.org>
References: <d9d76980-966a-e031-70d1-3254ba5be5eb@gmail.com>
 <s5hczmxgnm2.wl-tiwai@suse.de>
From:   Heiner Kallweit <hkallweit1@gmail.com>
Subject: Re: Warning due to "ALSA: hda: intel: More comprehensive PM runtime
 setup for controller driver"
In-Reply-To: <s5hczmxgnm2.wl-tiwai@suse.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 18.11.2021 22:28, Takashi Iwai wrote:
> On Thu, 18 Nov 2021 21:33:34 +0100,
> Heiner Kallweit wrote:
>>
>> I get the following warning caused by 4f66a9ef37d3 ("ALSA: hda: intel: More
>> comprehensive PM runtime setup for controller driver"):
>>
>> snd_hda_intel 0000:00:1f.3: Unbalanced pm_runtime_enable!
>>
>> Not sure how this patch was tested because the warning is obvious.
>> The patch doesn't consider what the PCI sub-system does with regard to
>> RPM. Have a look at pci_pm_init().
>>
>> I'd understand to add the call to pm_runtime_dont_use_autosuspend(),
>> but for all other added calls I see no justification.
>>
>> If being unsure about when to use which RPM call best involve
>> linux-pm@vger.kernel.org.
> 
> Thanks for the notice.  It's been through Intel CI and tests on a few
> local machines, maybe we haven't checked carefully those errors but
> only concentrated on the other issues, as it seems.
> 
> There were two problems: one was the runtime PM being kicked off even
> during the PCI driver remove call, and another was the proper runtime
> PM setup after re-binding.
> 

Having a look at the commit message of "ALSA: hda: fix general protection
fault in azx_runtime_idle" the following sounds weird:

  - pci-driver.c:pm_runtime_put_sync() leads to a call
    to rpm_idle() which again calls azx_runtime_idle()

rpm_idle() is only called if usage_count is 1 when entering
pm_runtime_put_sync. And this should not be the case.
pm_runtime_get_sync() increments the usage counter before remove()
is called, and remove() should also increment the usage counter.
This doesn't seem to happen. Maybe for whatever reason 
pm_runtime_get_noresume() isn't called in azx_free(), or azx_free()
isn't called from remove().
I think you should trace the call chain from the PCI core calling
remove() to pm_runtime_get_noresume() getting called or not.


> For avoiding the former, only the pm_runtime_forbid() (and maybe
> pm_runtime_dont_use_autosuspend(), too) would suffice?  Also, for PCI
> device, no need for pm_runtime_set_supended() at remove, right?
> 
> 
> thanks,
> 
> Takashi
>