From: Will Deacon <will@kernel.org>
To: Yong Wu <yong.wu@mediatek.com>
Cc: youlin.pei@mediatek.com, devicetree@vger.kernel.org,
Nicolas Boichat <drinkcat@chromium.org>,
cui.zhang@mediatek.com, srv_heupstream@mediatek.com,
Tomasz Figa <tfiga@google.com>, Joerg Roedel <joro@8bytes.org>,
Will Deacon <will.deacon@arm.com>,
linux-kernel@vger.kernel.org, Evan Green <evgreen@chromium.org>,
chao.hao@mediatek.com, iommu@lists.linux-foundation.org,
Rob Herring <robh+dt@kernel.org>,
linux-mediatek@lists.infradead.org,
Matthias Brugger <matthias.bgg@gmail.com>,
yingjoe.chen@mediatek.com, anan.sun@mediatek.com,
Robin Murphy <robin.murphy@arm.com>,
Matthias Kaehlcke <mka@chromium.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v8 07/21] iommu/io-pgtable-arm-v7s: Extend MediaTek 4GB Mode
Date: Mon, 15 Jul 2019 10:51:57 +0100 [thread overview]
Message-ID: <20190715095156.xczfkbm6zpjueq32@willie-the-truck> (raw)
In-Reply-To: <1563079280.31342.22.camel@mhfsdcap03>
On Sun, Jul 14, 2019 at 12:41:20PM +0800, Yong Wu wrote:
> On Thu, 2019-07-11 at 13:31 +0100, Will Deacon wrote:
> > This looks like the right sort of idea. Basically, I was thinking that you
> > can use the oas in conjunction with the quirk to specify whether or not
> > your two magic bits should be set. You could also then cap the oas using
> > the size of phys_addr_t to deal with my other comment.
> >
> > Finally, I was hoping you could drop the |= BIT_ULL(32) and the &=
> > ~BIT_ULL(32) bits of the mtk driver if the pgtable code now accepts higher
> > addresses. Did that not work out?
>
> After the current patch, the pgtable has accepted the higher address.
> the " |= BIT_ULL(32)" and "& = ~ BIT_ULL(32)" is for a special case(we
> call it 4GB mode).
>
> Now MediaTek IOMMU support 2 kind memory:
> 1) normal case: PA is 0x4000_0000 - 0x3_ffff_ffff. the PA won't be
> remapped. mt8183 and the non-4GB mode of mt8173/mt2712 use this mode.
>
> 2) 4GB Mode: PA is 0x4000_0000 - 0x1_3fff_ffff. But the PA will remapped
> to 0x1_0000_0000 to 0x1_ffff_ffff. This is for the 4GB mode of
> mt8173/mt2712. This case is so special that we should change the PA
> manually(add bit32).
> (mt2712 and mt8173 have both mode: 4GB and non-4GB.)
>
> If we try to use oas and our quirk to cover this two case. Then I can
> use "oas == 33" only for this 4GB mode. and "oas == 34" for the normal
> case even though the PA mayn't reach 34bit. Also I should add some
> "workaround" for the 4GB mode(oas==33).
>
> I copy the new patch in the mail below(have dropped the "|= BIT_ULL(32)"
> and the "&= ~BIT_ULL(32)) in mtk iommu". please help have a look if it
> is ok.
> (another thing: Current the PA can support over 4GB. So the quirk name
> "MTK_4GB" looks not suitable, I used a new patch rename to "MTK_EXT").
Makes sense, thanks. One comment below.
> @@ -205,7 +216,20 @@ static phys_addr_t iopte_to_paddr(arm_v7s_iopte
> pte, int lvl,
> else
> mask = ARM_V7S_LVL_MASK(lvl);
>
> - return pte & mask;
> + paddr = pte & mask;
> + if (IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT) &&
> + (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT)) {
> + /*
> + * Workaround for MTK 4GB Mode:
> + * Add BIT32 only when PA < 0x4000_0000.
> + */
> + if ((cfg->oas == 33 && paddr < 0x40000000UL) ||
> + (cfg->oas > 33 && (pte & ARM_V7S_ATTR_MTK_PA_BIT32)))
> + paddr |= BIT_ULL(32);
> + if (pte & ARM_V7S_ATTR_MTK_PA_BIT33)
> + paddr |= BIT_ULL(33);
> + }
> + return paddr;
> }
>
> static arm_v7s_iopte *iopte_deref(arm_v7s_iopte pte, int lvl,
> @@ -326,9 +350,6 @@ static arm_v7s_iopte arm_v7s_prot_to_pte(int prot,
> int lvl,
> if (lvl == 1 && (cfg->quirks & IO_PGTABLE_QUIRK_ARM_NS))
> pte |= ARM_V7S_ATTR_NS_SECTION;
>
> - if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT)
> - pte |= ARM_V7S_ATTR_MTK_4GB;
> -
> return pte;
> }
>
> @@ -742,7 +763,9 @@ static struct io_pgtable
> *arm_v7s_alloc_pgtable(struct io_pgtable_cfg *cfg,
> {
> struct arm_v7s_io_pgtable *data;
>
> - if (cfg->ias > ARM_V7S_ADDR_BITS || cfg->oas > ARM_V7S_ADDR_BITS)
> + if (cfg->ias > ARM_V7S_ADDR_BITS ||
> + (cfg->oas > ARM_V7S_ADDR_BITS &&
> + !(cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT)))
> return NULL;
I think you can rework this to do something like:
if (cfg->ias > ARM_V7S_ADDR_BITS)
return NULL;
if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT) {
if (!IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT))
cfg->oas = min(cfg->oas, ARM_V7S_ADDR_BITS);
else if (cfg->oas > 34)
return NULL;
} else if (cfg->oas > ARM_V7S_ADDR_BITS) {
return NULL;
}
so that we clamp the oas when phys_addr_t is 32-bit for you. That should
allow you to remove lots of the checking from iopte_to_paddr() too if you
check against oas in the map() function.
Does that make sense?
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-07-15 9:52 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-29 2:09 [PATCH v8 00/21] MT8183 IOMMU SUPPORT Yong Wu
2019-06-29 2:09 ` [PATCH v8 01/21] dt-bindings: mediatek: Add binding for mt8183 IOMMU and SMI Yong Wu
2019-06-29 2:09 ` [PATCH v8 02/21] iommu/mediatek: Use a struct as the platform data Yong Wu
2019-06-29 2:09 ` [PATCH v8 03/21] memory: mtk-smi: Use a general config_port interface Yong Wu
2019-06-29 2:09 ` [PATCH v8 04/21] memory: mtk-smi: Use a struct for the platform data for smi-common Yong Wu
2019-06-29 2:09 ` [PATCH v8 05/21] iommu/mediatek: Fix iova_to_phys PA start for 4GB mode Yong Wu
2019-06-29 2:09 ` [PATCH v8 06/21] iommu/io-pgtable-arm-v7s: Add paddr_to_iopte and iopte_to_paddr helpers Yong Wu
2019-06-29 2:09 ` [PATCH v8 07/21] iommu/io-pgtable-arm-v7s: Extend MediaTek 4GB Mode Yong Wu
2019-07-10 14:36 ` Will Deacon
2019-07-11 11:53 ` Yong Wu
2019-07-11 12:31 ` Will Deacon
2019-07-14 4:41 ` Yong Wu
2019-07-15 9:51 ` Will Deacon [this message]
2019-07-17 12:44 ` Yong Wu
2019-07-17 14:23 ` Will Deacon
2019-07-18 5:37 ` Yong Wu
2019-06-29 2:09 ` [PATCH v8 08/21] iommu/mediatek: Add bclk can be supported optionally Yong Wu
2019-06-29 2:09 ` [PATCH v8 09/21] iommu/mediatek: Add larb-id remapped support Yong Wu
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=20190715095156.xczfkbm6zpjueq32@willie-the-truck \
--to=will@kernel.org \
--cc=anan.sun@mediatek.com \
--cc=chao.hao@mediatek.com \
--cc=cui.zhang@mediatek.com \
--cc=devicetree@vger.kernel.org \
--cc=drinkcat@chromium.org \
--cc=evgreen@chromium.org \
--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=mka@chromium.org \
--cc=robh+dt@kernel.org \
--cc=robin.murphy@arm.com \
--cc=srv_heupstream@mediatek.com \
--cc=tfiga@google.com \
--cc=will.deacon@arm.com \
--cc=yingjoe.chen@mediatek.com \
--cc=yong.wu@mediatek.com \
--cc=youlin.pei@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).