On 29 May 2015 at 02:58, Matthijs van Duin <matthijsvanduin@xxxxxxxxx> wrote: > 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). OK, all this was actually assuming linux uses device-type mappings for device mappings, which was also the impression I got from build_mem_type_table() in arch/arm/mm/mmu.c (although it's a bit of a maze). A quick test however seems to imply otherwise: ~# ./bogus-dev-write Bus error So... linux actually uses strongly-ordered mappings? I really didn't expect that, given the performance implications (especially on a strictly in-order cpu like the Cortex-A8 which will really just sit there picking its nose until the write completes) and I think I recall having seen an OCP barrier being used somewhere in driver code... Well, in that case everything I said is technically still true, except the posting point is the peripheral itself. That also means the interconnect error reporting mechanism is not really useful for probing since you'll get a bus error before any error irq is delivered. So I'd say you're back at having to trap that bus error using the exception handling mechanism, which I still suspect shouldn't be hard to do. Or perhaps you could probe the device using a DMA access and combine that with the interconnect error reporting irq... ;-) -- 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
