From: Matthias Brugger <matthias.bgg@gmail.com>
To: chao hao <Chao.Hao@mediatek.com>
Cc: devicetree@vger.kernel.org, FY Yang <fy.yang@mediatek.com>,
wsd_upstream@mediatek.com, linux-kernel@vger.kernel.org,
Evan Green <evgreen@chromium.org>,
iommu@lists.linux-foundation.org,
Rob Herring <robh+dt@kernel.org>,
linux-mediatek@lists.infradead.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v5 04/10] iommu/mediatek: Setting MISC_CTRL register
Date: Wed, 1 Jul 2020 16:58:27 +0200 [thread overview]
Message-ID: <b9a68cda-bb2e-c9f3-4e44-c201df06c396@gmail.com> (raw)
In-Reply-To: <1593514398.2581.7.camel@mbjsdccf07>
On 30/06/2020 12:53, chao hao wrote:
> 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.
>
Thanks. So I propose change this part of the commit message to something like:
F_MMU_STANDARD_AXI_MODE_BIT:
If we set F_MMU_STANDARD_AXI_MODE_EN_MASK (bit[3][19] = 0, not follow standard
AXI protocol), the iommu will priorize sending of urgent read command over a
normal read command. This improves the performance.
>>
>>> 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.
F_MMU_IN_ORDER_WR_EN:
If we set F_MMU_IN_ORDER_WR_EN_MASK (bit[1][17] = 0, out-of-order write), the
iommu will re-order write commands and send the write command with higher
priority. Otherwise the sending of write commands will be done in order. The
feature is controlled by OUT_ORDER_WR_EN platform data flag.
>>>
>>> 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
>
What about
F_MMU_IN_ORDER_WR_EN_MASK
F_MMU_STANDARD_AXI_MODE_EN_MASK
Background is that we have to set/unset two bits to enable or disable the
feature, so it's a mask we have to apply to the register.
Regards,
Matthias
>>
>>> +
>>> #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))
>>>
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Matthias Brugger <matthias.bgg@gmail.com>
To: chao hao <Chao.Hao@mediatek.com>
Cc: devicetree@vger.kernel.org, FY Yang <fy.yang@mediatek.com>,
wsd_upstream@mediatek.com, Joerg Roedel <joro@8bytes.org>,
linux-kernel@vger.kernel.org, Evan Green <evgreen@chromium.org>,
iommu@lists.linux-foundation.org,
Rob Herring <robh+dt@kernel.org>,
linux-mediatek@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
Yong Wu <yong.wu@mediatek.com>
Subject: Re: [PATCH v5 04/10] iommu/mediatek: Setting MISC_CTRL register
Date: Wed, 1 Jul 2020 16:58:27 +0200 [thread overview]
Message-ID: <b9a68cda-bb2e-c9f3-4e44-c201df06c396@gmail.com> (raw)
In-Reply-To: <1593514398.2581.7.camel@mbjsdccf07>
On 30/06/2020 12:53, chao hao wrote:
> 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.
>
Thanks. So I propose change this part of the commit message to something like:
F_MMU_STANDARD_AXI_MODE_BIT:
If we set F_MMU_STANDARD_AXI_MODE_EN_MASK (bit[3][19] = 0, not follow standard
AXI protocol), the iommu will priorize sending of urgent read command over a
normal read command. This improves the performance.
>>
>>> 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.
F_MMU_IN_ORDER_WR_EN:
If we set F_MMU_IN_ORDER_WR_EN_MASK (bit[1][17] = 0, out-of-order write), the
iommu will re-order write commands and send the write command with higher
priority. Otherwise the sending of write commands will be done in order. The
feature is controlled by OUT_ORDER_WR_EN platform data flag.
>>>
>>> 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
>
What about
F_MMU_IN_ORDER_WR_EN_MASK
F_MMU_STANDARD_AXI_MODE_EN_MASK
Background is that we have to set/unset two bits to enable or disable the
feature, so it's a mask we have to apply to the register.
Regards,
Matthias
>>
>>> +
>>> #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))
>>>
>
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
WARNING: multiple messages have this Message-ID (diff)
From: Matthias Brugger <matthias.bgg@gmail.com>
To: chao hao <Chao.Hao@mediatek.com>
Cc: devicetree@vger.kernel.org, FY Yang <fy.yang@mediatek.com>,
wsd_upstream@mediatek.com, Joerg Roedel <joro@8bytes.org>,
linux-kernel@vger.kernel.org, Evan Green <evgreen@chromium.org>,
iommu@lists.linux-foundation.org,
Rob Herring <robh+dt@kernel.org>,
linux-mediatek@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
Yong Wu <yong.wu@mediatek.com>
Subject: Re: [PATCH v5 04/10] iommu/mediatek: Setting MISC_CTRL register
Date: Wed, 1 Jul 2020 16:58:27 +0200 [thread overview]
Message-ID: <b9a68cda-bb2e-c9f3-4e44-c201df06c396@gmail.com> (raw)
In-Reply-To: <1593514398.2581.7.camel@mbjsdccf07>
On 30/06/2020 12:53, chao hao wrote:
> 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.
>
Thanks. So I propose change this part of the commit message to something like:
F_MMU_STANDARD_AXI_MODE_BIT:
If we set F_MMU_STANDARD_AXI_MODE_EN_MASK (bit[3][19] = 0, not follow standard
AXI protocol), the iommu will priorize sending of urgent read command over a
normal read command. This improves the performance.
>>
>>> 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.
F_MMU_IN_ORDER_WR_EN:
If we set F_MMU_IN_ORDER_WR_EN_MASK (bit[1][17] = 0, out-of-order write), the
iommu will re-order write commands and send the write command with higher
priority. Otherwise the sending of write commands will be done in order. The
feature is controlled by OUT_ORDER_WR_EN platform data flag.
>>>
>>> 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
>
What about
F_MMU_IN_ORDER_WR_EN_MASK
F_MMU_STANDARD_AXI_MODE_EN_MASK
Background is that we have to set/unset two bits to enable or disable the
feature, so it's a mask we have to apply to the register.
Regards,
Matthias
>>
>>> +
>>> #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))
>>>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Matthias Brugger <matthias.bgg@gmail.com>
To: chao hao <Chao.Hao@mediatek.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>
Subject: Re: [PATCH v5 04/10] iommu/mediatek: Setting MISC_CTRL register
Date: Wed, 1 Jul 2020 16:58:27 +0200 [thread overview]
Message-ID: <b9a68cda-bb2e-c9f3-4e44-c201df06c396@gmail.com> (raw)
In-Reply-To: <1593514398.2581.7.camel@mbjsdccf07>
On 30/06/2020 12:53, chao hao wrote:
> 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.
>
Thanks. So I propose change this part of the commit message to something like:
F_MMU_STANDARD_AXI_MODE_BIT:
If we set F_MMU_STANDARD_AXI_MODE_EN_MASK (bit[3][19] = 0, not follow standard
AXI protocol), the iommu will priorize sending of urgent read command over a
normal read command. This improves the performance.
>>
>>> 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.
F_MMU_IN_ORDER_WR_EN:
If we set F_MMU_IN_ORDER_WR_EN_MASK (bit[1][17] = 0, out-of-order write), the
iommu will re-order write commands and send the write command with higher
priority. Otherwise the sending of write commands will be done in order. The
feature is controlled by OUT_ORDER_WR_EN platform data flag.
>>>
>>> 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
>
What about
F_MMU_IN_ORDER_WR_EN_MASK
F_MMU_STANDARD_AXI_MODE_EN_MASK
Background is that we have to set/unset two bits to enable or disable the
feature, so it's a mask we have to apply to the register.
Regards,
Matthias
>>
>>> +
>>> #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-07-01 14:58 UTC|newest]
Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-29 7:13 [PATCH v5 00/10] MT6779 IOMMU SUPPORT Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 7:13 ` [PATCH v5 01/10] dt-bindings: mediatek: Add bindings for MT6779 Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 7:13 ` [PATCH v5 02/10] iommu/mediatek: Rename the register STANDARD_AXI_MODE(0x48) to MISC_CTRL Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-07-01 2:17 ` Yong Wu
2020-07-01 2:17 ` Yong Wu
2020-07-03 2:36 ` chao hao
2020-07-03 2:36 ` chao hao
2020-06-29 7:13 ` [PATCH v5 03/10] iommu/mediatek: Modify the usage of mtk_iommu_plat_data structure Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 9:11 ` Matthias Brugger
2020-06-29 9:11 ` Matthias Brugger
2020-06-29 9:11 ` Matthias Brugger
2020-06-29 9:11 ` Matthias Brugger
2020-06-30 10:56 ` Yong Wu
2020-06-30 10:56 ` Yong Wu
2020-06-30 10:56 ` Yong Wu
2020-06-30 10:56 ` Yong Wu
2020-06-30 11:55 ` chao hao
2020-06-30 11:55 ` chao hao
2020-06-30 11:55 ` chao hao
2020-06-30 11:55 ` chao hao
2020-06-29 7:13 ` [PATCH v5 04/10] iommu/mediatek: Setting MISC_CTRL register Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 9:28 ` Matthias Brugger
2020-06-29 9:28 ` Matthias Brugger
2020-06-29 9:28 ` Matthias Brugger
2020-06-29 9:28 ` Matthias Brugger
2020-06-30 10:53 ` chao hao
2020-06-30 10:53 ` chao hao
2020-06-30 10:53 ` chao hao
2020-06-30 10:53 ` chao hao
2020-07-01 14:58 ` Matthias Brugger [this message]
2020-07-01 14:58 ` Matthias Brugger
2020-07-01 14:58 ` Matthias Brugger
2020-07-01 14:58 ` Matthias Brugger
2020-07-03 2:38 ` chao hao
2020-07-03 2:38 ` chao hao
2020-07-03 2:38 ` chao hao
2020-07-03 2:38 ` chao hao
2020-06-29 7:13 ` [PATCH v5 05/10] iommu/mediatek: Move inv_sel_reg into the plat_data Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 7:13 ` [PATCH v5 06/10] iommu/mediatek: Add sub_comm id in translation fault Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-30 10:55 ` Yong Wu
2020-06-30 10:55 ` Yong Wu
2020-06-30 10:55 ` Yong Wu
2020-06-30 10:55 ` Yong Wu
2020-06-30 11:07 ` chao hao
2020-06-30 11:07 ` chao hao
2020-06-30 11:07 ` chao hao
2020-06-30 11:07 ` chao hao
2020-06-29 7:13 ` [PATCH v5 07/10] iommu/mediatek: Add REG_MMU_WR_LEN register definition Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 10:16 ` Matthias Brugger
2020-06-29 10:16 ` Matthias Brugger
2020-06-29 10:16 ` Matthias Brugger
2020-06-29 10:16 ` Matthias Brugger
2020-06-30 10:59 ` chao hao
2020-06-30 10:59 ` chao hao
2020-06-30 10:59 ` chao hao
2020-06-30 10:59 ` chao hao
2020-07-01 15:00 ` Matthias Brugger
2020-07-01 15:00 ` Matthias Brugger
2020-07-01 15:00 ` Matthias Brugger
2020-07-01 15:00 ` Matthias Brugger
2020-06-29 7:13 ` [PATCH v5 08/10] iommu/mediatek: Extend protect pa alignment value Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 10:17 ` Matthias Brugger
2020-06-29 10:17 ` Matthias Brugger
2020-06-29 10:17 ` Matthias Brugger
2020-06-29 10:17 ` Matthias Brugger
2020-06-29 7:13 ` [PATCH v5 09/10] iommu/mediatek: Modify MMU_CTRL register setting Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 10:28 ` Matthias Brugger
2020-06-29 10:28 ` Matthias Brugger
2020-06-29 10:28 ` Matthias Brugger
2020-06-29 10:28 ` Matthias Brugger
2020-06-30 11:02 ` chao hao
2020-06-30 11:02 ` chao hao
2020-06-30 11:02 ` chao hao
2020-06-30 11:02 ` chao hao
2020-06-29 7:13 ` [PATCH v5 10/10] iommu/mediatek: Add mt6779 basic support Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 10:29 ` Matthias Brugger
2020-06-29 10:29 ` Matthias Brugger
2020-06-29 10:29 ` Matthias Brugger
2020-06-29 10:29 ` Matthias Brugger
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=b9a68cda-bb2e-c9f3-4e44-c201df06c396@gmail.com \
--to=matthias.bgg@gmail.com \
--cc=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=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=robh+dt@kernel.org \
--cc=wsd_upstream@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.