From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752569AbcGUNMv (ORCPT ); Thu, 21 Jul 2016 09:12:51 -0400 Received: from mail.warmcat.com ([163.172.24.82]:39868 "EHLO mail.warmcat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752478AbcGUNMf (ORCPT ); Thu, 21 Jul 2016 09:12:35 -0400 DKIM-Filter: OpenDKIM Filter v2.10.3 warmcat.warmcat.com 1EB18D8AC7 Message-ID: <1469106740.24655.65.camel@warmcat.com> Subject: Re: [PATCH 6/7] k3dma: Fix occasional DMA ERR issue by using proper dma api From: Andy Green To: Mark Brown Cc: John Stultz , zhangfei , lkml , Jingoo Han , Krzysztof Kozlowski , Maxime Ripard , Vinod Koul , Dan Williams Date: Thu, 21 Jul 2016 21:12:20 +0800 In-Reply-To: <20160721104000.GM6509@sirena.org.uk> 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> <20160721104000.GM6509@sirena.org.uk> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2016-07-21 at 11:40 +0100, Mark Brown wrote: > On Thu, Jul 21, 2016 at 02:27:02PM +0800, Andy Green wrote: > > > > On July 21, 2016 1:22:02 PM GMT+08:00, John Stultz > aro.org> wrote: > > > > > > On Wed, Jul 20, 2016 at 9:26 PM, zhangfei > > g> > > Please fix your mail client to word wrap within paragraphs at > something > substantially less than 80 columns.  Doing this makes your messages > much > easier to read and reply to. > > > > > > > > > > > > > > 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, > > > > > IIUI what the memory barrier does is tell the *compiler* to > > actually > > do any writes that the code asked for, but which otherwise might > > actually be deferred past that point.  The compiler doesn't know > > that > > buffer area has other hardware snooping it, so by default it feels > > it > > can play tricks with what seems to it like just generally deferring > > spilling registers to memory.  wmb makes sure the compiler's > > pending > > writes actually happen right there.  (writel() etc definitions have > > one built-in, so they always do what you asked when you asked). > > You might be interested in Mark Rutland's talk from ELC (Stale data, > or > how we (mis-)manage modern caches): > >     http://events.linuxfoundation.org/sites/events/files/slides/slide > s_17.pdf Thanks for the pointer. That is a somewhat different animal to wmb though: wmb is about managing when the initiator of the write actualizes it, prior to that the write does not instantenously exist anywhere and so is not subject to these coherency nightmares [1]. Also the presentation is from the hw POV only, at the Linux driver level most of the considerations can be made moot if you just use the generic Linux DMA or related apis, which thanks to the work of the Arm Linux gods already knows how to deal with / wrap the issues, plus or minus.  So it's not as dire as it sounds. -Andy [1] The details of some of those nightmares are unfortunately very familiar to me, since I spent many months where Linux was being blamed for Mali breakage via CCI on a platform that ultimately had its problems resolved by tweaks in its secure world... >     https://www.youtube.com/watch?v=F0SlIMHRnLk