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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1F842C433F5 for ; Thu, 30 Sep 2021 07:57:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F1E4F61555 for ; Thu, 30 Sep 2021 07:57:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348882AbhI3H65 (ORCPT ); Thu, 30 Sep 2021 03:58:57 -0400 Received: from mail-bn8nam12on2061.outbound.protection.outlook.com ([40.107.237.61]:52096 "EHLO NAM12-BN8-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1348701AbhI3H64 (ORCPT ); Thu, 30 Sep 2021 03:58:56 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i/86GhbA6XrHLNoRtVZrA2sd4YRPmcKer1nvgIWezs4D5GuarXaLqBm6SbLAwH+5epOSLRnliTzjj3gE9LRiOXTphRBwpoLmWJCG0iKwW4bkAvj3fCYD+Cr2WfffjsIziOWwYg6BjARJ/63+KoXW5UrjH8umPGwJhCP/a7xapZ0pgPIT45Jz4ZUn5kOHJyEnD4Uo2I1++SDzCX8csRFFso5VPpzbiptizSbYMWzl1WUU72Y/hnbwxZxgL+YBNTaL8U9rwTr+28BX0gqMQ2lwJ8lMn5am4V+LVXog5fx3ZHYe6cF7rsy4777y+qr7hhK4j4BpDF7M7QU68mNrochvAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yt7Anovnp6T7Y1g+Z6f/bQgqyXLTnr+vok3tfV4VCoo=; b=WK/IWSUg1BsDBB2r9bcSulLnibvMXgA9FhoTNF7J9JJ/5cvywx2VsBSagsCSaM1hdNRUJMhuuz59MW6b1F/yB+V1YmmbhspGLngEnKyHGQu7uqkc9pwtnKflIj2j+GgM9ytfFk/lzrP3IQUTUAvH45CVOOIevGPxrNOPtwkO3msfcI9Q2VTyNqp6Bn8A7J7kHBvwTZ4NA9oGXPolV8/4Ei4yaUI7NfRY57EBINurGR1kcOIDWw8AyciZtbjDM+/w53ui43Zja26SUrkXnkXzz/OFQKcs+GObC5BnR9Pufjw+ZAIyElPJP1tOyB2+D198BNeqtpYfWBtX48OKszjobg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 216.228.112.34) smtp.rcpttodomain=gmail.com smtp.mailfrom=nvidia.com; dmarc=pass (p=quarantine sp=none pct=100) action=none header.from=nvidia.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yt7Anovnp6T7Y1g+Z6f/bQgqyXLTnr+vok3tfV4VCoo=; b=ilpxOavVhlWKpYJVEchCLou3iZRZfZgXl7gnPoGwyc1kKdqm/BbN7QtpNtgGumagnLPRgZSyAqLlnD7W9pKCHfrl/WLTDtgouF4NijohbgKYVfJM3/JXeaF1A1+KJrFSMVPwr9lbSpT2mz/QK/hpZtU7p7m+M76mqHAOUr5W0TGoTQj0mi3o7Wfqs6LLJMkLYkp/t/DdmKKqLzZo36+XUICWNu+KbVuUYuKYq3VX7ww0SfoN8cb4ksnV3GfuOrC0mQrDuqKUQ7xL2Du+MZOvvueErmSk/MIi8vU0z1Bdo7rrxO6S4SsiVqgxOHWYkmz9hAt2+O6GsKKPbJUtZnQP0A== Received: from MW4PR04CA0265.namprd04.prod.outlook.com (2603:10b6:303:88::30) by DM6PR12MB3483.namprd12.prod.outlook.com (2603:10b6:5:11f::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.14; Thu, 30 Sep 2021 07:57:11 +0000 Received: from CO1NAM11FT044.eop-nam11.prod.protection.outlook.com (2603:10b6:303:88:cafe::1) by MW4PR04CA0265.outlook.office365.com (2603:10b6:303:88::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.14 via Frontend Transport; Thu, 30 Sep 2021 07:57:11 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 216.228.112.34) smtp.mailfrom=nvidia.com; gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=pass action=none header.from=nvidia.com; Received-SPF: Pass (protection.outlook.com: domain of nvidia.com designates 216.228.112.34 as permitted sender) receiver=protection.outlook.com; client-ip=216.228.112.34; helo=mail.nvidia.com; Received: from mail.nvidia.com (216.228.112.34) by CO1NAM11FT044.mail.protection.outlook.com (10.13.175.188) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.4566.14 via Frontend Transport; Thu, 30 Sep 2021 07:57:11 +0000 Received: from [10.25.99.231] (172.20.187.5) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Thu, 30 Sep 2021 07:57:04 +0000 Subject: Re: [PATCH 01/13] ASoC: soc-pcm: Don't reconnect an already active BE To: Pierre-Louis Bossart , =?UTF-8?Q?P=c3=a9ter_Ujfalusi?= , , , , , , , , , , CC: , , , , , References: <1630056839-6562-1-git-send-email-spujar@nvidia.com> <1630056839-6562-2-git-send-email-spujar@nvidia.com> <70422e52-89d2-d926-b3f9-be59780d464e@nvidia.com> <2f96f1aa-74f2-8ea8-3f43-e4da97400fde@linux.intel.com> <647b1d54-dbd7-ce91-291d-d677ce908398@linux.intel.com> From: Sameer Pujar Message-ID: <94861852-29ba-be9e-8c63-a70a01550b3a@nvidia.com> Date: Thu, 30 Sep 2021 13:27:01 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <647b1d54-dbd7-ce91-291d-d677ce908398@linux.intel.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Originating-IP: [172.20.187.5] X-ClientProxiedBy: HQMAIL107.nvidia.com (172.20.187.13) To HQMAIL107.nvidia.com (172.20.187.13) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: bd292a31-d556-49fa-6b16-08d983e7e89e X-MS-TrafficTypeDiagnostic: DM6PR12MB3483: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7691; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 8RPNFnIXlBKzayIs4Krmfh0zHtltOYK52I/aSl7c4ONWF826KrRlRrylVcZ/mv4V8T3lFdsn57YBfXdGJS/n4HQF4WicGB+at/6LdvPYiQqfrUsWO+ZAHeHAezl+NjeveVsWSzw8PZ1EhQR8t9jueu89YD8WR4wJh25J2yYQzwq6p7wXM30+5HT64v0whQ0doVD5yFKXucEO9c3lRsci5RLCvzpYExfqCAYJfaHjMqiTZiXWm4d97ea1fhv+kq6Bqga/yGIApV+UooLGA08sZI5wqTAoE0fRP8CjU6vgROUNNbQPmAm3guqipd/cE/TfHiAS7bAqqRAYP/gc9uP2CGSPlf0V326TKGCJ/OLm6ZSL05T+XvCEIOMG4e0winMuZF9jqYSU+xeB94y2goc4FwR9Ie5QjBuY1pMpH7LT0u0/dyE3r8KNdOTgpm8SMcc+dNHt+JBtPIoSqOBjIxJY/7wrf4chwk9oYUy/wnafG+l0AHJZR59+6LAcitgmFuISUYwjiPcl4qffyjcJrWxsskB1U3wkX9qQqUig0j/KS7qwkxYkQueZ//thEsHd7WLT53y1w0YLQWBLYkmFnx3t3EuRp1YeZlZQLecSH9j3iHkKvzA1SHy5ddlQnoNcReQNmDAzDZi/aIPxgi4NNh3jHnuicoNiPqE6Orkec4kVURo9xGYQdA+75cKSvXOeFhUqUvxs99abV8OXmopVfoalR1GMW+OVuxhZ1DxENjuzHRxCbdUSBsrP8l3YKYQITCaIFYT0PaPkHBguSHq+eE8iZ68+BNr1jRmEYsXB6v4Hq3eGOLE2VjESU2p3OJEZtHDt6S5awNTeN8PjVfWTsg9IuPA+mX2ikw/Qdu2dTAfhzLf5+kNmeoGPD2kgDhH4W0Ax X-Forefront-Antispam-Report: CIP:216.228.112.34;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:mail.nvidia.com;PTR:schybrid03.nvidia.com;CAT:NONE;SFS:(4636009)(46966006)(36840700001)(26005)(921005)(336012)(316002)(110136005)(54906003)(6666004)(4326008)(7636003)(16576012)(70206006)(5660300002)(70586007)(8936002)(2906002)(8676002)(53546011)(186003)(82310400003)(83380400001)(2616005)(7416002)(31686004)(966005)(86362001)(36860700001)(47076005)(356005)(508600001)(36756003)(16526019)(426003)(31696002)(43740500002);DIR:OUT;SFP:1101; X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Sep 2021 07:57:11.1616 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: bd292a31-d556-49fa-6b16-08d983e7e89e X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=43083d15-7273-40c1-b7db-39efd9ccc17a;Ip=[216.228.112.34];Helo=[mail.nvidia.com] X-MS-Exchange-CrossTenant-AuthSource: CO1NAM11FT044.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB3483 Precedence: bulk List-ID: X-Mailing-List: linux-tegra@vger.kernel.org On 9/29/2021 8:22 PM, Pierre-Louis Bossart wrote: >>>> But in addition we'd need to agree on what an 'active BE' is. Why can't >>>> we connect a second stream while the first one is already in HW_PARAMS >>>> or PAUSED or STOP? It's perfectly legal in ALSA/ASoC to have multiple >>>> HW_PARAMS calls, and when we reach STOP we have to do a prepare again. >>>> >>>> And more fundamentally, the ability to add a second FE on a 'active' BE >>>> in START state is a basic requirement for a mixer, e.g. to play a >>>> notification on one FE while listening to music on another. What needs >>>> to happen is only to make sure that the FE and BE are compatible in >>>> terms of HW_PARAMS and not sending a second TRIGGER_STOP, only checking >>>> the BE NEW or CLOSE state is way too restrictive. >>> Sorry for the trouble to your system. >>> >>> Idea was to avoid reconfiguration of the same BE DAI again, but not to >>> stop the provision to add a subsequent FE. In fact I had tested mixing >>> of streams coming from 10 different FEs. > Can you describe the sequence that you used to start them? That may be > useful to understand the criteria you used? I have something like this: FE1  --> Crossbar -> Mixer Input1    | FE2  --> Crossbar -> Mixer Input2    | ...                                  | --> Mixer Output --> ... | FE10 --> Crossbar -> Mixer Input10   | All these FEs are started one after the other. This is an example of 10x1. Similarly we can have 2x1, 3x1 etc., In our system, the crossbar [0] and mixer [1] are separate ASoC components. Basically audio paths consist of a group of ASoC components which are connected back to back. [0] https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/tree/sound/soc/tegra/tegra210_ahub.c [1] https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/tree/sound/soc/tegra/tegra210_mixer.c > [...] > I don't fully understand the notion of mixer input DAI, in our case we > have a bunch of PCM devices connected to a mixer. The mixer is not > directly connected to a DAI. Please see above mixer example. Since mixer is a separate ASoC component, it exposes 10 inputs (or DAIs) and outputs. Originally what I wanted to do was, for subsequent FE runs (FE2, FE3 ...) mixer output need not be configured again and again. >> The problem as I see is that with this patch one can not connect a new >> FE to a BE which is _not_ in NEW or CLOSE state. >> >> The FE and BE needs to be connected to have DPCM working and this patch >> makes the code to skip the dpcm_be_connect(). >> >> Consider this simple setup: >> >> FE1 -->| >> | --> BE --> >> FE2- ->| >> >> First we start FE1, dpcm_be_connect(FE1, BE, stream) is made. >> >> Later FE2 is started but dpcm_be_connect(FE2, BE, stream) would be not >> made because BE is no longer in NEW/CLOSE state. > I share Peter's analysis, there cannot be any restrictions on > connections - at any time. A mixer input might become active and be > added to the mix. We might have a temporary lock to delay new > connections but cannot not reject them outright based on BE state. Yes, I understand how this affects a system like yours. As per mixer example above, in our case subsequent FEs always find BE from Crossbar. That is why I don't see similar error. >>> I am just >>> curious to know, if originally you were reconfiguring the BE DAI again >>> with same parameters (for a second FE) or some additional configuration >>> is done? > That's a different question - and a good one. > > In the case of a mixer, the propagation of hw_params is a broken > concept. It leads to the first FE configuring the BE to define its > preferred parameters, e.g. S16_LE format. If later on a second FE is > started which could play S24_LE, the mixer and BE are already configured > to a lower resolution. A mixer should really have its own parameters and > be the start of a new 'domain' - as Lars described it several years ago > at the audio miniconference. Propagation is one of the problems we want to address and require help from DPCM experts. But the scenario you mentioned is a special case which need not be supported, because mixer can operate in one configuration at a given time and subsequent FEs should agree to the already running configuration. However mixer should support both S16_LE and S24_LE (whenever possible), but not simultaneously. At least this is the expecation from our systems. Yes mixer may require fixup of a specific config (we earlier had proposed mixer controls to configure mixer parameters, but the idea was disliked), but propagation may help avoid fixing up everywhere in the audio path where it is not really required. But I don't know how this can be done at the moment. > > For now, the only restriction that we could enforce is that the BE > cannot be reconfigured after the prepare step. > > Note that our DAIs tolerate multiple calls to hw_params. If you have a > case where the hw_params allocates resources, maybe you should consider > moving that allocation to the prepare step, or free them if you detect a > reconfiguration. That would be something needed even outside of the DPCM > scope. Similarly you need to support the case where the DAI hw_free is > called without hw_params ever being called, it's a known sequence that > can happen if the FE hw-params fails. Currently this does not seem to be a problem for us. Patch was to avoid reconfiguration which was felt to be redundant for our system. >>>> I can send a revert with the explanations in the commit message if there >>>> is a consensus that this patch needs to be revisited. >>> May be this can be revisited since it appears to be a critical problem >>> for your system. But I hope this discussion can be alive on following >>> points for a better fix. >>> >>> 1. The original issue at my end was not just a configuration redundancy. >>> I realize now that with more stream addition following error print is seen. >>> "ASoC: too many users playback at open 4" >>> >>> This is because the max DPCM users is capped at 8. Increasing this >>> may help (need to see what number is better), but does not address the >>> redundancy problem. > we haven't used more than 2 users, but it's already broken at 2 with > race conditions left and right. I am really surprised you managed to > have more than 2 without hitting inconsistent states - our automated > play/stop/pause monkey tests reliably break DPCM in less than 20s. I am not sure what is the exact difference, may be DPCM usage in our case is different from what you have. I have mixer tests for different combinations (2x1, 3x1 ...), which seem to pass. In general, we want to have path like this. FE -> BE1 -> BE2 -> ... -> BEx Each BEx could be a mixer, resampler etc., Currently DPCM core sees this as multiple BEs for a given FE and that is why multiple "users" are reported. In the interim, may be we can have following patch to keep both systems working and keep the discussion going to address the oustanding requirements/issues? diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index ab25f99..0fbab50 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -1395,7 +1395,13 @@ static int dpcm_add_paths(struct snd_soc_pcm_runtime *fe, int stream,                 if (!fe->dpcm[stream].runtime && !fe->fe_compr)                         continue; -               if ((be->dpcm[stream].state != SND_SOC_DPCM_STATE_NEW) && +               /* +                * Filter for systems with 'component_chaining' enabled. +                * This helps to avoid unnecessary re-configuration of an +                * already active BE on such systems. +                */ +               if (fe->card->component_chaining && +                   (be->dpcm[stream].state != SND_SOC_DPCM_STATE_NEW) &&                     (be->dpcm[stream].state != SND_SOC_DPCM_STATE_CLOSE))                         continue; > >>> 2. If reconfiguration of the same BE is not necessary for a subsequent >>> FE run, shouldn't we avoid the reconfig itself and somehow avoid FE >>> failure? >> I'm not sure, but it might be possible to just skip the >> dpcm_set_be_update_state(be, stream, SND_SOC_DPCM_UPDATE_BE); >> call at the end of the loop, but the question is under which condition? >> Can a BE asked to be reconfigured when STOP/OPEN/HW_PARAMS? >> >> Skipping the connect does not sound right for a new FE-BE connection. > The reconfiguration is one problem, but what also happens is that the BE > dailink will see multiple triggers. I've been playing with refcounts to > force consistency and make sure there is only one TRIGGER_START send to > the dailink, and conversely there are cases where the TRIGGER_STOP is > never sent... Just a thought. FE links have dummy codec DAI and core wants to find a real BE when FE is started. May be don't fail a FE when no back end DAI is found (and/or find if the same BE is already connected to some FE) and the above problem becomes simpler? 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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AB8DEC433EF for ; Thu, 30 Sep 2021 07:58:16 +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 314BC615A7 for ; Thu, 30 Sep 2021 07:58:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 314BC615A7 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=nvidia.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=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 072F01677; Thu, 30 Sep 2021 09:57:23 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 072F01677 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1632988693; bh=s7jyp5qSVo52mIbzCiKb5sagU2CuoTJW+PkmqqjhVFc=; h=Subject:To:References:From:Date:In-Reply-To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=iZIQ5G2ujm5MoPPhqOvs56LuIqVGKXll5U561/7OPsJGrG7gp3sOoOK0vwbg3doHW 9WjMqelJeTLP57/+M1GyIm0B3P3fsDyxr+a+CLJSHevMyP9LeHw7uypw6eJRPUEkWf GmKripA+SYrXSGwmNkHc0lSeDx4iB93nAo6zZWKA= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 72E8DF80113; Thu, 30 Sep 2021 09:57:22 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id BAA4FF804AD; Thu, 30 Sep 2021 09:57:20 +0200 (CEST) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2055.outbound.protection.outlook.com [40.107.237.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id EBA90F80218 for ; Thu, 30 Sep 2021 09:57:15 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz EBA90F80218 Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key) header.d=Nvidia.com header.i=@Nvidia.com header.b="ilpxOavV" ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i/86GhbA6XrHLNoRtVZrA2sd4YRPmcKer1nvgIWezs4D5GuarXaLqBm6SbLAwH+5epOSLRnliTzjj3gE9LRiOXTphRBwpoLmWJCG0iKwW4bkAvj3fCYD+Cr2WfffjsIziOWwYg6BjARJ/63+KoXW5UrjH8umPGwJhCP/a7xapZ0pgPIT45Jz4ZUn5kOHJyEnD4Uo2I1++SDzCX8csRFFso5VPpzbiptizSbYMWzl1WUU72Y/hnbwxZxgL+YBNTaL8U9rwTr+28BX0gqMQ2lwJ8lMn5am4V+LVXog5fx3ZHYe6cF7rsy4777y+qr7hhK4j4BpDF7M7QU68mNrochvAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yt7Anovnp6T7Y1g+Z6f/bQgqyXLTnr+vok3tfV4VCoo=; b=WK/IWSUg1BsDBB2r9bcSulLnibvMXgA9FhoTNF7J9JJ/5cvywx2VsBSagsCSaM1hdNRUJMhuuz59MW6b1F/yB+V1YmmbhspGLngEnKyHGQu7uqkc9pwtnKflIj2j+GgM9ytfFk/lzrP3IQUTUAvH45CVOOIevGPxrNOPtwkO3msfcI9Q2VTyNqp6Bn8A7J7kHBvwTZ4NA9oGXPolV8/4Ei4yaUI7NfRY57EBINurGR1kcOIDWw8AyciZtbjDM+/w53ui43Zja26SUrkXnkXzz/OFQKcs+GObC5BnR9Pufjw+ZAIyElPJP1tOyB2+D198BNeqtpYfWBtX48OKszjobg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 216.228.112.34) smtp.rcpttodomain=gmail.com smtp.mailfrom=nvidia.com; dmarc=pass (p=quarantine sp=none pct=100) action=none header.from=nvidia.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yt7Anovnp6T7Y1g+Z6f/bQgqyXLTnr+vok3tfV4VCoo=; b=ilpxOavVhlWKpYJVEchCLou3iZRZfZgXl7gnPoGwyc1kKdqm/BbN7QtpNtgGumagnLPRgZSyAqLlnD7W9pKCHfrl/WLTDtgouF4NijohbgKYVfJM3/JXeaF1A1+KJrFSMVPwr9lbSpT2mz/QK/hpZtU7p7m+M76mqHAOUr5W0TGoTQj0mi3o7Wfqs6LLJMkLYkp/t/DdmKKqLzZo36+XUICWNu+KbVuUYuKYq3VX7ww0SfoN8cb4ksnV3GfuOrC0mQrDuqKUQ7xL2Du+MZOvvueErmSk/MIi8vU0z1Bdo7rrxO6S4SsiVqgxOHWYkmz9hAt2+O6GsKKPbJUtZnQP0A== Received: from MW4PR04CA0265.namprd04.prod.outlook.com (2603:10b6:303:88::30) by DM6PR12MB3483.namprd12.prod.outlook.com (2603:10b6:5:11f::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.14; Thu, 30 Sep 2021 07:57:11 +0000 Received: from CO1NAM11FT044.eop-nam11.prod.protection.outlook.com (2603:10b6:303:88:cafe::1) by MW4PR04CA0265.outlook.office365.com (2603:10b6:303:88::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.14 via Frontend Transport; Thu, 30 Sep 2021 07:57:11 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 216.228.112.34) smtp.mailfrom=nvidia.com; gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=pass action=none header.from=nvidia.com; Received-SPF: Pass (protection.outlook.com: domain of nvidia.com designates 216.228.112.34 as permitted sender) receiver=protection.outlook.com; client-ip=216.228.112.34; helo=mail.nvidia.com; Received: from mail.nvidia.com (216.228.112.34) by CO1NAM11FT044.mail.protection.outlook.com (10.13.175.188) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.4566.14 via Frontend Transport; Thu, 30 Sep 2021 07:57:11 +0000 Received: from [10.25.99.231] (172.20.187.5) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Thu, 30 Sep 2021 07:57:04 +0000 Subject: Re: [PATCH 01/13] ASoC: soc-pcm: Don't reconnect an already active BE To: Pierre-Louis Bossart , =?UTF-8?Q?P=c3=a9ter_Ujfalusi?= , , , , , , , , , , References: <1630056839-6562-1-git-send-email-spujar@nvidia.com> <1630056839-6562-2-git-send-email-spujar@nvidia.com> <70422e52-89d2-d926-b3f9-be59780d464e@nvidia.com> <2f96f1aa-74f2-8ea8-3f43-e4da97400fde@linux.intel.com> <647b1d54-dbd7-ce91-291d-d677ce908398@linux.intel.com> From: Sameer Pujar Message-ID: <94861852-29ba-be9e-8c63-a70a01550b3a@nvidia.com> Date: Thu, 30 Sep 2021 13:27:01 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <647b1d54-dbd7-ce91-291d-d677ce908398@linux.intel.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Originating-IP: [172.20.187.5] X-ClientProxiedBy: HQMAIL107.nvidia.com (172.20.187.13) To HQMAIL107.nvidia.com (172.20.187.13) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: bd292a31-d556-49fa-6b16-08d983e7e89e X-MS-TrafficTypeDiagnostic: DM6PR12MB3483: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7691; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 8RPNFnIXlBKzayIs4Krmfh0zHtltOYK52I/aSl7c4ONWF826KrRlRrylVcZ/mv4V8T3lFdsn57YBfXdGJS/n4HQF4WicGB+at/6LdvPYiQqfrUsWO+ZAHeHAezl+NjeveVsWSzw8PZ1EhQR8t9jueu89YD8WR4wJh25J2yYQzwq6p7wXM30+5HT64v0whQ0doVD5yFKXucEO9c3lRsci5RLCvzpYExfqCAYJfaHjMqiTZiXWm4d97ea1fhv+kq6Bqga/yGIApV+UooLGA08sZI5wqTAoE0fRP8CjU6vgROUNNbQPmAm3guqipd/cE/TfHiAS7bAqqRAYP/gc9uP2CGSPlf0V326TKGCJ/OLm6ZSL05T+XvCEIOMG4e0winMuZF9jqYSU+xeB94y2goc4FwR9Ie5QjBuY1pMpH7LT0u0/dyE3r8KNdOTgpm8SMcc+dNHt+JBtPIoSqOBjIxJY/7wrf4chwk9oYUy/wnafG+l0AHJZR59+6LAcitgmFuISUYwjiPcl4qffyjcJrWxsskB1U3wkX9qQqUig0j/KS7qwkxYkQueZ//thEsHd7WLT53y1w0YLQWBLYkmFnx3t3EuRp1YeZlZQLecSH9j3iHkKvzA1SHy5ddlQnoNcReQNmDAzDZi/aIPxgi4NNh3jHnuicoNiPqE6Orkec4kVURo9xGYQdA+75cKSvXOeFhUqUvxs99abV8OXmopVfoalR1GMW+OVuxhZ1DxENjuzHRxCbdUSBsrP8l3YKYQITCaIFYT0PaPkHBguSHq+eE8iZ68+BNr1jRmEYsXB6v4Hq3eGOLE2VjESU2p3OJEZtHDt6S5awNTeN8PjVfWTsg9IuPA+mX2ikw/Qdu2dTAfhzLf5+kNmeoGPD2kgDhH4W0Ax X-Forefront-Antispam-Report: CIP:216.228.112.34; CTRY:US; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:mail.nvidia.com; PTR:schybrid03.nvidia.com; CAT:NONE; SFS:(4636009)(46966006)(36840700001)(26005)(921005)(336012)(316002)(110136005)(54906003)(6666004)(4326008)(7636003)(16576012)(70206006)(5660300002)(70586007)(8936002)(2906002)(8676002)(53546011)(186003)(82310400003)(83380400001)(2616005)(7416002)(31686004)(966005)(86362001)(36860700001)(47076005)(356005)(508600001)(36756003)(16526019)(426003)(31696002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Sep 2021 07:57:11.1616 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: bd292a31-d556-49fa-6b16-08d983e7e89e X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=43083d15-7273-40c1-b7db-39efd9ccc17a; Ip=[216.228.112.34]; Helo=[mail.nvidia.com] X-MS-Exchange-CrossTenant-AuthSource: CO1NAM11FT044.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB3483 Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, sharadg@nvidia.com, linux-tegra@vger.kernel.org, linux-arm-kernel@lists.infradead.org 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" On 9/29/2021 8:22 PM, Pierre-Louis Bossart wrote: >>>> But in addition we'd need to agree on what an 'active BE' is. Why can't >>>> we connect a second stream while the first one is already in HW_PARAMS >>>> or PAUSED or STOP? It's perfectly legal in ALSA/ASoC to have multiple >>>> HW_PARAMS calls, and when we reach STOP we have to do a prepare again. >>>> >>>> And more fundamentally, the ability to add a second FE on a 'active' BE >>>> in START state is a basic requirement for a mixer, e.g. to play a >>>> notification on one FE while listening to music on another. What needs >>>> to happen is only to make sure that the FE and BE are compatible in >>>> terms of HW_PARAMS and not sending a second TRIGGER_STOP, only checking >>>> the BE NEW or CLOSE state is way too restrictive. >>> Sorry for the trouble to your system. >>> >>> Idea was to avoid reconfiguration of the same BE DAI again, but not to >>> stop the provision to add a subsequent FE. In fact I had tested mixing >>> of streams coming from 10 different FEs. > Can you describe the sequence that you used to start them? That may be > useful to understand the criteria you used? I have something like this: FE1  --> Crossbar -> Mixer Input1    | FE2  --> Crossbar -> Mixer Input2    | ...                                  | --> Mixer Output --> ... | FE10 --> Crossbar -> Mixer Input10   | All these FEs are started one after the other. This is an example of 10x1. Similarly we can have 2x1, 3x1 etc., In our system, the crossbar [0] and mixer [1] are separate ASoC components. Basically audio paths consist of a group of ASoC components which are connected back to back. [0] https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/tree/sound/soc/tegra/tegra210_ahub.c [1] https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/tree/sound/soc/tegra/tegra210_mixer.c > [...] > I don't fully understand the notion of mixer input DAI, in our case we > have a bunch of PCM devices connected to a mixer. The mixer is not > directly connected to a DAI. Please see above mixer example. Since mixer is a separate ASoC component, it exposes 10 inputs (or DAIs) and outputs. Originally what I wanted to do was, for subsequent FE runs (FE2, FE3 ...) mixer output need not be configured again and again. >> The problem as I see is that with this patch one can not connect a new >> FE to a BE which is _not_ in NEW or CLOSE state. >> >> The FE and BE needs to be connected to have DPCM working and this patch >> makes the code to skip the dpcm_be_connect(). >> >> Consider this simple setup: >> >> FE1 -->| >> | --> BE --> >> FE2- ->| >> >> First we start FE1, dpcm_be_connect(FE1, BE, stream) is made. >> >> Later FE2 is started but dpcm_be_connect(FE2, BE, stream) would be not >> made because BE is no longer in NEW/CLOSE state. > I share Peter's analysis, there cannot be any restrictions on > connections - at any time. A mixer input might become active and be > added to the mix. We might have a temporary lock to delay new > connections but cannot not reject them outright based on BE state. Yes, I understand how this affects a system like yours. As per mixer example above, in our case subsequent FEs always find BE from Crossbar. That is why I don't see similar error. >>> I am just >>> curious to know, if originally you were reconfiguring the BE DAI again >>> with same parameters (for a second FE) or some additional configuration >>> is done? > That's a different question - and a good one. > > In the case of a mixer, the propagation of hw_params is a broken > concept. It leads to the first FE configuring the BE to define its > preferred parameters, e.g. S16_LE format. If later on a second FE is > started which could play S24_LE, the mixer and BE are already configured > to a lower resolution. A mixer should really have its own parameters and > be the start of a new 'domain' - as Lars described it several years ago > at the audio miniconference. Propagation is one of the problems we want to address and require help from DPCM experts. But the scenario you mentioned is a special case which need not be supported, because mixer can operate in one configuration at a given time and subsequent FEs should agree to the already running configuration. However mixer should support both S16_LE and S24_LE (whenever possible), but not simultaneously. At least this is the expecation from our systems. Yes mixer may require fixup of a specific config (we earlier had proposed mixer controls to configure mixer parameters, but the idea was disliked), but propagation may help avoid fixing up everywhere in the audio path where it is not really required. But I don't know how this can be done at the moment. > > For now, the only restriction that we could enforce is that the BE > cannot be reconfigured after the prepare step. > > Note that our DAIs tolerate multiple calls to hw_params. If you have a > case where the hw_params allocates resources, maybe you should consider > moving that allocation to the prepare step, or free them if you detect a > reconfiguration. That would be something needed even outside of the DPCM > scope. Similarly you need to support the case where the DAI hw_free is > called without hw_params ever being called, it's a known sequence that > can happen if the FE hw-params fails. Currently this does not seem to be a problem for us. Patch was to avoid reconfiguration which was felt to be redundant for our system. >>>> I can send a revert with the explanations in the commit message if there >>>> is a consensus that this patch needs to be revisited. >>> May be this can be revisited since it appears to be a critical problem >>> for your system. But I hope this discussion can be alive on following >>> points for a better fix. >>> >>> 1. The original issue at my end was not just a configuration redundancy. >>> I realize now that with more stream addition following error print is seen. >>> "ASoC: too many users playback at open 4" >>> >>> This is because the max DPCM users is capped at 8. Increasing this >>> may help (need to see what number is better), but does not address the >>> redundancy problem. > we haven't used more than 2 users, but it's already broken at 2 with > race conditions left and right. I am really surprised you managed to > have more than 2 without hitting inconsistent states - our automated > play/stop/pause monkey tests reliably break DPCM in less than 20s. I am not sure what is the exact difference, may be DPCM usage in our case is different from what you have. I have mixer tests for different combinations (2x1, 3x1 ...), which seem to pass. In general, we want to have path like this. FE -> BE1 -> BE2 -> ... -> BEx Each BEx could be a mixer, resampler etc., Currently DPCM core sees this as multiple BEs for a given FE and that is why multiple "users" are reported. In the interim, may be we can have following patch to keep both systems working and keep the discussion going to address the oustanding requirements/issues? diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index ab25f99..0fbab50 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -1395,7 +1395,13 @@ static int dpcm_add_paths(struct snd_soc_pcm_runtime *fe, int stream,                 if (!fe->dpcm[stream].runtime && !fe->fe_compr)                         continue; -               if ((be->dpcm[stream].state != SND_SOC_DPCM_STATE_NEW) && +               /* +                * Filter for systems with 'component_chaining' enabled. +                * This helps to avoid unnecessary re-configuration of an +                * already active BE on such systems. +                */ +               if (fe->card->component_chaining && +                   (be->dpcm[stream].state != SND_SOC_DPCM_STATE_NEW) &&                     (be->dpcm[stream].state != SND_SOC_DPCM_STATE_CLOSE))                         continue; > >>> 2. If reconfiguration of the same BE is not necessary for a subsequent >>> FE run, shouldn't we avoid the reconfig itself and somehow avoid FE >>> failure? >> I'm not sure, but it might be possible to just skip the >> dpcm_set_be_update_state(be, stream, SND_SOC_DPCM_UPDATE_BE); >> call at the end of the loop, but the question is under which condition? >> Can a BE asked to be reconfigured when STOP/OPEN/HW_PARAMS? >> >> Skipping the connect does not sound right for a new FE-BE connection. > The reconfiguration is one problem, but what also happens is that the BE > dailink will see multiple triggers. I've been playing with refcounts to > force consistency and make sure there is only one TRIGGER_START send to > the dailink, and conversely there are cases where the TRIGGER_STOP is > never sent... Just a thought. FE links have dummy codec DAI and core wants to find a real BE when FE is started. May be don't fail a FE when no back end DAI is found (and/or find if the same BE is already connected to some FE) and the above problem becomes simpler? 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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9A22BC433EF for ; Thu, 30 Sep 2021 08:00:04 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 5E76C615E2 for ; Thu, 30 Sep 2021 08:00:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 5E76C615E2 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=nvidia.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:CC:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=sQGh7LB/8tN1qEhu/YqUyeIeLB+rVqFE2Atwn2Z4c6M=; b=Rz3gSDCgm/jlXPIRUF4Mu0FH4J wq3KqE3AvWa+ODg/OPxS7fJTdx6IBSGGroUiF24YQLX8ub9b5cohm1C9JI2GvsqWwQGOWiMdhU7tk vEpXc/8+FZQYVzsH36KdToWFRX4EPE8bCYCAU0Cugwcyy+IrXf1ISYHHDB9A7x85mH1CkVHW6V6Vd 4vgiE/vs0Ausf90NiQQDcDkBXyOFs9zkEJ0n3X1EKrqnS/omeAQMQwEwdcchZIWQCvDSIScnA5oI1 pBERXhfnjusHCHwYCaT2enZ10LK9MAnPicxPq+mKUKee91ySem6xH43uXUfvbSDa+nX+hkHMbujMk mqoRoEsg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mVqwV-00DHu1-TN; Thu, 30 Sep 2021 07:57:24 +0000 Received: from mail-bn8nam12on2064.outbound.protection.outlook.com ([40.107.237.64] helo=NAM12-BN8-obe.outbound.protection.outlook.com) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mVqwO-00DHqy-Hz for linux-arm-kernel@lists.infradead.org; Thu, 30 Sep 2021 07:57:18 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i/86GhbA6XrHLNoRtVZrA2sd4YRPmcKer1nvgIWezs4D5GuarXaLqBm6SbLAwH+5epOSLRnliTzjj3gE9LRiOXTphRBwpoLmWJCG0iKwW4bkAvj3fCYD+Cr2WfffjsIziOWwYg6BjARJ/63+KoXW5UrjH8umPGwJhCP/a7xapZ0pgPIT45Jz4ZUn5kOHJyEnD4Uo2I1++SDzCX8csRFFso5VPpzbiptizSbYMWzl1WUU72Y/hnbwxZxgL+YBNTaL8U9rwTr+28BX0gqMQ2lwJ8lMn5am4V+LVXog5fx3ZHYe6cF7rsy4777y+qr7hhK4j4BpDF7M7QU68mNrochvAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yt7Anovnp6T7Y1g+Z6f/bQgqyXLTnr+vok3tfV4VCoo=; b=WK/IWSUg1BsDBB2r9bcSulLnibvMXgA9FhoTNF7J9JJ/5cvywx2VsBSagsCSaM1hdNRUJMhuuz59MW6b1F/yB+V1YmmbhspGLngEnKyHGQu7uqkc9pwtnKflIj2j+GgM9ytfFk/lzrP3IQUTUAvH45CVOOIevGPxrNOPtwkO3msfcI9Q2VTyNqp6Bn8A7J7kHBvwTZ4NA9oGXPolV8/4Ei4yaUI7NfRY57EBINurGR1kcOIDWw8AyciZtbjDM+/w53ui43Zja26SUrkXnkXzz/OFQKcs+GObC5BnR9Pufjw+ZAIyElPJP1tOyB2+D198BNeqtpYfWBtX48OKszjobg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 216.228.112.34) smtp.rcpttodomain=gmail.com smtp.mailfrom=nvidia.com; dmarc=pass (p=quarantine sp=none pct=100) action=none header.from=nvidia.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yt7Anovnp6T7Y1g+Z6f/bQgqyXLTnr+vok3tfV4VCoo=; b=ilpxOavVhlWKpYJVEchCLou3iZRZfZgXl7gnPoGwyc1kKdqm/BbN7QtpNtgGumagnLPRgZSyAqLlnD7W9pKCHfrl/WLTDtgouF4NijohbgKYVfJM3/JXeaF1A1+KJrFSMVPwr9lbSpT2mz/QK/hpZtU7p7m+M76mqHAOUr5W0TGoTQj0mi3o7Wfqs6LLJMkLYkp/t/DdmKKqLzZo36+XUICWNu+KbVuUYuKYq3VX7ww0SfoN8cb4ksnV3GfuOrC0mQrDuqKUQ7xL2Du+MZOvvueErmSk/MIi8vU0z1Bdo7rrxO6S4SsiVqgxOHWYkmz9hAt2+O6GsKKPbJUtZnQP0A== Received: from MW4PR04CA0265.namprd04.prod.outlook.com (2603:10b6:303:88::30) by DM6PR12MB3483.namprd12.prod.outlook.com (2603:10b6:5:11f::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.14; Thu, 30 Sep 2021 07:57:11 +0000 Received: from CO1NAM11FT044.eop-nam11.prod.protection.outlook.com (2603:10b6:303:88:cafe::1) by MW4PR04CA0265.outlook.office365.com (2603:10b6:303:88::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.14 via Frontend Transport; Thu, 30 Sep 2021 07:57:11 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 216.228.112.34) smtp.mailfrom=nvidia.com; gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=pass action=none header.from=nvidia.com; Received-SPF: Pass (protection.outlook.com: domain of nvidia.com designates 216.228.112.34 as permitted sender) receiver=protection.outlook.com; client-ip=216.228.112.34; helo=mail.nvidia.com; Received: from mail.nvidia.com (216.228.112.34) by CO1NAM11FT044.mail.protection.outlook.com (10.13.175.188) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.4566.14 via Frontend Transport; Thu, 30 Sep 2021 07:57:11 +0000 Received: from [10.25.99.231] (172.20.187.5) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Thu, 30 Sep 2021 07:57:04 +0000 Subject: Re: [PATCH 01/13] ASoC: soc-pcm: Don't reconnect an already active BE To: Pierre-Louis Bossart , =?UTF-8?Q?P=c3=a9ter_Ujfalusi?= , , , , , , , , , , CC: , , , , , References: <1630056839-6562-1-git-send-email-spujar@nvidia.com> <1630056839-6562-2-git-send-email-spujar@nvidia.com> <70422e52-89d2-d926-b3f9-be59780d464e@nvidia.com> <2f96f1aa-74f2-8ea8-3f43-e4da97400fde@linux.intel.com> <647b1d54-dbd7-ce91-291d-d677ce908398@linux.intel.com> From: Sameer Pujar Message-ID: <94861852-29ba-be9e-8c63-a70a01550b3a@nvidia.com> Date: Thu, 30 Sep 2021 13:27:01 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <647b1d54-dbd7-ce91-291d-d677ce908398@linux.intel.com> Content-Language: en-GB X-Originating-IP: [172.20.187.5] X-ClientProxiedBy: HQMAIL107.nvidia.com (172.20.187.13) To HQMAIL107.nvidia.com (172.20.187.13) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: bd292a31-d556-49fa-6b16-08d983e7e89e X-MS-TrafficTypeDiagnostic: DM6PR12MB3483: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7691; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 8RPNFnIXlBKzayIs4Krmfh0zHtltOYK52I/aSl7c4ONWF826KrRlRrylVcZ/mv4V8T3lFdsn57YBfXdGJS/n4HQF4WicGB+at/6LdvPYiQqfrUsWO+ZAHeHAezl+NjeveVsWSzw8PZ1EhQR8t9jueu89YD8WR4wJh25J2yYQzwq6p7wXM30+5HT64v0whQ0doVD5yFKXucEO9c3lRsci5RLCvzpYExfqCAYJfaHjMqiTZiXWm4d97ea1fhv+kq6Bqga/yGIApV+UooLGA08sZI5wqTAoE0fRP8CjU6vgROUNNbQPmAm3guqipd/cE/TfHiAS7bAqqRAYP/gc9uP2CGSPlf0V326TKGCJ/OLm6ZSL05T+XvCEIOMG4e0winMuZF9jqYSU+xeB94y2goc4FwR9Ie5QjBuY1pMpH7LT0u0/dyE3r8KNdOTgpm8SMcc+dNHt+JBtPIoSqOBjIxJY/7wrf4chwk9oYUy/wnafG+l0AHJZR59+6LAcitgmFuISUYwjiPcl4qffyjcJrWxsskB1U3wkX9qQqUig0j/KS7qwkxYkQueZ//thEsHd7WLT53y1w0YLQWBLYkmFnx3t3EuRp1YeZlZQLecSH9j3iHkKvzA1SHy5ddlQnoNcReQNmDAzDZi/aIPxgi4NNh3jHnuicoNiPqE6Orkec4kVURo9xGYQdA+75cKSvXOeFhUqUvxs99abV8OXmopVfoalR1GMW+OVuxhZ1DxENjuzHRxCbdUSBsrP8l3YKYQITCaIFYT0PaPkHBguSHq+eE8iZ68+BNr1jRmEYsXB6v4Hq3eGOLE2VjESU2p3OJEZtHDt6S5awNTeN8PjVfWTsg9IuPA+mX2ikw/Qdu2dTAfhzLf5+kNmeoGPD2kgDhH4W0Ax X-Forefront-Antispam-Report: CIP:216.228.112.34; CTRY:US; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:mail.nvidia.com; PTR:schybrid03.nvidia.com; CAT:NONE; SFS:(4636009)(46966006)(36840700001)(26005)(921005)(336012)(316002)(110136005)(54906003)(6666004)(4326008)(7636003)(16576012)(70206006)(5660300002)(70586007)(8936002)(2906002)(8676002)(53546011)(186003)(82310400003)(83380400001)(2616005)(7416002)(31686004)(966005)(86362001)(36860700001)(47076005)(356005)(508600001)(36756003)(16526019)(426003)(31696002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Sep 2021 07:57:11.1616 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: bd292a31-d556-49fa-6b16-08d983e7e89e X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=43083d15-7273-40c1-b7db-39efd9ccc17a; Ip=[216.228.112.34]; Helo=[mail.nvidia.com] X-MS-Exchange-CrossTenant-AuthSource: CO1NAM11FT044.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB3483 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210930_005716_707137_02E3FA92 X-CRM114-Status: GOOD ( 50.91 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org CgpPbiA5LzI5LzIwMjEgODoyMiBQTSwgUGllcnJlLUxvdWlzIEJvc3NhcnQgd3JvdGU6Cj4+Pj4g QnV0IGluIGFkZGl0aW9uIHdlJ2QgbmVlZCB0byBhZ3JlZSBvbiB3aGF0IGFuICdhY3RpdmUgQkUn IGlzLiBXaHkgY2FuJ3QKPj4+PiB3ZSBjb25uZWN0IGEgc2Vjb25kIHN0cmVhbSB3aGlsZSB0aGUg Zmlyc3Qgb25lIGlzIGFscmVhZHkgaW4gSFdfUEFSQU1TCj4+Pj4gb3IgUEFVU0VEIG9yIFNUT1A/ IEl0J3MgcGVyZmVjdGx5IGxlZ2FsIGluIEFMU0EvQVNvQyB0byBoYXZlIG11bHRpcGxlCj4+Pj4g SFdfUEFSQU1TIGNhbGxzLCBhbmQgd2hlbiB3ZSByZWFjaCBTVE9QIHdlIGhhdmUgdG8gZG8gYSBw cmVwYXJlIGFnYWluLgo+Pj4+Cj4+Pj4gQW5kIG1vcmUgZnVuZGFtZW50YWxseSwgdGhlIGFiaWxp dHkgdG8gYWRkIGEgc2Vjb25kIEZFIG9uIGEgJ2FjdGl2ZScgQkUKPj4+PiBpbiBTVEFSVCBzdGF0 ZSBpcyBhIGJhc2ljIHJlcXVpcmVtZW50IGZvciBhIG1peGVyLCBlLmcuIHRvIHBsYXkgYQo+Pj4+ IG5vdGlmaWNhdGlvbiBvbiBvbmUgRkUgd2hpbGUgbGlzdGVuaW5nIHRvIG11c2ljIG9uIGFub3Ro ZXIuIFdoYXQgbmVlZHMKPj4+PiB0byBoYXBwZW4gaXMgb25seSB0byBtYWtlIHN1cmUgdGhhdCB0 aGUgRkUgYW5kIEJFIGFyZSBjb21wYXRpYmxlIGluCj4+Pj4gdGVybXMgb2YgSFdfUEFSQU1TIGFu ZCBub3Qgc2VuZGluZyBhIHNlY29uZCBUUklHR0VSX1NUT1AsIG9ubHkgY2hlY2tpbmcKPj4+PiB0 aGUgQkUgTkVXIG9yIENMT1NFIHN0YXRlIGlzIHdheSB0b28gcmVzdHJpY3RpdmUuCj4+PiBTb3Jy eSBmb3IgdGhlIHRyb3VibGUgdG8geW91ciBzeXN0ZW0uCj4+Pgo+Pj4gSWRlYSB3YXMgdG8gYXZv aWQgcmVjb25maWd1cmF0aW9uIG9mIHRoZSBzYW1lIEJFIERBSSBhZ2FpbiwgYnV0IG5vdCB0bwo+ Pj4gc3RvcCB0aGUgcHJvdmlzaW9uIHRvIGFkZCBhIHN1YnNlcXVlbnQgRkUuIEluIGZhY3QgSSBo YWQgdGVzdGVkIG1peGluZwo+Pj4gb2Ygc3RyZWFtcyBjb21pbmcgZnJvbSAxMCBkaWZmZXJlbnQg RkVzLgo+IENhbiB5b3UgZGVzY3JpYmUgdGhlIHNlcXVlbmNlIHRoYXQgeW91IHVzZWQgdG8gc3Rh cnQgdGhlbT8gVGhhdCBtYXkgYmUKPiB1c2VmdWwgdG8gdW5kZXJzdGFuZCB0aGUgY3JpdGVyaWEg eW91IHVzZWQ/CgpJIGhhdmUgc29tZXRoaW5nIGxpa2UgdGhpczoKCkZFMcKgIC0tPiBDcm9zc2Jh ciAtPiBNaXhlciBJbnB1dDHCoMKgwqAgfApGRTLCoCAtLT4gQ3Jvc3NiYXIgLT4gTWl4ZXIgSW5w dXQywqDCoMKgIHwKLi4uwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwgLS0+IE1peGVyIE91dHB1dCAtLT4KLi4uIHwKRkUx MCAtLT4gQ3Jvc3NiYXIgLT4gTWl4ZXIgSW5wdXQxMCDCoCB8CgpBbGwgdGhlc2UgRkVzIGFyZSBz dGFydGVkIG9uZSBhZnRlciB0aGUgb3RoZXIuIFRoaXMgaXMgYW4gZXhhbXBsZSBvZiAKMTB4MS4g U2ltaWxhcmx5IHdlIGNhbiBoYXZlIDJ4MSwgM3gxIGV0Yy4sCkluIG91ciBzeXN0ZW0sIHRoZSBj cm9zc2JhciBbMF0gYW5kIG1peGVyIFsxXSBhcmUgc2VwYXJhdGUgQVNvQyAKY29tcG9uZW50cy4g QmFzaWNhbGx5IGF1ZGlvIHBhdGhzIGNvbnNpc3Qgb2YgYSBncm91cCBvZiBBU29DIGNvbXBvbmVu dHMgCndoaWNoIGFyZSBjb25uZWN0ZWQgYmFjayB0byBiYWNrLgoKWzBdIApodHRwczovL2dpdC5r ZXJuZWwub3JnL3B1Yi9zY20vbGludXgva2VybmVsL2dpdC9icm9vbmllL3NvdW5kLmdpdC90cmVl L3NvdW5kL3NvYy90ZWdyYS90ZWdyYTIxMF9haHViLmMKWzFdIApodHRwczovL2dpdC5rZXJuZWwu b3JnL3B1Yi9zY20vbGludXgva2VybmVsL2dpdC9icm9vbmllL3NvdW5kLmdpdC90cmVlL3NvdW5k L3NvYy90ZWdyYS90ZWdyYTIxMF9taXhlci5jCgo+CgpbLi4uXQoKPiBJIGRvbid0IGZ1bGx5IHVu ZGVyc3RhbmQgdGhlIG5vdGlvbiBvZiBtaXhlciBpbnB1dCBEQUksIGluIG91ciBjYXNlIHdlCj4g aGF2ZSBhIGJ1bmNoIG9mIFBDTSBkZXZpY2VzIGNvbm5lY3RlZCB0byBhIG1peGVyLiBUaGUgbWl4 ZXIgaXMgbm90Cj4gZGlyZWN0bHkgY29ubmVjdGVkIHRvIGEgREFJLgoKUGxlYXNlIHNlZSBhYm92 ZSBtaXhlciBleGFtcGxlLiBTaW5jZSBtaXhlciBpcyBhIHNlcGFyYXRlIEFTb0MgCmNvbXBvbmVu dCwgaXQgZXhwb3NlcyAxMCBpbnB1dHMgKG9yIERBSXMpIGFuZCBvdXRwdXRzLiBPcmlnaW5hbGx5 IHdoYXQgSSAKd2FudGVkIHRvIGRvIHdhcywgZm9yIHN1YnNlcXVlbnQgRkUgcnVucyAoRkUyLCBG RTMgLi4uKSBtaXhlciBvdXRwdXQgCm5lZWQgbm90IGJlIGNvbmZpZ3VyZWQgYWdhaW4gYW5kIGFn YWluLgoKPj4gVGhlIHByb2JsZW0gYXMgSSBzZWUgaXMgdGhhdCB3aXRoIHRoaXMgcGF0Y2ggb25l IGNhbiBub3QgY29ubmVjdCBhIG5ldwo+PiBGRSB0byBhIEJFIHdoaWNoIGlzIF9ub3RfIGluIE5F VyBvciBDTE9TRSBzdGF0ZS4KPj4KPj4gVGhlIEZFIGFuZCBCRSBuZWVkcyB0byBiZSBjb25uZWN0 ZWQgdG8gaGF2ZSBEUENNIHdvcmtpbmcgYW5kIHRoaXMgcGF0Y2gKPj4gbWFrZXMgdGhlIGNvZGUg dG8gc2tpcCB0aGUgZHBjbV9iZV9jb25uZWN0KCkuCj4+Cj4+IENvbnNpZGVyIHRoaXMgc2ltcGxl IHNldHVwOgo+Pgo+PiBGRTEgLS0+fAo+PiAgICAgICAgIHwgLS0+IEJFIC0tPgo+PiBGRTItIC0+ fAo+Pgo+PiBGaXJzdCB3ZSBzdGFydCBGRTEsIGRwY21fYmVfY29ubmVjdChGRTEsIEJFLCBzdHJl YW0pIGlzIG1hZGUuCj4+Cj4+IExhdGVyIEZFMiBpcyBzdGFydGVkIGJ1dCBkcGNtX2JlX2Nvbm5l Y3QoRkUyLCBCRSwgc3RyZWFtKSB3b3VsZCBiZSBub3QKPj4gbWFkZSBiZWNhdXNlIEJFIGlzIG5v IGxvbmdlciBpbiBORVcvQ0xPU0Ugc3RhdGUuCj4gSSBzaGFyZSBQZXRlcidzIGFuYWx5c2lzLCB0 aGVyZSBjYW5ub3QgYmUgYW55IHJlc3RyaWN0aW9ucyBvbgo+IGNvbm5lY3Rpb25zIC0gYXQgYW55 IHRpbWUuIEEgbWl4ZXIgaW5wdXQgbWlnaHQgYmVjb21lIGFjdGl2ZSBhbmQgYmUKPiBhZGRlZCB0 byB0aGUgbWl4LiBXZSBtaWdodCBoYXZlIGEgdGVtcG9yYXJ5IGxvY2sgdG8gZGVsYXkgbmV3Cj4g Y29ubmVjdGlvbnMgYnV0IGNhbm5vdCBub3QgcmVqZWN0IHRoZW0gb3V0cmlnaHQgYmFzZWQgb24g QkUgc3RhdGUuCgpZZXMsIEkgdW5kZXJzdGFuZCBob3cgdGhpcyBhZmZlY3RzIGEgc3lzdGVtIGxp a2UgeW91cnMuIEFzIHBlciBtaXhlciAKZXhhbXBsZSBhYm92ZSwgaW4gb3VyIGNhc2Ugc3Vic2Vx dWVudCBGRXMgYWx3YXlzIGZpbmQgQkUgZnJvbSBDcm9zc2Jhci4gClRoYXQgaXMgd2h5IEkgZG9u J3Qgc2VlIHNpbWlsYXIgZXJyb3IuCgo+Pj4gSSBhbSBqdXN0Cj4+PiBjdXJpb3VzIHRvIGtub3cs IGlmIG9yaWdpbmFsbHkgeW91IHdlcmUgcmVjb25maWd1cmluZyB0aGUgQkUgREFJIGFnYWluCj4+ PiB3aXRoIHNhbWUgcGFyYW1ldGVycyAoZm9yIGEgc2Vjb25kIEZFKSBvciBzb21lIGFkZGl0aW9u YWwgY29uZmlndXJhdGlvbgo+Pj4gaXMgZG9uZT8KPiBUaGF0J3MgYSBkaWZmZXJlbnQgcXVlc3Rp b24gLSBhbmQgYSBnb29kIG9uZS4KPgo+IEluIHRoZSBjYXNlIG9mIGEgbWl4ZXIsIHRoZSBwcm9w YWdhdGlvbiBvZiBod19wYXJhbXMgaXMgYSBicm9rZW4KPiBjb25jZXB0LiBJdCBsZWFkcyB0byB0 aGUgZmlyc3QgRkUgY29uZmlndXJpbmcgdGhlIEJFIHRvIGRlZmluZSBpdHMKPiBwcmVmZXJyZWQg cGFyYW1ldGVycywgZS5nLiBTMTZfTEUgZm9ybWF0LiBJZiBsYXRlciBvbiBhIHNlY29uZCBGRSBp cwo+IHN0YXJ0ZWQgd2hpY2ggY291bGQgcGxheSBTMjRfTEUsIHRoZSBtaXhlciBhbmQgQkUgYXJl IGFscmVhZHkgY29uZmlndXJlZAo+IHRvIGEgbG93ZXIgcmVzb2x1dGlvbi4gQSBtaXhlciBzaG91 bGQgcmVhbGx5IGhhdmUgaXRzIG93biBwYXJhbWV0ZXJzIGFuZAo+IGJlIHRoZSBzdGFydCBvZiBh IG5ldyAnZG9tYWluJyAtIGFzIExhcnMgZGVzY3JpYmVkIGl0IHNldmVyYWwgeWVhcnMgYWdvCj4g YXQgdGhlIGF1ZGlvIG1pbmljb25mZXJlbmNlLgoKUHJvcGFnYXRpb24gaXMgb25lIG9mIHRoZSBw cm9ibGVtcyB3ZSB3YW50IHRvIGFkZHJlc3MgYW5kIHJlcXVpcmUgaGVscCAKZnJvbSBEUENNIGV4 cGVydHMuIEJ1dCB0aGUgc2NlbmFyaW8geW91IG1lbnRpb25lZCBpcyBhIHNwZWNpYWwgY2FzZSAK d2hpY2ggbmVlZCBub3QgYmUgc3VwcG9ydGVkLCBiZWNhdXNlIG1peGVyIGNhbiBvcGVyYXRlIGlu IG9uZSAKY29uZmlndXJhdGlvbiBhdCBhIGdpdmVuIHRpbWUgYW5kIHN1YnNlcXVlbnQgRkVzIHNo b3VsZCBhZ3JlZSB0byB0aGUgCmFscmVhZHkgcnVubmluZyBjb25maWd1cmF0aW9uLiBIb3dldmVy IG1peGVyIHNob3VsZCBzdXBwb3J0IGJvdGggUzE2X0xFIAphbmQgUzI0X0xFICh3aGVuZXZlciBw b3NzaWJsZSksIGJ1dCBub3Qgc2ltdWx0YW5lb3VzbHkuIEF0IGxlYXN0IHRoaXMgaXMgCnRoZSBl eHBlY2F0aW9uIGZyb20gb3VyIHN5c3RlbXMuIFllcyBtaXhlciBtYXkgcmVxdWlyZSBmaXh1cCBv ZiBhIApzcGVjaWZpYyBjb25maWcgKHdlIGVhcmxpZXIgaGFkIHByb3Bvc2VkIG1peGVyIGNvbnRy b2xzIHRvIGNvbmZpZ3VyZSAKbWl4ZXIgcGFyYW1ldGVycywgYnV0IHRoZSBpZGVhIHdhcyBkaXNs aWtlZCksIGJ1dCBwcm9wYWdhdGlvbiBtYXkgaGVscCAKYXZvaWQgZml4aW5nIHVwIGV2ZXJ5d2hl cmUgaW4gdGhlIGF1ZGlvIHBhdGggd2hlcmUgaXQgaXMgbm90IHJlYWxseSAKcmVxdWlyZWQuIEJ1 dCBJIGRvbid0IGtub3cgaG93IHRoaXMgY2FuIGJlIGRvbmUgYXQgdGhlIG1vbWVudC4KCj4KPiBG b3Igbm93LCB0aGUgb25seSByZXN0cmljdGlvbiB0aGF0IHdlIGNvdWxkIGVuZm9yY2UgaXMgdGhh dCB0aGUgQkUKPiBjYW5ub3QgYmUgcmVjb25maWd1cmVkIGFmdGVyIHRoZSBwcmVwYXJlIHN0ZXAu Cj4KPiBOb3RlIHRoYXQgb3VyIERBSXMgdG9sZXJhdGUgbXVsdGlwbGUgY2FsbHMgdG8gaHdfcGFy YW1zLiBJZiB5b3UgaGF2ZSBhCj4gY2FzZSB3aGVyZSB0aGUgaHdfcGFyYW1zIGFsbG9jYXRlcyBy ZXNvdXJjZXMsIG1heWJlIHlvdSBzaG91bGQgY29uc2lkZXIKPiBtb3ZpbmcgdGhhdCBhbGxvY2F0 aW9uIHRvIHRoZSBwcmVwYXJlIHN0ZXAsIG9yIGZyZWUgdGhlbSBpZiB5b3UgZGV0ZWN0IGEKPiBy ZWNvbmZpZ3VyYXRpb24uIFRoYXQgd291bGQgYmUgc29tZXRoaW5nIG5lZWRlZCBldmVuIG91dHNp ZGUgb2YgdGhlIERQQ00KPiBzY29wZS4gU2ltaWxhcmx5IHlvdSBuZWVkIHRvIHN1cHBvcnQgdGhl IGNhc2Ugd2hlcmUgdGhlIERBSSBod19mcmVlIGlzCj4gY2FsbGVkIHdpdGhvdXQgaHdfcGFyYW1z IGV2ZXIgYmVpbmcgY2FsbGVkLCBpdCdzIGEga25vd24gc2VxdWVuY2UgdGhhdAo+IGNhbiBoYXBw ZW4gaWYgdGhlIEZFIGh3LXBhcmFtcyBmYWlscy4KCkN1cnJlbnRseSB0aGlzIGRvZXMgbm90IHNl ZW0gdG8gYmUgYSBwcm9ibGVtIGZvciB1cy4gUGF0Y2ggd2FzIHRvIGF2b2lkIApyZWNvbmZpZ3Vy YXRpb24gd2hpY2ggd2FzIGZlbHQgdG8gYmUgcmVkdW5kYW50IGZvciBvdXIgc3lzdGVtLgoKPj4+ PiBJIGNhbiBzZW5kIGEgcmV2ZXJ0IHdpdGggdGhlIGV4cGxhbmF0aW9ucyBpbiB0aGUgY29tbWl0 IG1lc3NhZ2UgaWYgdGhlcmUKPj4+PiBpcyBhIGNvbnNlbnN1cyB0aGF0IHRoaXMgcGF0Y2ggbmVl ZHMgdG8gYmUgcmV2aXNpdGVkLgo+Pj4gTWF5IGJlIHRoaXMgY2FuIGJlIHJldmlzaXRlZCBzaW5j ZSBpdCBhcHBlYXJzIHRvIGJlIGEgY3JpdGljYWwgcHJvYmxlbQo+Pj4gZm9yIHlvdXIgc3lzdGVt LiBCdXQgSSBob3BlIHRoaXMgZGlzY3Vzc2lvbiBjYW4gYmUgYWxpdmUgb24gZm9sbG93aW5nCj4+ PiBwb2ludHMgZm9yIGEgYmV0dGVyIGZpeC4KPj4+Cj4+PiAxLiBUaGUgb3JpZ2luYWwgaXNzdWUg YXQgbXkgZW5kIHdhcyBub3QganVzdCBhIGNvbmZpZ3VyYXRpb24gcmVkdW5kYW5jeS4KPj4+IEkg cmVhbGl6ZSBub3cgdGhhdCB3aXRoIG1vcmUgc3RyZWFtIGFkZGl0aW9uIGZvbGxvd2luZyBlcnJv ciBwcmludCBpcyBzZWVuLgo+Pj4gICAgICJBU29DOiB0b28gbWFueSB1c2VycyBwbGF5YmFjayBh dCBvcGVuIDQiCj4+Pgo+Pj4gICAgIFRoaXMgaXMgYmVjYXVzZSB0aGUgbWF4IERQQ00gdXNlcnMg aXMgY2FwcGVkIGF0IDguIEluY3JlYXNpbmcgdGhpcwo+Pj4gbWF5IGhlbHAgKG5lZWQgdG8gc2Vl IHdoYXQgbnVtYmVyIGlzIGJldHRlciksIGJ1dCBkb2VzIG5vdCBhZGRyZXNzIHRoZQo+Pj4gcmVk dW5kYW5jeSBwcm9ibGVtLgo+IHdlIGhhdmVuJ3QgdXNlZCBtb3JlIHRoYW4gMiB1c2VycywgYnV0 IGl0J3MgYWxyZWFkeSBicm9rZW4gYXQgMiB3aXRoCj4gcmFjZSBjb25kaXRpb25zIGxlZnQgYW5k IHJpZ2h0LiBJIGFtIHJlYWxseSBzdXJwcmlzZWQgeW91IG1hbmFnZWQgdG8KPiBoYXZlIG1vcmUg dGhhbiAyIHdpdGhvdXQgaGl0dGluZyBpbmNvbnNpc3RlbnQgc3RhdGVzIC0gb3VyIGF1dG9tYXRl ZAo+IHBsYXkvc3RvcC9wYXVzZSBtb25rZXkgdGVzdHMgcmVsaWFibHkgYnJlYWsgRFBDTSBpbiBs ZXNzIHRoYW4gMjBzLgoKSSBhbSBub3Qgc3VyZSB3aGF0IGlzIHRoZSBleGFjdCBkaWZmZXJlbmNl LCBtYXkgYmUgRFBDTSB1c2FnZSBpbiBvdXIgCmNhc2UgaXMgZGlmZmVyZW50IGZyb20gd2hhdCB5 b3UgaGF2ZS4gSSBoYXZlIG1peGVyIHRlc3RzIGZvciBkaWZmZXJlbnQgCmNvbWJpbmF0aW9ucyAo MngxLCAzeDEgLi4uKSwgd2hpY2ggc2VlbSB0byBwYXNzLiBJbiBnZW5lcmFsLCB3ZSB3YW50IHRv IApoYXZlIHBhdGggbGlrZSB0aGlzLgoKRkUgLT4gQkUxIC0+IEJFMiAtPiAuLi4gLT4gQkV4CgpF YWNoIEJFeCBjb3VsZCBiZSBhIG1peGVyLCByZXNhbXBsZXIgZXRjLiwgQ3VycmVudGx5IERQQ00g Y29yZSBzZWVzIHRoaXMgCmFzIG11bHRpcGxlIEJFcyBmb3IgYSBnaXZlbiBGRSBhbmQgdGhhdCBp cyB3aHkgbXVsdGlwbGUgInVzZXJzIiBhcmUgCnJlcG9ydGVkLgoKSW4gdGhlIGludGVyaW0sIG1h eSBiZSB3ZSBjYW4gaGF2ZSBmb2xsb3dpbmcgcGF0Y2ggdG8ga2VlcCBib3RoIHN5c3RlbXMgCndv cmtpbmcgYW5kIGtlZXAgdGhlIGRpc2N1c3Npb24gZ29pbmcgdG8gYWRkcmVzcyB0aGUgb3VzdGFu ZGluZyAKcmVxdWlyZW1lbnRzL2lzc3Vlcz8KCmRpZmYgLS1naXQgYS9zb3VuZC9zb2Mvc29jLXBj bS5jIGIvc291bmQvc29jL3NvYy1wY20uYwppbmRleCBhYjI1Zjk5Li4wZmJhYjUwIDEwMDY0NAot LS0gYS9zb3VuZC9zb2Mvc29jLXBjbS5jCisrKyBiL3NvdW5kL3NvYy9zb2MtcGNtLmMKQEAgLTEz OTUsNyArMTM5NSwxMyBAQCBzdGF0aWMgaW50IGRwY21fYWRkX3BhdGhzKHN0cnVjdCAKc25kX3Nv Y19wY21fcnVudGltZSAqZmUsIGludCBzdHJlYW0sCiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgaWYgKCFmZS0+ZHBjbVtzdHJlYW1dLnJ1bnRpbWUgJiYgIWZlLT5mZV9jb21wcikKIMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgY29udGludWU7Cgot wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBpZiAoKGJlLT5kcGNtW3N0cmVhbV0uc3RhdGUg IT0gU05EX1NPQ19EUENNX1NUQVRFX05FVykgJiYKK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgLyoKK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAqIEZpbHRlciBmb3Igc3lzdGVt cyB3aXRoICdjb21wb25lbnRfY2hhaW5pbmcnIGVuYWJsZWQuCivCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgKiBUaGlzIGhlbHBzIHRvIGF2b2lkIHVubmVjZXNzYXJ5IHJlLWNvbmZpZ3Vy YXRpb24gb2YgYW4KK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAqIGFscmVhZHkgYWN0 aXZlIEJFIG9uIHN1Y2ggc3lzdGVtcy4KK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAq LworwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBpZiAoZmUtPmNhcmQtPmNvbXBvbmVudF9j aGFpbmluZyAmJgorwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIChiZS0+ZHBj bVtzdHJlYW1dLnN0YXRlICE9IFNORF9TT0NfRFBDTV9TVEFURV9ORVcpICYmCiDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAoYmUtPmRwY21bc3RyZWFtXS5zdGF0ZSAhPSBT TkRfU09DX0RQQ01fU1RBVEVfQ0xPU0UpKQogwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCBjb250aW51ZTsKCj4KPj4+IDIuIElmIHJlY29uZmlndXJhdGlvbiBv ZiB0aGUgc2FtZSBCRSBpcyBub3QgbmVjZXNzYXJ5IGZvciBhIHN1YnNlcXVlbnQKPj4+IEZFIHJ1 biwgc2hvdWxkbid0IHdlIGF2b2lkIHRoZSByZWNvbmZpZyBpdHNlbGYgYW5kIHNvbWVob3cgYXZv aWQgRkUKPj4+IGZhaWx1cmU/Cj4+IEknbSBub3Qgc3VyZSwgYnV0IGl0IG1pZ2h0IGJlIHBvc3Np YmxlIHRvIGp1c3Qgc2tpcCB0aGUKPj4gZHBjbV9zZXRfYmVfdXBkYXRlX3N0YXRlKGJlLCBzdHJl YW0sIFNORF9TT0NfRFBDTV9VUERBVEVfQkUpOwo+PiBjYWxsIGF0IHRoZSBlbmQgb2YgdGhlIGxv b3AsIGJ1dCB0aGUgcXVlc3Rpb24gaXMgdW5kZXIgd2hpY2ggY29uZGl0aW9uPwo+PiBDYW4gYSBC RSBhc2tlZCB0byBiZSByZWNvbmZpZ3VyZWQgd2hlbiBTVE9QL09QRU4vSFdfUEFSQU1TPwo+Pgo+ PiBTa2lwcGluZyB0aGUgY29ubmVjdCBkb2VzIG5vdCBzb3VuZCByaWdodCBmb3IgYSBuZXcgRkUt QkUgY29ubmVjdGlvbi4KPiBUaGUgcmVjb25maWd1cmF0aW9uIGlzIG9uZSBwcm9ibGVtLCBidXQg d2hhdCBhbHNvIGhhcHBlbnMgaXMgdGhhdCB0aGUgQkUKPiBkYWlsaW5rIHdpbGwgc2VlIG11bHRp cGxlIHRyaWdnZXJzLiBJJ3ZlIGJlZW4gcGxheWluZyB3aXRoIHJlZmNvdW50cyB0bwo+IGZvcmNl IGNvbnNpc3RlbmN5IGFuZCBtYWtlIHN1cmUgdGhlcmUgaXMgb25seSBvbmUgVFJJR0dFUl9TVEFS VCBzZW5kIHRvCj4gdGhlIGRhaWxpbmssIGFuZCBjb252ZXJzZWx5IHRoZXJlIGFyZSBjYXNlcyB3 aGVyZSB0aGUgVFJJR0dFUl9TVE9QIGlzCj4gbmV2ZXIgc2VudC4uLgpKdXN0IGEgdGhvdWdodC4g RkUgbGlua3MgaGF2ZSBkdW1teSBjb2RlYyBEQUkgYW5kIGNvcmUgd2FudHMgdG8gZmluZCBhIApy ZWFsIEJFIHdoZW4gRkUgaXMgc3RhcnRlZC4gTWF5IGJlIGRvbid0IGZhaWwgYSBGRSB3aGVuIG5v IGJhY2sgZW5kIERBSSAKaXMgZm91bmQgKGFuZC9vciBmaW5kIGlmIHRoZSBzYW1lIEJFIGlzIGFs cmVhZHkgY29ubmVjdGVkIHRvIHNvbWUgRkUpIAphbmQgdGhlIGFib3ZlIHByb2JsZW0gYmVjb21l cyBzaW1wbGVyPwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KbGludXgtYXJtLWtlcm5lbCBtYWlsaW5nIGxpc3QKbGludXgtYXJtLWtlcm5lbEBsaXN0cy5p bmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8v bGludXgtYXJtLWtlcm5lbAo=