From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_2 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C2032C433E1 for ; Fri, 19 Jun 2020 10:57:03 +0000 (UTC) Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8BB93208B8 for ; Fri, 19 Jun 2020 10:57:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="G4R7llYP" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8BB93208B8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 4118926698; Fri, 19 Jun 2020 10:57:03 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k84tn57Wgj49; Fri, 19 Jun 2020 10:57:02 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by silver.osuosl.org (Postfix) with ESMTP id E8B7622BA3; Fri, 19 Jun 2020 10:57:01 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id D4B59C0865; Fri, 19 Jun 2020 10:57:01 +0000 (UTC) Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id BE52AC016E for ; Fri, 19 Jun 2020 10:57:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id A57D288E29 for ; Fri, 19 Jun 2020 10:57:00 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amKfABlL9raz for ; Fri, 19 Jun 2020 10:56:59 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mailgw02.mediatek.com (unknown [210.61.82.184]) by whitealder.osuosl.org (Postfix) with ESMTP id 57B0B889C6 for ; Fri, 19 Jun 2020 10:56:59 +0000 (UTC) X-UUID: e3ffb29f32964897bee5235e74b17c9d-20200619 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References:In-Reply-To:Date:CC:To:From:Subject:Message-ID; bh=oL5TlAXNn0Cmq0gGUlNt/GBvCP0nGgQwLNZafI+vGMI=; b=G4R7llYPfIjj7ym3FzaJV/68DG/cT08PfJXOegMySuIVyHSzT4bEctKewdYsQibaowdi6+8kI3Td3Buq0oVOhjMEGhRuTemDV00wnO4Mu3xRDwPinvR19TsorLRMIa1uLUsd6bdz8V/NhpN4NwkOOenHry401P0SYN3+NIdttg4=; X-UUID: e3ffb29f32964897bee5235e74b17c9d-20200619 Received: from mtkcas10.mediatek.inc [(172.21.101.39)] by mailgw02.mediatek.com (envelope-from ) (Cellopoint E-mail Firewall v4.1.10 Build 0809 with TLS) with ESMTP id 1280163925; Fri, 19 Jun 2020 18:56:54 +0800 Received: from mtkcas08.mediatek.inc (172.21.101.126) by mtkmbs01n1.mediatek.inc (172.21.101.68) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 19 Jun 2020 18:56:51 +0800 Received: from [10.15.20.246] (10.15.20.246) by mtkcas08.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Fri, 19 Jun 2020 18:56:50 +0800 Message-ID: <1592564184.5692.6.camel@mbjsdccf07> Subject: Re: [PATCH v4 6/7] iommu/mediatek: Add REG_MMU_WR_LEN definition preparing for mt6779 From: chao hao To: Matthias Brugger Date: Fri, 19 Jun 2020 18:56:24 +0800 In-Reply-To: <9e2c52d6-a887-1977-8877-fbcd30cb4261@gmail.com> References: <20200617030029.4082-1-chao.hao@mediatek.com> <20200617030029.4082-7-chao.hao@mediatek.com> <9e2c52d6-a887-1977-8877-fbcd30cb4261@gmail.com> X-Mailer: Evolution 3.10.4-0ubuntu2 MIME-Version: 1.0 X-MTK: N Cc: devicetree@vger.kernel.org, FY Yang , wsd_upstream@mediatek.com, linux-kernel@vger.kernel.org, Chao Hao , iommu@lists.linux-foundation.org, Rob Herring , linux-mediatek@lists.infradead.org, linux-arm-kernel@lists.infradead.org X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On Wed, 2020-06-17 at 11:22 +0200, Matthias Brugger wrote: > > On 17/06/2020 05:00, Chao Hao wrote: > > Some platforms(ex: mt6779) have a new register called by REG_MMU_WR_LEN > > to improve performance. > > This patch add this register definition. > > Please be more specific what this register is about. > OK. thanks. We can use "has_wr_len" flag to control whether we need to set the register. If the register uses default value, iommu will send command to EMI without restriction, when the number of commands become more and more, it will drop the EMI performance. So when more than ten_commands(default value) don't be handled for EMI, IOMMU will stop send command to EMI for keeping EMI's performace by enabling write throttling mechanism(bit[5][21]=0) in MMU_WR_LEN_CTRL register. I will write description above to commit message in next version > > > > Signed-off-by: Chao Hao > > --- > > drivers/iommu/mtk_iommu.c | 10 ++++++++++ > > drivers/iommu/mtk_iommu.h | 2 ++ > > 2 files changed, 12 insertions(+) > > > > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c > > index a687e8db0e51..c706bca6487e 100644 > > --- a/drivers/iommu/mtk_iommu.c > > +++ b/drivers/iommu/mtk_iommu.c > > @@ -46,6 +46,8 @@ > > #define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19)) > > > > #define REG_MMU_DCM_DIS 0x050 > > +#define REG_MMU_WR_LEN 0x054 > > +#define F_MMU_WR_THROT_DIS_BIT (BIT(5) | BIT(21)) > > > > #define REG_MMU_CTRL_REG 0x110 > > #define F_MMU_TF_PROT_TO_PROGRAM_ADDR (2 << 4) > > @@ -581,6 +583,12 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data) > > writel_relaxed(regval, data->base + REG_MMU_VLD_PA_RNG); > > } > > writel_relaxed(0, data->base + REG_MMU_DCM_DIS); > > + if (data->plat_data->has_wr_len) { > > + /* write command throttling mode */ > > + regval = readl_relaxed(data->base + REG_MMU_WR_LEN); > > + regval &= ~F_MMU_WR_THROT_DIS_BIT; > > + writel_relaxed(regval, data->base + REG_MMU_WR_LEN); > > + } > > > > if (data->plat_data->reset_axi) { > > /* The register is called STANDARD_AXI_MODE in this case */ > > @@ -737,6 +745,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device *dev) > > struct mtk_iommu_suspend_reg *reg = &data->reg; > > void __iomem *base = data->base; > > > > + reg->wr_len = readl_relaxed(base + REG_MMU_WR_LEN); > > Can we read/write the register without any side effect although hardware has not > implemented it (!has_wr_len)? It doesn't have side effect. Becasue all the MTK platform have the register for iommu HW. If we need to have requirement for performance, we can set it by has_wr_len. But I'm Sorry, the name of flag(has_wr_len) is not exact, I will rename it in next version, ex: "wr_throt_en" > > > > reg->misc_ctrl = readl_relaxed(base + REG_MMU_MISC_CTRL); > > reg->dcm_dis = readl_relaxed(base + REG_MMU_DCM_DIS); > > reg->ctrl_reg = readl_relaxed(base + REG_MMU_CTRL_REG); > > @@ -761,6 +770,7 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev) > > dev_err(data->dev, "Failed to enable clk(%d) in resume\n", ret); > > return ret; > > } > > + writel_relaxed(reg->wr_len, base + REG_MMU_WR_LEN); > > writel_relaxed(reg->misc_ctrl, base + REG_MMU_MISC_CTRL); > > writel_relaxed(reg->dcm_dis, base + REG_MMU_DCM_DIS); > > writel_relaxed(reg->ctrl_reg, base + REG_MMU_CTRL_REG); > > diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h > > index d51ff99c2c71..9971cedd72ea 100644 > > --- a/drivers/iommu/mtk_iommu.h > > +++ b/drivers/iommu/mtk_iommu.h > > @@ -25,6 +25,7 @@ struct mtk_iommu_suspend_reg { > > u32 int_main_control; > > u32 ivrp_paddr; > > u32 vld_pa_rng; > > + u32 wr_len; > > }; > > > > enum mtk_iommu_plat { > > @@ -43,6 +44,7 @@ struct mtk_iommu_plat_data { > > bool has_misc_ctrl; > > bool has_sub_comm; > > bool has_vld_pa_rng; > > + bool has_wr_len; > > Given the fact that we are adding more and more plat_data bool values, I think > it would make sense to use a u32 flags register and add the appropriate macro > definitions to set and check for a flag present. Thanks for your advice. do you mean like this: struct plat_flag { #define HAS_4GB_MODE BIT(0) #define HAS_BCLK BIT(1) #define REST_AXI BIT(2) ... ... u32 flag; }; struct mtk_iommu_plat_data { ...... struct plat_flag flag; ...... }; > Regards, > Matthias > > > bool reset_axi; > > u32 inv_sel_reg; > > unsigned char larbid_remap[8][4]; > > _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_2 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 68B9CC433DF for ; Fri, 19 Jun 2020 10:57:19 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 15552208B8 for ; Fri, 19 Jun 2020 10:57:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="a495AJlY"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="G4R7llYP" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 15552208B8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=0jNpUBLyqjs4rwfNuH3GMC9kvwDylbPM9+Es1Dgrhqs=; b=a495AJlYFmKqj+ bIVXvwylTtNw6U1Xu6FetLfkGZcbkxhTJvu/F+yDnjlu/lOuFNxQ/fLIoFr1XDZFthu3y/qZ6JOfl BnFbPhVIfsdtrpiAq87YvHPKg/3SBDkKosNusj8gRrXggK4B/sU6OJJFXNaGH6x30N8go/W2dattn 5h6lCiTrDJv/awjD8AaNrXLpy8dhHgwI7SOWvxORKpswjgtddYMDw1vIHNVIcnB7vQenwmzPHYKGM vMS/DjRC+a18XsU6EbU/fYZl3sfjsClrX7xBkXz1TdXP2qRpdU9G2AzqQ1BIG7uTod2b7kmRaf4T2 T/wJYZ34q2LOgj3DGOVA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jmEhj-00049b-M0; Fri, 19 Jun 2020 10:57:03 +0000 Received: from mailgw02.mediatek.com ([216.200.240.185]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jmEhg-00047j-Eq; Fri, 19 Jun 2020 10:57:01 +0000 X-UUID: 84a24bf78eff496fa17109036253b889-20200619 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References:In-Reply-To:Date:CC:To:From:Subject:Message-ID; bh=oL5TlAXNn0Cmq0gGUlNt/GBvCP0nGgQwLNZafI+vGMI=; b=G4R7llYPfIjj7ym3FzaJV/68DG/cT08PfJXOegMySuIVyHSzT4bEctKewdYsQibaowdi6+8kI3Td3Buq0oVOhjMEGhRuTemDV00wnO4Mu3xRDwPinvR19TsorLRMIa1uLUsd6bdz8V/NhpN4NwkOOenHry401P0SYN3+NIdttg4=; X-UUID: 84a24bf78eff496fa17109036253b889-20200619 Received: from mtkcas68.mediatek.inc [(172.29.94.19)] by mailgw02.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLS) with ESMTP id 1683716732; Fri, 19 Jun 2020 02:56:53 -0800 Received: from MTKMBS01N1.mediatek.inc (172.21.101.68) by MTKMBS62DR.mediatek.inc (172.29.94.18) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 19 Jun 2020 03:56:53 -0700 Received: from mtkcas08.mediatek.inc (172.21.101.126) by mtkmbs01n1.mediatek.inc (172.21.101.68) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 19 Jun 2020 18:56:51 +0800 Received: from [10.15.20.246] (10.15.20.246) by mtkcas08.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Fri, 19 Jun 2020 18:56:50 +0800 Message-ID: <1592564184.5692.6.camel@mbjsdccf07> Subject: Re: [PATCH v4 6/7] iommu/mediatek: Add REG_MMU_WR_LEN definition preparing for mt6779 From: chao hao To: Matthias Brugger Date: Fri, 19 Jun 2020 18:56:24 +0800 In-Reply-To: <9e2c52d6-a887-1977-8877-fbcd30cb4261@gmail.com> References: <20200617030029.4082-1-chao.hao@mediatek.com> <20200617030029.4082-7-chao.hao@mediatek.com> <9e2c52d6-a887-1977-8877-fbcd30cb4261@gmail.com> X-Mailer: Evolution 3.10.4-0ubuntu2 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200619_035700_498858_319AE210 X-CRM114-Status: GOOD ( 24.87 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, FY Yang , wsd_upstream@mediatek.com, Joerg Roedel , linux-kernel@vger.kernel.org, Chao Hao , iommu@lists.linux-foundation.org, Rob Herring , linux-mediatek@lists.infradead.org, Yong Wu , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org On Wed, 2020-06-17 at 11:22 +0200, Matthias Brugger wrote: > > On 17/06/2020 05:00, Chao Hao wrote: > > Some platforms(ex: mt6779) have a new register called by REG_MMU_WR_LEN > > to improve performance. > > This patch add this register definition. > > Please be more specific what this register is about. > OK. thanks. We can use "has_wr_len" flag to control whether we need to set the register. If the register uses default value, iommu will send command to EMI without restriction, when the number of commands become more and more, it will drop the EMI performance. So when more than ten_commands(default value) don't be handled for EMI, IOMMU will stop send command to EMI for keeping EMI's performace by enabling write throttling mechanism(bit[5][21]=0) in MMU_WR_LEN_CTRL register. I will write description above to commit message in next version > > > > Signed-off-by: Chao Hao > > --- > > drivers/iommu/mtk_iommu.c | 10 ++++++++++ > > drivers/iommu/mtk_iommu.h | 2 ++ > > 2 files changed, 12 insertions(+) > > > > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c > > index a687e8db0e51..c706bca6487e 100644 > > --- a/drivers/iommu/mtk_iommu.c > > +++ b/drivers/iommu/mtk_iommu.c > > @@ -46,6 +46,8 @@ > > #define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19)) > > > > #define REG_MMU_DCM_DIS 0x050 > > +#define REG_MMU_WR_LEN 0x054 > > +#define F_MMU_WR_THROT_DIS_BIT (BIT(5) | BIT(21)) > > > > #define REG_MMU_CTRL_REG 0x110 > > #define F_MMU_TF_PROT_TO_PROGRAM_ADDR (2 << 4) > > @@ -581,6 +583,12 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data) > > writel_relaxed(regval, data->base + REG_MMU_VLD_PA_RNG); > > } > > writel_relaxed(0, data->base + REG_MMU_DCM_DIS); > > + if (data->plat_data->has_wr_len) { > > + /* write command throttling mode */ > > + regval = readl_relaxed(data->base + REG_MMU_WR_LEN); > > + regval &= ~F_MMU_WR_THROT_DIS_BIT; > > + writel_relaxed(regval, data->base + REG_MMU_WR_LEN); > > + } > > > > if (data->plat_data->reset_axi) { > > /* The register is called STANDARD_AXI_MODE in this case */ > > @@ -737,6 +745,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device *dev) > > struct mtk_iommu_suspend_reg *reg = &data->reg; > > void __iomem *base = data->base; > > > > + reg->wr_len = readl_relaxed(base + REG_MMU_WR_LEN); > > Can we read/write the register without any side effect although hardware has not > implemented it (!has_wr_len)? It doesn't have side effect. Becasue all the MTK platform have the register for iommu HW. If we need to have requirement for performance, we can set it by has_wr_len. But I'm Sorry, the name of flag(has_wr_len) is not exact, I will rename it in next version, ex: "wr_throt_en" > > > > reg->misc_ctrl = readl_relaxed(base + REG_MMU_MISC_CTRL); > > reg->dcm_dis = readl_relaxed(base + REG_MMU_DCM_DIS); > > reg->ctrl_reg = readl_relaxed(base + REG_MMU_CTRL_REG); > > @@ -761,6 +770,7 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev) > > dev_err(data->dev, "Failed to enable clk(%d) in resume\n", ret); > > return ret; > > } > > + writel_relaxed(reg->wr_len, base + REG_MMU_WR_LEN); > > writel_relaxed(reg->misc_ctrl, base + REG_MMU_MISC_CTRL); > > writel_relaxed(reg->dcm_dis, base + REG_MMU_DCM_DIS); > > writel_relaxed(reg->ctrl_reg, base + REG_MMU_CTRL_REG); > > diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h > > index d51ff99c2c71..9971cedd72ea 100644 > > --- a/drivers/iommu/mtk_iommu.h > > +++ b/drivers/iommu/mtk_iommu.h > > @@ -25,6 +25,7 @@ struct mtk_iommu_suspend_reg { > > u32 int_main_control; > > u32 ivrp_paddr; > > u32 vld_pa_rng; > > + u32 wr_len; > > }; > > > > enum mtk_iommu_plat { > > @@ -43,6 +44,7 @@ struct mtk_iommu_plat_data { > > bool has_misc_ctrl; > > bool has_sub_comm; > > bool has_vld_pa_rng; > > + bool has_wr_len; > > Given the fact that we are adding more and more plat_data bool values, I think > it would make sense to use a u32 flags register and add the appropriate macro > definitions to set and check for a flag present. Thanks for your advice. do you mean like this: struct plat_flag { #define HAS_4GB_MODE BIT(0) #define HAS_BCLK BIT(1) #define REST_AXI BIT(2) ... ... u32 flag; }; struct mtk_iommu_plat_data { ...... struct plat_flag flag; ...... }; > Regards, > Matthias > > > bool reset_axi; > > u32 inv_sel_reg; > > unsigned char larbid_remap[8][4]; > > _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_2 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ACBF9C433E1 for ; Fri, 19 Jun 2020 10:57:05 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7E472214F1 for ; Fri, 19 Jun 2020 10:57:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="EaqHRQ2v"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="G4R7llYP" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7E472214F1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=JNVNdKdfG1WQ5MehSLQHkokuPvI7a/r9semOHUasEd0=; b=EaqHRQ2vWuYrG4 nKk79b+vnzx6IXppnXKHa6NBV9ogkrx9Ko01iizA0S7op/ZCeSA9Yo94THxFVQyRjIgSWyH8Hl1+4 bhEv9E4Zr1BynyG8MpMFT5ATUNsLHo87bIp5qmhzqrxjreKKKjUf0xy3viiZsg3CXGi2Ah2FuHLl4 OrvrlC66F3tP/foOZdTeDU3oTnNdDDHAmtpmNikJhB+jxN2vHEEuFLYjn0o5uzBNKIywmtZMUp8os 86xHxtcjHYbX5iu/4NhChQtO3Ra97U1CK3EZbaPan30PsN9+Y4kHXODf7wWdnrxlNIDInTvioFxI2 TZ1s1BvM9wZWrmllxHQw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jmEhk-0004AL-QM; Fri, 19 Jun 2020 10:57:04 +0000 Received: from mailgw02.mediatek.com ([216.200.240.185]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jmEhg-00047j-Eq; Fri, 19 Jun 2020 10:57:01 +0000 X-UUID: 84a24bf78eff496fa17109036253b889-20200619 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References:In-Reply-To:Date:CC:To:From:Subject:Message-ID; bh=oL5TlAXNn0Cmq0gGUlNt/GBvCP0nGgQwLNZafI+vGMI=; b=G4R7llYPfIjj7ym3FzaJV/68DG/cT08PfJXOegMySuIVyHSzT4bEctKewdYsQibaowdi6+8kI3Td3Buq0oVOhjMEGhRuTemDV00wnO4Mu3xRDwPinvR19TsorLRMIa1uLUsd6bdz8V/NhpN4NwkOOenHry401P0SYN3+NIdttg4=; X-UUID: 84a24bf78eff496fa17109036253b889-20200619 Received: from mtkcas68.mediatek.inc [(172.29.94.19)] by mailgw02.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLS) with ESMTP id 1683716732; Fri, 19 Jun 2020 02:56:53 -0800 Received: from MTKMBS01N1.mediatek.inc (172.21.101.68) by MTKMBS62DR.mediatek.inc (172.29.94.18) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 19 Jun 2020 03:56:53 -0700 Received: from mtkcas08.mediatek.inc (172.21.101.126) by mtkmbs01n1.mediatek.inc (172.21.101.68) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 19 Jun 2020 18:56:51 +0800 Received: from [10.15.20.246] (10.15.20.246) by mtkcas08.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Fri, 19 Jun 2020 18:56:50 +0800 Message-ID: <1592564184.5692.6.camel@mbjsdccf07> Subject: Re: [PATCH v4 6/7] iommu/mediatek: Add REG_MMU_WR_LEN definition preparing for mt6779 From: chao hao To: Matthias Brugger Date: Fri, 19 Jun 2020 18:56:24 +0800 In-Reply-To: <9e2c52d6-a887-1977-8877-fbcd30cb4261@gmail.com> References: <20200617030029.4082-1-chao.hao@mediatek.com> <20200617030029.4082-7-chao.hao@mediatek.com> <9e2c52d6-a887-1977-8877-fbcd30cb4261@gmail.com> X-Mailer: Evolution 3.10.4-0ubuntu2 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200619_035700_498858_319AE210 X-CRM114-Status: GOOD ( 24.87 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, FY Yang , wsd_upstream@mediatek.com, Joerg Roedel , linux-kernel@vger.kernel.org, Chao Hao , iommu@lists.linux-foundation.org, Rob Herring , linux-mediatek@lists.infradead.org, Yong Wu , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, 2020-06-17 at 11:22 +0200, Matthias Brugger wrote: > > On 17/06/2020 05:00, Chao Hao wrote: > > Some platforms(ex: mt6779) have a new register called by REG_MMU_WR_LEN > > to improve performance. > > This patch add this register definition. > > Please be more specific what this register is about. > OK. thanks. We can use "has_wr_len" flag to control whether we need to set the register. If the register uses default value, iommu will send command to EMI without restriction, when the number of commands become more and more, it will drop the EMI performance. So when more than ten_commands(default value) don't be handled for EMI, IOMMU will stop send command to EMI for keeping EMI's performace by enabling write throttling mechanism(bit[5][21]=0) in MMU_WR_LEN_CTRL register. I will write description above to commit message in next version > > > > Signed-off-by: Chao Hao > > --- > > drivers/iommu/mtk_iommu.c | 10 ++++++++++ > > drivers/iommu/mtk_iommu.h | 2 ++ > > 2 files changed, 12 insertions(+) > > > > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c > > index a687e8db0e51..c706bca6487e 100644 > > --- a/drivers/iommu/mtk_iommu.c > > +++ b/drivers/iommu/mtk_iommu.c > > @@ -46,6 +46,8 @@ > > #define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19)) > > > > #define REG_MMU_DCM_DIS 0x050 > > +#define REG_MMU_WR_LEN 0x054 > > +#define F_MMU_WR_THROT_DIS_BIT (BIT(5) | BIT(21)) > > > > #define REG_MMU_CTRL_REG 0x110 > > #define F_MMU_TF_PROT_TO_PROGRAM_ADDR (2 << 4) > > @@ -581,6 +583,12 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data) > > writel_relaxed(regval, data->base + REG_MMU_VLD_PA_RNG); > > } > > writel_relaxed(0, data->base + REG_MMU_DCM_DIS); > > + if (data->plat_data->has_wr_len) { > > + /* write command throttling mode */ > > + regval = readl_relaxed(data->base + REG_MMU_WR_LEN); > > + regval &= ~F_MMU_WR_THROT_DIS_BIT; > > + writel_relaxed(regval, data->base + REG_MMU_WR_LEN); > > + } > > > > if (data->plat_data->reset_axi) { > > /* The register is called STANDARD_AXI_MODE in this case */ > > @@ -737,6 +745,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device *dev) > > struct mtk_iommu_suspend_reg *reg = &data->reg; > > void __iomem *base = data->base; > > > > + reg->wr_len = readl_relaxed(base + REG_MMU_WR_LEN); > > Can we read/write the register without any side effect although hardware has not > implemented it (!has_wr_len)? It doesn't have side effect. Becasue all the MTK platform have the register for iommu HW. If we need to have requirement for performance, we can set it by has_wr_len. But I'm Sorry, the name of flag(has_wr_len) is not exact, I will rename it in next version, ex: "wr_throt_en" > > > > reg->misc_ctrl = readl_relaxed(base + REG_MMU_MISC_CTRL); > > reg->dcm_dis = readl_relaxed(base + REG_MMU_DCM_DIS); > > reg->ctrl_reg = readl_relaxed(base + REG_MMU_CTRL_REG); > > @@ -761,6 +770,7 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev) > > dev_err(data->dev, "Failed to enable clk(%d) in resume\n", ret); > > return ret; > > } > > + writel_relaxed(reg->wr_len, base + REG_MMU_WR_LEN); > > writel_relaxed(reg->misc_ctrl, base + REG_MMU_MISC_CTRL); > > writel_relaxed(reg->dcm_dis, base + REG_MMU_DCM_DIS); > > writel_relaxed(reg->ctrl_reg, base + REG_MMU_CTRL_REG); > > diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h > > index d51ff99c2c71..9971cedd72ea 100644 > > --- a/drivers/iommu/mtk_iommu.h > > +++ b/drivers/iommu/mtk_iommu.h > > @@ -25,6 +25,7 @@ struct mtk_iommu_suspend_reg { > > u32 int_main_control; > > u32 ivrp_paddr; > > u32 vld_pa_rng; > > + u32 wr_len; > > }; > > > > enum mtk_iommu_plat { > > @@ -43,6 +44,7 @@ struct mtk_iommu_plat_data { > > bool has_misc_ctrl; > > bool has_sub_comm; > > bool has_vld_pa_rng; > > + bool has_wr_len; > > Given the fact that we are adding more and more plat_data bool values, I think > it would make sense to use a u32 flags register and add the appropriate macro > definitions to set and check for a flag present. Thanks for your advice. do you mean like this: struct plat_flag { #define HAS_4GB_MODE BIT(0) #define HAS_BCLK BIT(1) #define REST_AXI BIT(2) ... ... u32 flag; }; struct mtk_iommu_plat_data { ...... struct plat_flag flag; ...... }; > Regards, > Matthias > > > bool reset_axi; > > u32 inv_sel_reg; > > unsigned char larbid_remap[8][4]; > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_2 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5C83BC433E0 for ; Fri, 19 Jun 2020 10:57:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2E6A4208B8 for ; Fri, 19 Jun 2020 10:57:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="G4R7llYP" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732381AbgFSK5B (ORCPT ); Fri, 19 Jun 2020 06:57:01 -0400 Received: from mailgw02.mediatek.com ([210.61.82.184]:50750 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1732362AbgFSK5A (ORCPT ); Fri, 19 Jun 2020 06:57:00 -0400 X-UUID: e3ffb29f32964897bee5235e74b17c9d-20200619 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References:In-Reply-To:Date:CC:To:From:Subject:Message-ID; bh=oL5TlAXNn0Cmq0gGUlNt/GBvCP0nGgQwLNZafI+vGMI=; b=G4R7llYPfIjj7ym3FzaJV/68DG/cT08PfJXOegMySuIVyHSzT4bEctKewdYsQibaowdi6+8kI3Td3Buq0oVOhjMEGhRuTemDV00wnO4Mu3xRDwPinvR19TsorLRMIa1uLUsd6bdz8V/NhpN4NwkOOenHry401P0SYN3+NIdttg4=; X-UUID: e3ffb29f32964897bee5235e74b17c9d-20200619 Received: from mtkcas10.mediatek.inc [(172.21.101.39)] by mailgw02.mediatek.com (envelope-from ) (Cellopoint E-mail Firewall v4.1.10 Build 0809 with TLS) with ESMTP id 1280163925; Fri, 19 Jun 2020 18:56:54 +0800 Received: from mtkcas08.mediatek.inc (172.21.101.126) by mtkmbs01n1.mediatek.inc (172.21.101.68) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 19 Jun 2020 18:56:51 +0800 Received: from [10.15.20.246] (10.15.20.246) by mtkcas08.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Fri, 19 Jun 2020 18:56:50 +0800 Message-ID: <1592564184.5692.6.camel@mbjsdccf07> Subject: Re: [PATCH v4 6/7] iommu/mediatek: Add REG_MMU_WR_LEN definition preparing for mt6779 From: chao hao To: Matthias Brugger CC: Joerg Roedel , Rob Herring , , , , , , , Yong Wu , FY Yang , Chao Hao Date: Fri, 19 Jun 2020 18:56:24 +0800 In-Reply-To: <9e2c52d6-a887-1977-8877-fbcd30cb4261@gmail.com> References: <20200617030029.4082-1-chao.hao@mediatek.com> <20200617030029.4082-7-chao.hao@mediatek.com> <9e2c52d6-a887-1977-8877-fbcd30cb4261@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 MIME-Version: 1.0 X-MTK: N Content-Transfer-Encoding: base64 Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org T24gV2VkLCAyMDIwLTA2LTE3IGF0IDExOjIyICswMjAwLCBNYXR0aGlhcyBCcnVnZ2VyIHdyb3Rl Og0KPiANCj4gT24gMTcvMDYvMjAyMCAwNTowMCwgQ2hhbyBIYW8gd3JvdGU6DQo+ID4gU29tZSBw bGF0Zm9ybXMoZXg6IG10Njc3OSkgaGF2ZSBhIG5ldyByZWdpc3RlciBjYWxsZWQgYnkgUkVHX01N VV9XUl9MRU4NCj4gPiB0byBpbXByb3ZlIHBlcmZvcm1hbmNlLg0KPiA+IFRoaXMgcGF0Y2ggYWRk IHRoaXMgcmVnaXN0ZXIgZGVmaW5pdGlvbi4NCj4gDQo+IFBsZWFzZSBiZSBtb3JlIHNwZWNpZmlj IHdoYXQgdGhpcyByZWdpc3RlciBpcyBhYm91dC4NCj4gDQpPSy4gdGhhbmtzLg0KV2UgY2FuIHVz ZSAiaGFzX3dyX2xlbiIgZmxhZyB0byBjb250cm9sIHdoZXRoZXIgd2UgbmVlZCB0byBzZXQgdGhl DQpyZWdpc3Rlci4gSWYgdGhlIHJlZ2lzdGVyIHVzZXMgZGVmYXVsdCB2YWx1ZSwgaW9tbXUgd2ls bCBzZW5kIGNvbW1hbmQgdG8NCkVNSSB3aXRob3V0IHJlc3RyaWN0aW9uLCB3aGVuIHRoZSBudW1i ZXIgb2YgY29tbWFuZHMgYmVjb21lIG1vcmUgYW5kDQptb3JlLCBpdCB3aWxsIGRyb3AgdGhlIEVN SSBwZXJmb3JtYW5jZS4gU28gd2hlbiBtb3JlIHRoYW4NCnRlbl9jb21tYW5kcyhkZWZhdWx0IHZh bHVlKSBkb24ndCBiZSBoYW5kbGVkIGZvciBFTUksIElPTU1VIHdpbGwgc3RvcA0Kc2VuZCBjb21t YW5kIHRvIEVNSSBmb3Iga2VlcGluZyBFTUkncyBwZXJmb3JtYWNlIGJ5IGVuYWJsaW5nIHdyaXRl DQp0aHJvdHRsaW5nIG1lY2hhbmlzbShiaXRbNV1bMjFdPTApIGluIE1NVV9XUl9MRU5fQ1RSTCBy ZWdpc3Rlci4NCg0KSSB3aWxsIHdyaXRlIGRlc2NyaXB0aW9uIGFib3ZlIHRvIGNvbW1pdCBtZXNz YWdlIGluIG5leHQgdmVyc2lvbg0KDQo+ID4gDQo+ID4gU2lnbmVkLW9mZi1ieTogQ2hhbyBIYW8g PGNoYW8uaGFvQG1lZGlhdGVrLmNvbT4NCj4gPiAtLS0NCj4gPiAgZHJpdmVycy9pb21tdS9tdGtf aW9tbXUuYyB8IDEwICsrKysrKysrKysNCj4gPiAgZHJpdmVycy9pb21tdS9tdGtfaW9tbXUuaCB8 ICAyICsrDQo+ID4gIDIgZmlsZXMgY2hhbmdlZCwgMTIgaW5zZXJ0aW9ucygrKQ0KPiA+IA0KPiA+ IGRpZmYgLS1naXQgYS9kcml2ZXJzL2lvbW11L210a19pb21tdS5jIGIvZHJpdmVycy9pb21tdS9t dGtfaW9tbXUuYw0KPiA+IGluZGV4IGE2ODdlOGRiMGU1MS4uYzcwNmJjYTY0ODdlIDEwMDY0NA0K PiA+IC0tLSBhL2RyaXZlcnMvaW9tbXUvbXRrX2lvbW11LmMNCj4gPiArKysgYi9kcml2ZXJzL2lv bW11L210a19pb21tdS5jDQo+ID4gQEAgLTQ2LDYgKzQ2LDggQEANCj4gPiAgI2RlZmluZSBGX01N VV9TVEFOREFSRF9BWElfTU9ERV9CSVQJCShCSVQoMykgfCBCSVQoMTkpKQ0KPiA+ICANCj4gPiAg I2RlZmluZSBSRUdfTU1VX0RDTV9ESVMJCQkJMHgwNTANCj4gPiArI2RlZmluZSBSRUdfTU1VX1dS X0xFTgkJCQkweDA1NA0KPiA+ICsjZGVmaW5lIEZfTU1VX1dSX1RIUk9UX0RJU19CSVQJCQkoQklU KDUpIHwgIEJJVCgyMSkpDQo+ID4gIA0KPiA+ICAjZGVmaW5lIFJFR19NTVVfQ1RSTF9SRUcJCQkw eDExMA0KPiA+ICAjZGVmaW5lIEZfTU1VX1RGX1BST1RfVE9fUFJPR1JBTV9BRERSCQkoMiA8PCA0 KQ0KPiA+IEBAIC01ODEsNiArNTgzLDEyIEBAIHN0YXRpYyBpbnQgbXRrX2lvbW11X2h3X2luaXQo Y29uc3Qgc3RydWN0IG10a19pb21tdV9kYXRhICpkYXRhKQ0KPiA+ICAJCXdyaXRlbF9yZWxheGVk KHJlZ3ZhbCwgZGF0YS0+YmFzZSArIFJFR19NTVVfVkxEX1BBX1JORyk7DQo+ID4gIAl9DQo+ID4g IAl3cml0ZWxfcmVsYXhlZCgwLCBkYXRhLT5iYXNlICsgUkVHX01NVV9EQ01fRElTKTsNCj4gPiAr CWlmIChkYXRhLT5wbGF0X2RhdGEtPmhhc193cl9sZW4pIHsNCj4gPiArCQkvKiB3cml0ZSBjb21t YW5kIHRocm90dGxpbmcgbW9kZSAqLw0KPiA+ICsJCXJlZ3ZhbCA9IHJlYWRsX3JlbGF4ZWQoZGF0 YS0+YmFzZSArIFJFR19NTVVfV1JfTEVOKTsNCj4gPiArCQlyZWd2YWwgJj0gfkZfTU1VX1dSX1RI Uk9UX0RJU19CSVQ7DQo+ID4gKwkJd3JpdGVsX3JlbGF4ZWQocmVndmFsLCBkYXRhLT5iYXNlICsg UkVHX01NVV9XUl9MRU4pOw0KPiA+ICsJfQ0KPiA+ICANCj4gPiAgCWlmIChkYXRhLT5wbGF0X2Rh dGEtPnJlc2V0X2F4aSkgew0KPiA+ICAJCS8qIFRoZSByZWdpc3RlciBpcyBjYWxsZWQgU1RBTkRB UkRfQVhJX01PREUgaW4gdGhpcyBjYXNlICovDQo+ID4gQEAgLTczNyw2ICs3NDUsNyBAQCBzdGF0 aWMgaW50IF9fbWF5YmVfdW51c2VkIG10a19pb21tdV9zdXNwZW5kKHN0cnVjdCBkZXZpY2UgKmRl dikNCj4gPiAgCXN0cnVjdCBtdGtfaW9tbXVfc3VzcGVuZF9yZWcgKnJlZyA9ICZkYXRhLT5yZWc7 DQo+ID4gIAl2b2lkIF9faW9tZW0gKmJhc2UgPSBkYXRhLT5iYXNlOw0KPiA+ICANCj4gPiArCXJl Zy0+d3JfbGVuID0gcmVhZGxfcmVsYXhlZChiYXNlICsgUkVHX01NVV9XUl9MRU4pOw0KPiANCj4g Q2FuIHdlIHJlYWQvd3JpdGUgdGhlIHJlZ2lzdGVyIHdpdGhvdXQgYW55IHNpZGUgZWZmZWN0IGFs dGhvdWdoIGhhcmR3YXJlIGhhcyBub3QNCj4gaW1wbGVtZW50ZWQgaXQgKCFoYXNfd3JfbGVuKT8N Cg0KSXQgZG9lc24ndCBoYXZlIHNpZGUgZWZmZWN0LiBCZWNhc3VlIGFsbCB0aGUgTVRLIHBsYXRm b3JtIGhhdmUgdGhlDQpyZWdpc3RlciBmb3IgaW9tbXUgSFcuIElmIHdlIG5lZWQgdG8gaGF2ZSBy ZXF1aXJlbWVudCBmb3IgcGVyZm9ybWFuY2UsDQp3ZSBjYW4gc2V0IGl0IGJ5IGhhc193cl9sZW4u DQpCdXQgSSdtIFNvcnJ5LCB0aGUgbmFtZSBvZiBmbGFnKGhhc193cl9sZW4pIGlzIG5vdCBleGFj dCwgSSB3aWxsIHJlbmFtZQ0KaXQgaW4gbmV4dCB2ZXJzaW9uLCBleDogIndyX3Rocm90X2VuIg0K DQo+IA0KPiANCj4gPiAgCXJlZy0+bWlzY19jdHJsID0gcmVhZGxfcmVsYXhlZChiYXNlICsgUkVH X01NVV9NSVNDX0NUUkwpOw0KPiA+ICAJcmVnLT5kY21fZGlzID0gcmVhZGxfcmVsYXhlZChiYXNl ICsgUkVHX01NVV9EQ01fRElTKTsNCj4gPiAgCXJlZy0+Y3RybF9yZWcgPSByZWFkbF9yZWxheGVk KGJhc2UgKyBSRUdfTU1VX0NUUkxfUkVHKTsNCj4gPiBAQCAtNzYxLDYgKzc3MCw3IEBAIHN0YXRp YyBpbnQgX19tYXliZV91bnVzZWQgbXRrX2lvbW11X3Jlc3VtZShzdHJ1Y3QgZGV2aWNlICpkZXYp DQo+ID4gIAkJZGV2X2VycihkYXRhLT5kZXYsICJGYWlsZWQgdG8gZW5hYmxlIGNsayglZCkgaW4g cmVzdW1lXG4iLCByZXQpOw0KPiA+ICAJCXJldHVybiByZXQ7DQo+ID4gIAl9DQo+ID4gKwl3cml0 ZWxfcmVsYXhlZChyZWctPndyX2xlbiwgYmFzZSArIFJFR19NTVVfV1JfTEVOKTsNCj4gPiAgCXdy aXRlbF9yZWxheGVkKHJlZy0+bWlzY19jdHJsLCBiYXNlICsgUkVHX01NVV9NSVNDX0NUUkwpOw0K PiA+ICAJd3JpdGVsX3JlbGF4ZWQocmVnLT5kY21fZGlzLCBiYXNlICsgUkVHX01NVV9EQ01fRElT KTsNCj4gPiAgCXdyaXRlbF9yZWxheGVkKHJlZy0+Y3RybF9yZWcsIGJhc2UgKyBSRUdfTU1VX0NU UkxfUkVHKTsNCj4gPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9pb21tdS9tdGtfaW9tbXUuaCBiL2Ry aXZlcnMvaW9tbXUvbXRrX2lvbW11LmgNCj4gPiBpbmRleCBkNTFmZjk5YzJjNzEuLjk5NzFjZWRk NzJlYSAxMDA2NDQNCj4gPiAtLS0gYS9kcml2ZXJzL2lvbW11L210a19pb21tdS5oDQo+ID4gKysr IGIvZHJpdmVycy9pb21tdS9tdGtfaW9tbXUuaA0KPiA+IEBAIC0yNSw2ICsyNSw3IEBAIHN0cnVj dCBtdGtfaW9tbXVfc3VzcGVuZF9yZWcgew0KPiA+ICAJdTMyCQkJCWludF9tYWluX2NvbnRyb2w7 DQo+ID4gIAl1MzIJCQkJaXZycF9wYWRkcjsNCj4gPiAgCXUzMgkJCQl2bGRfcGFfcm5nOw0KPiA+ ICsJdTMyCQkJCXdyX2xlbjsNCj4gPiAgfTsNCj4gPiAgDQo+ID4gIGVudW0gbXRrX2lvbW11X3Bs YXQgew0KPiA+IEBAIC00Myw2ICs0NCw3IEBAIHN0cnVjdCBtdGtfaW9tbXVfcGxhdF9kYXRhIHsN Cj4gPiAgCWJvb2wJCSAgICBoYXNfbWlzY19jdHJsOw0KPiA+ICAJYm9vbAkJICAgIGhhc19zdWJf Y29tbTsNCj4gPiAgCWJvb2wgICAgICAgICAgICAgICAgaGFzX3ZsZF9wYV9ybmc7DQo+ID4gKwli b29sICAgICAgICAgICAgICAgIGhhc193cl9sZW47DQo+IA0KPiBHaXZlbiB0aGUgZmFjdCB0aGF0 IHdlIGFyZSBhZGRpbmcgbW9yZSBhbmQgbW9yZSBwbGF0X2RhdGEgYm9vbCB2YWx1ZXMsIEkgdGhp bmsNCj4gaXQgd291bGQgbWFrZSBzZW5zZSB0byB1c2UgYSB1MzIgZmxhZ3MgcmVnaXN0ZXIgYW5k IGFkZCB0aGUgYXBwcm9wcmlhdGUgbWFjcm8NCj4gZGVmaW5pdGlvbnMgdG8gc2V0IGFuZCBjaGVj ayBmb3IgYSBmbGFnIHByZXNlbnQuDQoNClRoYW5rcyBmb3IgeW91ciBhZHZpY2UuDQpkbyB5b3Ug bWVhbiBsaWtlIHRoaXM6DQpzdHJ1Y3QgcGxhdF9mbGFnIHsNCg0KICAgICAgICAjZGVmaW5lICBI QVNfNEdCX01PREUgICBCSVQoMCkNCiAgICAgICAgI2RlZmluZSAgSEFTX0JDTEsgICAgICAgQklU KDEpDQogICAgICAgICNkZWZpbmUgIFJFU1RfQVhJICAgICAgIEJJVCgyKQ0KICAgICAgICAuLi4g Li4uDQoNCiAgICAgICAgdTMyIGZsYWc7DQp9Ow0KDQpzdHJ1Y3QgbXRrX2lvbW11X3BsYXRfZGF0 YSB7DQogICAgICAgIC4uLi4uLg0KICAgICAgICBzdHJ1Y3QgcGxhdF9mbGFnIGZsYWc7DQogICAg ICAgIC4uLi4uLg0KfTsNCg0KDQo+IFJlZ2FyZHMsDQo+IE1hdHRoaWFzDQo+IA0KPiA+ICAJYm9v bCAgICAgICAgICAgICAgICByZXNldF9heGk7DQo+ID4gIAl1MzIgICAgICAgICAgICAgICAgIGlu dl9zZWxfcmVnOw0KPiA+ICAJdW5zaWduZWQgY2hhciAgICAgICBsYXJiaWRfcmVtYXBbOF1bNF07 DQo+ID4gDQoNCg==