Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp3477102imm; Thu, 17 May 2018 09:20:40 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrWcX5FavXgfkZf+YaunRJckOGKvdr68P9ytrHaA6Y58UVNxc9qFHCvNqvmhI0I0HZKQClG X-Received: by 2002:a63:7f1a:: with SMTP id a26-v6mr4468710pgd.371.1526574040708; Thu, 17 May 2018 09:20:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526574040; cv=none; d=google.com; s=arc-20160816; b=CZPEb2tchvFimWO2AbSazh80QUR1eNzZQWGs6KBWqE6bUuDyE/BPg3mzL4rBAxQ82M qpUe4HqJ49bMQE7FuKITjjw5IiipZx0F/8FCmlobIaExJ4COtyfNe4E9NytO3wSKb3/b W5FhtQ0hwZKGA8wubPUJutsjdxOL0DjtpE4jGgoYs+iXB0AWuVm2kKtyCVkpXgbbYUQR IBOSEFdEjziFOzwcKZa/5+qybi/z9+i6b6qUK8rVSb2ecptHR30jWUcLqFPIIukXovD0 aXkOeGmjQbwAUUyAqPBmGksdCtPOEcIxT0Af0zmbRlMSWgj/jdmbFGNXRy6F6wW71U+3 tojA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=52oSjcxm5H3MWM7B6jO2IvbwEQu+KztfPhBl2VaFT1o=; b=xEkJhHeWQ5dOWSDdAqlJLZ/HR5pqK4wn7eKs95x0UXYJSYOjmlFuxJ6t3dwxkFRsYv lIOAsaTY1yrCi6Sf6/8IMrzgNImNRz2QgGsc/rwEQx31tLRRdIym49s31QpA0gXi1BfT d53O6aBMjhlBAX9nfMIOXiCd/tp4aNa7IUhZFbqmvFN1JYUeL/wy4tx+/ugEdjLfHIHH pMX7Q5AjpQEH8VjEz6wILy8oeC59r+vu4KF1aBSQEga0Ct+qubK3s2hkPeEZVL7BCPNF 20DnTow4vXqghL7CnbEBrQ6jskXsoYwBigxw1drQh8VCjVtqSQP1KckwXwRjmHIQCHu0 g2DA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=fSQEbEla; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i195-v6si1780214pgc.291.2018.05.17.09.20.26; Thu, 17 May 2018 09:20:40 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=fSQEbEla; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752304AbeEQQUM (ORCPT + 99 others); Thu, 17 May 2018 12:20:12 -0400 Received: from mail-io0-f195.google.com ([209.85.223.195]:40363 "EHLO mail-io0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751649AbeEQQUJ (ORCPT ); Thu, 17 May 2018 12:20:09 -0400 Received: by mail-io0-f195.google.com with SMTP id g14-v6so2684531ioc.7; Thu, 17 May 2018 09:20:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=52oSjcxm5H3MWM7B6jO2IvbwEQu+KztfPhBl2VaFT1o=; b=fSQEbElapQgzVFhKmIZF4asl4aeL2g/oBSkWHE2SFdn9ZsQheg+lqirjHgD5w/4aus ja434KdABPT9LHz3/0qp0N55/DhbD2lKknd4p8QMevMlN2hm7o7E3FelOduxcwWEyBA6 D9GmhRyCwduI95zl8LbfM8PWX7Gj/Hu5CWGqYaoslhst+dheWXTkdXx1KNvBaVlAl3pR xTQeVUCu4wdYLqx/0R/cU1tgAO0T2HRxl2g628W6CgVCW3Phdfqn1yO9PirnSSosw9Oh XjnKKdxFjpRWcvEIxKmXhs7QuMBze8MFA+Pqi37zBBIe4CXKELSqWptOZ3CI9Xyvlhop W3RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=52oSjcxm5H3MWM7B6jO2IvbwEQu+KztfPhBl2VaFT1o=; b=Ahd3CvuFkuypjufJt3a317yqe6FTWbABVTC4150srgD9s6FzQukamF1/ksWoh0XxYF j9mDGHR8wn+foPdqayPHsEwsXgiLXoMun1tTeW+2PSRj+y/nQP4SXsK98B0P625hjPoG yDxEhkVJB81WbiOrLrzPfPfTRZK+aCF4XRoiRurwLVzbOpXzMvGcUzOJz7VGTh4wnRq1 LejUHDQUtPmJUkb7MSA7Reyhh1QpjWLD66f9f7n/z6tOslp5PzzruTGcmhb3jgmzX4LP QGtM+BORn6v+yr+LmNBx/SWfxpogIX0YcnL1f3w0YOUw7uxgu0jyaksEL73IrIjOcoGR UY/A== X-Gm-Message-State: ALKqPwf3Ow7c7qoE03mWKZy9j1XE8kpKWuXbPCV5Z+P5Gh8AVPnMDZ3g R791/pCvwGURfEm3LKwTw6947WpehMMrvEOXCH4= X-Received: by 2002:a6b:a0ce:: with SMTP id j197-v6mr6894327ioe.290.1526574008703; Thu, 17 May 2018 09:20:08 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:4d51:0:0:0:0:0 with HTTP; Thu, 17 May 2018 09:20:07 -0700 (PDT) In-Reply-To: <20180517041946.GQ13271@vkoul-mobl> 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: Frank Mori Hess Date: Thu, 17 May 2018 12:20:07 -0400 Message-ID: Subject: Re: Revert "dmaengine: pl330: add DMA_PAUSE feature" To: 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. On Thu, May 17, 2018 at 12:19 AM, Vinod Koul wrote: >> > Terminate is abort, data loss may happen here. >> >> Wait, are you saying if you do >> >> dma pause > > no data loss >> read residue > > here as well >> dma terminate > > Oh yes, we aborted... >> I see two ways of interpreting what you are saying. First, from the point of view of the user of the dmaengine api. From this point of view it is impossible for data loss to occur during pause or reading the residue, so saying they cause no data loss during pause/residue/terminate is meaningless. This is because the user can't confirm any data loss until after they have read the residue and the transfer is terminated, since optimistically the data may still be available if only the user would resume and allow the transfer to continue. Second there is the interpretation I want to believe. This is "no data loss on pause" means that after the pause, no data has been discarded by the dma controller hardware, in fact all the data it has read before being paused has been fully transferred to its destination. Reading the residue while paused gives you an accurate, up-to-date state of the paused transfer. Then finally, although in general dma terminate causes data loss, it does not in this case since we terminated while we were paused and read the up-to-date residue. This is the interpretation implicit in the 8250 serial driver.