Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp3964119rwe; Tue, 30 Aug 2022 01:57:56 -0700 (PDT) X-Google-Smtp-Source: AA6agR5bZeIaaINq4G6mR5eb+V4oU2J6dq5Ut50kFqsl9MfwPnc4tM/hOGuS43UMAiyAel3MMKlR X-Received: by 2002:a05:6402:1f87:b0:43b:b88d:1d93 with SMTP id c7-20020a0564021f8700b0043bb88d1d93mr19462161edc.314.1661849876668; Tue, 30 Aug 2022 01:57:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661849876; cv=none; d=google.com; s=arc-20160816; b=A9jiX1FDvN7sVMaRZLH0WbL4vbgDxdS4gcBWopIyTuxO1sfvUpZT3JNBbmauwaMNnY CpbEYbA4xR8w0TDiEMKc8UcxplJBeWAjbWI+HzYBmxuOWfel1xmKWeMmXbojrkTwC0TI +xeeny3mNLo9tDH9c+AL5BR1tRSi8Kvelep8a91RcO/xZpXd28J641jLc1gck9r5zSsg vSMNDe1FYw2hXTe9+xsysuvft/WXOYPhmZGTuvp3tz38XjHGfTlG04uc5445sjslqOJI v7EsKuBkOwxmIpIB5acEL3oyplsDUDknMNrqajmEbolLN/kcO3LtNuqsElf705IjbTSk 1pqQ== 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=81OR0oPnwVLZbG5EMgpxwrEfKIUDP4yreNN0fvoxLSM=; b=JlwYzz3IJe3N4HhQh7taYUPFbAWuiVcqxuxDaDFcExArRL3HmEdCxnPadE3BDYD1gV 8n5hDiSeLtP0rKtn4PkLAVPQkznikN3zTY44BT+FrCHVSAG6GS2VVZVrhtd2SDfzHgGZ cXqT04uuQlP6AvYyxkW1e9s7bfrnkBiQ02NUk/BYofHnketY2RAKrhkFSaJ0XhJ9uGa4 mDCbRI+JdqTOPfmZOxiCIxEp5ROa2lC5Va7OQuwnDZMzL95qqtu0Pce6ObGfQLWRBwft IMiX6feQo5hfbR8Z4OjFAtT9PCZrT8hrpaYiwGOvnAp2XU6iOcSEFOkfpjLKaT8JNR1p wtkw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=hXSXDo0z; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g20-20020a170906521400b0072f09c398b7si7066637ejm.118.2022.08.30.01.57.31; Tue, 30 Aug 2022 01:57:56 -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=hXSXDo0z; 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 S231215AbiH3HiJ (ORCPT + 99 others); Tue, 30 Aug 2022 03:38:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59654 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231196AbiH3HiC (ORCPT ); Tue, 30 Aug 2022 03:38:02 -0400 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5B401BA15E for ; Tue, 30 Aug 2022 00:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1661845070; x=1693381070; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=4146rQbNgpJKmVBNz3ybM+Hn/wyGiAEsiucLmRjbNWI=; b=hXSXDo0zxr8FQjTsgXbgW4ccI4lN4Hf6kAdVtNcXgtuT6iu1UYZzpYno 3GHj0Lm9nC+8CG0EsH7OBhxUVyOkHG+6dlKaPvq5sts2U6Flw+jJwdQJ8 WZsMTwcaBPNeKcZP0lOLHPRALgGBqzzaymkw8xX9VJyBCtCYVmXBsjsaz 1FpfrThFlgm40HMx/rnN9qLGgYgmFLcUCq2KFqQAeZUBzYCamw+pEl+u6 K+6A3xm2wVZ1VpfuNP3gpw4EPS8e5KgtcSzh4GYSZpsxqxN8YGqKW0Oy3 4HfQxpJopSvfieMwxdILnnZ1Fs0QrLTzDzzVXEjsVxEDsY+/hMHGqJzby Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10454"; a="282078621" X-IronPort-AV: E=Sophos;i="5.93,274,1654585200"; d="scan'208";a="282078621" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Aug 2022 00:37:45 -0700 X-IronPort-AV: E=Sophos;i="5.93,274,1654585200"; d="scan'208";a="672734380" Received: from bard-ubuntu.sh.intel.com ([10.239.185.57]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Aug 2022 00:37:43 -0700 From: Bard Liao To: alsa-devel@alsa-project.org, vkoul@kernel.org, broonie@kernel.org Cc: vinod.koul@linaro.org, linux-kernel@vger.kernel.org, pierre-louis.bossart@linux.intel.com, bard.liao@intel.com Subject: [PATCH] soundwire: bus: conditionally recheck UNATTACHED status Date: Tue, 30 Aug 2022 15:42:24 +0800 Message-Id: <20220830074224.2924179-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=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE 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: X-Mailing-List: linux-kernel@vger.kernel.org From: Pierre-Louis Bossart In configurations with two amplifiers on the same link, the Intel CI reports occasional enumeration/initialization timeouts during suspend-resume stress tests, where one of the two amplifiers becomes UNATTACHED immediately after being enumerated. This problem was reported both with Maxim and Realtek codecs, which pointed initially to a problem with status handling on the Intel side. The Cadence IP integrated on Intel platforms throws an interrupt when the status changes, and the information is kept with sticky bits until cleared. We initially added more checks to make sure the edge detection did not miss any transition, but that did not improve the results significantly. With the recent addition of the read_ping_status() callback, we were able to show that the status in sticky bits is shown as UNATTACHED even though the PING frames show the problematic device as ATTACHED. That completely breaks the entire logic where we assumed that a peripheral would always re-attach as device0. The resume timeouts make sense in that in those cases, the enumeration/initialization never happens a second time. One possible explanation is that this problem typically happens when a bus clash is reported, so it could very well be that the detection is fooled by a transient electrical issue or conflict between two peripherals. This patch conditionally double-checks the status reported in the sticky bits with the actual PING frame status. If the peripheral reports as attached in PING frames, the early detection based on sticky bits is discarded. Note that this patch only corrects issues of false positives on the manager side. If the peripheral lost and regain sync, then it would report as attached on Device0. A peripheral that would not reset its dev_num would not be compliant with the MIPI specification. BugLink: https://github.com/thesofproject/linux/issues/3638 BugLink: https://github.com/thesofproject/linux/issues/3325 Signed-off-by: Pierre-Louis Bossart Reviewed-by: Rander Wang Signed-off-by: Bard Liao --- Hi Vinod, You will need the "ASoC/soundwire: log actual PING status on resume issues" series which is applied at ASoC tree before appling this patch. --- drivers/soundwire/bus.c | 19 +++++++++++++++++++ drivers/soundwire/intel.c | 1 + include/linux/soundwire/sdw.h | 3 +++ 3 files changed, 23 insertions(+) diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c index 2772973eebb1..d0d486f07673 100644 --- a/drivers/soundwire/bus.c +++ b/drivers/soundwire/bus.c @@ -1767,6 +1767,25 @@ int sdw_handle_slave_status(struct sdw_bus *bus, slave->status != SDW_SLAVE_UNATTACHED) { dev_warn(&slave->dev, "Slave %d state check1: UNATTACHED, status was %d\n", i, slave->status); + + if (bus->recheck_unattached && bus->ops->read_ping_status) { + u32 ping_status; + + mutex_lock(&bus->msg_lock); + + ping_status = bus->ops->read_ping_status(bus); + + mutex_unlock(&bus->msg_lock); + + ping_status >>= (i * 2); + ping_status &= 0x3; + + if (ping_status != 0) { + dev_warn(&slave->dev, "Slave %d state in PING frame is %d, ignoring earlier detection\n", + i, ping_status); + continue; + } + } sdw_modify_slave_status(slave, SDW_SLAVE_UNATTACHED); } } diff --git a/drivers/soundwire/intel.c b/drivers/soundwire/intel.c index 25ec9c272239..0c6e674dbf85 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->recheck_unattached = true; sdw_cdns_probe(cdns); diff --git a/include/linux/soundwire/sdw.h b/include/linux/soundwire/sdw.h index a2b31d25ea27..51ac71984260 100644 --- a/include/linux/soundwire/sdw.h +++ b/include/linux/soundwire/sdw.h @@ -892,6 +892,8 @@ struct sdw_master_ops { * @dev_num_ida_min: if set, defines the minimum values for the IDA * used to allocate system-unique device numbers. This value needs to be * identical across all SoundWire bus in the system. + * @recheck_unattached: if set, double-check UNATTACHED status changes + * by reading PING frame status. */ struct sdw_bus { struct device *dev; @@ -917,6 +919,7 @@ struct sdw_bus { bool multi_link; int hw_sync_min_links; int dev_num_ida_min; + bool recheck_unattached; }; int sdw_bus_master_add(struct sdw_bus *bus, struct device *parent, -- 2.25.1