Subject: Re: [PATCH] ppc64: Fix __raw_* IO accessors
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
       Petr Vandrovec <vandrove@vc.cvut.cz>
In-Reply-To: <1095761113.30931.13.camel@localhost.localdomain>
References: <1095758630.3332.133.camel@gaston>
	 <1095761113.30931.13.camel@localhost.localdomain>
Content-Type: text/plain
Message-Id: <1095766919.3577.138.camel@gaston>
Mime-Version: 1.0
Date: Tue, 21 Sep 2004 21:41:59 +1000
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1131
Lines: 27

On Tue, 2004-09-21 at 20:05, Alan Cox wrote:
> On Maw, 2004-09-21 at 10:23, Benjamin Herrenschmidt wrote:
> > Hi !
> > 
> > Linus, I don't know if you did that on purpose, but you removed the
> > "volatile" statement from the definition of the __raw_* IO accessors
> > on ppc64, which cause some real bad optisations to happen in some
> > fbdev's like matroxfb to happen (just imagine that matroxfb loops
> > reading an IO register waiting for a bit to change).
> 
> Why is it using __raw if it cares about ordering and not using barriers
> ? Way back when the original definition was that __raw didnt do
> barriers. Thats why I2O for example uses __raw_ so that messages can be
> generated as efficiently as possible.

It uses __raw for non-byteswap... The problem is that __raw does both
non-byteswap and non-barriers and there is no simple way to get one
and not the other...

Ben.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/