On 8/19/2018 11:41 AM, Arnd Bergmann wrote:
Sounds like we need a similar solution for all architectures that
require mmiowb().
That depends on how expensive the barrier is on a given architecture.
It's possible that doing adding the barrier every time is actually
cheaper than keeping track of
On Sun, 19 Aug 2018, Arnd Bergmann wrote:
> > > My understanding for mmiowb() is that it should not be implied by
> > > writel() itself but that it would be added between a writel() and a
> > > spin_unlock(). Putting it into writel() itself would make it completely
> > > pointless as an
On Sun, Aug 19, 2018 at 5:28 PM Sinan Kaya wrote:
>
> On 8/19/2018 11:21 AM, Arnd Bergmann wrote:
> >> This matches my understanding of mmiowb. In fact, mmiowb is a powerpc
> >> thing. All other architectures stub out.
> > There are a few architectures that define mmiowb to something other
> >
On 8/19/2018 11:21 AM, Arnd Bergmann wrote:
This matches my understanding of mmiowb. In fact, mmiowb is a powerpc
thing. All other architectures stub out.
There are a few architectures that define mmiowb to something other
than a nop: some ia64, some mips and sh in particular, plus also the
new
On Sun, Aug 19, 2018 at 5:12 PM wrote:
> On 2018-08-18 19:03, Arnd Bergmann wrote:
> > On Sat, Aug 18, 2018 at 12:05 AM Maciej W. Rozycki
> >
> >> A while ago I proposed a set of different MMIO barriers, that some
> >> systems may require, corresponding to the respective regular memory
> >>
+my new email
On 2018-08-18 19:03, Arnd Bergmann wrote:
On Sat, Aug 18, 2018 at 12:05 AM Maciej W. Rozycki
wrote:
On Fri, 17 Aug 2018, Arnd Bergmann wrote:
> - For outb()/outw()/outl(), we ought to provide stronger barriers than for
> writeb()/writew()/writel(), as PCI drivers should
