Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Message-ID: <147f7144-5a9f-55e8-6164-6ede73f270a1@nvidia.com>
Date:   Mon, 28 Mar 2022 22:33:01 +0530
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.7.0
Subject: Re: [PATCH] ALSA: hda: Avoid unsol event during RPM suspending
Content-Language: en-US
To:     Takashi Iwai <tiwai@suse.de>
Cc:     tiwai@suse.com, kai.vehmanen@linux.intel.com, perex@perex.cz,
        ville.syrjala@linux.intel.com, alsa-devel@alsa-project.org,
        linux-kernel@vger.kernel.org, thierry.reding@gmail.com,
        jonathanh@nvidia.com
References: <20220328091411.31488-1-mkumard@nvidia.com>
 <s5hczi6l8fz.wl-tiwai@suse.de>
 <7f7934e6-137c-4d8d-049b-0ed5e57cf00b@nvidia.com>
 <s5ha6dal4ys.wl-tiwai@suse.de>
 <7cbfca20-bd1a-9ca0-f0e2-2ecf5fa74f45@nvidia.com>
 <s5hilryjbnq.wl-tiwai@suse.de>
From:   Mohan Kumar D <mkumard@nvidia.com>
In-Reply-To: <s5hilryjbnq.wl-tiwai@suse.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OEQ4T3Vqa2haVTJRMW1jd2I1dHd0Y2dQMGxrcHZQY0pLUGFLSitRN2JjS0Iw?=
 =?utf-8?B?OWtWZEFmOFRYZXNlNXZzQ0Q5NFBpN0JzQmxYdzFMQ1B5VDNseHNlMGptcUty?=
 =?utf-8?B?RHNHYk5FY0pYdXVuRFJYb3IrT3NyYXJoZkFVdjNhUWgyb1VtdlJrWlVsd3hZ?=
 =?utf-8?B?Zk1pWHZBeG9nbml4WElVc1hTSVNPUlVuYUVyWEhTZ3MxRkpJSG5jLy9IOGZT?=
 =?utf-8?B?eWg5dHdvZ1F4RFpyelN5WkY1OEJwTTZLRGJIVlJ5ang1T01UM2xPVEZCdmFK?=
 =?utf-8?B?NTdxeHhTMjhITU5VRVVwZlpQL045S1M5ZGpUYTVLQ2s3TUlEM3g5OHZtWjc1?=
 =?utf-8?B?dC9jY0RqUFZ4M3lxdktrODUyc1B0cjBjN0pHQXBNMGQwY0VZN011QnBOUzFI?=
 =?utf-8?B?ZWhHSmNvUVQxU3FFai9aTG9DRm8xUnMvMUVudnVhb21iaVNFUlNqNGF3WE1O?=
 =?utf-8?B?aTU4OVZGNTRUVTZ3VkxyeWpzbFVPY3FUaUZRRkl4SkpnbklYcVJPK0VWMHJ6?=
 =?utf-8?B?TlRkaUFkTDhoTTFCQ1dzKzJoZmRLZXZHUW1iRndBN3RpS3loWjhtL2lwOTBP?=
 =?utf-8?B?NUJ5VHNOYXhNeG8wbHJCVVB4RHpERFNyUWVUVms1NGtKQU9DUGVEdTdSN3ho?=
 =?utf-8?B?Zkl1NXhVNmxTYkdJdjhVSG4rRUxPNjRMeXNYNDd1elkxeU5kZDlYK25zd0JL?=
 =?utf-8?B?ZjNKR3dwOUg2MFc3Q3hJQ3dDazhCcGVaSnFTSzNkdXoyVXViR2piODROUEo5?=
 =?utf-8?B?VEpUbE9jME1sSW1hdEpXVzNyUmFKUnFOUWE5azRRR1BtdUU3WjRsUGdjeTNU?=
 =?utf-8?B?TWxpdkNiSHN5V05LVUFObEZUYktneFhRLzJyaEdZLzZnL0lWZFdSajhGSnRj?=
 =?utf-8?B?LzhWdWZkZ2p6MTNaY1NBNThDbzR2TzdxTkFVZ0xGT3JkcGNCL2tsSWRVK2tN?=
 =?utf-8?B?Q0FpSCtoK2JFdkl1aFJSN2tlSVpQRjY1YktUQTdzYkdSbWttaEtKQW42NFNj?=
 =?utf-8?B?Z1ZTTTRrQy9KWmxpUWpKRVlZdDZFMHhlSzBWMFJDWks2cm51U3RPSTRoUHVj?=
 =?utf-8?B?aW5MZmhrN3NIbi9uaGlhY3UxSmVWdXg3Z0c0Mm1BMXJtaFZmaXJlN1ZhQ1Ax?=
 =?utf-8?B?ZlEwMWI2TUJBUnIxN0hYSENWME44ZG5vR0h1Zm4yUW9QdEUzYnRYYmNaOFV0?=
 =?utf-8?B?N2ZrQ2NjNnYxeUhKVDhTOVRQYU81eFdLSTViUGtWQmNQSmlIWGczTlJOblNR?=
 =?utf-8?B?NzIyVGs3dXlmb0dpYjJEWGgwZE5OM2t0SGUvVmk4UEpVTUg4eDB2SjAyeFRu?=
 =?utf-8?B?dnVpenIrSG93emVEcVRtVzN2SXROajF2ekJUN0dvbnVHL0ZIa2d2Q3JzUjAv?=
 =?utf-8?B?MGhXeUppZGNwanhQUWVGUXFpSWtHbDVLUGxDc2I0dDJ1SnViaXlRQUE1UkhJ?=
 =?utf-8?B?QXlzcFBPRG56SlUwRDNqaGl3OWNPdnpTUFArei96bUdDSFVyZEVyaWpDRzdQ?=
 =?utf-8?B?QXpiZVpFQWlSOGlMWDhHMUpiOVV6bE9uc1ZBY2pJMk5tS3Z2MWw3b1pLZ1lr?=
 =?utf-8?B?MmxxRU85c1JnbDVFZlFnQWhaWUc5b1UrRnhQdTlNcE15T2V5UzZxaG50RTZT?=
 =?utf-8?B?M3pZLyt4SkVZaXMyQU5USlM3Uy8xRFlPaGRoMUl2Q1RZblM1VzIxL3JCSlRw?=
 =?utf-8?B?VEk5WkdtOW1vV1p5VTB5YUxiREpZYlhsd044a1lKN2tTY3cvN2tEdlNNTzQ5?=
 =?utf-8?B?a1Rad0YvTEZobmx4aklQRHBJWWZVb2I0aTRMTEZRRjBMN0VVaVNFZHA3cC85?=
 =?utf-8?B?OVNwamtxNzVDWGhXcmVmSUlKS1BsbGVDTVBLT0JEc09ONDNRWW1PODZHcVpY?=
 =?utf-8?B?NnpTWUpnTEVvbVZvMTRrZENJNm1RREhZK2MzREhLU0lBVmU2d2hJRjQveWVv?=
 =?utf-8?Q?wQm7YYaHHRnqqPBkYkK1ASkQkYms+dSt?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7c79e9bc-2cd3-47f3-5fb7-08da10dcd834
X-MS-Exchange-CrossTenant-AuthSource: DM6PR12MB4435.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Mar 2022 17:03:13.5766
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: EgfyFjUBYPBXwZVpQAmcWYXFRTdtf+SU94rS7gelv0ha1gDo/9Wv1ZztlwCeuj0K6Kcfaa/ebbMPRLnIo/kwkQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR12MB5971
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
	DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE,
	T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On 3/28/2022 9:45 PM, Takashi Iwai wrote:
> External email: Use caution opening links or attachments
>
>
> On Mon, 28 Mar 2022 15:51:17 +0200,
> Mohan Kumar D wrote:
>>
>> On 3/28/2022 4:27 PM, Takashi Iwai wrote:
>>> External email: Use caution opening links or attachments
>>>
>>>
>>> On Mon, 28 Mar 2022 12:19:03 +0200,
>>> Mohan Kumar D wrote:
>>>> On 3/28/2022 3:12 PM, Takashi Iwai wrote:
>>>>> External email: Use caution opening links or attachments
>>>>>
>>>>>
>>>>> On Mon, 28 Mar 2022 11:14:11 +0200,
>>>>> Mohan Kumar wrote:
>>>>>> There is a corner case with unsol event handling during codec runtime
>>>>>> suspending state. When the codec runtime suspend call initiated, the
>>>>>> codec->in_pm atomic variable would be 0, currently the codec runtime
>>>>>> suspend function calls snd_hdac_enter_pm() which will just increments
>>>>>> the codec->in_pm atomic variable. Consider unsol event happened just
>>>>>> after this step and before snd_hdac_leave_pm() in the codec runtime
>>>>>> suspend function. The snd_hdac_power_up_pm() in the unsol event
>>>>>> flow in hdmi_present_sense_via_verbs() function would just increment
>>>>>> the codec->in_pm atomic variable without calling pm_runtime_get_sync
>>>>>> function.
>>>>>>
>>>>>> As codec runtime suspend flow is already in progress and in parallel
>>>>>> unsol event is also accessing the codec verbs, as soon as codec
>>>>>> suspend flow completes and clocks are  switched off before completing
>>>>>> the unsol event handling as both functions doesn't wait for each other.
>>>>>> This will result in below errors
>>>>>>
>>>>>> [  589.428020] tegra-hda 3510000.hda: azx_get_response timeout, switching
>>>>>> to polling mode: last cmd=0x505f2f57
>>>>>> [  589.428344] tegra-hda 3510000.hda: spurious response 0x80000074:0x5,
>>>>>> last cmd=0x505f2f57
>>>>>> [  589.428547] tegra-hda 3510000.hda: spurious response 0x80000065:0x5,
>>>>>> last cmd=0x505f2f57
>>>>>>
>>>>>> To avoid this, the unsol event flow should not perform any codec verb
>>>>>> related operations during RPM_SUSPENDING state.
>>>>>>
>>>>>> Signed-off-by: Mohan Kumar <mkumard@nvidia.com>
>>>>> Thanks, that's a hairy problem...
>>>>>
>>>>> The logic sounds good, but can we check the PM state before calling
>>>>> snd_hda_power_up_pm()?
>>>> If am not wrong, PM apis exposed either provide RPM_ACTIVE or
>>>> RPM_SUSPENDED status. Don't see anything which provides info on
>>>> RPM_SUSPENDING. We might need to exactly know this state to fix this
>>>> issue.
>>> Well, maybe my question wasn't clear.  What I meant was that your
>>> change below
>>>
>>>>         ret = snd_hda_power_up_pm(codec);
>>>> -     if (ret < 0 && pm_runtime_suspended(hda_codec_dev(codec)))
>>>> +     if ((ret < 0 && pm_runtime_suspended(dev)) ||
>>>> +             (dev->power.runtime_status == RPM_SUSPENDING))
>>>>                 goto out;
>>> can be rather like:
>>>
>>>> +     if (dev->power.runtime_status == RPM_SUSPENDING)
>>>> +             return;
>>>>         ret = snd_hda_power_up_pm(codec);
>>>>         if (ret < 0 && pm_runtime_suspended(hda_codec_dev(codec)))
>>> so that it skips unneeded power up/down calls.
>>>
>>> Basically the state is set at drivers/base/power/runtime.c
>>> rpm_suspend() just before calling the device's runtime_suspend
>>> callback.  So the state is supposed to be same before and after
>>> snd_hda_power_up_pm() in that case.
>> Thanks!, Make sense, will push the updated patch after testing with
>> latest suggestion.
> Thanks.  Also don't forget to cover a case the test bot complained:
> the reference to power.runtime_status needs #ifdef CONFIG_PM.
Sure, will take care same in next patch update.
>
> Takashi