Received: by 2002:ac0:950c:0:0:0:0:0 with SMTP id f12csp2826335imc; Wed, 13 Mar 2019 02:14:00 -0700 (PDT) X-Google-Smtp-Source: APXvYqzOAPp9+rO8AcMJrlCptGLl6zPZBSMQBdg4atjUrOjkObeDovvNHXkSBhrnVPKEk0+Vlaz5 X-Received: by 2002:a62:45da:: with SMTP id n87mr36599083pfi.160.1552468440623; Wed, 13 Mar 2019 02:14:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552468440; cv=none; d=google.com; s=arc-20160816; b=H6bBpK46D9jnAtf7o8MDADsjH8MTSoXKa0MntdJIrR60t3LTDtDBmMVbo5MmumaLoC wno2D0YZe+4WvxBlXEY3XtLA0zPnfomMUDEXa3iVOcimTNa0hHB5BBuDOJ3BuNICh1Nc ehjUyPTmEtcT2MNI4pgyE/xYVQXHgdHnAOVCVO0Xj5dS8yU3dPOclpOdkbW8cUzhh6+G vGZOTSfYfMmFhDjNT+E2oSQ9zBF+iENRLssTljg2eoLkd+xIg6tdUFgv1GQM8q7cb3Go 4XAswCdcJA41NWPDzuwDNrJnHmflYK5vMMRnyUtellOr3eK7lnx0f4xW5pEdFqI29c8D jLPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :references:in-reply-to:date:cc:to:from:subject:message-id; bh=02SVWyFDCy/IbVpoEQ3r5qNNuLbp8VBQ+0D0ioAb/Kg=; b=T7kPYJkLK+MHTW2WYXLtvbo8i8+sGBwi9ii3AkkWoR4EQOYU1oyLsDD5lVXxwXarK7 sRq/kv5worgFwT06njvFxv3l5R6Pv3UcBRWqUj8TUaWqyoTbsFNw9zT4vDzEL0KhZNFf jTkZETxdZ2fK6V0u9jkwbO+QnJUT2jmRiphsuLdS008e9/8AqTUXDmqWAtUtH4i8kz5y auYf1QwbgHduPT93Djz8m5Eb03DOJAJHigIuef7eVg1UhvTGn8k/ME5o/hGsBq9S4wGr pdNLi7LyJ8heUNb763RY8eHWIJLFNE/DSOAu2yA3SeDNck9jGtgAo3MLZhvwvVWqOl2g v+ig== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 11si11151387plb.330.2019.03.13.02.13.43; Wed, 13 Mar 2019 02:14:00 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727279AbfCMJMK (ORCPT + 99 others); Wed, 13 Mar 2019 05:12:10 -0400 Received: from mailgw02.mediatek.com ([1.203.163.81]:53229 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726163AbfCMJMJ (ORCPT ); Wed, 13 Mar 2019 05:12:09 -0400 X-UUID: a4ae4db5cc434582a9148da334c2e57d-20190313 X-UUID: a4ae4db5cc434582a9148da334c2e57d-20190313 Received: from mtkcas35.mediatek.inc [(172.27.4.253)] by mailgw02.mediatek.com (envelope-from ) (mailgw01.mediatek.com ESMTP with TLS) with ESMTP id 650479586; Wed, 13 Mar 2019 17:11:55 +0800 Received: from MTKCAS32.mediatek.inc (172.27.4.184) by MTKMBS31DR.mediatek.inc (172.27.6.102) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 13 Mar 2019 17:11:53 +0800 Received: from [10.17.3.153] (172.27.4.253) by MTKCAS32.mediatek.inc (172.27.4.170) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Wed, 13 Mar 2019 17:11:53 +0800 Message-ID: <1552468313.7433.14.camel@mhfsdcap03> Subject: Re: [PATCH 04/13] iommu/mediatek: Add device_link between the consumer and the larb devices From: Yong Wu To: Robin Murphy CC: Joerg Roedel , Greg Kroah-Hartman , Matthias Brugger , Rob Herring , , , Nicolas Boichat , , , Will Deacon , , Tomasz Figa , , , , Date: Wed, 13 Mar 2019 17:11:53 +0800 In-Reply-To: <709d7d66-9610-eeb3-128e-e2156bcfb616@arm.com> References: <1546318276-18993-1-git-send-email-yong.wu@mediatek.com> <1546318276-18993-5-git-send-email-yong.wu@mediatek.com> <709d7d66-9610-eeb3-128e-e2156bcfb616@arm.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-MTK: N Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Robin, sorry for reply so late. On Wed, 2019-02-27 at 19:30 +0000, Robin Murphy wrote: > On 01/01/2019 04:51, Yong Wu wrote: > > MediaTek IOMMU don't have its power-domain. all the consumer connect > > with smi-larb, then connect with smi-common. > > > > M4U > > | > > smi-common > > | > > ------------- > > | | ... > > | | > > larb1 larb2 > > | | > > vdec venc > > > > When the consumer works, it should enable the smi-larb's power which > > also need enable the smi-common's power firstly. > > > > Thus, First of all, use the device link connect the consumer and the > > smi-larbs. then add device link between the smi-larb and smi-common. > > > > This patch adds device_link between the consumer and the larbs. > > > > Suggested-by: Tomasz Figa > > Signed-off-by: Yong Wu > > --- > > drivers/iommu/mtk_iommu.c | 15 +++++++++++++-- > > drivers/iommu/mtk_iommu_v1.c | 14 ++++++++++++-- > > 2 files changed, 25 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c > > index 202e41b..735ae8d 100644 > > --- a/drivers/iommu/mtk_iommu.c > > +++ b/drivers/iommu/mtk_iommu.c > > @@ -247,6 +247,7 @@ static void mtk_iommu_config(struct mtk_iommu_data *data, > > struct mtk_smi_larb_iommu *larb_mmu; > > unsigned int larbid, portid; > > struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev); > > + struct device_link *link; > > int i; > > > > for (i = 0; i < fwspec->num_ids; ++i) { > > @@ -257,10 +258,20 @@ static void mtk_iommu_config(struct mtk_iommu_data *data, > > dev_dbg(dev, "%s iommu port: %d\n", > > enable ? "enable" : "disable", portid); > > > > - if (enable) > > + if (enable) { > > larb_mmu->mmu |= MTK_SMI_MMU_EN(portid); > > - else > > + /* Link the consumer with the larb device(supplier) */ > > + link = device_link_add(dev, larb_mmu->dev, > > + DL_FLAG_PM_RUNTIME | > > + DL_FLAG_AUTOREMOVE_CONSUMER); > > This looks technically wrong, since we get here from > mtk_iommu_attach_device(), and in theory a device could get attached to > any number of domains over its lifetime, so adding a link at this point > when there's no corresponding cleanup on detach is definitely > unbalanced. If you want this layer to manage the link on behalf of the > consumer, it would probably be better to do it at the point of > mtk_iommu_add_device(), and either track it for manual cleanup in > mtk_iommu_remove_device() or rely on AUTOREMOVE_SUPPLIER. Thanks. I will try to move the "device_link_add" in add_device in next version. > > Robin. > > > + if (!link) { > > + dev_err(dev, "Unable to link %s\n", > > + dev_name(larb_mmu->dev)); > > + return; > > + } > > + } else { > > larb_mmu->mmu &= ~MTK_SMI_MMU_EN(portid); > > + } > > } > > } > > > > diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c > > index 9386aee..022bad9 100644 > > --- a/drivers/iommu/mtk_iommu_v1.c > > +++ b/drivers/iommu/mtk_iommu_v1.c > > @@ -201,6 +201,7 @@ static void mtk_iommu_config(struct mtk_iommu_data *data, > > struct mtk_smi_larb_iommu *larb_mmu; > > unsigned int larbid, portid; > > struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev); > > + struct device_link *link; > > int i; > > > > for (i = 0; i < fwspec->num_ids; ++i) { > > @@ -211,10 +212,19 @@ static void mtk_iommu_config(struct mtk_iommu_data *data, > > dev_dbg(dev, "%s iommu port: %d\n", > > enable ? "enable" : "disable", portid); > > > > - if (enable) > > + if (enable) { > > larb_mmu->mmu |= MTK_SMI_MMU_EN(portid); > > - else > > + link = device_link_add(dev, larb_mmu->dev, > > + DL_FLAG_PM_RUNTIME | > > + DL_FLAG_AUTOREMOVE_CONSUMER); > > + if (!link) { > > + dev_err(dev, "Unable to link %s\n", > > + dev_name(larb_mmu->dev)); > > + return; > > + } > > + } else { > > larb_mmu->mmu &= ~MTK_SMI_MMU_EN(portid); > > + } > > } > > } > > > >