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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 C6E21C433DF for ; Mon, 17 Aug 2020 11:39:47 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 8ADAE2063A for ; Mon, 17 Aug 2020 11:39:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="XKCxvCDD"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=skidata.com header.i=@skidata.com header.b="Lw2ae5yj" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8ADAE2063A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=skidata.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:In-Reply-To:References:Message-ID:Date: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Cs2AkFQt0eiXEj7ebl/lHPEi9EUj1naRbXJ3/QzsIp4=; b=XKCxvCDDJKEW/iZ2THzm4SNIG 3r6QPB31iQo654FTO007UTq8fQ9ifnWv/TGI3Cn9otVxs4fhI5OAoJ9O5J8edv1XMFAtgMfIRJfQO 09HqvM6AhwWRZgHoa6aua3E0sCrF2XmbfUGPuVkJwv97+uKUdSAlZCxyxlvAiylgFlr6DKbC4o+CG H6CT9VJECaE9dbtc2s9SXRfxNHtXwWmEinSjBAsj2qYz2+xJUTdl6XaQxSEKdZ8+wyuMnQKw75W4G /Cif995Q0qpJB5XlwDd7yVSY09uq9cZyjRmRcv8ZKxYjgQmZ/zzvJb5cAfHhu/HfW0Ry41ZgbLCNC HgrdePM+Q==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k7dT1-0004wv-Cf; Mon, 17 Aug 2020 11:38:19 +0000 Received: from mail2.skidata.com ([91.230.2.91]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k7dSu-0004ov-Pt for linux-arm-kernel@lists.infradead.org; Mon, 17 Aug 2020 11:38:14 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=skidata.com; i=@skidata.com; q=dns/txt; s=selector1; t=1597664292; x=1629200292; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qAiSySTl/y8QrdoOwS73hqC2vZPrIK22GvC7HIEK8Sw=; b=Lw2ae5yjXRHf7myWWOh9PWaFnXR/cW4hDNv/yaM5IgTnQ5SVHDGFrU/S n+pYuHvDEQasHbL7mDQrMECvQeSTxTzKhgnRF2nCj1882OzdyVEIDSel1 vGwBOEEsqff5Eq6lVVkxIW8RuUbAHt0nA1HyeC/EgXP18mY4hO60xv+QL fMDhgs94xdDYD1lJoTcDPiAqnbPGlGm3jScLL9iMFM3yoWU/O09fLhHcX YfMBNLubaNUipDZU7OniOmC+ppDOMP4bk8/8agFyn9YwHJ0wpH3oJbJJW lTZlDue8mWgLvYQjIABwVsKwUuJs9/ynhaSs7/dMdG0TeaceEwUZbLXVx A==; IronPort-SDR: r14hO/kLklIsGQ2dnpEN7qM09P2f2aF1EjhAlxzmSMcuqfvXFBRe+N2g2GbNAQy6RBnH6mvub4 G9CzTCq5/0Xu34vgrQoODE4XvobffdAgUcNAoI/Wd3UL6Jq51FS5mK4HdyazyQntye83cu6C1d Utxs08P5rh1ovPmRJnbqt32sNVRq/vBpgr26ga+RPc5pxsLbfheQqpxpsN6+Av0kB6MiwftAt7 /fB6w62Tw9zJn1oFUf2wPuRXpstyhH7KMAs9dQhCYg8DlQFi2903uhUeTmOramaYOuZ2OpH0lA PAs= X-IronPort-AV: E=Sophos;i="5.76,322,1592863200"; d="scan'208";a="2642801" From: Benjamin Bara - SKIDATA To: Robin Gong Subject: RE: pcm|dmaengine|imx-sdma race condition on i.MX6 Thread-Topic: pcm|dmaengine|imx-sdma race condition on i.MX6 Thread-Index: AQHWcWQZKYOChL0mPkuCFeZyDJy6mKk3KiiAgABS1/CABG6hAIAARo2Q Date: Mon, 17 Aug 2020 11:38:10 +0000 Message-ID: References: <20200813112258.GA327172@pcleri> <61498763c60e488a825e8dd270732b62@skidata.com> In-Reply-To: Accept-Language: en-US, de-AT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.111.252] MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200817_073813_204896_DC097D4D X-CRM114-Status: GOOD ( 10.58 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "alsa-devel@alsa-project.org" , "timur@kernel.org" , "linux-kernel@vger.kernel.org" , "nicoleotsuka@gmail.com" , "vkoul@kernel.org" , dl-linux-imx , "kernel@pengutronix.de" , "dmaengine@vger.kernel.org" , "dan.j.williams@intel.com" , "shawnguo@kernel.org" , "linux-arm-kernel@lists.infradead.org" , Richard Leitner - SKIDATA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org > -----Original Message----- > From: Robin Gong > Sent: Montag, 17. August 2020 11:23 > busy_wait is not good I think, would you please have a try with the attached patch > which is based on https://lkml.org/lkml/2020/8/11/111? The basic idea is > to keep the freed descriptor into another list for freeing in later terminate_worker > instead of freeing directly all in terminate_worker by vchan_get_all_descriptors > which may break next descriptor coming soon The idea sounds good, but with this attempt we are still not sure that the 1ms (the ultimate reason why this is a problem) is awaited between DMA disabling and re-enabling. If we are allowed to leave the atomic PCM context on each trigger, synchronize the DMA and then enter it back again, everything is fine. This might be the most performant and elegant solution. However, since we are in an atomic context for a reason, it might not be wanted by the PCM system that the DMA termination completion of the previous context happens within the next call, but we are not sure about that. In this case, a busy wait is not a good solution, but a necessary one, or at least the only valid solution we are aware of. Anyhow, based on my understanding, either the start or the stop trigger has to wait the 1ms (or whats left of it). _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel