[PATCH v3 2/9] iommu/of: Consolidate device creation workarounds

[Marek Szyprowski]

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 <m.szyprowski at samsung.com>
>>> CC: Yong Wu <yong.wu at mediatek.com>
>>> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
>> 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