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,URIBL_BLOCKED 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 EDF58C433DF for ; Wed, 19 Aug 2020 14:27:23 +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 BA4F12076E for ; Wed, 19 Aug 2020 14:27:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="AMYCkWaf"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=skidata.com header.i=@skidata.com header.b="ZNxDmnru" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BA4F12076E 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=IwV4SsOI1Mi1/5xh4ap38GjT1XqteXQhuuTG0dYMEIo=; b=AMYCkWafzPMIzJP1TOrTrEgMn qPEeO8ibpq0q4IL8+NZN3zsJk2O59Ut+A/8R5qJe5R/IvqjMdTFbxhmGRtf0w5AmrDnQZBB9aiE1h yTAEYi9nfr6mhcSdO2U8NTM0TyJ6Z9gzBWMGZ2YycV/OCSsOmsBeESw/Y8uDdZgwDS/TI2QR3qpiG ucV2+wUyvj4EEunDo8SeH/tOrsGQmHMMhT0JhUJjlWRsMXJWnSUbGmfLa/rzl5Hmhk+yOOfMRRDzc /U84olL7NfOsr9mpqz55Sf+MpiooZ2xl2YckUeDIefdnBKDdC1I4g1lbEDGSWweVed+Tzt+j06iWT 1s6Fi3b0Q==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k8P2E-0005BK-5Z; Wed, 19 Aug 2020 14:25:50 +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 1k8P2B-0005Ab-0z for linux-arm-kernel@lists.infradead.org; Wed, 19 Aug 2020 14:25:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=skidata.com; i=@skidata.com; q=dns/txt; s=selector1; t=1597847146; x=1629383146; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YymJ3dZVzHVrgFLhK05T17oVu6zGDEJc8AVV1WphDOI=; b=ZNxDmnrukdDhezm7QxgtcjdoP/Qg9bW0JO/u3xXFHqEL6MaupcNfks3m z1THOqEhZKM/SZ6V1Dy6VHrg2vvs9CVwJ5rnbZg0GPrxMkTDfQmh7q+H3 Z4jxBpQhxURIksGHV3y2C+qkMQsIQ+5smFvMw3kIZh3dFg9j7NGsrEfVr l04ek+c4cx4Ybtc+f7XZEq/OkakrR0/4D2cVlZsR44GrvzfTjr2pSAdA/ n9uhKBKmzVq9cuUFyQOGSH2fqow/sYouCR33GUTIccVr3agNzvNK4HFSV UHsi59dx1DXCmOgiKSLyXqzf4sIOzdMDv+0jSahfORSEVmfdPtB6+WOje A==; IronPort-SDR: 5PZhNmYKfRS1iEeazk3AUKjiex7CCBzJyiV0oe9bAGIFuqLnuWxvzOP+yOxygw0LMhZigOUvVQ Oh1reciiML1xT1TScCcBSeclRPTNjstksGsl+TaIVoY/ATKey4/zPptkdOvg8NSe9HjE+Aplpq 1MT9V3sFQa6u1SNwc/G8gdgsx7/Qzw7/ajztXCosU35zxddFuAW/MmfTcXf6NY1TTIij3D0ApU GG6BpbvaK3nicyTS5nXQ5X+jOD3Lsz2K8yCeR7dm7AQ8AZWUn6LW097UuGtm1cDm93J6JoWuLM gYk= X-IronPort-AV: E=Sophos;i="5.76,331,1592863200"; d="scan'208";a="2645167" From: Benjamin Bara - SKIDATA To: Lars-Peter Clausen , 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/CAB7DUgIAAV/7Q Date: Wed, 19 Aug 2020 14:25:43 +0000 Message-ID: <6b5799a567d14cfb9ce34d278a33017d@skidata.com> References: <20200813112258.GA327172@pcleri> <61498763c60e488a825e8dd270732b62@skidata.com> <16942794-1e03-6da0-b8e5-c82332a217a5@metafoo.de> In-Reply-To: <16942794-1e03-6da0-b8e5-c82332a217a5@metafoo.de> 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-20200819_102547_306776_45DA3F20 X-CRM114-Status: GOOD ( 16.70 ) 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: Lars-Peter Clausen > Sent: Mittwoch, 19. August 2020 13:08 > I think this might be an sdma specific problem after all. > dmaengine_terminate_async() will issue a request to stop the DMA. But it > is still safe to issue the next transfer, even without calling > dmaengine_synchronize(). The DMA should start the new transfer at its > earliest convenience in that case. > > dmaegine_synchronize() is so that the consumer has a guarantee that the > DMA is finished using the resources (e.g. the memory buffers) associated > with the DMA transfer so it can safely free them. Thank you for the clarifications! > I don't know how feasible this is to implement in the SDMA dmaengine > driver. But I think what is should do is to have some flag to indicate > if a terminate is in progress. If a new transfer is issued while > terminate is in progress the transfer should go on a list. Once > terminate finishes it should check the list and start the transfer if > there are any on the list. IMHO that's nearly what Robin's patches does, so this should be sufficient: Putting the descriptors to free in an extra termination list and ensuring that a new transfer is handled after the last termination is done. @Robin: Is it possible to tag the commits for the stable-tree Cc: stable@vger.kernel.org? Best regards and thank you all! Benjamin Richard _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel