From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752809AbcGYIkG (ORCPT <rfc822;w@1wt.eu>);
	Mon, 25 Jul 2016 04:40:06 -0400
Received: from mail-wm0-f65.google.com ([74.125.82.65]:32833 "EHLO
	mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751962AbcGYIj5 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 25 Jul 2016 04:39:57 -0400
Subject: Re: [PATCH 1/3] memory: mediatek: Add a new interface
 mtk_smi_larb_is_ready
To: Yong Wu <yong.wu@mediatek.com>, David Airlie <airlied@linux.ie>,
        Philipp Zabel <p.zabel@pengutronix.de>,
        Hans Verkuil <hans.verkuil@cisco.com>
References: <1468983721-3627-1-git-send-email-yong.wu@mediatek.com>
Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>,
        Tiffany Lin <tiffany.lin@mediatek.com>,
        Honghui Zhang <honghui.zhang@mediatek.com>,
        Bibby Hsieh <bibby.hsieh@mediatek.com>, YT Shen <yt.shen@mediatek.com>,
        CK Hu <ck.hu@mediatek.com>, Daniel Kurtz <djkurtz@google.com>,
        Tomasz Figa <tfiga@google.com>, Arnd Bergmann <arnd@arndb.de>,
        Lucas Stach <l.stach@pengutronix.de>, youlin.pei@mediatek.com,
        linux-mediatek@lists.infradead.org, srv_heupstream@mediatek.com,
        linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        iommu@lists.linux-foundation.org, Joerg Roedel <joro@8bytes.org>
From: Matthias Brugger <matthias.bgg@gmail.com>
Message-ID: <cd01b829-f869-606b-5c1a-8077fbddb085@gmail.com>
Date: Mon, 25 Jul 2016 10:39:52 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2
MIME-Version: 1.0
In-Reply-To: <1468983721-3627-1-git-send-email-yong.wu@mediatek.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org



On 20/07/16 05:01, Yong Wu wrote:
> Currently the iommu consumer always call iommu_present to get whether
> the iommu is ready. But in MTK IOMMU, this function can't indicate
> this. The IOMMU call bus_set_iommu->mtk_iommu_add_device->
> mtk_iommu_attach_device to parse the iommu data, then it's able to
> transfer "struct mtk_smi_iommu" to SMI-LARB, and the iommu uses the
> larbs as compoents, the iommu will finish its probe until all the larbs
> probe done.
>
> If the iommu consumer(like DRM) begin to probe after the time of
> calling bus_set_iommu and before the time of SMI probe finish, it
> will hang like this:
>
> [    7.832359] Call trace:
> [    7.834778] [<ffffffc000764424>] mtk_smi_larb_get+0x24/0xa8
> [    7.840300] [<ffffffc0005a1390>] mtk_drm_crtc_enable+0x6c/0x450
>
> Because the larb->mmu is NULL at that time.
>
> In order to avoid this issue, we add a new interface
> (mtk_smi_larb_is_ready) for checking whether the IOMMU and SMI have
> finished their probe. If it return false, the iommu consumer should
> probe-defer for the IOMMU and SMI.
>

Can't we just skip the functions in the probe and call bus_set_iommu 
only if we were able to bind all components?
Something like this:

diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index c3043d8..0bef49b 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -649,10 +649,14 @@ static int mtk_iommu_probe(struct platform_device 
*pdev)
         if (ret)
                 return ret;

+       ret = component_master_add_with_match(dev, &mtk_iommu_com_ops, 
match);
+       if (ret)
+               return ret;
+
         if (!iommu_present(&platform_bus_type))
                 bus_set_iommu(&platform_bus_type, &mtk_iommu_ops);

-       return component_master_add_with_match(dev, &mtk_iommu_com_ops, 
match);
+       return ret;
  } 

 

  static int mtk_iommu_remove(struct platform_device *pdev)

Regards,
Matthias