From mboxrd@z Thu Jan 1 00:00:00 1970 From: m.szyprowski@samsung.com (Marek Szyprowski) Date: Fri, 01 Jul 2016 14:02:14 +0200 Subject: [PATCH v3 2/9] iommu/of: Consolidate device creation workarounds In-Reply-To: <577651D7.4030309@arm.com> References: <611b2a77-e7e8-e1e2-85b5-4f469f3ebdf4@samsung.com> <577651D7.4030309@arm.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Robin, On 2016-07-01 13:19, Robin Murphy wrote: > Hi Marek, > > On 01/07/16 11:32, Marek Szyprowski wrote: >> Hi Robin, >> >> >> On 2016-06-28 17:48, Robin Murphy wrote: >>> So far, all the users of the generic of_xlate configuration mechanism >>> are resorting to explicit platform device creation to ensure the IOMMU >>> device is ready before anything tries to refer to it. As I'm about to >>> convert two more drivers that will need exactly the same thing, let's >>> nip that proliferation in the bud and move it to a single place. >>> >>> A neat solution is to make of_get_iommu_ops() ensure an IOMMU device is >>> instantiated before giving out its associated ops, since it's a fairly >>> safe assumption that the ops aren't going to be much use if the IOMMU >>> can't or won't exist to back them up. >>> >>> CC: Marek Szyprowski >>> CC: Yong Wu >>> Signed-off-by: Robin Murphy >> 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? I will keep it as is until the core will be ready for initializing Exynos iommu driver simply from the core_initcall (or other), which will just do platform_driver_register(&exynos_sysmmu_driver). > 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. It should be quite easy to get Exynos DRM with HDMI display working on Odroid XU1, I can take a look in that after getting back from holidays (probably after 17th July). > 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). > > Robin. > > -----8<----- > diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c > index e4c3916efba9..c002ff06b625 100644 > --- a/drivers/iommu/arm-smmu-v3.c > +++ b/drivers/iommu/arm-smmu-v3.c > @@ -2678,6 +2678,14 @@ module_exit(arm_smmu_exit); > > static int __init arm_smmu_of_init(struct device_node *np) > { > + static bool registered; > + > + if (!registered) > + registered = !arm_smmu_init(); > + > + if (!of_platform_device_create(np, NULL, platform_bus_type.dev_root)) > + return -ENODEV; > + > of_iommu_set_ops(np, &arm_smmu_ops); > > return 0; > > Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland