Received: by 10.192.165.148 with SMTP id m20csp186358imm; Wed, 9 May 2018 10:52:34 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoZRY5wChnQlNBJYe/RxtTIqrYj9De2etZyAdABJTuRJjKIyrPLEVTdkQ0zEYtpPjHiy3tY X-Received: by 2002:a17:902:144:: with SMTP id 62-v6mr46437923plb.202.1525888354325; Wed, 09 May 2018 10:52:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525888354; cv=none; d=google.com; s=arc-20160816; b=LkTHtKccMQ9+/xPOxJ2plX4StW1nnxMURGwPn6wnyqmiEXJsBxEUz4PFA3oSvLfZz8 t1EOISvvpt11S3rrNDx20mTyoDN84P9ZjRgwo9ysztdsNlTUjjs35osoNYDwwNpaVkem Gph0z07G6IZTgGVTPUtfGa4/xngGjWFkSCFsQ4oSyR63c5HpfvyvyC0zeLYu+ZQ6nyNv dYd+k+69tGGoQQ8XDRKUezPtmxX6/Lu/vySlgp4ViImuBTvhHwkfCAnJjwRTbg08ajGe qxYICrbZI0RixDyGzgL9XZdPjRbCbyiORksBFAO6sjdMeioVkaj0k9rVxqXwsHhSx60I 6HhQ== 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=FEgt7MgDGDQDPuJ7b88evYW9MbQLu9KFJPvydFaJWWs=; b=JH1Kg5vEsf23zb5tr5OAiGXUJxY85YJVtZQdKfo9ZbqyhRYPGCJXLZbyOLinfq+RB4 zAx0Pej3aZHJ+680QWpdAb6wmIJ05fQBBZhoGkQ+jy1mUiJ/EcqtYhE8aRBHPKK0cnI6 vhXeJNKtDe2KqCp4qKltThMWE/jTDUXj7KEw+2RQuzppWTPkDCBcIRl7+zsYCUjQgIjO aUwKgFW4cChoNp2b2S2ln0WNFB+j+OwLaAG4ED/pcFK00R0cI5MpYQeHlcXMG8mKYW0Z /2Hp5QhWyk8OhkUz7epgXMcMrY0+gp3B2rOeBYlJhOv/xaqYIEX5eaC/K/TnPY+eHO5y hE8Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=cMdnhanv; 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 s24-v6si25137992plp.564.2018.05.09.10.52.16; Wed, 09 May 2018 10:52:34 -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=cMdnhanv; 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 S935374AbeEIRsO (ORCPT + 99 others); Wed, 9 May 2018 13:48:14 -0400 Received: from mail-io0-f174.google.com ([209.85.223.174]:43013 "EHLO mail-io0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933555AbeEIRsL (ORCPT ); Wed, 9 May 2018 13:48:11 -0400 Received: by mail-io0-f174.google.com with SMTP id t23-v6so43630164ioc.10; Wed, 09 May 2018 10:48:11 -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=FEgt7MgDGDQDPuJ7b88evYW9MbQLu9KFJPvydFaJWWs=; b=cMdnhanviKstaFyXSwVk4eGpZEQlSY2j7V2lo3hMrFrjynAWmXHIs0+q2cRBs2zJJH Wtr6mPfdsBzNiVOSEVk0Cn7SqJ9woHMHdFTxQygjrXFoEHt0TTjFIOMzM3eUw6o0WneT I3O1sfE0cD3hqJ6JU/NWOP4flt10Ao5qLUV83jlush1nEHMM819yyzj+Fb4fQLP5kosy 8NE4skZuslSumPxSMFeVR52IETKpFjFEx/YTNuuQECv5hPlb0Nf5U+cYWkWtVHSvz1LL fzAk1wT7FLrJr/B3sAA2xgwZ163bm6xY6xv1785Au2gzkTZpZD9+dBcLUcbBlYkdCiUJ +6tQ== 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=FEgt7MgDGDQDPuJ7b88evYW9MbQLu9KFJPvydFaJWWs=; b=fl5WF39CLNf/17QPQVF3G4L+VH3o7ALX8BEKGfA4DO7etW1mgVOzH6E6ZzaICXZCGk bRJYsLg3GiUrscLV2j6IaDlZoAxTK5Qu8R/RvCXdcsbQJx37PCD13jiKONH0Slw/GBsC eJWVhp0X9QYAnPPCiLV19xRBz0AM96JXuIbFxeOl9YAjjEO2GR7CBWct0zqQEhA1vLRh QeLRb/faYVt27aksweCG1nY0ueDcpalvNkR2T6XWi55fNmEDHUYGPTeFkLIVYkAFHSuY HVthdc3zWRbJdXZMTHdZQw++VTYenLYb+QHbpmhJQ7M2JV35VLUQBad1xPVGh82wI1O+ 5DCw== X-Gm-Message-State: ALKqPwcQJvS5pRTvujI02scJjPj1SuVJydNPR6+6T1sMYiOIe153jU/a iDX3x1xartQjymPvJXuC8N0FtsYAo8IsuICob1A= X-Received: by 2002:a6b:dd16:: with SMTP id f22-v6mr1776899ioc.7.1525888090861; Wed, 09 May 2018 10:48:10 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:4d51:0:0:0:0:0 with HTTP; Wed, 9 May 2018 10:48:10 -0700 (PDT) In-Reply-To: <182f50b9-55b6-c9ce-07fb-718a1d22e9c8@samsung.com> References: <2484918.HKVQc3yJkt@bear> <53b13d76-16a1-0e0a-09e1-c917e5d49326@samsung.com> <182f50b9-55b6-c9ce-07fb-718a1d22e9c8@samsung.com> From: Frank Mori Hess Date: Wed, 9 May 2018 13:48:10 -0400 Message-ID: Subject: Re: Revert "dmaengine: pl330: add DMA_PAUSE feature" To: Marek Szyprowski Cc: Vinod Koul , 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 Wed, May 9, 2018 at 9:19 AM, Marek Szyprowski wrote: > > I understand that pl330 doesn't support real PAUSE, but as it has been > implemented since 2015 the limited support is perfectly possible - just > to let serial driver to read the amount of data transferred. > > Please note that DMA engine documentation clearly states that the best > residue granularity the driver might expect is BURST granularity. There > is no way to get the information about the data which still sits in the > DMA engine fifo when transfer is paused/terminated. This means that > the serial driver should set maxburst = 1 if it is interested in > getting exact number of bytes received/sent. With maxburst = 1 there > is no such thing as data loose in the DMA engine fifo. That is not my understanding of the dmaengine pause requirements, but of course Vinod can speak authoritatively on this. I also don't agree that data loss cannot happen for single transfers. It only becomes less likely since there are fewer bytes in the dma controller fifo and they stay there for a shorter period of time. But even so, there is nothing stopping the DMAKILL from killing the transfer thread after it does a single byte load but before it does the associated single byte store, as they are performed by separate instructions. As far as your serial port goes, the byte has been read by the host, even though it never made it to memory, so it is gone forever. The dma-330 does have a load lock which prevents some operations from interrupting a load/store combination, but in my observations DMAKILL does not respect the load lock. > 3. Samsung driver doesn't check if DMA engine supports PAUSE feature and > proper residue reporting granularity, so your revert simply breaks its > operation. Oh, I was wrongly assuming you were talking about an 8250 based serial driver. > I've checked other device drivers, which use pl330 DMA on Samsung SoCs and > besides serial, none of them configure maxburst > 1. When I forced such > configuration, none worked fine. I'm a bit confused what does it mean. > Either none of the Samsung SoC integrated peripherals support real burst > DMA transfers, or the PL330 in Samsung SoCs are somehow limited or > dysfunctional. There is already a quirk in pl330 for broken FLUSHP, but I > have no idea how to diagnose if this is the case or the problem is in the > SoC peripherals. I can live with maxburst set to 1 in those drivers as the > proper fix. When the DMA-330 is instructed to do a peripheral burst transfer, it ignores single transfer requests from the peripheral. When it is instructed to do a single transfer, it will do a single transfer in response to either a burst request or a single request. So unless the peripheral actually supports burst requests, the transfer will just wait forever for a burst request which never comes. -- Frank