On 28 May 2015 at 18:01, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > For failed device access you get an interrupt Well for failed reads you get a bus error, and "catching" those (e.g. using the existing exception mechanism used to catch MMU faults) is the whole issue. Though now that you mention it, it is true that for writes you won't get any fault (at least on the DM814x and AM335x the posting point appears to be the async bridge from MPUSS to the L3 interconnect) but an interconnect error irq instead. It may be easier to make some kind of harmless write (e.g. to the version register), wait a bit, and check if the write triggered an interconnect error. Feels hackish though: you'd need to be sure you waited long enough (though using a read from another device on the same L4 interconnect should be a reliable barrier in this case), and drivers for receiving/interpreting interconnect errors are not implemented yet on all SoCs (for some, like the AM335x, TI didn't even bother publishing the relevant data in its TRM). Interconnect errors can also be lost in some cases (multiple errors involving the same target in a short time window) though that problem shouldn't arise in this particular case. Also, presumably interconnect error reporting is unavailable on HS devices given the fact that all interconnect registers seemed to be inaccessible? Matthijs -- 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
