Message ID | 20230113060133.9394-8-yong.wu@mediatek.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp107357wrt; Thu, 12 Jan 2023 22:09:17 -0800 (PST) X-Google-Smtp-Source: AMrXdXvyylVxAELrN8Iowi7bsK9ir1EuQ0yg8HAbwT5Hb2Z85C3X8yriemKsZ++kGgTlfA7UcsfQ X-Received: by 2002:a17:90a:d144:b0:227:17e:32a with SMTP id t4-20020a17090ad14400b00227017e032amr19665778pjw.18.1673590157400; Thu, 12 Jan 2023 22:09:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673590157; cv=none; d=google.com; s=arc-20160816; b=R1QQVQ6gRZ9mf8YE3pmz/u+Ngl+gjcvXDj3YUE3Zy2AokRZDnugBSQx/PjNSFYzGPq q9EVw9hhFWUtRVm3h5H4xF/vAxnGrR0pa6c8cim1UOYLIGIIlUvm8oGuGBwmMeHDxUem Syzie+BozCA6vYruaBFmEOgfqYtk3U+kPng8nNDpVSpdmapP4qpJ30FzHn/4egHq9crg /YJef+33yBllIMmDYDjzBOdk3oDAa9FqHIy/zXjFxbCNl4TWYDsnfBulIxW1i1cXkpuM yjwNZTtdssZCiFFk1siRHiPK65hs9qAUDC8GNHW3/0LSLLW65iwc/8F4Rm1mSLmhU/0P 99ag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=F4ZV6xzjZejZiT9UUWAGDwGBFilCWnMXsf8yFsCz4s4=; b=LU+mxI1tHzivJS6z7oehhnv0J+eK6B9xL6BQyWVQYn0/Fi2KG3zI5d3CTFZ3ShTPLZ 6767AVoOdnNJujtm5niqqL4iOOZ7p3B/fT5BrvXsWqw/QJWaGg/02Gcpt3OOkHxMl0oW jRYKqEDZBQC/hDIh+k8qdKToJsZGWlKWbLUkvKDhT0etkIeZ3x4YoDYXAITBB3hGHkU6 4TdDWT33nbGShIUUEATIJs+v8pZ3bwhEowOOMcqpO+twPTdkdE5MH+NQ0b4Laf5TtBTI F1QJT5Rm1fKGeoJO+14bT4UseO2h4UevLEajlyFSjuj5rjure3cFCrKuj+CgGok0H+jq 6gzA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@mediatek.com header.s=dk header.b="ghK/j8ik"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=mediatek.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g11-20020a17090a67cb00b00225fc594eacsi22983942pjm.80.2023.01.12.22.09.04; Thu, 12 Jan 2023 22:09:17 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@mediatek.com header.s=dk header.b="ghK/j8ik"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=mediatek.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240603AbjAMGHo (ORCPT <rfc822;zhuangel570@gmail.com> + 99 others); Fri, 13 Jan 2023 01:07:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53600 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234573AbjAMGGU (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 13 Jan 2023 01:06:20 -0500 Received: from mailgw02.mediatek.com (unknown [210.61.82.184]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7586E5931A; Thu, 12 Jan 2023 22:03:07 -0800 (PST) X-UUID: ef2d0a9a930711ed945fc101203acc17-20230113 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:CC:To:From; bh=F4ZV6xzjZejZiT9UUWAGDwGBFilCWnMXsf8yFsCz4s4=; b=ghK/j8ikNhrRqIlkKg4ts6syqwyRvgeOPkSWn0W2UaAlXgOP5NM/RizOx+n0q4rUxZfmhRt2h5HjJrQvh39VcjnR0UKFAMwAkUveE15ok1+Kw30G52KIfY8AMgQtvRAnjRGcMUnubYQE2ilmEsg7Try68zxCF1UCQ7j5oIGsN84=; X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.1.17,REQID:8ed42090-1223-416a-923c-43629131ce34,IP:0,U RL:0,TC:0,Content:0,EDM:0,RT:0,SF:0,FILE:0,BULK:0,RULE:Release_Ham,ACTION: release,TS:0 X-CID-META: VersionHash:543e81c,CLOUDID:23f7258c-8530-4eff-9f77-222cf6e2895b,B ulkID:nil,BulkQuantity:0,Recheck:0,SF:102,TC:nil,Content:0,EDM:-3,IP:nil,U RL:0,File:nil,Bulk:nil,QS:nil,BEC:nil,COL:0,OSI:0,OSA:0 X-CID-BVR: 0,NGT X-UUID: ef2d0a9a930711ed945fc101203acc17-20230113 Received: from mtkmbs13n2.mediatek.inc [(172.21.101.108)] by mailgw02.mediatek.com (envelope-from <yong.wu@mediatek.com>) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256/256) with ESMTP id 148862957; Fri, 13 Jan 2023 14:03:00 +0800 Received: from mtkmbs13n2.mediatek.inc (172.21.101.108) by mtkmbs10n1.mediatek.inc (172.21.101.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 13 Jan 2023 14:02:59 +0800 Received: from mhfsdcap04.gcn.mediatek.inc (10.17.3.154) by mtkmbs13n2.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.2.792.15 via Frontend Transport; Fri, 13 Jan 2023 14:02:57 +0800 From: Yong Wu <yong.wu@mediatek.com> To: Joerg Roedel <joro@8bytes.org>, Matthias Brugger <matthias.bgg@gmail.com>, Mauro Carvalho Chehab <mchehab@kernel.org>, Rob Herring <robh+dt@kernel.org> CC: Will Deacon <will@kernel.org>, Robin Murphy <robin.murphy@arm.com>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Hans Verkuil <hverkuil@xs4all.nl>, <nfraprado@collabora.com>, <linux-media@vger.kernel.org>, <devicetree@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, <linux-mediatek@lists.infradead.org>, <linux-kernel@vger.kernel.org>, <iommu@lists.linux.dev>, "AngeloGioacchino Del Regno" <angelogioacchino.delregno@collabora.com>, <mingyuan.ma@mediatek.com>, <yf.wang@mediatek.com>, <libo.kang@mediatek.com>, Yunfei Dong <yunfei.dong@mediatek.com>, kyrie wu <kyrie.wu@mediatek.corp-partner.google.com>, <chengci.xu@mediatek.com>, <youlin.pei@mediatek.com>, <anan.sun@mediatek.com>, Yong Wu <yong.wu@mediatek.com> Subject: [PATCH 07/10] iommu/mediatek: Add a gap for the iova regions Date: Fri, 13 Jan 2023 14:01:30 +0800 Message-ID: <20230113060133.9394-8-yong.wu@mediatek.com> X-Mailer: git-send-email 2.18.0 In-Reply-To: <20230113060133.9394-1-yong.wu@mediatek.com> References: <20230113060133.9394-1-yong.wu@mediatek.com> MIME-Version: 1.0 Content-Type: text/plain X-MTK: N X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS, SPF_PASS,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1754886473297211017?= X-GMAIL-MSGID: =?utf-8?q?1754886473297211017?= |
Series |
Adjust the dma-ranges for MTK IOMMU
|
|
Commit Message
Yong Wu
Jan. 13, 2023, 6:01 a.m. UTC
Currenly masters can not indicate its special dma-ranges. Prepare
for vcodec. some vcodec end address is address + size, if our size
is 4G, the end address may be 0x2_0000_0000. and the
register is u32, then it may get zero. thus add a gap(8M) for
all the regions.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
Comments
Il 13/01/23 07:01, Yong Wu ha scritto: > Currenly masters can not indicate its special dma-ranges. Prepare > for vcodec. some vcodec end address is address + size, if our size > is 4G, the end address may be 0x2_0000_0000. and the > register is u32, then it may get zero. thus add a gap(8M) for > all the regions. > > Signed-off-by: Yong Wu <yong.wu@mediatek.com> I definitely agree on the fact that we do *need* this series... but this particular commit looks like a hack. I'm not convinced: I have a hunch that this one will sooner or later backfire on us and break things again... at the same time, I'm not sure how to do this properly at this point (I didn't do any research, anyway). Ideas? Regards, Angelo
On Mon, 2023-01-16 at 10:46 +0100, AngeloGioacchino Del Regno wrote: > Il 13/01/23 07:01, Yong Wu ha scritto: > > Currenly masters can not indicate its special dma-ranges. Prepare > > for vcodec. some vcodec end address is address + size, if our size > > is 4G, the end address may be 0x2_0000_0000. and the > > register is u32, then it may get zero. thus add a gap(8M) for > > all the regions. > > > > Signed-off-by: Yong Wu <yong.wu@mediatek.com> > > I definitely agree on the fact that we do *need* this series... Thanks very much for your review. > but this particular commit looks like a hack. > > I'm not convinced: I have a hunch that this one will sooner or later > backfire > on us and break things again... at the same time, I'm not sure how to > do this > properly at this point (I didn't do any research, anyway). I got a real vcodec issue described in the commit message. As you may see in the vcodec's dt-binding example[1/10] or the dts node[9/10], their length is 0xfff00000 that means they use 1M as the gap. Vcodec use this for a long time. After this patchset, this property is unused, then I have to take care of this in the iommu, therefore this patch is required, and I just give a bigger gap(8M) here. > > Ideas? > > Regards, > Angelo >
On Mon, 2023-01-16 at 10:46 +0100, AngeloGioacchino Del Regno wrote: > Il 13/01/23 07:01, Yong Wu ha scritto: > > Currenly masters can not indicate its special dma-ranges. Prepare > > for vcodec. some vcodec end address is address + size, if our size > > is 4G, the end address may be 0x2_0000_0000. and the > > register is u32, then it may get zero. thus add a gap(8M) for > > all the regions. > > > > Signed-off-by: Yong Wu <yong.wu@mediatek.com> > > I definitely agree on the fact that we do *need* this series... Thanks very much for your review. > but this particular commit looks like a hack. > > I'm not convinced: I have a hunch that this one will sooner or later > backfire > on us and break things again... at the same time, I'm not sure how to > do this > properly at this point (I didn't do any research, anyway). I got a real vcodec issue described in the commit message. As you may see in the vcodec's dt-binding example[1/10] or the dts node[9/10], their length is 0xfff00000 that means they use 1M as the gap. Vcodec use this for a long time. After this patchset, this property is unused, then I have to take care this in the iommu, therefore this patch is required, and I just give a bigger gap(8M) here. > > Ideas? > > Regards, > Angelo >
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c index e4b8c07d4dbd..dd63d9994133 100644 --- a/drivers/iommu/mtk_iommu.c +++ b/drivers/iommu/mtk_iommu.c @@ -304,15 +304,15 @@ static LIST_HEAD(m4ulist); /* List all the M4U HWs */ #define for_each_m4u(data, head) list_for_each_entry(data, head, list) static const struct mtk_iommu_iova_region single_domain[] = { - {.iova_base = 0, .size = SZ_4G}, + {.iova_base = 0, .size = SZ_4G - SZ_8M}, }; static const struct mtk_iommu_iova_region mt8192_multi_dom[] = { - { .iova_base = 0x0, .size = SZ_4G}, /* 0 ~ 4G */ + { .iova_base = 0x0, .size = SZ_4G - SZ_8M}, /* 0 ~ 4G, 8M as a gap. */ #if IS_ENABLED(CONFIG_ARCH_DMA_ADDR_T_64BIT) - { .iova_base = SZ_4G, .size = SZ_4G}, /* 4G ~ 8G */ - { .iova_base = SZ_4G * 2, .size = SZ_4G}, /* 8G ~ 12G */ - { .iova_base = SZ_4G * 3, .size = SZ_4G}, /* 12G ~ 16G */ + { .iova_base = SZ_4G, .size = SZ_4G - SZ_8M}, /* 4G ~ 8G */ + { .iova_base = SZ_4G * 2, .size = SZ_4G - SZ_8M}, /* 8G ~ 12G */ + { .iova_base = SZ_4G * 3, .size = SZ_4G - SZ_8M}, /* 12G ~ 16G */ { .iova_base = 0x240000000ULL, .size = 0x4000000}, /* CCU0 */ { .iova_base = 0x244000000ULL, .size = 0x4000000}, /* CCU1 */