On Thu, Jan 5, 2017 at 12:25 PM, Will Deacon <will.deacon@xxxxxxx> wrote: >> That's still got to be a per-master property, not a SMMU property, I >> think. To illustrate: >> >> [A] [B] [C] >> | |_____| >> __|______________|___ >> | TBU | | TBU | >> |_____| SMMU |_____| >> |__|______________|__| >> | | >> >> Say A and B are instances of some device happy to be stalled, and C is a >> PCIe RC, and each is attached to their own context bank - enabling >> stalls for A is definitely fine. However even though B and C are using >> different context banks, enabling stalls for B might deadlock C if it >> results in more total outstanding transactions than the TBU's slave port >> supports. Therefore A can happily claim to be stall-safe, but B cannot >> due to its integration with respect to C. > > So in this case, don't say that B and C can DMA to unpinned memory. You > need the third property. This property (property 2) is concerned with the > SMMU itself because, e.g. the way the walker has been integrated can > cause a deadlock. fwiw, I guess I'm mostly thinking about case (A).. but I guess in the (B) case amend my suggestion about adding param to iommu_set_fault_handler() slightly to consider the enable_stall param passed in when both (B) and (C) register their fault handlers? Or I guess the idea about increasing extra cell (which IIUC would let us add an extra param in dt in the devices iommus property) could also work. Unless maybe there could be some cases where whether a device can do stalling is also a function of the driver as well (ie. some feature needs to be implemented type thing).. BR, -R -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
