> On Fri, Aug 13, 1999 at 03:00:10PM +1000, Paul Mackerras wrote:
>
> > In your opinion, should there be a guarantee that accesses initiated
> > by readl/writel/etc. will not be reordered?
> >
> > Alternatively, should device driver writers be required to put in an
> > explicit statement (mb() or something similar) when they use
> > readl/writel/etc. and want to prevent the accesses being reordered?
Yes. Forcing ordering when it is not needed just break optimizations
that are generally the purpose of the reordering of operations.
But, device drivers must have some handle on flushing and know about
ordering rules in order to ensure some consistent view of data when a part
accesses data written by the other part (CPU accessing data written by the
the device or device accessing data written by the CPU).
In order to make things right, the driver writers/maintainers must be
carefull about the order of operations each time this is required.
For that to be achieved, all the parts that may buffer data, and so
reorder operations, must be considered. The C compiler, the CPU, the host
bridge, inter-bus bridges and the PCI device are the parts I am talking
about.
So, trying to hide how these parts _actually_ behave with regards to
ordering of operations seems a high stupidity to me.
Could it be that we have so much resources in modern hardware that we are
just trying to find a way to waste them ? ;-)
> MIPS R3000 requires explicit flushing of write buffers anyway, so making
> that explicit and not hidden inside write[bwl]() would be handy.
The write[bwl] stuff does not address the entire ordering issue that a
device driver has to be careful about. Everything that occurs from one
part and that is to be seen by another part is to be considered.
If you want device drivers to safely support devices and not break
hardware optimizations we must allow drivers to deal with ordering.
On the other hand, I _do_ think that dealing with ordering in the back of
device drivers just does not work at all.
Gérard.
-
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/