Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp950873imm; Mon, 21 May 2018 17:57:05 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqd00o8noePPRnN1h3P3BORrdSqqBsMYWP45QYcqAYg56Ph0+eA3Nmz2U0XSKgUAj0X60/Z X-Received: by 2002:a17:902:ba87:: with SMTP id k7-v6mr22642723pls.193.1526950625768; Mon, 21 May 2018 17:57:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526950625; cv=none; d=google.com; s=arc-20160816; b=Ckvpk9r9YxDjuXsalkcd3bnHUwJQjzPYnGq8NhAytWG5mZQORENBfBVl5oms3igpGT Lu3Hl7lEDgk/em4eIrISY90i4E7XemPikN0Jh6fYZHA/ANmdNiMX7Y3IY2RipCZSmNqs WDlinWywWp/GkpiO0jR2LGXURWQ9mnEqyX49bQIODnDal1RfdYo9fAjymmwxUBWRZEpn SmjbJHFekGUyNVyV3jq/k2KtdgZZkmCDwFQQUsuNmZS0kBBlTOM5tqaPG+F3Y6u1kITQ SlyGPklq1XLxrEHxrDKwSRrGZRz9HDg50CxVV4hNO2HZHgRgObQl0/5gtnX9cXc6Nlze zkrg== 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=8pSROUSJKYTYhmmsJbWRl9dzj4kFe5/fc650aC1KmyE=; b=psivHC/PlDC59qg4kg8UJhyfcQ4M8ZbQ4nCUnDSuxAxkC72BMi60RMl+WfzT9Pb8I5 sf4amMDEzhoL828WepX3I5whA5hjdlzy/BU+41LItsZjTi8cktU1F/j2aBsDTvj0c4bU NRI9kiyTRnMb8jZgJ9bQ2/aTCaiG3Zd8i585xdQAxZzUqVpK1TTYl+7MMgnqY+J6Natb jjN6LW5GZV7gsaycknRBTh8+90obkLfAlT965HtbvGIJt7L3AKzzDm7lL1rg7zoqefFA 4w8ae3z6Pb7HjJaadIW95pmaFPCqLi4KkvEuRloa1+G0H/pz6CrLgUrEA7jQ4qNICpQL L/Fw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=B3AUz9v7; 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 e13-v6si9407434pgt.332.2018.05.21.17.56.50; Mon, 21 May 2018 17:57:05 -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=B3AUz9v7; 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 S1752187AbeEVA4Z (ORCPT + 99 others); Mon, 21 May 2018 20:56:25 -0400 Received: from mail-io0-f196.google.com ([209.85.223.196]:36496 "EHLO mail-io0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752016AbeEVA4W (ORCPT ); Mon, 21 May 2018 20:56:22 -0400 Received: by mail-io0-f196.google.com with SMTP id d73-v6so16483882iog.3; Mon, 21 May 2018 17:56:21 -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=8pSROUSJKYTYhmmsJbWRl9dzj4kFe5/fc650aC1KmyE=; b=B3AUz9v7mfJUosQBBTc26In2Lmc/S5ajoeqhXQ9iH5PJhXGWr/EAQY3YWB5nVzvtk3 vyi3Qogk7aCDtKeC58S3UYH18zKQBj9rxAsaleCfS+JpFEVrguKY298GaI2rDKFLyrYJ vdbxe6eJ3YxYf5/emmj30momPYll1/pTNgfzycAYCXcyjU6yyB0yr/S21erJvqWXzPVI 6lltSvRqG73Y644QiGK2ARArERrwZ542whH0Zs1H/go1U9gNd6tedKTal4ITfIVilhrH N74qdHVWKl0e3UroscsYHdq2uTX4oIyHn/z5meYd42W3upzFJk5ONc4i8BZZOPuhi/W6 UlyQ== 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=8pSROUSJKYTYhmmsJbWRl9dzj4kFe5/fc650aC1KmyE=; b=DViivhDozmWRdvu8ODFZTb2MHO8SSbCRKFpvdsEkuZ/tQtSs5DHfLLH6Yq3BIp/CPb CI9oajfosENxxX9aXWKO8j9OrGYwCbL147th7Rwl7/xX3oUs0IzpoW+QERTnIxGeddAN 9z7/+BWnON0KTzaIOktRqa9nPWN+HWMvemWk+hhxyDzsGmjgTfYjaBez75Tjv/D3CtMX g0/desj6gfaxnwHq82sbXijfcc7T0hQhtN3oek14/aUSfx2KpFAS9BEu+1SfogWiE3Tu vznf1JddhfZpLnzB0jOTU4M2raMcAELecIwsevUPa6/N99G1JVRAnPwp/qkwacRL7Gl+ LKYw== X-Gm-Message-State: ALKqPwfck5DTr64sb5bX6Lnw73Ux8bbU7/ZZy2Bdv2XY0VW/k9SWeJtF nvUcXv1MTzcismDGS9BjknTz7wRd63w1UCsZxpo= X-Received: by 2002:a6b:7c9:: with SMTP id g70-v6mr24485052ioi.82.1526950581585; Mon, 21 May 2018 17:56:21 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:4d51:0:0:0:0:0 with HTTP; Mon, 21 May 2018 17:56:20 -0700 (PDT) In-Reply-To: <20180521091626.GB14654@vkoul-mobl> References: <06f54061-c537-b399-e493-ec2cdf4def5d@samsung.com> <20180515062144.GC13271@vkoul-mobl> <20180517041946.GQ13271@vkoul-mobl> <20180518040349.GB2932@vkoul-mobl> <20180521091626.GB14654@vkoul-mobl> From: Frank Mori Hess Date: Mon, 21 May 2018 20:56:20 -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 On Mon, May 21, 2018 at 5:16 AM, Vinod Koul wrote: >> >> I understand the residue can't be read after terminate, that's why >> reading the residue is step 2 in pause/residue/terminate. My question >> was whether the entire sequence pause/residue/terminate taken as a >> whole can or cannot lose data. Saying that individual steps can or >> can't lose data is not enough, context is required. The key point is >> whether pause flushes in-flight data to its destination or not. If it >> does, and our residue is accurate, the terminate cannot cause data >> loss. If pause doesn't flush, an additional step of flush_sync as >> Lars suggested is required. So pause/flush_sync/residue/terminate >> would be the safe sequence that cannot lose data. > > I wouldn't use cannot, shouldn't would be better here as it depends on HW and > where all data has been buffered and if it can be flushed or not. > > Have you checked if pl330 supports such flushing? It does not, at least in the context of pausing. The dma-330 DMAEND instruction flushes in-flight data to its destination, and there are read/write barrier instructions also, but none of them can be injected on the fly into a running dma thread. DMAKILL can be, but it discards in-flight data. Currently, if an 8250 serial driver uses the pl330 for rx dma, the result is possible data loss/corruption. If there was a stronger pause capability, call it "cmd_sync_pause" which guaranteed flushing of in-flight data to its destination and accurate residue reading when paused, then the 8250 serial driver could check for "cmd_sync_pause" and reject dma drivers that do not have that capability. pl330.c would not advertise cmd_sync_pause. I don't know if other dmaengine hardware would be able to support cmd_sync_pause or not, I'm mostly just familiar with the pl330. The ep93xx_dma.c driver for example has a m2p_hw_synchronize function which seems to do a flush. -- Frank