mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Yong Wu (吴勇)" <Yong.Wu@mediatek.com>
To: "Chengci Xu (许承赐)" <Chengci.Xu@mediatek.com>
Cc: "linux-mediatek@lists.infradead.org" 
	<linux-mediatek@lists.infradead.org>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"robin.murphy@arm.com" <robin.murphy@arm.com>,
	"joro@8bytes.org" <joro@8bytes.org>,
	Project_Global_Chrome_Upstream_Group 
	<Project_Global_Chrome_Upstream_Group@mediatek.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"krzysztof.kozlowski+dt@linaro.org" 
	<krzysztof.kozlowski+dt@linaro.org>,
	"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
	"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
	"will@kernel.org" <will@kernel.org>
Subject: Re: [PATCH v4 2/4] iommu/mediatek: Adjust mtk_iommu_config flow
Date: Mon, 21 Nov 2022 05:17:54 +0000	[thread overview]
Message-ID: <2ea0120c31d4230701aa031daf57317720f78cf0.camel@mediatek.com> (raw)
In-Reply-To: <20221018064239.13391-3-chengci.xu@mediatek.com>

On Tue, 2022-10-18 at 14:42 +0800, Chengci.Xu wrote:
> For reduce indention without functional change, prepare for MT8188.
> If there are many port in a same larb, current flow will update
> larb_mmu->mmu or update INFRA register for too many times.
> So we save all port to portid_msk in the front of mtk_iommu_config(),
> and then update only once for IOMMU configure. By this modification,
> we can prevent MT8188 from sending to many SMC calls, avoiding enter
> ATF for each port.
> 
> Signed-off-by: Chengci.Xu <chengci.xu@mediatek.com>
> ---
>  drivers/iommu/mtk_iommu.c | 60 ++++++++++++++++++++++---------------
> --
>  1 file changed, 34 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 5a4e00e4bbbc..fbaf401f34e0 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -534,41 +534,49 @@ static int mtk_iommu_config(struct
> mtk_iommu_data *data, struct device *dev,
>  	unsigned int                 larbid, portid;
>  	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
>  	const struct mtk_iommu_iova_region *region;
> -	u32 peri_mmuen, peri_mmuen_msk;
> +	unsigned long portid_msk_ext;
> +	u32 portid_msk = 0;
>  	int i, ret = 0;
>  
>  	for (i = 0; i < fwspec->num_ids; ++i) {
> -		larbid = MTK_M4U_TO_LARB(fwspec->ids[i]);
>  		portid = MTK_M4U_TO_PORT(fwspec->ids[i]);
> +		portid_msk |= BIT(portid);
> +	}
>  
> -		if (MTK_IOMMU_IS_TYPE(data->plat_data,
> MTK_IOMMU_TYPE_MM)) {
> -			larb_mmu = &data->larb_imu[larbid];
> +	if (MTK_IOMMU_IS_TYPE(data->plat_data, MTK_IOMMU_TYPE_MM)) {
> +		/* All ports should be in the same larb. just use 0
> here */
> +		larbid = MTK_M4U_TO_LARB(fwspec->ids[0]);
> +		larb_mmu = &data->larb_imu[larbid];
> +		region = data->plat_data->iova_region + regionid;
>  
> -			region = data->plat_data->iova_region +
> regionid;
> +		portid_msk_ext = portid_msk;
> +		for_each_set_bit(portid, &portid_msk_ext, 32)

Why do we need define a new portid_msk_ext? Can't we use portid_msk
directly?

>  			larb_mmu->bank[portid] = upper_32_bits(region-
> >iova_base);
>  
> -			dev_dbg(dev, "%s iommu for larb(%s) port %d
> region %d rgn-bank %d.\n",
> -				enable ? "enable" : "disable",
> dev_name(larb_mmu->dev),
> -				portid, regionid, larb_mmu-
> >bank[portid]);
> -
> -			if (enable)
> -				larb_mmu->mmu |=
> MTK_SMI_MMU_EN(portid);
> -			else
> -				larb_mmu->mmu &=
> ~MTK_SMI_MMU_EN(portid);
> -		} else if (MTK_IOMMU_IS_TYPE(data->plat_data,
> MTK_IOMMU_TYPE_INFRA)) {
> -			peri_mmuen_msk = BIT(portid);
> -			/* PCI dev has only one output id, enable the
> next writing bit for PCIe */
> -			if (dev_is_pci(dev))
> -				peri_mmuen_msk |= BIT(portid + 1);
> -
> -			peri_mmuen = enable ? peri_mmuen_msk : 0;
> -			ret = regmap_update_bits(data->pericfg,
> PERICFG_IOMMU_1,
> -						 peri_mmuen_msk,
> peri_mmuen);
> -			if (ret)
> -				dev_err(dev, "%s iommu(%s) inframaster
> 0x%x fail(%d).\n",
> -					enable ? "enable" : "disable",
> -					dev_name(data->dev),
> peri_mmuen_msk, ret);
> +		dev_dbg(dev, "%s iommu for larb(%s) port 0x%x region %d
> rgn-bank %d.\n",
> +			enable ? "enable" : "disable",
> dev_name(larb_mmu->dev),
> +			portid_msk, regionid, upper_32_bits(region-
> >iova_base));
> +
> +		if (enable)
> +			larb_mmu->mmu |= portid_msk;
> +		else
> +			larb_mmu->mmu &= ~portid_msk;
> +	} else if (MTK_IOMMU_IS_TYPE(data->plat_data,
> MTK_IOMMU_TYPE_INFRA)) {
> +		/* PCI dev has only one output id, enable the next
> writing bit for PCIe */
> +		if (dev_is_pci(dev)) {
> +			if (fwspec->num_ids != 1) {
> +				dev_err(dev, "PCI dev can only have one
> port.\n");
> +				return -ENODEV;
> +			}
> +			portid_msk |= BIT(portid + 1);
>  		}
> +
> +		ret = regmap_update_bits(data->pericfg,
> PERICFG_IOMMU_1,
> +					 portid_msk, enable ?
> portid_msk : 0);
> +		if (ret)
> +			dev_err(dev, "%s iommu(%s) inframaster 0x%x
> fail(%d).\n",
> +				enable ? "enable" : "disable",
> +				dev_name(data->dev), portid_msk, ret);
>  	}
>  	return ret;
>  }

  parent reply	other threads:[~2022-11-21  5:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20221018064239.13391-1-chengci.xu@mediatek.com>
     [not found] ` <20221018064239.13391-2-chengci.xu@mediatek.com>
2022-11-21  5:17   ` [PATCH v4 1/4] dt-bindings: mediatek: mt8188: Add binding for MM & INFRA IOMMU Yong Wu (吴勇)
     [not found] ` <20221018064239.13391-5-chengci.xu@mediatek.com>
2022-11-21  5:17   ` [PATCH v4 4/4] iommu/mediatek: Add MT8188 IOMMU Support Yong Wu (吴勇)
     [not found] ` <20221018064239.13391-4-chengci.xu@mediatek.com>
2022-11-21  5:17   ` [PATCH v4 3/4] iommu/mediatek: Add enable IOMMU SMC command for INFRA master Yong Wu (吴勇)
     [not found] ` <20221018064239.13391-3-chengci.xu@mediatek.com>
2022-11-21  5:17   ` Yong Wu (吴勇) [this message]
2022-11-21  6:37     ` [PATCH v4 2/4] iommu/mediatek: Adjust mtk_iommu_config flow Chengci Xu (许承赐)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2ea0120c31d4230701aa031daf57317720f78cf0.camel@mediatek.com \
    --to=yong.wu@mediatek.com \
    --cc=Chengci.Xu@mediatek.com \
    --cc=Project_Global_Chrome_Upstream_Group@mediatek.com \
    --cc=devicetree@vger.kernel.org \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®