From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753318AbcGUQIr (ORCPT ); Thu, 21 Jul 2016 12:08:47 -0400 Received: from mail-pa0-f47.google.com ([209.85.220.47]:35545 "EHLO mail-pa0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753217AbcGUQIn (ORCPT ); Thu, 21 Jul 2016 12:08:43 -0400 Message-ID: <5790F380.4020204@linaro.org> Date: Fri, 22 Jul 2016 00:08:32 +0800 From: zhangfei User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: John Stultz CC: lkml , Jingoo Han , Krzysztof Kozlowski , Maxime Ripard , Vinod Koul , Dan Williams , Mark Brown , Andy Green Subject: Re: [PATCH 6/7] k3dma: Fix occasional DMA ERR issue by using proper dma api References: <1469073189-9167-1-git-send-email-john.stultz@linaro.org> <1469073189-9167-7-git-send-email-john.stultz@linaro.org> <57904F08.7020109@linaro.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/21/2016 01:22 PM, John Stultz wrote: > On Wed, Jul 20, 2016 at 9:26 PM, zhangfei wrote: >> >> >> On 07/21/2016 11:53 AM, John Stultz wrote: >>> >>> After lots of debugging on an occasional DMA ERR issue, I realized >>> that the desc structures which we point the dma hardware are being >>> allocated out of regular memory. This means when we fill the desc >>> structures, that data doesn't always get flushed out to memory by >>> the time we start the dma transfer, resulting in the dma engine getting >>> some null values, resulting in a DMA ERR on the first irq. >> >> >> How about using wmb() flush before start dma to sync desc? > > So I'm not going to pretend to be an expert here, but my understanding > is that wmb() syncrhonizes cpu write ordering operations across cpus, > so the cpus see all the changes before the wmb() before they see any > changes after. But I'm not sure what effect wmb() has across cpu > cache to device ordering. I don't think it works as a cache flush to > memory. > > Andy's patch introducing the cyclic support actually had a wmb() in it > that I removed as I couldn't understand clearly why it was there (and > there wasn't a comment explaining, as required by checkpatch :). But > even with that wmb(), the DMA ERR was still seen. > > Only with these two new changes have I gotten to the point where I > can't seem to trigger the DMA error. > Yes, you are right. Have double checked, we have to use non-cached memory here as dma descriptor, instead of cached memory from kzalloc. And barrier (wmb or writel) is used to ensure descriptor are written before start dma. Though we start dma much later in issue_pending -> tasklet, so the chance is low. Thanks