[linux-fbdev] Re: [DRIVER UPDATE] aty128fb - PPC

[Brad Douglas]

> -----Original Message-----
> From: Benjamin Herrenschmidt [mailto:bh40 en calva.net]
> 
> >Second, you are not adding any io barrier to the 32 bit store macro
> >(aty_st_le32()) but you do for the 8 bit version, why?
> 
> Hum. It should be there. Did I miss this when you asked my about your
> patch, Brad ? I Need some more sleep ...

It's there.

> >You also add the io barriers before the operation you are about to
> >perform instead of after. That means that if you are storing a value
> >to register, you have no idea when it is actually being 
> propagated out
> >to the hardware. The safer way to do this would be to put a wmb()
> >after each register write and an rmb() after each register read(),
> >instead of before
> 
> I don't completely agree. Putting them before or after is a matter of
> style. The rare cases where this actually matters must usually be
> hand-tuned. (For example, filling some HW cursor datas in the
> framebuffer, so without using eieio, and then writing a register that
> will cause the chip to use those datas. One eieio is needed before the
> write in this case. I tend personally to prefer having them before.

Do we know this for sure?  I'm basing my code on what I've seen other people
do.  I don't have a PPC to test on (yet).

> >Note that standard {read,write}[bwl]() are guaranteeing ordering
> >themselves so when using those you should not need to add eieio()
> >manually. (note this was not the case on the Alpha until some time
> >during 2.3.x).
> 
> Right.

Hmm.  I'm not at an optimization state right yet.  Maybe I should just stick
with read/write and ditch eieio()?

Thanks,

Brad Douglas
brad en neruo.com

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