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

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/

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: Fwd: Re: still no accelerated X ($#!$*)

[Kevin Hendricks]

Hi,

> I actually doubt that the eieio are necessary but then I'm not a
> specialist on this kind of hardware. Every eieio is a bus broadcast
> operation (except on 603, on G3 it is IIRC an option controlled by a bit
> in HID0) and actually has a cost comparable to a write posted I/O access
> but the other consequences (preventing bursts on the I/O bus) may actually
> cause a significant performance hit.  So it should be used only when
> necessary...
>
> > Please let me know how to change the above so that I get it right this time.
>
> Try to determine first whether the eieio are necessary; for access to the
> frame buffer I'm almost sure that they are superfluous and potentially
> very costly in terms of performance. For the MMIO I suspect that they may
> be necessary at some places, but adding them systematically will have less
> impact.

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 think I will go with the output constraint version given above without the
eieio until or unless the kernel driver begins to use them too.

Thanks for all of your help with this everyone.  I have learned alot.

Kevin

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

Re: Fwd: Re: still no accelerated X ($#!$*)

[Benjamin Herrenschmidt]

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.


** 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/