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;
Subject: Re: [PATCH v7 13/19] dmaengine: tegra-apb: Don't stop cyclic DMA in a
 case of error condition
To:     Dmitry Osipenko <digetx@gmail.com>,
        Laxman Dewangan <ldewangan@nvidia.com>,
        Vinod Koul <vkoul@kernel.org>,
        Dan Williams <dan.j.williams@intel.com>,
        Thierry Reding <thierry.reding@gmail.com>,
        =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= <mirq-linux@rere.qmqm.pl>
CC:     <dmaengine@vger.kernel.org>, <linux-tegra@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>
References: <20200202222854.18409-1-digetx@gmail.com>
 <20200202222854.18409-14-digetx@gmail.com>
From:   Jon Hunter <jonathanh@nvidia.com>
Message-ID: <332e8e86-dca5-19f2-9ef1-6d89a55f3651@nvidia.com>
Date:   Tue, 4 Feb 2020 12:02:36 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <20200202222854.18409-14-digetx@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


On 02/02/2020 22:28, Dmitry Osipenko wrote:
> There is no harm in keeping DMA active in the case of error condition,
> which should never happen in practice anyways. This will become useful
> for the next patch, which will keep RPM enabled only during of DMA
> transfer, and thus, it will be much nicer if cyclic DMA handler could
> not touch the DMA-enable state.
> 
> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
> ---
>  drivers/dma/tegra20-apb-dma.c | 9 +++++----
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
> index c7dc27ef1856..50abce608318 100644
> --- a/drivers/dma/tegra20-apb-dma.c
> +++ b/drivers/dma/tegra20-apb-dma.c
> @@ -571,9 +571,7 @@ static bool handle_continuous_head_request(struct tegra_dma_channel *tdc,
>  	 */
>  	hsgreq = list_first_entry(&tdc->pending_sg_req, typeof(*hsgreq), node);
>  	if (!hsgreq->configured) {
> -		tegra_dma_stop(tdc);
> -		dev_err(tdc2dev(tdc), "Error in DMA transfer, aborting DMA\n");
> -		tegra_dma_abort_all(tdc);
> +		dev_err_ratelimited(tdc2dev(tdc), "Error in DMA transfer\n");

While we are at it, a more descriptive error message could be good here.
I believe that this condition would indicate a potential underrun condition.

>  		return false;
>  	}
>  
> @@ -772,7 +770,10 @@ static int tegra_dma_terminate_all(struct dma_chan *dc)
>  	if (!list_empty(&tdc->pending_sg_req) && was_busy) {
>  		sgreq = list_first_entry(&tdc->pending_sg_req, typeof(*sgreq),
>  					 node);
> -		sgreq->dma_desc->bytes_transferred +=
> +		dma_desc = sgreq->dma_desc;
> +
> +		if (dma_desc->dma_status != DMA_ERROR)
> +			dma_desc->bytes_transferred +=
>  				get_current_xferred_count(tdc, sgreq, wcount);

I am wondering if we need to check this here? I assume that the transfer
count would still reflect the amount of data transferred, even if some
was dropped. We will never know how much data was lost.

Jon

-- 
nvpublic