Message ID | 20221020015624.1703950-1-yung-chuan.liao@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp17619wrs; Wed, 19 Oct 2022 19:10:40 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4Jh04JZqmzmAmbjDldebTgaFbiHS3yemHbEzKdLVBS9Fud0jR2HfmMrTnhG4tRlh2yHvOK X-Received: by 2002:a05:6402:51c6:b0:45d:50ef:1142 with SMTP id r6-20020a05640251c600b0045d50ef1142mr10253868edd.259.1666231840424; Wed, 19 Oct 2022 19:10:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666231840; cv=none; d=google.com; s=arc-20160816; b=iKL9i3Q+hByFq9TCEAqdJGstYAs9+aY6RpeNncbmkxrwpUEO/C2oFqH4VlPX3Twfmt LYuHpPzahmGQPrTGEfTfU5vNvT4YXobZC4joKy8MBrdcaShsenTSr2qVLstgEFMDUexy Duc8NDrW/60hy21KbtAhZ4YL9g7/RuBG79S5ZvLNnX27EIUEyeM6qm/Twgt/6Dz+CvtG cW2z8nUj0HtwG184JPpTtbGqHngSory/IZrB6VYIewuQOS1Gc9bnoy/0/tV/qTUQoYYK SJu41zDru/+1UDGchb33Vyk6qeDeErFwPFiLV73j0csNvbxtKzx5TcdzFZhC9J0yKmMH Z+QA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=zlCH7ETqgT8hSYc1rYeIaQoGAsvFpi6qJQN/2focQ+Y=; b=MY1d3Tt5KX8RQtdgAcmKBMVtDt1MlG1J7eiJuEd2y/fNZnyMtV5mEGn+8Dp+f9jsM2 4WC1whMfnCVv3Rdvq84I08g0sgXI8aB93kj7shdszXETkUj0Y6NScWYu6hO1RvRsKz27 AxloVIwQJH8gKDAqQz9coKUSUQqf41+aBie/gTKcixLy7d5+x2kuHjLUxz4xDkDl1vT9 nccVDYqEEtAlftLe2rbWP3TCiMPJFjtH25oZKV9UrcbY8IWVQIkMbNtH77i6pyPNgUF0 NVxG3CMWvF67W5ursj6Yz/E6NWxg5N8Nvjj6qpcjqIFEHM5tEdKIn5DImXE8/DmL1d6a 7IjA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Zn1yfRx0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ht22-20020a170907609600b007882936243fsi17371437ejc.772.2022.10.19.19.09.28; Wed, 19 Oct 2022 19:10:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Zn1yfRx0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231567AbiJTBxP (ORCPT <rfc822;samuel.l.nystrom@gmail.com> + 99 others); Wed, 19 Oct 2022 21:53:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51172 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231544AbiJTBxN (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 19 Oct 2022 21:53:13 -0400 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ED6BF1C3E7D; Wed, 19 Oct 2022 18:53:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1666230791; x=1697766791; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=hfWjYaVPC1jR2bOcPd6wO2+FVIEpJFXHmpCSZH0ayOk=; b=Zn1yfRx0T7aLVCEiLn6KrBi9mOWgotUohRaFiwT8D/xCD8wNjRDK/269 3Dt2NkzOYaQ32cqfY9IxulZzNeGnHlfFt5L+tpD8rG1gn5OKnot+tvxcn /Wt16ejh6sFkbaG7JnRMzVD4ruYo6WpUj6GpfnIJMLdNJzqiTccKEJWd/ mbh+++Jm5ksNWh6om9NETKLdm1HC578uRWFJuZWlbP3IpyL0XO1neSvLm 31ptYCFBm8pld1OCa9qO/pB4SahhnHU4Lrl+1bH1R9vM8IhdC8P/n7onr 413qQCrK0NMxluyCiJ0OOpEWNd+BRdFptx21gMR1+CdKUFC8SbcJc3Gti A==; X-IronPort-AV: E=McAfee;i="6500,9779,10505"; a="333143313" X-IronPort-AV: E=Sophos;i="5.95,196,1661842800"; d="scan'208";a="333143313" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Oct 2022 18:52:52 -0700 X-IronPort-AV: E=McAfee;i="6500,9779,10505"; a="662755519" X-IronPort-AV: E=Sophos;i="5.95,196,1661842800"; d="scan'208";a="662755519" Received: from bard-ubuntu.sh.intel.com ([10.239.185.57]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Oct 2022 18:52:49 -0700 From: Bard Liao <yung-chuan.liao@linux.intel.com> To: alsa-devel@alsa-project.org, vkoul@kernel.org Cc: vinod.koul@linaro.org, linux-kernel@vger.kernel.org, pierre-louis.bossart@linux.intel.com, bard.liao@intel.com, stable@vger.kernel.org Subject: [PATCH] soundwire: intel: Initialize clock stop timeout Date: Thu, 20 Oct 2022 09:56:24 +0800 Message-Id: <20221020015624.1703950-1-yung-chuan.liao@linux.intel.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, URIBL_BLOCKED autolearn=ham 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 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747170718495022055?= X-GMAIL-MSGID: =?utf-8?q?1747170718495022055?= |
Series |
soundwire: intel: Initialize clock stop timeout
|
|
Commit Message
Bard Liao
Oct. 20, 2022, 1:56 a.m. UTC
From: Sjoerd Simons <sjoerd@collabora.com> The bus->clk_stop_timeout member is only initialized to a non-zero value during the codec driver probe. This can lead to corner cases where this value remains pegged at zero when the bus suspends, which results in an endless loop in sdw_bus_wait_for_clk_prep_deprep(). Corner cases include configurations with no codecs described in the firmware, or delays in probing codec drivers. Initializing the default timeout to the smallest non-zero value avoid this problem and allows for the existing logic to be preserved: the bus->clk_stop_timeout is set as the maximum required by all codecs connected on the bus. Fixes: 1f2dcf3a154ac ("soundwire: intel: set dev_num_ida_min") Signed-off-by: Sjoerd Simons <sjoerd@collabora.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Chao Song <chao.song@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> --- drivers/soundwire/intel.c | 1 + 1 file changed, 1 insertion(+)
Comments
On 10/19/22 20:56, Bard Liao wrote: > From: Sjoerd Simons <sjoerd@collabora.com> > > The bus->clk_stop_timeout member is only initialized to a non-zero value > during the codec driver probe. This can lead to corner cases where this > value remains pegged at zero when the bus suspends, which results in an > endless loop in sdw_bus_wait_for_clk_prep_deprep(). > > Corner cases include configurations with no codecs described in the > firmware, or delays in probing codec drivers. > > Initializing the default timeout to the smallest non-zero value avoid this > problem and allows for the existing logic to be preserved: the > bus->clk_stop_timeout is set as the maximum required by all codecs > connected on the bus. > > Fixes: 1f2dcf3a154ac ("soundwire: intel: set dev_num_ida_min") > Signed-off-by: Sjoerd Simons <sjoerd@collabora.com> > Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> > Reviewed-by: Chao Song <chao.song@intel.com> > Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> this patch should be sent to GregKH/Linus as a 6.1-rcx fix, it does seem to make the life of Arch/Debian users less miserable - for some reason very large delays on driver probe seem to trigger this corner case and make things even worse. see https://github.com/thesofproject/linux/issues/3777 for details. Thanks Vinod. > --- > drivers/soundwire/intel.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/soundwire/intel.c b/drivers/soundwire/intel.c > index 25ec9c272239..78d35bb4852c 100644 > --- a/drivers/soundwire/intel.c > +++ b/drivers/soundwire/intel.c > @@ -1311,6 +1311,7 @@ static int intel_link_probe(struct auxiliary_device *auxdev, > > bus->link_id = auxdev->id; > bus->dev_num_ida_min = INTEL_DEV_NUM_IDA_MIN; > + bus->clk_stop_timeout = 1; > > sdw_cdns_probe(cdns); >
On 20-10-22, 09:56, Bard Liao wrote: > From: Sjoerd Simons <sjoerd@collabora.com> > > The bus->clk_stop_timeout member is only initialized to a non-zero value > during the codec driver probe. This can lead to corner cases where this > value remains pegged at zero when the bus suspends, which results in an > endless loop in sdw_bus_wait_for_clk_prep_deprep(). > > Corner cases include configurations with no codecs described in the > firmware, or delays in probing codec drivers. > > Initializing the default timeout to the smallest non-zero value avoid this > problem and allows for the existing logic to be preserved: the > bus->clk_stop_timeout is set as the maximum required by all codecs > connected on the bus. Applied to fixes, thanks
On 10/28/22 06:28, Vinod Koul wrote: > On 20-10-22, 09:56, Bard Liao wrote: >> From: Sjoerd Simons <sjoerd@collabora.com> >> >> The bus->clk_stop_timeout member is only initialized to a non-zero value >> during the codec driver probe. This can lead to corner cases where this >> value remains pegged at zero when the bus suspends, which results in an >> endless loop in sdw_bus_wait_for_clk_prep_deprep(). >> >> Corner cases include configurations with no codecs described in the >> firmware, or delays in probing codec drivers. >> >> Initializing the default timeout to the smallest non-zero value avoid this >> problem and allows for the existing logic to be preserved: the >> bus->clk_stop_timeout is set as the maximum required by all codecs >> connected on the bus. > > Applied to fixes, thanks Thanks Vinod, was this sent to Greg/Linus? the last pull request I see was for 6.1-rc1. Arch Linux cherry-picked this patch but other distros did not, so quite a few users are left with no audio card.
On 09-11-22, 10:05, Pierre-Louis Bossart wrote: > > > On 10/28/22 06:28, Vinod Koul wrote: > > On 20-10-22, 09:56, Bard Liao wrote: > >> From: Sjoerd Simons <sjoerd@collabora.com> > >> > >> The bus->clk_stop_timeout member is only initialized to a non-zero value > >> during the codec driver probe. This can lead to corner cases where this > >> value remains pegged at zero when the bus suspends, which results in an > >> endless loop in sdw_bus_wait_for_clk_prep_deprep(). > >> > >> Corner cases include configurations with no codecs described in the > >> firmware, or delays in probing codec drivers. > >> > >> Initializing the default timeout to the smallest non-zero value avoid this > >> problem and allows for the existing logic to be preserved: the > >> bus->clk_stop_timeout is set as the maximum required by all codecs > >> connected on the bus. > > > > Applied to fixes, thanks > > Thanks Vinod, was this sent to Greg/Linus? the last pull request I see > was for 6.1-rc1. > Arch Linux cherry-picked this patch but other distros did not, so quite > a few users are left with no audio card. https://git.kernel.org/torvalds/c/f014699cca9a9a28fbdc06a9225b54562154fc20
diff --git a/drivers/soundwire/intel.c b/drivers/soundwire/intel.c index 25ec9c272239..78d35bb4852c 100644 --- a/drivers/soundwire/intel.c +++ b/drivers/soundwire/intel.c @@ -1311,6 +1311,7 @@ static int intel_link_probe(struct auxiliary_device *auxdev, bus->link_id = auxdev->id; bus->dev_num_ida_min = INTEL_DEV_NUM_IDA_MIN; + bus->clk_stop_timeout = 1; sdw_cdns_probe(cdns);