Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp3545416imm; Thu, 17 May 2018 10:23:21 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqgy2kJAqyCC+ZlqF1Wm4yy4+4dx/+zV+6s4Yy6yYambYb14IHZeCqrjkABzUTKj9kNLL1t X-Received: by 2002:a65:64c7:: with SMTP id t7-v6mr4823371pgv.274.1526577801796; Thu, 17 May 2018 10:23:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526577801; cv=none; d=google.com; s=arc-20160816; b=fYwMJnn6irE8SKa6WxmXQSx7LPx+59zKimX1R7WgExveyejiFuRFmarenQ/W1CQPE0 MP+JlhHTSFrP9PW/jC7cIaPNqU4AvsFdBgpNd6trx1zWPy7XqCNB+viNzqGadiFy7yKO yotU4ifs+1Kgyw9otXD9uqr+OFG/WI+/VaESMWYV6KHW3ag4OYw2A/vraG/s1lisMqmq OCNN+T+c4HFRMGowPj/i+vNgyRJMPBFyoNh/yQ5Lqh9id0PRoudmyPxaGhCbZ72AJOm7 cjzFlDwH98RPO9yPB2wn5bKMGPlLJoH1T+crZGGpZVL27pNbDiqSdVC/IzH4yZTNhSI3 z6Nw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=oB0nT2vt55BCFWT4LifS0xam3Dp/qRk2vBdo9B//kRs=; b=aB3SAkrVIiQWLdaKn1OrHyo4r/VWrZTJy8XhaJSBMelUfWkUv4E6O/THgLRCbbOtVI PFVdNts2uS/QrZCjryFGImN811wOjFqAfTCkwftSVMSUwjqBSrzJa9XfV5xO3av1ZH85 m0dcQRxWXopej4+FrKIjrz/dT3pGEgaJaMNAkp5YuWHLpb055fKGoQEoqr2zLAUY3aSN a87Enu1AT8DGsBzuN+c2uKrHVWWZKxg0bablXWsu563Ue5KAoVya4U+i+DrPm18vfIcG 66FKCJSJxh0D+OyfkB21PoCnPHUSUe48ys0Xiyp9NeC6vZdKce3JAXlZeH3Uyp+D2W/Q crpg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g92-v6si5435384plg.342.2018.05.17.10.23.07; Thu, 17 May 2018 10:23:21 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752512AbeEQRWe (ORCPT + 99 others); Thu, 17 May 2018 13:22:34 -0400 Received: from www381.your-server.de ([78.46.137.84]:42291 "EHLO www381.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752030AbeEQRWb (ORCPT ); Thu, 17 May 2018 13:22:31 -0400 Received: from [78.46.172.3] (helo=sslproxy06.your-server.de) by www381.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1fJMbl-0005vB-1o; Thu, 17 May 2018 19:22:29 +0200 Received: from [46.244.176.172] (helo=[192.168.178.26]) by sslproxy06.your-server.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1fJMbk-000DW8-R1; Thu, 17 May 2018 19:22:28 +0200 Subject: Re: Revert "dmaengine: pl330: add DMA_PAUSE feature" To: Frank Mori Hess , Vinod Koul Cc: Marek Szyprowski , dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org, Dan Williams , r.baldyga@hackerion.com, Krzysztof Kozlowski , Bartlomiej Zolnierkiewicz , Linux Samsung SOC References: <2484918.HKVQc3yJkt@bear> <53b13d76-16a1-0e0a-09e1-c917e5d49326@samsung.com> <182f50b9-55b6-c9ce-07fb-718a1d22e9c8@samsung.com> <06f54061-c537-b399-e493-ec2cdf4def5d@samsung.com> <20180515062144.GC13271@vkoul-mobl> <20180517041946.GQ13271@vkoul-mobl> From: Lars-Peter Clausen Message-ID: Date: Thu, 17 May 2018 19:22:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-Sender: lars@metafoo.de X-Virus-Scanned: Clear (ClamAV 0.99.3/24578/Thu May 17 14:36:29 2018) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/17/2018 06:20 PM, Frank Mori Hess wrote: > Sorry to keep coming back to this, but I'm experiencing a bit of > incredulity that you are saying what you seem to be saying. You seem > to be saying dmaengine provides no way to permanently stop a transfer > safely other than transferring the full number of bytes initially > requested. So the proper resolution is the 8250 serial driver needs > to remove rx dma support, because they are just trying to do something > that is not supported. The problem is not so much on the software side but even more so on the hardware side. Not all hardware even supports aborting a transfer with no data loss because there is no precise measurement of how much data has been transferred. The residue that is reported is always the lower bound, this much has been transferred but it might actually have been more. And even if hardware supports precise residue reporting there often is no synchronization mechanism to ensure that there is no pending data anywhere in the pipeline. This doesn't even have to be inside the DMA's buffers, the DMA might have send the data to the peripheral but it has not arrived at the peripheral side. If the peripheral has a memory mapped FIFO there will typically be some confirmation that the data was received, but with a dedicated DMA bus between the DMA controller and the peripheral that is often not the case. And for the first case the DMA controller also needs to actually expose the information how many acknowledgements it has received. Because there are basically two different resides, residue one is how much data has been read from/written to memory and the other is how much data has been read from/written to the peripheral. Any differences between the two will account for in flight data. What I'd recommend is to add a flush_sync() operation to the DMA interface. This function would wait until all in flight data transfers have been completed. That makes it safe to call terminate() without the risk of loosing data and also allow accurate residue reporting. Although I'd expect that there is fair risk that implementations will not get flush_sync() 100% correct because it requires in-depth knowledge about the internal behavior of the DMA which is often not documented.