From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9B896C433ED for ; Thu, 8 Apr 2021 10:50:23 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5FB0561159 for ; Thu, 8 Apr 2021 10:50:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5FB0561159 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=nosignal.fi Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 381321666; Thu, 8 Apr 2021 12:49:28 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 381321666 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1617879018; bh=XLotnKnM12hP7LXa0lM27Y5YNVbdFQ/0Q54Ic17temQ=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=KLr73P5Yz00Dzek4x6LX4jyD3wXgVmGmawejL8VBmokz5KeEuUgWSLqfF5VH/dS+H ZkRcg/UpwY//8wRR4UAlqb0bj+U3NhpimQCqhBl3S2FaB0kgH1XsdzheJV5StPb4mE IH47RRUhLoRKodguH/G8YJ9e1s7mk5dQ8JRW+TEM= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id A82B8F80169; Thu, 8 Apr 2021 12:49:27 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 7B399F8020B; Thu, 8 Apr 2021 12:49:25 +0200 (CEST) Received: from webmail.tpnet.fi (webmail.tpnet.fi [62.106.63.33]) by alsa1.perex.cz (Postfix) with ESMTP id CA983F800BD for ; Thu, 8 Apr 2021 12:49:17 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz CA983F800BD Received: from 87-95-165-136.bb.dnainternet.fi (87-95-165-136.bb.dnainternet.fi [87.95.165.136]) by webmail.tpnet.fi (Postfix) with ESMTPS id A93D8242FA; Thu, 8 Apr 2021 13:49:15 +0300 (EEST) Date: Thu, 8 Apr 2021 13:49:15 +0300 (EEST) From: Kai Vehmanen X-X-Sender: kaiv@ecabase.localdomain To: Takashi Iwai Subject: Re: [RFC PATCH] ALSA: hda/hdmi: fix race in handling acomp ELD notification at resume In-Reply-To: Message-ID: References: <20210407154727.589017-1-kai.vehmanen@linux.intel.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Cc: alsa-devel@alsa-project.org, pierre-louis.bossart@linux.intel.com, Kai Vehmanen X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" Hi, On Thu, 8 Apr 2021, Takashi Iwai wrote: > OK, that's a messy problem, indeed. It's partly because of ASoC > referred resume that is completely independent from the rest resume > via HD-audio bus. More badly, this can't be managed via the device > link because the resume callback itself has been processed. > > And, IIUC, another part of the problem is that i915 notifies the HPD > *after* the resume completion, right? Then indeed it can be racy. yes, exactly. >> Seems quite odd indeed, but I've now got reports of systems where this is >> hit, and unfortunately it's very systematic on these systems. By adding >> some arbitrary delay to soc_resume_deferred(), I could easily hit this >> myself as well on the systems I have at hand. > > Another possible fix would be to check dev->power.power_state instead > of the global card state. This is set in each PM callback in > hda_codec.c to indicate the current PM state of the codec. Something > like below. Let me know if this works, too. Thanks, this works in my setup and is much cleaner. I think this is also more robust. I realized that with snd_power_get_state() check, there is a theoretical race still possible if notify comes before soc_resume_deferred() gets scheduled (i.e. delay is not within soc_resume_deferred() but in getting it scheduled to begin with). This would seem really unlikely, but it's a possible race nevertheless. I'll update the patch to use dev->power.power_state, ask people with affected systems to double check, and I'll send a V2. Br, Kai