On Tue, 21 Aug 2018, Arnd Bergmann wrote:
> On Mon, Aug 20, 2018 at 11:42 PM Mikulas Patocka wrote:
> > On Mon, 20 Aug 2018, Arnd Bergmann wrote:
> >
> > > On Mon, Aug 20, 2018 at 4:17 PM Mikulas Patocka
> > > wrote:
> > > > On Sun, 19 Aug 2018, ok...@codeaurora.org wrote:
> > > >
> > > > >
On 8/22/2018 3:56 PM, Mikulas Patocka wrote:
On Wed, 22 Aug 2018, Sinan Kaya wrote:
On 8/22/2018 1:47 PM, Mikulas Patocka wrote:
If ARM guarantees that the accesses to a given device are not reordered -
then the barriers in readl and writel are superfluous.
It is not. ARM only guarantees
On Wed, Aug 22, 2018 at 03:56:28PM -0400, Mikulas Patocka wrote:
>
>
> On Wed, 22 Aug 2018, Sinan Kaya wrote:
>
> > On 8/22/2018 1:47 PM, Mikulas Patocka wrote:
> > > If ARM guarantees that the accesses to a given device are not reordered -
> > > then the barriers in readl and writel are
On Wed, 22 Aug 2018, Sinan Kaya wrote:
> On 8/22/2018 1:47 PM, Mikulas Patocka wrote:
> > If ARM guarantees that the accesses to a given device are not reordered -
> > then the barriers in readl and writel are superfluous.
>
> It is not. ARM only guarantees ordering of read/write transactions
On 8/22/2018 1:47 PM, Mikulas Patocka wrote:
If ARM guarantees that the accesses to a given device are not reordered -
then the barriers in readl and writel are superfluous.
It is not. ARM only guarantees ordering of read/write transactions targeting
a device not memory.
example:
write
On Wed, 22 Aug 2018, Arnd Bergmann wrote:
> On Wed, Aug 22, 2018 at 5:50 PM Mikulas Patocka wrote:
> > On Wed, 22 Aug 2018, Maciej W. Rozycki wrote:
> > > On Wed, 22 Aug 2018, Sinan Kaya wrote:
> >
> > According to the Alpha handbook, non-overlapping accesses may be
> > reordered.
> >
> > So
On Wed, 22 Aug 2018, Arnd Bergmann wrote:
> > According to the Alpha handbook, non-overlapping accesses may be
> > reordered.
I have had a notion of this since forever, however I have had troubles
tracking down the exact reference in the architecture specification.
> > So if someone does
> >
On Wed, Aug 22, 2018 at 5:50 PM Mikulas Patocka wrote:
> On Wed, 22 Aug 2018, Maciej W. Rozycki wrote:
> > On Wed, 22 Aug 2018, Sinan Kaya wrote:
>
> According to the Alpha handbook, non-overlapping accesses may be
> reordered.
>
> So if someone does
> writel(REG1);
> readl(REG2);
>
> readl may
On Wed, 22 Aug 2018, Maciej W. Rozycki wrote:
> On Wed, 22 Aug 2018, Sinan Kaya wrote:
>
> > > It's hard to tell. The Alpha manual says that only overlapping accesses
> > > are ordered.
> > >
> > > I did some tests on framebuffer and found out that "read+read+write+write"
> > > is faster
On Wed, 22 Aug 2018, Sinan Kaya wrote:
> > It's hard to tell. The Alpha manual says that only overlapping accesses
> > are ordered.
> >
> > I did some tests on framebuffer and found out that "read+read+write+write"
> > is faster than "read+write+read+write" - that may suggest that the reads
> >
On 8/22/2018 7:59 AM, Mikulas Patocka wrote:
I did some tests on framebuffer and found out that "read+read+write+write"
is faster than "read+write+read+write" - that may suggest that the reads
flush the write queue.
I think we are worried about correctness at this moment like a raw_read
On Wed, 22 Aug 2018, Sinan Kaya wrote:
> On 8/22/2018 7:59 AM, Mikulas Patocka wrote:
> >
> >
> > On Tue, 21 Aug 2018, Arnd Bergmann wrote:
> >
> > > On Tue, Aug 21, 2018 at 3:40 PM Mikulas Patocka
> > > wrote:
> > > > On Tue, 21 Aug 2018, Arnd Bergmann wrote:
> > > > > On Mon, Aug 20,
On Tue, 21 Aug 2018, Arnd Bergmann wrote:
> On Tue, Aug 21, 2018 at 3:40 PM Mikulas Patocka wrote:
> > On Tue, 21 Aug 2018, Arnd Bergmann wrote:
> > > On Mon, Aug 20, 2018 at 11:42 PM Mikulas Patocka
> > > wrote:
> > > > On Mon, 20 Aug 2018, Arnd Bergmann wrote:
> > > > > On Mon, Aug 20,
On Tue, Aug 21, 2018 at 3:40 PM Mikulas Patocka wrote:
> On Tue, 21 Aug 2018, Arnd Bergmann wrote:
> > On Mon, Aug 20, 2018 at 11:42 PM Mikulas Patocka
> > wrote:
> > > On Mon, 20 Aug 2018, Arnd Bergmann wrote:
> > > > On Mon, Aug 20, 2018 at 4:17 PM Mikulas Patocka
> > > > wrote:
> > > > >
On Tue, 21 Aug 2018, Arnd Bergmann wrote:
> On Mon, Aug 20, 2018 at 11:42 PM Mikulas Patocka wrote:
> > On Mon, 20 Aug 2018, Arnd Bergmann wrote:
> >
> > > On Mon, Aug 20, 2018 at 4:17 PM Mikulas Patocka
> > > wrote:
> > > > On Sun, 19 Aug 2018, ok...@codeaurora.org wrote:
> > > >
> > > > >
On 2018-08-21 05:12, Maciej W. Rozycki wrote:
On Mon, 20 Aug 2018, Sinan Kaya wrote:
> Likewise see memory-barriers.txt throughout concerning `mmiowb' (which is
> an obviously lighter weight barrier compared to `readX').
Here is a better reference from memory-barriers.txt
(*) readX(),
On Mon, 20 Aug 2018, Sinan Kaya wrote:
> > Likewise see memory-barriers.txt throughout concerning `mmiowb' (which is
> > an obviously lighter weight barrier compared to `readX').
>
> Here is a better reference from memory-barriers.txt
>
> (*) readX(), writeX():
>
> Whether these are
On Mon, 20 Aug 2018, Sinan Kaya wrote:
> > That is that the caller must not
> > assume that writes issued by `writeX' calls will be observed in order on
> > the external bus or specifically by the device addressed.
>
> Where do you see it?
Right in the first paragraph of io_ordering.txt, and
On Tue, 21 Aug 2018, Arnd Bergmann wrote:
> > The lockup happens somewhere in the function autoconfig in
> > drivers/tty/serial/8250/8250_port.c, but I don't know where exactly
> > because serial console doesn't work while the port is being probed.
> >
> > When I use console on a graphics card,
On 8/20/2018 6:39 PM, Maciej W. Rozycki wrote:
On Mon, 20 Aug 2018, Sinan Kaya wrote:
That is that the caller must not
assume that writes issued by `writeX' calls will be observed in order on
the external bus or specifically by the device addressed.
Where do you see it?
Right in the
On Mon, 20 Aug 2018, Mikulas Patocka wrote:
> > > I observed that not every kernel with the patch
> > > 92d7223a74235054f2aa7227d207d9c57f84dca0 fails, some of them get stuck
> > > only at boot, some get stuck only at shutdown, some not at all. Although
> > > all the kernels with this patch
On 8/20/2018 5:50 PM, Maciej W. Rozycki wrote:
That is that the caller must not
assume that writes issued by `writeX' calls will be observed in order on
the external bus or specifically by the device addressed.
Where do you see it?
I interpret that two writeX() need to be observed in order
On Mon, Aug 20, 2018 at 11:42 PM Mikulas Patocka wrote:
> On Mon, 20 Aug 2018, Arnd Bergmann wrote:
>
> > On Mon, Aug 20, 2018 at 4:17 PM Mikulas Patocka wrote:
> > > On Sun, 19 Aug 2018, ok...@codeaurora.org wrote:
> > >
> > > > +my new email
> > > >
> > > > On 2018-08-18 19:03, Arnd Bergmann
On Mon, 20 Aug 2018, Mikulas Patocka wrote:
> > A while ago I proposed a set of different MMIO barriers, that some
> > systems may require, corresponding to the respective regular memory
> > barriers, but in the I/O context. I never got to implementing that
> > proposal, but I still think
On Sun, 19 Aug 2018, ok...@codeaurora.org wrote:
> >> 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 riscv.
> >>
> >> It does make some sense that alpha might need a barrier between
> >> an
On 2018-08-20 10:39, Arnd Bergmann wrote:
On Mon, Aug 20, 2018 at 4:17 PM Mikulas Patocka
wrote:
On Sun, 19 Aug 2018, ok...@codeaurora.org wrote:
> +my new email
>
> On 2018-08-18 19:03, Arnd Bergmann wrote:
> > On Sat, Aug 18, 2018 at 12:05 AM Maciej W. Rozycki
> I think we need to
On Mon, Aug 20, 2018 at 4:17 PM Mikulas Patocka wrote:
> On Sun, 19 Aug 2018, ok...@codeaurora.org wrote:
>
> > +my new email
> >
> > On 2018-08-18 19:03, Arnd Bergmann wrote:
> > > On Sat, Aug 18, 2018 at 12:05 AM Maciej W. Rozycki
> > I think we need to identify the driver that is failing.
>
On Sun, 19 Aug 2018, ok...@codeaurora.org wrote:
> +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
On Fri, 17 Aug 2018, 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 expect the store to have
> > arrived at the device by the time
On Fri, 17 Aug 2018, Arnd Bergmann wrote:
> On Fri, Aug 17, 2018 at 9:10 PM Mikulas Patocka wrote:
> >
> > Hi
> >
> > The commit 9ce8654323d69273b4977f76f11c9e2d345ab130 breaks the Alpha
> > Avanti platform. There is temporary 40-second hang during boot when
> > detecting serial ports
On Mon, Aug 20, 2018 at 06:22:26AM -0400, Mikulas Patocka wrote:
> Alpha already has a memory barrier inside arch_spin_unlock.
>
>
> BTW. I think that arch_spinlock_t (and atomic_t) on alpha should be
> 8-byte. See this case - writing the variable "x" performs
> read-modify-write cycle on the
On Sun, 19 Aug 2018, Arnd Bergmann wrote:
> 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
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
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 expect the store to have
> > arrived at the device by
On Fri, Aug 17, 2018 at 9:10 PM Mikulas Patocka wrote:
>
> Hi
>
> The commit 9ce8654323d69273b4977f76f11c9e2d345ab130 breaks the Alpha
> Avanti platform. There is temporary 40-second hang during boot when
> detecting serial ports (although the hang eventually resolves and the
> machine boots) and
40 matches
Mail list logo
