From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752123AbcGUKkR (ORCPT ); Thu, 21 Jul 2016 06:40:17 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:40906 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751718AbcGUKkN (ORCPT ); Thu, 21 Jul 2016 06:40:13 -0400 Date: Thu, 21 Jul 2016 11:40:00 +0100 From: Mark Brown To: Andy Green Cc: John Stultz , zhangfei , lkml , Jingoo Han , Krzysztof Kozlowski , Maxime Ripard , Vinod Koul , Dan Williams Message-ID: <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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ogUXNSQj4OI1q3LQ" Content-Disposition: inline In-Reply-To: X-Cookie: Sin boldly. User-Agent: Mutt/1.6.0 (2016-04-01) X-SA-Exim-Connect-IP: 2a01:348:6:8808:fab::3 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [PATCH 6/7] k3dma: Fix occasional DMA ERR issue by using proper dma api X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mezzanine.sirena.org.uk) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --ogUXNSQj4OI1q3LQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 wrote: > >On Wed, Jul 20, 2016 at 9:26 PM, zhangfei 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/slides_17.pdf https://www.youtube.com/watch?v=F0SlIMHRnLk --ogUXNSQj4OI1q3LQ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXkKZwAAoJECTWi3JdVIfQ41YIAIMbq/SKVnXFcNXEb1JLcx4s zBv0bIIokqVBVsy4h0ARWpqhaZjLwplbKIBEH7E4JZ42iVV6i9VThip8NsolBf+p OQGSWdVXLrijtGNBC/RaqeU6hgK7QIMmfl+xcCLWUC3mKcjca6HDGDUfL2UMhr/A qC3GjPriEAysI7CUua+CfzcGcg7zHD7FyB7WMjsE9gd3iA8BmgeNLP3NLpqWBUk0 JTwExckFm96byde7hBN8/5FjpUdreTfB1frQKcRdDG8NqMUroEhRs33VVqbVFLLg OXSv2OrZ1qgtRyFsEMSsMfgMlKqMC03Uvg9WNXfYc2b4kPe3rO34PwmstAum42k= =wg3E -----END PGP SIGNATURE----- --ogUXNSQj4OI1q3LQ--