Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1648763

Re: [PATCH 4/7] RISC-V: arch/riscv/include

Show all headers | View raw

On Tue, 2017-05-23 at 14:55 +0200, Arnd Bergmann wrote:
> > +
> > +#include <asm-generic/io.h>
> 
> I would recommend providing your own {read,write}{b,w,l,q}{,_relaxed}
> helpers using inline assembly, to prevent the compiler for breaking
> up accesses into byte accesses.
> 
> Also, most architectures require to some synchronization after a
> non-relaxed readl() to prevent prefetching of DMA buffers, and
> before a writel() to flush write buffers when a DMA gets triggered.

Right, I was about to comment on that one.

The question Palmer is about the ordering semantics of non-cached
storage.

What kind of ordering is provided architecturally ? Especially
between cachable and non-cachable loads and stores ?

Also, you have PCIe right ? What is the behaviour of MSIs ?

Does your HW provide a guarantee that in the case of a series of DMA
writes to memory by a device followed by an MSI, the CPU getting the
MSI will only get it after all the previous DMA writes have reached
coherency ? (Unlike LSIs where the driver is required to do an MMIO
read from the device, MSIs are expected to be ordered with data).

Another things with the read*() accessors. It's not uncommon for
a driver to do:

	writel(1, reset_reg);
	readl(reset_reg); /* flush posted writes */
	udelay(10);
	writel(0, reset_reg);

Now, in the above case, what can typically happen if you aren't careful
is that the readl which is intended to "push" the previous writel, will
not actually do its job because the return value hasn't been "consumed"
by the processor. Thus, the CPU will stick that on some kind of load
queue and won't actually wait for the return value before hitting the
delay loop.

Thus you might end up in a situation where the writel of 1 to the
device is itself reaching the device way after you started the delay
loop, and thus end up violating the delay requirement of the HW.

On powerpc we solve that by using a special instruction construct
inside the read* accessors that prevents the CPU from executing
subsequent instructions until the read value has been returned.

You may want to consider something similar.

Cheers,
Ben.

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

RISC-V Linux Port v1 Palmer Dabbelt <palmer@dabbelt.com> - 2017-05-23 02:50 +0200
  [PATCH 5/7] RISC-V: arch/riscv/lib Palmer Dabbelt <palmer@dabbelt.com> - 2017-05-23 02:50 +0200
    Re: [PATCH 5/7] RISC-V: arch/riscv/lib Geert Uytterhoeven <geert@linux-m68k.org> - 2017-05-23 12:50 +0200
      Re: [PATCH 5/7] RISC-V: arch/riscv/lib Palmer Dabbelt <palmer@dabbelt.com> - 2017-05-24 00:10 +0200
    Re: [PATCH 5/7] RISC-V: arch/riscv/lib Arnd Bergmann <arnd@arndb.de> - 2017-05-23 13:30 +0200
  [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs Palmer Dabbelt <palmer@dabbelt.com> - 2017-05-23 02:50 +0200
    Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs Olof Johansson <olof@lixom.net> - 2017-05-23 03:30 +0200
      Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs Randy Dunlap <rdunlap@infradead.org> - 2017-05-23 03:40 +0200
        Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs Palmer Dabbelt <palmer@dabbelt.com> - 2017-05-23 06:50 +0200
      Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs Palmer Dabbelt <palmer@dabbelt.com> - 2017-05-23 06:50 +0200
        Re: [patches] Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs Olof Johansson <olof@lixom.net> - 2017-05-23 07:20 +0200
          Re: [patches] Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and  Kconfigs Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2017-05-23 23:10 +0200
    Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs Olof Johansson <olof@lixom.net> - 2017-05-23 07:30 +0200
      Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs Palmer Dabbelt <palmer@dabbelt.com> - 2017-05-23 17:30 +0200
    Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs Geert Uytterhoeven <geert@linux-m68k.org> - 2017-05-23 13:00 +0200
    Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs Arnd Bergmann <arnd@arndb.de> - 2017-05-23 13:50 +0200
  [PATCH 3/7] RISC-V: Device Tree Documentation Palmer Dabbelt <palmer@dabbelt.com> - 2017-05-23 02:50 +0200
    Re: [PATCH 3/7] RISC-V: Device Tree Documentation Arnd Bergmann <arnd@arndb.de> - 2017-05-23 14:10 +0200
  Re: RISC-V Linux Port v1 Olof Johansson <olof@lixom.net> - 2017-05-23 03:20 +0200
    Re: RISC-V Linux Port v1 Randy Dunlap <rdunlap@infradead.org> - 2017-05-23 03:30 +0200
      Re: RISC-V Linux Port v1 Palmer Dabbelt <palmer@dabbelt.com> - 2017-05-23 05:40 +0200
    Re: RISC-V Linux Port v1 Palmer Dabbelt <palmer@dabbelt.com> - 2017-05-23 05:40 +0200
      Re: RISC-V Linux Port v1 Tobias Klauser <tklauser@distanz.ch> - 2017-05-23 08:50 +0200
        Re: RISC-V Linux Port v1 Palmer Dabbelt <palmer@dabbelt.com> - 2017-05-23 17:50 +0200
  Re: RISC-V Linux Port v1 Randy Dunlap <rdunlap@infradead.org> - 2017-05-23 04:20 +0200
    Re: RISC-V Linux Port v1 Palmer Dabbelt <palmer@dabbelt.com> - 2017-05-23 06:50 +0200
  Re: [PATCH 6/7] RISC-V: arch/riscv/kernel Olof Johansson <olof@lixom.net> - 2017-05-23 04:20 +0200
  Re: [PATCH 4/7] RISC-V: arch/riscv/include Arnd Bergmann <arnd@arndb.de> - 2017-05-23 15:00 +0200
    Re: [PATCH 4/7] RISC-V: arch/riscv/include Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2017-05-23 23:30 +0200
  Re: [PATCH 6/7] RISC-V: arch/riscv/kernel Arnd Bergmann <arnd@arndb.de> - 2017-05-23 15:40 +0200

csiph-web