> 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.
Attachment:
bus_posting.diff
Description: bus_posting.diff
