On 29 May 2015 at 00:24, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > Hmm I believe the interrupt happens immediately trying to access an > invalid device. But maybe I'm thinking about just errors if a device > is not powered or clocked. It is only guaranteed to happen immediately (before the next instruction is executed) if the error occurs before the posting-point of the write. However, in that case the error is reported in-band to the cpu, resulting in a (synchronous) bus error which takes precedence over the out-of-band error irq (if any is signalled). Once the write is posted however, the cpu will receive an ack on the write and continue execution, and there's no reason to assume that an error irq will happen *immediately* after the write. Of course it typically will happen soon afterwards, possibly even before the next instruction is executed, depending a bit on how soon after the posting-point the error occurs versus how long it takes for the write-ack to reach the cpu. On the other hand, it's also possible the write, after becoming posted, gets stuck for a while due to a burst of higher-priority traffic. (I also recall reading about some situation where a request needs to wait for something to be dynamically powered up before an error response could be generated, but I think that was on the OMAP 4.) So that's the icky part: it will very likely happen almost immediately. There's however no *guarantee* that it will, and in fact it's quite tricky to absolutely make sure a write is no longer in transit. The usual solution is an "OCP barrier": a read that is known to follow the same path as the write. Normally that means a read from the same peripheral, but that would defeat the purpose in this case. Fortunately, the L4 interconnects (unlike the L3) detect firewall violations in the initiator agent rather than the target agents, hence a read from any peripheral on the same L4 interconnect suffices. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
