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 <m.szyprowski@xxxxxxxxxxx>
>> CC: Yong Wu <yong.wu@xxxxxxxxxxxx>
>> Signed-off-by: Robin Murphy <robin.murphy@xxxxxxx>
>
> 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).
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;
--
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
