On Fri, Jul 01, 2016 at 12:19:51PM +0100, Robin Murphy wrote: > On 01/07/16 11:32, Marek Szyprowski wrote: > > Frankly, I would avoid moving this workaround to the iommu core. IMHO the > > best solution would be to let IOMMU controllers to be instantiated as > > normal > > devices and implement proper support in the device core for waiting for the > > iommu controller. Then the workaround can be removed from exynos and mtk > > iommu drivers. What's the status of IOMMU deferred probe patches? > > I think revisiting probe ordering is now second-from-top on my to-do > list after this lot. This patch was kind of thinking ahead to get the > "touch all the drivers" aspect out of the way before it grows any > bigger, and all the development can then happen in the core code alone, > but I admit it's not a particularly strong argument. > > > I've encountered a serious problems with current code (the one which > > instantiates iommu controller devices from iommu driver) and its > > integration > > with power domains, clocks and runtime pm, which were not possible to > > resolve > > without iommu deferred probe. > > OK. Do you have any plans to try tweaking the current workaround, or is > it really not worth it? FWIW I do have an Exynos 5410 (Odroid-XU) on my > desk which I could theoretically test things on, but I suspect it would > take a fair amount of work to get the SYSMMUs and relevant media bits up > and running on top of Krzysztof's basic support. > > Will: for the time being, the alternative to this patch would be to > squash the following change into patch 7/9 (without either, patch 8/9 > doesn't really work). It's ugly, but I'm fine with it for the moment. No need to wait for the probe deferral stuff before getting this in. Will -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
