> -----Original Message-----
> From: Benjamin Herrenschmidt [mailto:bh40@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@neruo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:19 EST