Re: [PATCH v5 14/20] iommu/mediatek: Add mmu1 support

Evan Green
2019-01-30T18:55:45Z

On Mon, Dec 31, 2018 at 7:59 PM Yong Wu <yong.wu@mediatek.com> wrote:
>
> Normally the M4U HW connect EMI with smi. the diagram is like below:
> EMI
> |
> M4U
> |
> smi-common
> |
> -----------------
> | | | | ...
> larb0 larb1 larb2 larb3
>
> Actually there are 2 mmu cells in the M4U HW, like this diagram:
>
> EMI
> ---------
> | |
> mmu0 mmu1 <- M4U
> | |
> ---------
> |
> smi-common
> |
> -----------------
> | | | | ...
> larb0 larb1 larb2 larb3
>
> This patch add support for mmu1. In order to get better performance,
> we could adjust some larbs go to mmu1 while the others still go to
> mmu0. This is controlled by a SMI COMMON register SMI_BUS_SEL(0x220).
>
> mt2712, mt8173 and mt8183 M4U HW all have 2 mmu cells. the default
> value of that register is 0 which means all the larbs go to mmu0
> defaultly.
>
> This is a preparing patch for adjusting SMI_BUS_SEL for mt8183.
>
> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> ---
> drivers/iommu/mtk_iommu.c | 47 +++++++++++++++++++++++++++++------------------
> 1 file changed, 29 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 66e3615..7fcef19 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -70,27 +70,32 @@
> #define F_MISS_FIFO_ERR_INT_EN BIT(6)
> #define F_INT_CLR_BIT BIT(12)
>
> -#define REG_MMU_INT_MAIN_CONTROL 0x124
> -#define F_INT_TRANSLATION_FAULT BIT(0)
> -#define F_INT_MAIN_MULTI_HIT_FAULT BIT(1)
> -#define F_INT_INVALID_PA_FAULT BIT(2)
> -#define F_INT_ENTRY_REPLACEMENT_FAULT BIT(3)
> -#define F_INT_TLB_MISS_FAULT BIT(4)
> -#define F_INT_MISS_TRANSACTION_FIFO_FAULT BIT(5)
> -#define F_INT_PRETETCH_TRANSATION_FIFO_FAULT BIT(6)
> +#define REG_MMU_INT_MAIN_CONTROL 0x124 /* mmu0 | mmu1 */

The comment being on that line is kind of weird, since the comment
really applies to the lines below it. Maybe the comment should be on
its own line, or on the TRANSLATION_FAULT line.

Other than that,
Reviewed-by: Evan Green <evgreen@chromium.org>