Re: [linux-fbdev] Re: Fwd: Re: still no accelerated X ($#!$*)

Re: [linux-fbdev] Re: Fwd: Re: still no accelerated X ($#!$*)

[Brad Douglas]

-----Original Message-----
From: Benjamin Herrenschmidt <bh40@calva.net>

>
>>Okay, I went and looked at the latest aty128fb.c code and it does not use
>>eieio
>>anywhere.  I looked at ealier verions of this file and it at one time had
>>eieio
>>but they have since been removed.
>>
>>I also looked and the endian conversion routines do not use the output
>>contraint approach you took but do include the memory clobber on the
writes.
>
>I just looked at atyfb.c and aty128fb.c in my source tree (atyfb is
>2.2.14 one and aty128fb is the latest backport done by atong) and neither
>uses eieio nor mb(), wmb(), ...
>
>This looks bogus to me. I've spotted a few cases where those calls should
>be in.
>
>We can either put the eieio back in the access functions (less optimal,
>but we can also fix the constraints to get rid of the memory clobber as
>discussed previously), or we can fill the code with carefuly placed mb()
>and wmb() but this requires more knowledge of the chipset than I actually
>have.
>
>I'll put back eieio() in the access macros for my kernels until a
>definitive answer pops up on this issue.


I'm forwarding this to Anthony...

Thanks,

Brad Douglas
brad@neruo.com


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [linux-fbdev] Re: Fwd: Re: still no accelerated X ($#!$*)

[anthony tong]

Benjamin Herrenschmidt (Fri, Jan 21, 2000 at 03:15:11PM +0100):
> On Thu, Jan 20, 2000, Kevin Hendricks <khendricks@ivey.uwo.ca> wrote:
> >Okay, I went and looked at the latest aty128fb.c code and it does not use
> >eieio
> >anywhere.  I looked at ealier verions of this file and it at one time had
> >eieio
> >but they have since been removed.
> >
> >I also looked and the endian conversion routines do not use the output
> >contraint approach you took but do include the memory clobber on the writes.
>
> I just looked at atyfb.c and aty128fb.c in my source tree (atyfb is
> 2.2.14 one and aty128fb is the latest backport done by atong) and neither
> uses eieio nor mb(), wmb(), ...
>
> This looks bogus to me. I've spotted a few cases where those calls should
> be in.
>
> We can either put the eieio back in the access functions (less optimal,
> but we can also fix the constraints to get rid of the memory clobber as
> discussed previously), or we can fill the code with carefuly placed mb()
> and wmb() but this requires more knowledge of the chipset than I actually
> have.
>
> I'll put back eieio() in the access macros for my kernels until a
> definitive answer pops up on this issue.

I must have missed when these were taken out; does anyone know the reason
why it was done?


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [linux-fbdev] Re: Fwd: Re: still no accelerated X ($#!$*)

[Kevin Hendricks]

Hi Anthony,

> > I'll put back eieio() in the access macros for my kernels until a
> > definitive answer pops up on this issue.
>
> I must have missed when these were taken out; does anyone know the reason
> why it was done?

When the eieio's in aty128fb.c have been added back in to the version that was
backported to 2.2.14 please cc a copy of the file you send to Ben to me also.
I am still having trouble debugging some final nits in the xf 3.9.17 r128
module and would love to have a "fixed" driver.

Thanks,

Kevin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [linux-fbdev] Re: Fwd: Re: still no accelerated X ($#!$*)

[Geert Uytterhoeven]

On Wed, 26 Jan 2000, James A Simmons wrote:
>   I have seen alot of talk about wmb() and eieio(). Where can I find docs
> on these functions and how to program driver correctly using them? Thank
> you.

Very simple, cfr. include/asm-ppc/system.h:

/*
 * Memory barrier.
 * The sync instruction guarantees that all memory accesses initiated
 * by this processor have been performed (with respect to all other
 * mechanisms that access memory).  The eieio instruction is a barrier
 * providing an ordering (separately) for (a) cacheable stores and (b)
 * loads and stores to non-cacheable memory (e.g. I/O devices).
 *
 * mb() prevents loads and stores being reordered across this point.
 * rmb() prevents loads being reordered across this point.
 * wmb() prevents stores being reordered across this point.
 *
 * We can use the eieio instruction for wmb, but since it doesn't
 * give any ordering guarantees about loads, we have to use the
 * stronger but slower sync instruction for mb and rmb.
 */
#define mb()  __asm__ __volatile__ ("sync" : : : "memory")
#define rmb()  __asm__ __volatile__ ("sync" : : : "memory")
#define wmb()  __asm__ __volatile__ ("eieio" : : : "memory")

The *mb() macro's are portable across the different architectures supported by
Linux. Yes, *mb are Alpha mnemonics :-)

Gr{oetje,eeting}s,
--
Geert Uytterhoeven -- Linux/{m68k~Amiga,PPC~CHRP} -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [linux-fbdev] Re: Fwd: Re: still no accelerated X ($#!$*)

[Benjamin Herrenschmidt]

On Wed, Jan 26, 2000, Geert Uytterhoeven <geert@linux-m68k.org> wrote:

>Very simple, cfr. include/asm-ppc/system.h:
>
>/*
> * Memory barrier.
> * The sync instruction guarantees that all memory accesses initiated
> * by this processor have been performed (with respect to all other
> * mechanisms that access memory).  The eieio instruction is a barrier
> * providing an ordering (separately) for (a) cacheable stores and (b)
> * loads and stores to non-cacheable memory (e.g. I/O devices).
> *
> * mb() prevents loads and stores being reordered across this point.
> * rmb() prevents loads being reordered across this point.
> * wmb() prevents stores being reordered across this point.
> *
> * We can use the eieio instruction for wmb, but since it doesn't
> * give any ordering guarantees about loads, we have to use the
> * stronger but slower sync instruction for mb and rmb.
> */
>#define mb()  __asm__ __volatile__ ("sync" : : : "memory")
>#define rmb()  __asm__ __volatile__ ("sync" : : : "memory")
>#define wmb()  __asm__ __volatile__ ("eieio" : : : "memory")
>
>The *mb() macro's are portable across the different architectures
supported by
>Linux. Yes, *mb are Alpha mnemonics :-)

The semantics used here are a bit strange. Definitely sync is evil and
should be avoided except in rare few cases. It's not a memory barrier,
it's a lot more since it ensure synchronisation on the bus, inter-cpu
synchro, and interrupt synchro. It eats a lot of cycles on SMP configs
and with recent G3/G4 CPUs.

eieio is used for wmb, but it actually works for both reads and writes
provided that you actually want a _memory access_ barrier and not an
interrupt barrier or other means of syncing CPUs on the bus.

Note that include/asm/io.h contains iobarrer macros which are better
suited for io operations.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/