[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <18492.37741.798622.696166@cargo.ozlabs.ibm.com>
Date: Wed, 28 May 2008 09:04:13 +1000
From: Paul Mackerras <paulus@...ba.org>
To: "Chris Friesen" <cfriesen@...tel.com>
Cc: Roland Dreier <rdreier@...co.com>, linux-arch@...r.kernel.org,
linux-kernel@...r.kernel.org, tpiepho@...escale.com,
James Bottomley <James.Bottomley@...senPartnership.com>,
linuxppc-dev@...abs.org, scottwood@...escale.com,
torvalds@...ux-foundation.org, David Miller <davem@...emloft.net>,
alan@...rguk.ukuu.org.uk, Arjan van de Ven <arjan@...radead.org>
Subject: Re: MMIO and gcc re-ordering issue
Chris Friesen writes:
> Roland Dreier wrote:
>
> > Writes are posted yes, but not reordered arbitrarily. If I have code like:
> >
> > spin_lock(&mmio_lock);
> > writel(val1, reg1);
> > writel(val2, reg2);
> > spin_unlock(&mmio_lock);
> >
> > then I have a reasonable expectation that if two CPUs run this at the
> > same time, their writes to reg1/reg2 won't be interleaved with each
> > other (because the whole section is inside a spinlock). And Altix
> > violates that expectation.
>
> Does that necessarily follow?
>
> If you've got a large system with multiple pci bridges, could you end up
> with posted writes coming from different cpus taking a different amount
> of time to propagate to a device and thus colliding?
On powerpc we explicitly make sure that can't happen. That's the "do
a sync in spin_unlock if there were any writels since the last
spin_lock" magic. The sync instruction makes sure the writes have got
to the host bridge before the spinlock is unlocked.
Paul.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists