From: chao hao <Chao.Hao@mediatek.com>
To: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Joerg Roedel <joro@8bytes.org>, Rob Herring <robh+dt@kernel.org>,
"Yong Wu" <yong.wu@mediatek.com>,
Evan Green <evgreen@chromium.org>,
<iommu@lists.linux-foundation.org>, <devicetree@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-mediatek@lists.infradead.org>, <wsd_upstream@mediatek.com>,
FY Yang <fy.yang@mediatek.com>, Chao Hao <chao.hao@mediatek.com>
Subject: Re: [PATCH v5 04/10] iommu/mediatek: Setting MISC_CTRL register
Date: Tue, 30 Jun 2020 18:53:18 +0800 [thread overview]
Message-ID: <1593514398.2581.7.camel@mbjsdccf07> (raw)
In-Reply-To: <0e9ceba8-0cc4-44a1-148c-1c9a6b3844ce@gmail.com>
On Mon, 2020-06-29 at 11:28 +0200, Matthias Brugger wrote:
>
> On 29/06/2020 09:13, Chao Hao wrote:
> > Add F_MMU_IN_ORDER_WR_EN and F_MMU_STANDARD_AXI_MODE_BIT definition
> > in MISC_CTRL register.
> > F_MMU_STANDARD_AXI_MODE_BIT:
> > If we set F_MMU_STANDARD_AXI_MODE_BIT(bit[3][19] = 0, not follow
> > standard AXI protocol), iommu will send urgent read command firstly
> > compare with normal read command to improve performance.
>
> Can you please help me to understand the phrase. Sorry I'm not a AXI specialist.
> Does this mean that you will send a 'urgent read command' which is not described
> in the specifications instead of a normal read command?
ok.
iommu sends read command to next bus_node normally(we can name it to
cmd1), when cmd1 isn't handled by next bus_node, iommu has a urgent read
command is needed to be sent(we can name it to cmd2), iommu will send
cmd2 and replace cmd1. So cmd2 is handled by next bus_node firstly and
cmd2 will be handled secondly.
But for standard AXI protocol, it will ignore the priority of read
command and only be handled in order. So cmd2 is handled by next
bus_node after cmd1 is done.
>
> > F_MMU_IN_ORDER_WR_EN:
> > If we set F_MMU_IN_ORDER_WR_EN(bit[1][17] = 0, out-of-order write), iommu
> > will re-order write command and send more higher priority write command
> > instead of sending write command in order. The feature be controlled
> > by OUT_ORDER_EN macro definition.
> >
> > Cc: Matthias Brugger <matthias.bgg@gmail.com>
> > Suggested-by: Yong Wu <yong.wu@mediatek.com>
> > Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> > ---
> > drivers/iommu/mtk_iommu.c | 12 +++++++++++-
> > drivers/iommu/mtk_iommu.h | 1 +
> > 2 files changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > index 8f81df6cbe51..67b46b5d83d9 100644
> > --- a/drivers/iommu/mtk_iommu.c
> > +++ b/drivers/iommu/mtk_iommu.c
> > @@ -42,6 +42,9 @@
> > #define F_INVLD_EN1 BIT(1)
> >
> > #define REG_MMU_MISC_CTRL 0x048
> > +#define F_MMU_IN_ORDER_WR_EN (BIT(1) | BIT(17))
> > +#define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
>
> Wouldn't it make more sense to name it F_MMU_STANDARD_AXI_MODE_EN?
ok, you are right.
1'b1: follow standard axi protocol
>
> > +
> > #define REG_MMU_DCM_DIS 0x050
> >
> > #define REG_MMU_CTRL_REG 0x110
> > @@ -574,10 +577,17 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> > }
> > writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
> >
> > + regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
>
> We only need to read regval in the else branch.
ok, I got it. thanks
>
> > if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
> > /* The register is called STANDARD_AXI_MODE in this case */
> > - writel_relaxed(0, data->base + REG_MMU_MISC_CTRL);
> > + regval = 0;
> > + } else {
> > + /* For mm_iommu, it can improve performance by the setting */
> > + regval &= ~F_MMU_STANDARD_AXI_MODE_BIT;
> > + if (MTK_IOMMU_HAS_FLAG(data->plat_data, OUT_ORDER_EN))
> > + regval &= ~F_MMU_IN_ORDER_WR_EN;
> > }
> > + writel_relaxed(regval, data->base + REG_MMU_MISC_CTRL);
> >
> > if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
> > dev_name(data->dev), (void *)data)) {
> > diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> > index 7cc39f729263..4b780b651ef4 100644
> > --- a/drivers/iommu/mtk_iommu.h
> > +++ b/drivers/iommu/mtk_iommu.h
> > @@ -22,6 +22,7 @@
> > #define HAS_BCLK BIT(1)
> > #define HAS_VLD_PA_RNG BIT(2)
> > #define RESET_AXI BIT(3)
> > +#define OUT_ORDER_EN BIT(4)
>
> Maybe something like OUT_ORDER_WR_EN, to make clear that it's about the the
> write path.
>
ok, thanks for your advice.
> >
> > #define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> > ((((pdata)->flags) & (_x)) == (_x))
> >
next prev parent reply other threads:[~2020-06-30 10:54 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200629071310.1557-1-chao.hao@mediatek.com>
[not found] ` <20200629071310.1557-5-chao.hao@mediatek.com>
2020-06-29 9:28 ` [PATCH v5 04/10] iommu/mediatek: Setting MISC_CTRL register Matthias Brugger
2020-06-30 10:53 ` chao hao [this message]
2020-07-01 14:58 ` Matthias Brugger
2020-07-03 2:38 ` chao hao
[not found] ` <20200629071310.1557-8-chao.hao@mediatek.com>
2020-06-29 10:16 ` [PATCH v5 07/10] iommu/mediatek: Add REG_MMU_WR_LEN register definition Matthias Brugger
2020-06-30 10:59 ` chao hao
2020-07-01 15:00 ` Matthias Brugger
[not found] ` <20200629071310.1557-9-chao.hao@mediatek.com>
2020-06-29 10:17 ` [PATCH v5 08/10] iommu/mediatek: Extend protect pa alignment value Matthias Brugger
[not found] ` <20200629071310.1557-10-chao.hao@mediatek.com>
2020-06-29 10:28 ` [PATCH v5 09/10] iommu/mediatek: Modify MMU_CTRL register setting Matthias Brugger
2020-06-30 11:02 ` chao hao
[not found] ` <20200629071310.1557-11-chao.hao@mediatek.com>
2020-06-29 10:29 ` [PATCH v5 10/10] iommu/mediatek: Add mt6779 basic support Matthias Brugger
[not found] ` <20200629071310.1557-7-chao.hao@mediatek.com>
2020-06-30 10:55 ` [PATCH v5 06/10] iommu/mediatek: Add sub_comm id in translation fault Yong Wu
2020-06-30 11:07 ` chao hao
[not found] ` <20200629071310.1557-4-chao.hao@mediatek.com>
2020-06-29 9:11 ` [PATCH v5 03/10] iommu/mediatek: Modify the usage of mtk_iommu_plat_data structure Matthias Brugger
2020-06-30 10:56 ` Yong Wu
2020-06-30 11:55 ` chao hao
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=1593514398.2581.7.camel@mbjsdccf07 \
--to=chao.hao@mediatek.com \
--cc=devicetree@vger.kernel.org \
--cc=evgreen@chromium.org \
--cc=fy.yang@mediatek.com \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.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=wsd_upstream@mediatek.com \
--cc=yong.wu@mediatek.com \
/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;
as well as URLs for NNTP newsgroup(s).