On Thu, Feb 21, 2019 at 05:22:03PM +1100, Michael Ellerman wrote:
> Will Deacon writes:
> > [+more ppc folks]
> >
> > On Mon, Feb 18, 2019 at 04:50:12PM +, Will Deacon wrote:
> >> On Wed, Feb 13, 2019 at 10:27:09AM -0800, Linus Torvalds wrote:
> >> > Note that even if mmiowb() is expensive (an
Will Deacon writes:
> [+more ppc folks]
>
> On Mon, Feb 18, 2019 at 04:50:12PM +, Will Deacon wrote:
>> On Wed, Feb 13, 2019 at 10:27:09AM -0800, Linus Torvalds wrote:
>> > Note that even if mmiowb() is expensive (and I don't think that's
>> > actually even the case on ia64), you can - and pro
[+more ppc folks]
On Mon, Feb 18, 2019 at 04:50:12PM +, Will Deacon wrote:
> On Wed, Feb 13, 2019 at 10:27:09AM -0800, Linus Torvalds wrote:
> > Note that even if mmiowb() is expensive (and I don't think that's
> > actually even the case on ia64), you can - and probably should - do
> > what Po
On Tue, Feb 19, 2019 at 2:20 PM Will Deacon wrote:
> On Tue, Feb 19, 2019 at 02:01:50PM +0100, Arnd Bergmann wrote:
> > On Tue, Feb 19, 2019 at 12:36 PM Will Deacon wrote:
> > > On Tue, Feb 19, 2019 at 12:31:50PM +0100, Arnd Bergmann wrote:
> > > > On Tue, Feb 19, 2019 at 11:27 AM Thomas Petazzon
On Tue, Feb 19, 2019 at 02:01:50PM +0100, Arnd Bergmann wrote:
> On Tue, Feb 19, 2019 at 12:36 PM Will Deacon wrote:
> > On Tue, Feb 19, 2019 at 12:31:50PM +0100, Arnd Bergmann wrote:
> > > On Tue, Feb 19, 2019 at 11:27 AM Thomas Petazzoni
> > > wrote:
> > >
> > > I think an example of this would
On Tue, Feb 19, 2019 at 12:36 PM Will Deacon wrote:
> On Tue, Feb 19, 2019 at 12:31:50PM +0100, Arnd Bergmann wrote:
> > On Tue, Feb 19, 2019 at 11:27 AM Thomas Petazzoni
> > wrote:
> >
> > I think an example of this would be a driver using outb() to disable
> > an interrupt, and then relying on
On Tue, Feb 19, 2019 at 12:31:50PM +0100, Arnd Bergmann wrote:
> On Tue, Feb 19, 2019 at 11:27 AM Thomas Petazzoni
> wrote:
> > On Mon, 18 Feb 2019 21:37:25 +0100
> > Arnd Bergmann wrote:
> >
> > > Ah, it seems we actually do that on 32-bit ARM, at least on one platform,
> > > see 6a02734d420f ("
Hi Thomas,
On Tue, Feb 19, 2019 at 11:27:47AM +0100, Thomas Petazzoni wrote:
> On Mon, 18 Feb 2019 21:37:25 +0100
> Arnd Bergmann wrote:
>
> > > > I would say we should strengthen the behavior of outX() where possible.
> > > > I don't know if arm64 actually has a way of doing that, my understand
On Tue, Feb 19, 2019 at 11:27 AM Thomas Petazzoni
wrote:
> On Mon, 18 Feb 2019 21:37:25 +0100
> Arnd Bergmann wrote:
>
> > Ah, it seems we actually do that on 32-bit ARM, at least on one platform,
> > see 6a02734d420f ("ARM: mvebu: map PCI I/O regions strongly ordered")
> > and prior commits.
>
>
Hello,
On Mon, 18 Feb 2019 21:37:25 +0100
Arnd Bergmann wrote:
> > > I would say we should strengthen the behavior of outX() where possible.
> > > I don't know if arm64 actually has a way of doing that, my understanding
> > > earlier was that the AXI bus was already posted, so there is not much
On Mon, Feb 18, 2019 at 6:56 PM Will Deacon wrote:
>
> On Mon, Feb 18, 2019 at 05:59:13PM +0100, Arnd Bergmann wrote:
> > On Mon, Feb 18, 2019 at 5:30 PM Will Deacon wrote:
> > >
> > > >
> > > > ioremap_wc() in turn is used almost exclusively to map RAM behind
> > > > a bus, (typically for frame
On Mon, Feb 18, 2019 at 05:59:13PM +0100, Arnd Bergmann wrote:
> On Mon, Feb 18, 2019 at 5:30 PM Will Deacon wrote:
> >
> > On Tue, Feb 12, 2019 at 02:03:04PM +0100, Arnd Bergmann wrote:
> > > On Mon, Feb 11, 2019 at 6:29 PM Will Deacon wrote:
> > >
> > > > + __iomem pointers obtained with no
On Mon, Feb 18, 2019 at 5:30 PM Will Deacon wrote:
>
> On Tue, Feb 12, 2019 at 02:03:04PM +0100, Arnd Bergmann wrote:
> > On Mon, Feb 11, 2019 at 6:29 PM Will Deacon wrote:
> >
> > > + __iomem pointers obtained with non-default attributes (e.g. those
> > > returned
> > > + by ioremap_wc(
On Wed, Feb 13, 2019 at 10:27:09AM -0800, Linus Torvalds wrote:
> On Wed, Feb 13, 2019 at 9:20 AM Will Deacon wrote:
> > On Mon, Feb 11, 2019 at 02:34:31PM -0800, Linus Torvalds wrote:
> > > IOW, we should seriously just consider making the rule be that locking
> > > will order mmio too. Because t
Hi Arnd,
On Tue, Feb 12, 2019 at 02:03:04PM +0100, Arnd Bergmann wrote:
> On Mon, Feb 11, 2019 at 6:29 PM Will Deacon wrote:
>
> > + __iomem pointers obtained with non-default attributes (e.g. those
> > returned
> > + by ioremap_wc()) are unlikely to provide many of these guarantees. If
On Wed, Feb 13, 2019 at 06:43:41PM +, Luck, Tony wrote:
> > I think the last time this came up, it was said that those people still
> > running Linux on Itanium were running old distro kernels, not upstream.
> >
> > So yeah, we could probably do whatever and nobody would ever notice,
> > except
> I think the last time this came up, it was said that those people still
> running Linux on Itanium were running old distro kernels, not upstream.
>
> So yeah, we could probably do whatever and nobody would ever notice,
> except maybe Al, who is rumoured to still have an ia64 :-)
I haven't heard
On Wed, Feb 13, 2019 at 10:27:09AM -0800, Linus Torvalds wrote:
> Yeah, yeah, there's the SGI "SN" platform that apparently has a bug,
> so because of that platform problem maybe it needs the more complex
> "use a flag" model. But even the complex model isn't _hugely_
> complex.
>
> But we *could
On Wed, Feb 13, 2019 at 9:20 AM Will Deacon wrote:
>
> On Mon, Feb 11, 2019 at 02:34:31PM -0800, Linus Torvalds wrote:
> >
> > IOW, we should seriously just consider making the rule be that locking
> > will order mmio too. Because that's practically the rule anyway.
>
> I would /love/ to get rid o
[+Tony]
On Mon, Feb 11, 2019 at 02:34:31PM -0800, Linus Torvalds wrote:
> On Mon, Feb 11, 2019 at 9:30 AM Will Deacon wrote:
> >
> > +
> > + 1. All readX() and writeX() accesses to the same peripheral are
> > ordered
> > +with respect to each other. For example, this ensures that MMI
On Tue, Feb 12, 2019 at 06:43:54PM +, Will Deacon wrote:
> On Mon, Feb 11, 2019 at 12:22:18PM -0800, Paul E. McKenney wrote:
> > On Mon, Feb 11, 2019 at 05:29:48PM +, Will Deacon wrote:
> > > The "KERNEL I/O BARRIER EFFECTS" section of memory-barriers.txt is vague,
> > > x86-centric, out-of
On Mon, Feb 11, 2019 at 12:22:18PM -0800, Paul E. McKenney wrote:
> On Mon, Feb 11, 2019 at 05:29:48PM +, Will Deacon wrote:
> > The "KERNEL I/O BARRIER EFFECTS" section of memory-barriers.txt is vague,
> > x86-centric, out-of-date, incomplete and demonstrably incorrect in places.
> > This is l
On Mon, Feb 11, 2019 at 6:29 PM Will Deacon wrote:
> + __iomem pointers obtained with non-default attributes (e.g. those
> returned
> + by ioremap_wc()) are unlikely to provide many of these guarantees. If
> + ordering is required for such mappings, then the mandatory barriers
> sho
On Mon, 2019-02-11 at 14:34 -0800, Linus Torvalds wrote:
> On Mon, Feb 11, 2019 at 9:30 AM Will Deacon wrote:
> > +
> > + 1. All readX() and writeX() accesses to the same peripheral are
> > ordered
> > +with respect to each other. For example, this ensures that MMIO
> > register
> >
On Mon, Feb 11, 2019 at 9:30 AM Will Deacon wrote:
>
> +
> + 1. All readX() and writeX() accesses to the same peripheral are ordered
> +with respect to each other. For example, this ensures that MMIO
> register
> + writes by the CPU to a particular device will arrive in program
On Mon, Feb 11, 2019 at 05:29:48PM +, Will Deacon wrote:
> The "KERNEL I/O BARRIER EFFECTS" section of memory-barriers.txt is vague,
> x86-centric, out-of-date, incomplete and demonstrably incorrect in places.
> This is largely because I/O ordering is a horrible can of worms, but also
> because
26 matches
Mail list logo
