Re: [linux-fbdev] Re: readl() and friends and eieio on PPC

[Jes Sorensen <Jes.Sorensen@cern.ch>]

>>>>> "Paul" == Paul Mackerras <paulus@cs.anu.edu.au> writes:

Paul> If you take out the eieios, you will break other drivers,
Paul> starting with the OHCI USB host driver.  Can we think of another
Paul> way around the problem?  You could use le32_to_cpup for loading
Paul> from the frame buffer, but there isn't currently an equivalent
Paul> for stores, unfortunately (one could be invented, though).

This is quite easily solved by putting in mb()'s in the right
places. This is how it is done for other drivers that are supposed to
work on the Alpha.

Paul> I thought the point of the aty_ld/st* routines was to avoid one
Paul> add instruction each time by using the PPC indexed addressing
Paul> mode.  Anyway, IMO the aty_ld/st* routines *should* include the
Paul> eieio.  That would mean you wouldn't need the explicit eieio()
Paul> calls scattered through the rest of the driver.  I guess it's
Paul> just luck that it works where you do a sequence of aty_st_le32's
Paul> to set up some drawing command and then call wait_for_fifo (or
Paul> wait_for_idle) which does an aty_ld_le32.  Or doesn't it matter
Paul> if the load gets done before all of the stores have completed?

Having mb()'s explicitly put into the driver in the right places also
makes sure that a driver will work on other architectures. Right now a
driver that is written for the PPC is likely not to work on the Alpha
if the author expects readl/writel to guarantee write ordering.

Jes

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]