[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1469106740.24655.65.camel@warmcat.com>
Date: Thu, 21 Jul 2016 21:12:20 +0800
From: Andy Green <andy@...mcat.com>
To: Mark Brown <broonie@...nel.org>
Cc: John Stultz <john.stultz@...aro.org>,
zhangfei <zhangfei.gao@...aro.org>,
lkml <linux-kernel@...r.kernel.org>,
Jingoo Han <jg1.han@...sung.com>,
Krzysztof Kozlowski <k.kozlowski@...sung.com>,
Maxime Ripard <maxime.ripard@...e-electrons.com>,
Vinod Koul <vinod.koul@...el.com>,
Dan Williams <dan.j.williams@...el.com>
Subject: Re: [PATCH 6/7] k3dma: Fix occasional DMA ERR issue by using proper
dma api
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 <john.stultz@lin
> > aro.org> wrote:
> > >
> > > On Wed, Jul 20, 2016 at 9:26 PM, zhangfei <zhangfei.gao@...aro.or
> > > 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
Powered by blists - more mailing lists