> Which says to me that grumbling about strongly ordered regions > is more of a developer discipline/training problem than any > kind of real technical issue. Not unlike how to do locking > right; or satisfy coding style guidelines; or follow correct > procedures to merge patches; or synchronize between several > execution contexts; or ... lots of other things that waste > time when folk don't bother doing them right at first.
Problem is of course much of the code base we written with out this in mind.
I've not checked for a long time but I seem to recall shutting off posting was
a common thing for devices. It is also something old-featured BIOS used to
give as options. This was a way for working around hardware and software
issues.
Mind you, this change does not disable posting to the device in the way I
interpret what a PC used to do (I could be wrong). It just disables the ARM's
initiator's ability to post into the interconnect (it may still post into a
device). DMA engines and others still can generated posted accesses on
interconnect and device.
Much of the ARM-Linux main line and certainly the OMAP code have not been
exposed to the issues. Before MPCORE bug fixes all generic ARM used SO here.
And, only ARMv6 and above has this ability to generate this behavior. ARMv5
and before behavior is SO. And, until recently most interconnects used with
ARM SOCs were slower and dumber about these things.
ARM-SO accesses are somewhat close to self-synchronizing. Provides a way to get
more intuitive behavior for control accesses. This is not true for DEVICE on
OMAP. When you do a series of writes to an IO range with DEVICE. Do you mind
they will post up? Also, it is possible the writes will be merged. The effect
is registers a, a+1, a+2, a+3 all get written in a burst on OMAP3 at some time
latter. The ARM may move right along given AXI2OCP mapping. Given the way the
IPs have been exercised for so long, its seems there may be a good number of
subtle issues about.
Even with SO, you still may need some readbacks. This happens for a couple of
reasons:
- omap device itself has explicit device side posting (like timer)
- omap device needs to re-synchronize to slower functional clock
- write-irq clear, but it requires some number of clocks to
de-assert irq line. Once the message gets to the ip it will ack. Its not
going to wait to all effects are done.
** Both the above are in addition to Interconnect posting.
SO for OMAP has an effect on the interconnect and the ARM pipeline. It has
less effect on end peripheral.
I'll attach the rough patch we added to one tree. It gives an OPTION to
disable posting. If I'm shipping tomorrow I want such an option.
Regards,
Richard W.
bus_posting.diff
Description: bus_posting.diff
