From: chao hao <Chao.Hao@mediatek.com>
To: Yong Wu <yong.wu@mediatek.com>
Cc: devicetree@vger.kernel.org, FY Yang <fy.yang@mediatek.com>,
wsd_upstream@mediatek.com, linux-kernel@vger.kernel.org,
iommu@lists.linux-foundation.org,
Rob Herring <robh+dt@kernel.org>,
linux-mediatek@lists.infradead.org,
Matthias Brugger <matthias.bgg@gmail.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 5/7] iommu/mediatek: Add sub_comm id in translation fault
Date: Thu, 18 Jun 2020 19:44:16 +0800 [thread overview]
Message-ID: <1592480656.12647.2.camel@mbjsdccf07> (raw)
In-Reply-To: <1592392265.20080.11.camel@mhfsdcap03>
On Wed, 2020-06-17 at 19:11 +0800, Yong Wu wrote:
> Hi Matthias,
>
> Thanks very much for your review.
>
> On Wed, 2020-06-17 at 11:17 +0200, Matthias Brugger wrote:
> >
> > On 17/06/2020 05:00, Chao Hao wrote:
> > > The max larb number that a iommu HW support is 8(larb0~larb7 in the below
> > > diagram).
> > > If the larb's number is over 8, we use a sub_common for merging
> > > several larbs into one larb. At this case, we will extend larb_id:
> > > bit[11:9] means common-id;
> > > bit[8:7] means subcommon-id;
> > > From these two variable, we could get the real larb number when
> > > translation fault happen.
> > > The diagram is as below:
> > > EMI
> > > |
> > > IOMMU
> > > |
> > > -----------------
> > > | |
> > > common1 common0
> > > | |
> > > -----------------
> > > |
> > > smi common
> > > |
> > > ------------------------------------
> > > | | | | | |
> > > 3'd0 3'd1 3'd2 3'd3 ... 3'd7 <-common_id(max is 8)
> > > | | | | | |
> > > Larb0 Larb1 | Larb3 ... Larb7
> > > |
> > > smi sub common
> > > |
> > > --------------------------
> > > | | | |
> > > 2'd0 2'd1 2'd2 2'd3 <-sub_common_id(max is 4)
> > > | | | |
> > > Larb8 Larb9 Larb10 Larb11
> > >
> > > In this patch we extern larb_remap[] to larb_remap[8][4] for this.
> >
> > extern -> extend
> >
> > > larb_remap[x][y]: x mean common-id above, y means subcommon_id above.
> >
> > mean -> means
> >
> > >
> > > We can also distinguish if the M4U HW has sub_common by has_sub_comm
> > > property.
> > >
> > > Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> > > Reviewed-by: Yong Wu <yong.wu@mediatek.com>
> > > ---
> > > drivers/iommu/mtk_iommu.c | 20 +++++++++++++-------
> > > drivers/iommu/mtk_iommu.h | 3 ++-
> > > 2 files changed, 15 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > > index f23919feba4e..a687e8db0e51 100644
> > > --- a/drivers/iommu/mtk_iommu.c
> > > +++ b/drivers/iommu/mtk_iommu.c
> > > @@ -91,6 +91,8 @@
> > > #define REG_MMU1_INVLD_PA 0x148
> > > #define REG_MMU0_INT_ID 0x150
> > > #define REG_MMU1_INT_ID 0x154
> > > +#define F_MMU_INT_ID_COMM_ID(a) (((a) >> 9) & 0x7)
> > > +#define F_MMU_INT_ID_SUB_COMM_ID(a) (((a) >> 7) & 0x3)
> > > #define F_MMU_INT_ID_LARB_ID(a) (((a) >> 7) & 0x7)
> > > #define F_MMU_INT_ID_PORT_ID(a) (((a) >> 2) & 0x1f)
> > >
> > > @@ -229,7 +231,7 @@ static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
> > > struct mtk_iommu_data *data = dev_id;
> > > struct mtk_iommu_domain *dom = data->m4u_dom;
> > > u32 int_state, regval, fault_iova, fault_pa;
> > > - unsigned int fault_larb, fault_port;
> > > + unsigned int fault_larb, fault_port, sub_comm = 0;
> > > bool layer, write;
> > >
> > > /* Read error info from registers */
> > > @@ -245,10 +247,14 @@ static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
> > > }
> > > layer = fault_iova & F_MMU_FAULT_VA_LAYER_BIT;
> > > write = fault_iova & F_MMU_FAULT_VA_WRITE_BIT;
> > > - fault_larb = F_MMU_INT_ID_LARB_ID(regval);
> > > fault_port = F_MMU_INT_ID_PORT_ID(regval);
> > > -
> > > - fault_larb = data->plat_data->larbid_remap[fault_larb];
> > > + if (data->plat_data->has_sub_comm) {
> > > + fault_larb = F_MMU_INT_ID_COMM_ID(regval);
> > > + sub_comm = F_MMU_INT_ID_SUB_COMM_ID(regval);
> > > + } else {
> > > + fault_larb = F_MMU_INT_ID_LARB_ID(regval);
> > > + }
> > > + fault_larb = data->plat_data->larbid_remap[fault_larb][sub_comm];
> > >
> > > if (report_iommu_fault(&dom->domain, data->dev, fault_iova,
> > > write ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ)) {
> > > @@ -778,7 +784,7 @@ static const struct mtk_iommu_plat_data mt2712_data = {
> > > .has_bclk = true,
> > > .has_vld_pa_rng = true,
> > > .inv_sel_reg = REG_MMU_INV_SEL_GEN1,
> > > - .larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
> > > + .larbid_remap = {{0}, {1}, {2}, {3}, {4}, {5}, {6}, {7}},
> > > };
> > >
> > > static const struct mtk_iommu_plat_data mt8173_data = {
> > > @@ -787,14 +793,14 @@ static const struct mtk_iommu_plat_data mt8173_data = {
> > > .has_bclk = true,
> > > .reset_axi = true,
> > > .inv_sel_reg = REG_MMU_INV_SEL_GEN1,
> > > - .larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
> > > + .larbid_remap = {{0}, {1}, {2}, {3}, {4}, {5}}, /* Linear mapping. */
> > > };
> > >
> > > static const struct mtk_iommu_plat_data mt8183_data = {
> > > .m4u_plat = M4U_MT8183,
> > > .reset_axi = true,
> > > .inv_sel_reg = REG_MMU_INV_SEL_GEN1,
> > > - .larbid_remap = {0, 4, 5, 6, 7, 2, 3, 1},
> > > + .larbid_remap = {{0}, {4}, {5}, {6}, {7}, {2}, {3}, {1}},
> > > };
> > >
> > > static const struct of_device_id mtk_iommu_of_ids[] = {
> > > diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> > > index afd7a2de5c1e..d51ff99c2c71 100644
> > > --- a/drivers/iommu/mtk_iommu.h
> > > +++ b/drivers/iommu/mtk_iommu.h
> > > @@ -41,10 +41,11 @@ struct mtk_iommu_plat_data {
> > > /* HW will use the EMI clock if there isn't the "bclk". */
> > > bool has_bclk;
> > > bool has_misc_ctrl;
> > > + bool has_sub_comm;
> > > bool has_vld_pa_rng;
> > > bool reset_axi;
> > > u32 inv_sel_reg;
> > > - unsigned char larbid_remap[MTK_LARB_NR_MAX];
> > > + unsigned char larbid_remap[8][4];
> >
> > MTK_LARB_NR_MAX is 16, why do you decrease it to 8?
>
> From the diagram above, the max number of the larbs that could connected
> with a IOMMU HW is 8. thus, 8 is right here for each a IOMMU HW.
>
> as I commented when v3. mt2712 have the larbs over 8 since it has 2
> IOMMU HWes.
>
> and MTK_LARB_NR_MAX means the max larbs number that this SoC support.
> Keep its value as is.
>
>
> > Should we use a define for the subcommon as well?
> >
> > Regards,
> > Matthias
> >
Hi Matthias and yong,
Thanks very much for your review.
HW diagram is as belove and whether we need to use macro definitions to
show it, maybe more clearer? like this:
#define LARB_COMMON_MAX 8
#define LARB_SUB_COMMON_MAX 4
unsigned char larbid_remap[LARB_COMMON_MAX][LARB_SUB_COMMON_MAX];
>
> > > };
> > >
> > > struct mtk_iommu_domain;
> > >
>
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: chao hao <Chao.Hao@mediatek.com>
To: Yong Wu <yong.wu@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, iommu@lists.linux-foundation.org,
Rob Herring <robh+dt@kernel.org>,
linux-mediatek@lists.infradead.org,
Matthias Brugger <matthias.bgg@gmail.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 5/7] iommu/mediatek: Add sub_comm id in translation fault
Date: Thu, 18 Jun 2020 19:44:16 +0800 [thread overview]
Message-ID: <1592480656.12647.2.camel@mbjsdccf07> (raw)
In-Reply-To: <1592392265.20080.11.camel@mhfsdcap03>
On Wed, 2020-06-17 at 19:11 +0800, Yong Wu wrote:
> Hi Matthias,
>
> Thanks very much for your review.
>
> On Wed, 2020-06-17 at 11:17 +0200, Matthias Brugger wrote:
> >
> > On 17/06/2020 05:00, Chao Hao wrote:
> > > The max larb number that a iommu HW support is 8(larb0~larb7 in the below
> > > diagram).
> > > If the larb's number is over 8, we use a sub_common for merging
> > > several larbs into one larb. At this case, we will extend larb_id:
> > > bit[11:9] means common-id;
> > > bit[8:7] means subcommon-id;
> > > From these two variable, we could get the real larb number when
> > > translation fault happen.
> > > The diagram is as below:
> > > EMI
> > > |
> > > IOMMU
> > > |
> > > -----------------
> > > | |
> > > common1 common0
> > > | |
> > > -----------------
> > > |
> > > smi common
> > > |
> > > ------------------------------------
> > > | | | | | |
> > > 3'd0 3'd1 3'd2 3'd3 ... 3'd7 <-common_id(max is 8)
> > > | | | | | |
> > > Larb0 Larb1 | Larb3 ... Larb7
> > > |
> > > smi sub common
> > > |
> > > --------------------------
> > > | | | |
> > > 2'd0 2'd1 2'd2 2'd3 <-sub_common_id(max is 4)
> > > | | | |
> > > Larb8 Larb9 Larb10 Larb11
> > >
> > > In this patch we extern larb_remap[] to larb_remap[8][4] for this.
> >
> > extern -> extend
> >
> > > larb_remap[x][y]: x mean common-id above, y means subcommon_id above.
> >
> > mean -> means
> >
> > >
> > > We can also distinguish if the M4U HW has sub_common by has_sub_comm
> > > property.
> > >
> > > Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> > > Reviewed-by: Yong Wu <yong.wu@mediatek.com>
> > > ---
> > > drivers/iommu/mtk_iommu.c | 20 +++++++++++++-------
> > > drivers/iommu/mtk_iommu.h | 3 ++-
> > > 2 files changed, 15 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > > index f23919feba4e..a687e8db0e51 100644
> > > --- a/drivers/iommu/mtk_iommu.c
> > > +++ b/drivers/iommu/mtk_iommu.c
> > > @@ -91,6 +91,8 @@
> > > #define REG_MMU1_INVLD_PA 0x148
> > > #define REG_MMU0_INT_ID 0x150
> > > #define REG_MMU1_INT_ID 0x154
> > > +#define F_MMU_INT_ID_COMM_ID(a) (((a) >> 9) & 0x7)
> > > +#define F_MMU_INT_ID_SUB_COMM_ID(a) (((a) >> 7) & 0x3)
> > > #define F_MMU_INT_ID_LARB_ID(a) (((a) >> 7) & 0x7)
> > > #define F_MMU_INT_ID_PORT_ID(a) (((a) >> 2) & 0x1f)
> > >
> > > @@ -229,7 +231,7 @@ static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
> > > struct mtk_iommu_data *data = dev_id;
> > > struct mtk_iommu_domain *dom = data->m4u_dom;
> > > u32 int_state, regval, fault_iova, fault_pa;
> > > - unsigned int fault_larb, fault_port;
> > > + unsigned int fault_larb, fault_port, sub_comm = 0;
> > > bool layer, write;
> > >
> > > /* Read error info from registers */
> > > @@ -245,10 +247,14 @@ static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
> > > }
> > > layer = fault_iova & F_MMU_FAULT_VA_LAYER_BIT;
> > > write = fault_iova & F_MMU_FAULT_VA_WRITE_BIT;
> > > - fault_larb = F_MMU_INT_ID_LARB_ID(regval);
> > > fault_port = F_MMU_INT_ID_PORT_ID(regval);
> > > -
> > > - fault_larb = data->plat_data->larbid_remap[fault_larb];
> > > + if (data->plat_data->has_sub_comm) {
> > > + fault_larb = F_MMU_INT_ID_COMM_ID(regval);
> > > + sub_comm = F_MMU_INT_ID_SUB_COMM_ID(regval);
> > > + } else {
> > > + fault_larb = F_MMU_INT_ID_LARB_ID(regval);
> > > + }
> > > + fault_larb = data->plat_data->larbid_remap[fault_larb][sub_comm];
> > >
> > > if (report_iommu_fault(&dom->domain, data->dev, fault_iova,
> > > write ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ)) {
> > > @@ -778,7 +784,7 @@ static const struct mtk_iommu_plat_data mt2712_data = {
> > > .has_bclk = true,
> > > .has_vld_pa_rng = true,
> > > .inv_sel_reg = REG_MMU_INV_SEL_GEN1,
> > > - .larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
> > > + .larbid_remap = {{0}, {1}, {2}, {3}, {4}, {5}, {6}, {7}},
> > > };
> > >
> > > static const struct mtk_iommu_plat_data mt8173_data = {
> > > @@ -787,14 +793,14 @@ static const struct mtk_iommu_plat_data mt8173_data = {
> > > .has_bclk = true,
> > > .reset_axi = true,
> > > .inv_sel_reg = REG_MMU_INV_SEL_GEN1,
> > > - .larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
> > > + .larbid_remap = {{0}, {1}, {2}, {3}, {4}, {5}}, /* Linear mapping. */
> > > };
> > >
> > > static const struct mtk_iommu_plat_data mt8183_data = {
> > > .m4u_plat = M4U_MT8183,
> > > .reset_axi = true,
> > > .inv_sel_reg = REG_MMU_INV_SEL_GEN1,
> > > - .larbid_remap = {0, 4, 5, 6, 7, 2, 3, 1},
> > > + .larbid_remap = {{0}, {4}, {5}, {6}, {7}, {2}, {3}, {1}},
> > > };
> > >
> > > static const struct of_device_id mtk_iommu_of_ids[] = {
> > > diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> > > index afd7a2de5c1e..d51ff99c2c71 100644
> > > --- a/drivers/iommu/mtk_iommu.h
> > > +++ b/drivers/iommu/mtk_iommu.h
> > > @@ -41,10 +41,11 @@ struct mtk_iommu_plat_data {
> > > /* HW will use the EMI clock if there isn't the "bclk". */
> > > bool has_bclk;
> > > bool has_misc_ctrl;
> > > + bool has_sub_comm;
> > > bool has_vld_pa_rng;
> > > bool reset_axi;
> > > u32 inv_sel_reg;
> > > - unsigned char larbid_remap[MTK_LARB_NR_MAX];
> > > + unsigned char larbid_remap[8][4];
> >
> > MTK_LARB_NR_MAX is 16, why do you decrease it to 8?
>
> From the diagram above, the max number of the larbs that could connected
> with a IOMMU HW is 8. thus, 8 is right here for each a IOMMU HW.
>
> as I commented when v3. mt2712 have the larbs over 8 since it has 2
> IOMMU HWes.
>
> and MTK_LARB_NR_MAX means the max larbs number that this SoC support.
> Keep its value as is.
>
>
> > Should we use a define for the subcommon as well?
> >
> > Regards,
> > Matthias
> >
Hi Matthias and yong,
Thanks very much for your review.
HW diagram is as belove and whether we need to use macro definitions to
show it, maybe more clearer? like this:
#define LARB_COMMON_MAX 8
#define LARB_SUB_COMMON_MAX 4
unsigned char larbid_remap[LARB_COMMON_MAX][LARB_SUB_COMMON_MAX];
>
> > > };
> > >
> > > struct mtk_iommu_domain;
> > >
>
>
_______________________________________________
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: chao hao <Chao.Hao@mediatek.com>
To: Yong Wu <yong.wu@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, iommu@lists.linux-foundation.org,
Rob Herring <robh+dt@kernel.org>,
linux-mediatek@lists.infradead.org,
Matthias Brugger <matthias.bgg@gmail.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 5/7] iommu/mediatek: Add sub_comm id in translation fault
Date: Thu, 18 Jun 2020 19:44:16 +0800 [thread overview]
Message-ID: <1592480656.12647.2.camel@mbjsdccf07> (raw)
In-Reply-To: <1592392265.20080.11.camel@mhfsdcap03>
On Wed, 2020-06-17 at 19:11 +0800, Yong Wu wrote:
> Hi Matthias,
>
> Thanks very much for your review.
>
> On Wed, 2020-06-17 at 11:17 +0200, Matthias Brugger wrote:
> >
> > On 17/06/2020 05:00, Chao Hao wrote:
> > > The max larb number that a iommu HW support is 8(larb0~larb7 in the below
> > > diagram).
> > > If the larb's number is over 8, we use a sub_common for merging
> > > several larbs into one larb. At this case, we will extend larb_id:
> > > bit[11:9] means common-id;
> > > bit[8:7] means subcommon-id;
> > > From these two variable, we could get the real larb number when
> > > translation fault happen.
> > > The diagram is as below:
> > > EMI
> > > |
> > > IOMMU
> > > |
> > > -----------------
> > > | |
> > > common1 common0
> > > | |
> > > -----------------
> > > |
> > > smi common
> > > |
> > > ------------------------------------
> > > | | | | | |
> > > 3'd0 3'd1 3'd2 3'd3 ... 3'd7 <-common_id(max is 8)
> > > | | | | | |
> > > Larb0 Larb1 | Larb3 ... Larb7
> > > |
> > > smi sub common
> > > |
> > > --------------------------
> > > | | | |
> > > 2'd0 2'd1 2'd2 2'd3 <-sub_common_id(max is 4)
> > > | | | |
> > > Larb8 Larb9 Larb10 Larb11
> > >
> > > In this patch we extern larb_remap[] to larb_remap[8][4] for this.
> >
> > extern -> extend
> >
> > > larb_remap[x][y]: x mean common-id above, y means subcommon_id above.
> >
> > mean -> means
> >
> > >
> > > We can also distinguish if the M4U HW has sub_common by has_sub_comm
> > > property.
> > >
> > > Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> > > Reviewed-by: Yong Wu <yong.wu@mediatek.com>
> > > ---
> > > drivers/iommu/mtk_iommu.c | 20 +++++++++++++-------
> > > drivers/iommu/mtk_iommu.h | 3 ++-
> > > 2 files changed, 15 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > > index f23919feba4e..a687e8db0e51 100644
> > > --- a/drivers/iommu/mtk_iommu.c
> > > +++ b/drivers/iommu/mtk_iommu.c
> > > @@ -91,6 +91,8 @@
> > > #define REG_MMU1_INVLD_PA 0x148
> > > #define REG_MMU0_INT_ID 0x150
> > > #define REG_MMU1_INT_ID 0x154
> > > +#define F_MMU_INT_ID_COMM_ID(a) (((a) >> 9) & 0x7)
> > > +#define F_MMU_INT_ID_SUB_COMM_ID(a) (((a) >> 7) & 0x3)
> > > #define F_MMU_INT_ID_LARB_ID(a) (((a) >> 7) & 0x7)
> > > #define F_MMU_INT_ID_PORT_ID(a) (((a) >> 2) & 0x1f)
> > >
> > > @@ -229,7 +231,7 @@ static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
> > > struct mtk_iommu_data *data = dev_id;
> > > struct mtk_iommu_domain *dom = data->m4u_dom;
> > > u32 int_state, regval, fault_iova, fault_pa;
> > > - unsigned int fault_larb, fault_port;
> > > + unsigned int fault_larb, fault_port, sub_comm = 0;
> > > bool layer, write;
> > >
> > > /* Read error info from registers */
> > > @@ -245,10 +247,14 @@ static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
> > > }
> > > layer = fault_iova & F_MMU_FAULT_VA_LAYER_BIT;
> > > write = fault_iova & F_MMU_FAULT_VA_WRITE_BIT;
> > > - fault_larb = F_MMU_INT_ID_LARB_ID(regval);
> > > fault_port = F_MMU_INT_ID_PORT_ID(regval);
> > > -
> > > - fault_larb = data->plat_data->larbid_remap[fault_larb];
> > > + if (data->plat_data->has_sub_comm) {
> > > + fault_larb = F_MMU_INT_ID_COMM_ID(regval);
> > > + sub_comm = F_MMU_INT_ID_SUB_COMM_ID(regval);
> > > + } else {
> > > + fault_larb = F_MMU_INT_ID_LARB_ID(regval);
> > > + }
> > > + fault_larb = data->plat_data->larbid_remap[fault_larb][sub_comm];
> > >
> > > if (report_iommu_fault(&dom->domain, data->dev, fault_iova,
> > > write ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ)) {
> > > @@ -778,7 +784,7 @@ static const struct mtk_iommu_plat_data mt2712_data = {
> > > .has_bclk = true,
> > > .has_vld_pa_rng = true,
> > > .inv_sel_reg = REG_MMU_INV_SEL_GEN1,
> > > - .larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
> > > + .larbid_remap = {{0}, {1}, {2}, {3}, {4}, {5}, {6}, {7}},
> > > };
> > >
> > > static const struct mtk_iommu_plat_data mt8173_data = {
> > > @@ -787,14 +793,14 @@ static const struct mtk_iommu_plat_data mt8173_data = {
> > > .has_bclk = true,
> > > .reset_axi = true,
> > > .inv_sel_reg = REG_MMU_INV_SEL_GEN1,
> > > - .larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
> > > + .larbid_remap = {{0}, {1}, {2}, {3}, {4}, {5}}, /* Linear mapping. */
> > > };
> > >
> > > static const struct mtk_iommu_plat_data mt8183_data = {
> > > .m4u_plat = M4U_MT8183,
> > > .reset_axi = true,
> > > .inv_sel_reg = REG_MMU_INV_SEL_GEN1,
> > > - .larbid_remap = {0, 4, 5, 6, 7, 2, 3, 1},
> > > + .larbid_remap = {{0}, {4}, {5}, {6}, {7}, {2}, {3}, {1}},
> > > };
> > >
> > > static const struct of_device_id mtk_iommu_of_ids[] = {
> > > diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> > > index afd7a2de5c1e..d51ff99c2c71 100644
> > > --- a/drivers/iommu/mtk_iommu.h
> > > +++ b/drivers/iommu/mtk_iommu.h
> > > @@ -41,10 +41,11 @@ struct mtk_iommu_plat_data {
> > > /* HW will use the EMI clock if there isn't the "bclk". */
> > > bool has_bclk;
> > > bool has_misc_ctrl;
> > > + bool has_sub_comm;
> > > bool has_vld_pa_rng;
> > > bool reset_axi;
> > > u32 inv_sel_reg;
> > > - unsigned char larbid_remap[MTK_LARB_NR_MAX];
> > > + unsigned char larbid_remap[8][4];
> >
> > MTK_LARB_NR_MAX is 16, why do you decrease it to 8?
>
> From the diagram above, the max number of the larbs that could connected
> with a IOMMU HW is 8. thus, 8 is right here for each a IOMMU HW.
>
> as I commented when v3. mt2712 have the larbs over 8 since it has 2
> IOMMU HWes.
>
> and MTK_LARB_NR_MAX means the max larbs number that this SoC support.
> Keep its value as is.
>
>
> > Should we use a define for the subcommon as well?
> >
> > Regards,
> > Matthias
> >
Hi Matthias and yong,
Thanks very much for your review.
HW diagram is as belove and whether we need to use macro definitions to
show it, maybe more clearer? like this:
#define LARB_COMMON_MAX 8
#define LARB_SUB_COMMON_MAX 4
unsigned char larbid_remap[LARB_COMMON_MAX][LARB_SUB_COMMON_MAX];
>
> > > };
> > >
> > > struct mtk_iommu_domain;
> > >
>
>
_______________________________________________
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: chao hao <Chao.Hao@mediatek.com>
To: Yong Wu <yong.wu@mediatek.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>,
Joerg Roedel <joro@8bytes.org>, Rob Herring <robh+dt@kernel.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 v4 5/7] iommu/mediatek: Add sub_comm id in translation fault
Date: Thu, 18 Jun 2020 19:44:16 +0800 [thread overview]
Message-ID: <1592480656.12647.2.camel@mbjsdccf07> (raw)
In-Reply-To: <1592392265.20080.11.camel@mhfsdcap03>
On Wed, 2020-06-17 at 19:11 +0800, Yong Wu wrote:
> Hi Matthias,
>
> Thanks very much for your review.
>
> On Wed, 2020-06-17 at 11:17 +0200, Matthias Brugger wrote:
> >
> > On 17/06/2020 05:00, Chao Hao wrote:
> > > The max larb number that a iommu HW support is 8(larb0~larb7 in the below
> > > diagram).
> > > If the larb's number is over 8, we use a sub_common for merging
> > > several larbs into one larb. At this case, we will extend larb_id:
> > > bit[11:9] means common-id;
> > > bit[8:7] means subcommon-id;
> > > From these two variable, we could get the real larb number when
> > > translation fault happen.
> > > The diagram is as below:
> > > EMI
> > > |
> > > IOMMU
> > > |
> > > -----------------
> > > | |
> > > common1 common0
> > > | |
> > > -----------------
> > > |
> > > smi common
> > > |
> > > ------------------------------------
> > > | | | | | |
> > > 3'd0 3'd1 3'd2 3'd3 ... 3'd7 <-common_id(max is 8)
> > > | | | | | |
> > > Larb0 Larb1 | Larb3 ... Larb7
> > > |
> > > smi sub common
> > > |
> > > --------------------------
> > > | | | |
> > > 2'd0 2'd1 2'd2 2'd3 <-sub_common_id(max is 4)
> > > | | | |
> > > Larb8 Larb9 Larb10 Larb11
> > >
> > > In this patch we extern larb_remap[] to larb_remap[8][4] for this.
> >
> > extern -> extend
> >
> > > larb_remap[x][y]: x mean common-id above, y means subcommon_id above.
> >
> > mean -> means
> >
> > >
> > > We can also distinguish if the M4U HW has sub_common by has_sub_comm
> > > property.
> > >
> > > Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> > > Reviewed-by: Yong Wu <yong.wu@mediatek.com>
> > > ---
> > > drivers/iommu/mtk_iommu.c | 20 +++++++++++++-------
> > > drivers/iommu/mtk_iommu.h | 3 ++-
> > > 2 files changed, 15 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > > index f23919feba4e..a687e8db0e51 100644
> > > --- a/drivers/iommu/mtk_iommu.c
> > > +++ b/drivers/iommu/mtk_iommu.c
> > > @@ -91,6 +91,8 @@
> > > #define REG_MMU1_INVLD_PA 0x148
> > > #define REG_MMU0_INT_ID 0x150
> > > #define REG_MMU1_INT_ID 0x154
> > > +#define F_MMU_INT_ID_COMM_ID(a) (((a) >> 9) & 0x7)
> > > +#define F_MMU_INT_ID_SUB_COMM_ID(a) (((a) >> 7) & 0x3)
> > > #define F_MMU_INT_ID_LARB_ID(a) (((a) >> 7) & 0x7)
> > > #define F_MMU_INT_ID_PORT_ID(a) (((a) >> 2) & 0x1f)
> > >
> > > @@ -229,7 +231,7 @@ static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
> > > struct mtk_iommu_data *data = dev_id;
> > > struct mtk_iommu_domain *dom = data->m4u_dom;
> > > u32 int_state, regval, fault_iova, fault_pa;
> > > - unsigned int fault_larb, fault_port;
> > > + unsigned int fault_larb, fault_port, sub_comm = 0;
> > > bool layer, write;
> > >
> > > /* Read error info from registers */
> > > @@ -245,10 +247,14 @@ static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
> > > }
> > > layer = fault_iova & F_MMU_FAULT_VA_LAYER_BIT;
> > > write = fault_iova & F_MMU_FAULT_VA_WRITE_BIT;
> > > - fault_larb = F_MMU_INT_ID_LARB_ID(regval);
> > > fault_port = F_MMU_INT_ID_PORT_ID(regval);
> > > -
> > > - fault_larb = data->plat_data->larbid_remap[fault_larb];
> > > + if (data->plat_data->has_sub_comm) {
> > > + fault_larb = F_MMU_INT_ID_COMM_ID(regval);
> > > + sub_comm = F_MMU_INT_ID_SUB_COMM_ID(regval);
> > > + } else {
> > > + fault_larb = F_MMU_INT_ID_LARB_ID(regval);
> > > + }
> > > + fault_larb = data->plat_data->larbid_remap[fault_larb][sub_comm];
> > >
> > > if (report_iommu_fault(&dom->domain, data->dev, fault_iova,
> > > write ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ)) {
> > > @@ -778,7 +784,7 @@ static const struct mtk_iommu_plat_data mt2712_data = {
> > > .has_bclk = true,
> > > .has_vld_pa_rng = true,
> > > .inv_sel_reg = REG_MMU_INV_SEL_GEN1,
> > > - .larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
> > > + .larbid_remap = {{0}, {1}, {2}, {3}, {4}, {5}, {6}, {7}},
> > > };
> > >
> > > static const struct mtk_iommu_plat_data mt8173_data = {
> > > @@ -787,14 +793,14 @@ static const struct mtk_iommu_plat_data mt8173_data = {
> > > .has_bclk = true,
> > > .reset_axi = true,
> > > .inv_sel_reg = REG_MMU_INV_SEL_GEN1,
> > > - .larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
> > > + .larbid_remap = {{0}, {1}, {2}, {3}, {4}, {5}}, /* Linear mapping. */
> > > };
> > >
> > > static const struct mtk_iommu_plat_data mt8183_data = {
> > > .m4u_plat = M4U_MT8183,
> > > .reset_axi = true,
> > > .inv_sel_reg = REG_MMU_INV_SEL_GEN1,
> > > - .larbid_remap = {0, 4, 5, 6, 7, 2, 3, 1},
> > > + .larbid_remap = {{0}, {4}, {5}, {6}, {7}, {2}, {3}, {1}},
> > > };
> > >
> > > static const struct of_device_id mtk_iommu_of_ids[] = {
> > > diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> > > index afd7a2de5c1e..d51ff99c2c71 100644
> > > --- a/drivers/iommu/mtk_iommu.h
> > > +++ b/drivers/iommu/mtk_iommu.h
> > > @@ -41,10 +41,11 @@ struct mtk_iommu_plat_data {
> > > /* HW will use the EMI clock if there isn't the "bclk". */
> > > bool has_bclk;
> > > bool has_misc_ctrl;
> > > + bool has_sub_comm;
> > > bool has_vld_pa_rng;
> > > bool reset_axi;
> > > u32 inv_sel_reg;
> > > - unsigned char larbid_remap[MTK_LARB_NR_MAX];
> > > + unsigned char larbid_remap[8][4];
> >
> > MTK_LARB_NR_MAX is 16, why do you decrease it to 8?
>
> From the diagram above, the max number of the larbs that could connected
> with a IOMMU HW is 8. thus, 8 is right here for each a IOMMU HW.
>
> as I commented when v3. mt2712 have the larbs over 8 since it has 2
> IOMMU HWes.
>
> and MTK_LARB_NR_MAX means the max larbs number that this SoC support.
> Keep its value as is.
>
>
> > Should we use a define for the subcommon as well?
> >
> > Regards,
> > Matthias
> >
Hi Matthias and yong,
Thanks very much for your review.
HW diagram is as belove and whether we need to use macro definitions to
show it, maybe more clearer? like this:
#define LARB_COMMON_MAX 8
#define LARB_SUB_COMMON_MAX 4
unsigned char larbid_remap[LARB_COMMON_MAX][LARB_SUB_COMMON_MAX];
>
> > > };
> > >
> > > struct mtk_iommu_domain;
> > >
>
>
next prev parent reply other threads:[~2020-06-18 11:44 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-17 3:00 [PATCH v4 00/07] MT6779 IOMMU SUPPORT Chao Hao
2020-06-17 3:00 ` Chao Hao
2020-06-17 3:00 ` Chao Hao
2020-06-17 3:00 ` Chao Hao
2020-06-17 3:00 ` [PATCH v4 1/7] dt-bindings: mediatek: Add bindings for MT6779 Chao Hao
2020-06-17 3:00 ` Chao Hao
2020-06-17 3:00 ` Chao Hao
2020-06-17 3:00 ` Chao Hao
2020-06-17 3:00 ` [PATCH v4 2/7] iommu/mediatek: Rename the register STANDARD_AXI_MODE(0x48) to MISC_CTRL Chao Hao
2020-06-17 3:00 ` Chao Hao
2020-06-17 3:00 ` Chao Hao
2020-06-17 3:00 ` Chao Hao
2020-06-17 9:04 ` Matthias Brugger
2020-06-17 9:04 ` Matthias Brugger
2020-06-17 9:04 ` Matthias Brugger
2020-06-17 9:04 ` Matthias Brugger
2020-06-17 3:00 ` [PATCH v4 3/7] iommu/mediatek: Set MISC_CTRL register Chao Hao
2020-06-17 3:00 ` Chao Hao
2020-06-17 3:00 ` Chao Hao
2020-06-17 3:00 ` Chao Hao
2020-06-17 9:34 ` Matthias Brugger
2020-06-17 9:34 ` Matthias Brugger
2020-06-17 9:34 ` Matthias Brugger
2020-06-17 9:34 ` Matthias Brugger
2020-06-18 11:49 ` chao hao
2020-06-18 11:49 ` chao hao
2020-06-18 11:49 ` chao hao
2020-06-18 11:49 ` chao hao
2020-06-20 2:03 ` Yong Wu
2020-06-24 6:39 ` chao hao
2020-06-24 6:39 ` chao hao
2020-06-24 6:39 ` chao hao
2020-06-24 6:39 ` chao hao
2020-06-17 3:00 ` [PATCH v4 4/7] iommu/mediatek: Move inv_sel_reg into the plat_data Chao Hao
2020-06-17 3:00 ` Chao Hao
2020-06-17 3:00 ` Chao Hao
2020-06-17 3:00 ` Chao Hao
2020-06-17 9:09 ` Matthias Brugger
2020-06-17 9:09 ` Matthias Brugger
2020-06-17 9:09 ` Matthias Brugger
2020-06-17 9:09 ` Matthias Brugger
2020-06-17 3:00 ` [PATCH v4 5/7] iommu/mediatek: Add sub_comm id in translation fault Chao Hao
2020-06-17 3:00 ` Chao Hao
2020-06-17 3:00 ` Chao Hao
2020-06-17 3:00 ` Chao Hao
2020-06-17 9:17 ` Matthias Brugger
2020-06-17 9:17 ` Matthias Brugger
2020-06-17 9:17 ` Matthias Brugger
2020-06-17 9:17 ` Matthias Brugger
2020-06-17 11:11 ` Yong Wu
2020-06-17 11:11 ` Yong Wu
2020-06-17 11:11 ` Yong Wu
2020-06-17 11:11 ` Yong Wu
2020-06-18 11:44 ` chao hao [this message]
2020-06-18 11:44 ` chao hao
2020-06-18 11:44 ` chao hao
2020-06-18 11:44 ` chao hao
2020-06-17 3:00 ` [PATCH v4 6/7] iommu/mediatek: Add REG_MMU_WR_LEN definition preparing for mt6779 Chao Hao
2020-06-17 3:00 ` Chao Hao
2020-06-17 3:00 ` Chao Hao
2020-06-17 3:00 ` Chao Hao
2020-06-17 9:22 ` Matthias Brugger
2020-06-17 9:22 ` Matthias Brugger
2020-06-17 9:22 ` Matthias Brugger
2020-06-17 9:22 ` Matthias Brugger
2020-06-19 10:56 ` chao hao
2020-06-19 10:56 ` chao hao
2020-06-19 10:56 ` chao hao
2020-06-19 10:56 ` chao hao
2020-06-21 11:01 ` Matthias Brugger
2020-06-21 11:01 ` Matthias Brugger
2020-06-24 6:36 ` chao hao
2020-06-24 6:36 ` chao hao
2020-06-24 6:36 ` chao hao
2020-06-24 6:36 ` chao hao
2020-06-17 3:00 ` [PATCH v4 7/7] iommu/mediatek: Add mt6779 basic support Chao Hao
2020-06-17 3:00 ` Chao Hao
2020-06-17 3:00 ` Chao Hao
2020-06-17 3:00 ` Chao Hao
2020-06-17 9:33 ` Matthias Brugger
2020-06-17 9:33 ` Matthias Brugger
2020-06-17 9:33 ` Matthias Brugger
2020-06-17 9:33 ` Matthias Brugger
2020-06-18 11:54 ` chao hao
2020-06-18 11:54 ` chao hao
2020-06-18 11:54 ` chao hao
2020-06-18 11:54 ` chao hao
2020-06-18 16:00 ` Matthias Brugger
2020-06-18 16:00 ` Matthias Brugger
2020-06-18 16:00 ` Matthias Brugger
2020-06-18 16:00 ` Matthias Brugger
2020-06-19 10:50 ` chao hao
2020-06-19 10:50 ` chao hao
2020-06-19 10:50 ` chao hao
2020-06-19 10:50 ` 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=1592480656.12647.2.camel@mbjsdccf07 \
--to=chao.hao@mediatek.com \
--cc=devicetree@vger.kernel.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=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 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.