From: Yong Wu <yong.wu@mediatek.com>
To: Will Deacon <will@kernel.org>, Robin Murphy <robin.murphy@arm.com>
Cc: <youlin.pei@mediatek.com>, <devicetree@vger.kernel.org>,
Nicolas Boichat <drinkcat@chromium.org>, <cui.zhang@mediatek.com>,
<srv_heupstream@mediatek.com>, <chao.hao@mediatek.com>,
Joerg Roedel <joro@8bytes.org>, <linux-kernel@vger.kernel.org>,
Evan Green <evgreen@chromium.org>, Tomasz Figa <tfiga@google.com>,
<iommu@lists.linux-foundation.org>,
Rob Herring <robh+dt@kernel.org>,
<linux-mediatek@lists.infradead.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
<ming-fan.chen@mediatek.com>, <anan.sun@mediatek.com>,
Matthias Kaehlcke <mka@chromium.org>,
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v10 09/23] iommu/io-pgtable-arm-v7s: Extend to support PA[33:32] for MediaTek
Date: Thu, 22 Aug 2019 20:05:33 +0800 [thread overview]
Message-ID: <1566475533.11621.18.camel@mhfsdcap03> (raw)
In-Reply-To: <20190822112836.efodtwu3souq3uwa@willie-the-truck>
Thanks very much for viewing this so quickly.
On Thu, 2019-08-22 at 12:28 +0100, Will Deacon wrote:
> On Thu, Aug 22, 2019 at 11:57:11AM +0100, Robin Murphy wrote:
> > On 2019-08-22 11:17 am, Will Deacon wrote:
> > > On Thu, Aug 22, 2019 at 11:08:58AM +0100, Robin Murphy wrote:
> > > > On 2019-08-22 9:56 am, Yong Wu wrote:
> > > > > On Wed, 2019-08-21 at 16:24 +0100, Will Deacon wrote:
> > > > > > On Wed, Aug 21, 2019 at 09:53:12PM +0800, Yong Wu wrote:
> > > > > > > MediaTek extend the arm v7s descriptor to support up to 34 bits PA where
> > > > > > > the bit32 and bit33 are encoded in the bit9 and bit4 of the PTE
> > > > > > > respectively. Meanwhile the iova still is 32bits.
> > > > > > >
> > > > > > > Regarding whether the pagetable address could be over 4GB, the mt8183
> > > > > > > support it while the previous mt8173 don't, thus keep it as is.
> > > > > > >
> > > > > > > Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> > > > > > > ---
> > > > > > > drivers/iommu/io-pgtable-arm-v7s.c | 32 +++++++++++++++++++++++++-------
> > > > > > > include/linux/io-pgtable.h | 7 +++----
> > > > > > > 2 files changed, 28 insertions(+), 11 deletions(-)
> > > > > >
> > > > > > [...]
> > > > > >
> > > > > > > @@ -731,7 +747,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)))
> > > > > >
> > > > > > Please can you instead change arm_v7s_alloc_pgtable() so that it allows an
> > > > > > ias of up to 34 when the IO_PGTABLE_QUIRK_ARM_MTK_EXT is set?
> > > > >
> > > > > Here I only simply skip the oas checking for our case. then which way do
> > > > > your prefer? something like you commented before:?
> > > > >
> > > > >
> > > > > 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;
> > > > > }
> > > >
> > > > All it should take is something like:
> > > >
> > > > if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT)
> > > > max_oas = 34;
> > > > else
> > > > max_oas = 32;
> > > > if (cfg->oas > max_oas)
> > > > return NULL;
> > > >
> > > > or even just:
> > > >
> > > > if (cfg->oas > 32 ||
> > > > (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT && cfg->oas > 34))
> > > > return NULL;
> > > >
> > > > (and if we prefer the latter style, perhaps we could introduce some kind of
> > > > "is_mtk_4gb()" helper to save on verbosity)
> > >
> > > I wondered the same thing, but another place we'd want the check is in
> > > iopte_to_paddr() which probably needs the PHYS_ADDR_T check to avoid GCC
> > > warnings, although I didn't try it.
> >
> > I'm pretty sure I confirmed that "paddr |= BIT_ULL(32)" doesn't warn when
> > phys_addt_t is 32-bit - it's well-defined unsigned integer truncation after
> > all, and if GCC starts warning about all the valid no-op code it optimises
> > away then it's going to run up against IS_ENABLED() first and foremost ;)
>
> You're quite right, although we live in a world where GCC shouts at us about
> missing comments in switch statements so I think my worry was justified!
>
> > > So if we did:
> > >
> > > static bool cfg_mtk_ext_enabled(struct io_pgtable_cfg *cfg)
> > > {
> > > return IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT) &&
> > > cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT;
> > > }
> > >
> > > Then I suppose we could do this in _alloc():
> > >
> > > if (cfg->oas > cfg_mtk_ext_enabled(cfg) ? 34 : ARM_V7S_ADDR_BITS)
> > > return NULL;
>
> ^^ Apparantly, I left the bracketting here as an exercise to the reader.
>
> > >
> > > and then this in iopte_to_paddr():
> > >
> > > [...]
> > >
> > > paddr = pte & mask;
> > > if (!cfg_mtk_ext_enabled(cfg))
> > > return paddr;
> > >
> > > if (pte & ARM_V7S_ATTR_MTK_PA_BIT32)
> > > paddr |= ...
> > >
> > > [...]
> > >
> > > What do you reckon?
> >
> > Yeah, that's the general shape of things I was picturing - I'm not that
> > fussed about the PHYS_ADDR_T_64BIT thing, especially if it's wrapped up in
> > just one place, so if you do want to keep it as belt-and-braces I'll just
> > consider it a slight code size optimisation for 32-bit builds.
>
> Ok, great. Yong Wu -- are you ok respinning with the above + missing
> brackets?
Of course I can.
NearlyAll the interface in this file is prefixed with "arm_v7s_", so
does the new interface also need it?, like arm_v7s_is_mtk_enabled. And
keep the iopte_to_paddr and paddr_to_iopte symmetrical.
Then the final patch would looks like below, is it ok?
+static bool arm_v7s_is_mtk_enabled(struct io_pgtable_cfg *cfg)
+{
+ return IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT) &&
+ (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT);
+}
+
static arm_v7s_iopte paddr_to_iopte(phys_addr_t paddr, int lvl,
struct io_pgtable_cfg *cfg)
{
- return paddr & ARM_V7S_LVL_MASK(lvl);
+ arm_v7s_iopte pte = paddr & ARM_V7S_LVL_MASK(lvl);
+
+ if (!arm_v7s_is_mtk_enabled(cfg))
+ return pte;
+
+ if (paddr & BIT_ULL(32))
+ pte |= ARM_V7S_ATTR_MTK_PA_BIT32;
+ if (paddr & BIT_ULL(33))
+ pte |= ARM_V7S_ATTR_MTK_PA_BIT33;
+ return pte;
}
static phys_addr_t iopte_to_paddr(arm_v7s_iopte pte, int lvl,
struct io_pgtable_cfg *cfg)
{
arm_v7s_iopte mask;
+ phys_addr_t paddr;
if (ARM_V7S_PTE_IS_TABLE(pte, lvl))
mask = ARM_V7S_TABLE_MASK;
@@ -194,7 +212,15 @@ 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 (!arm_v7s_is_mtk_enabled(cfg))
+ return paddr;
+
+ if (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,
@@ -315,9 +341,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;
}
@@ -731,7 +754,10 @@ 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)
+ return NULL;
+
+ if (cfg->oas > (arm_v7s_is_mtk_enabled(cfg) ? 34 : ARM_V7S_ADDR_BITS))
return NULL;
>
> Will
WARNING: multiple messages have this Message-ID (diff)
From: Yong Wu <yong.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
To: Will Deacon <will-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
Cc: youlin.pei-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Nicolas Boichat
<drinkcat-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
cui.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org,
Tomasz Figa <tfiga-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Evan Green <evgreen-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
chao.hao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Matthias Brugger
<matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
ming-fan.chen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org,
anan.sun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org,
Matthias Kaehlcke <mka-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH v10 09/23] iommu/io-pgtable-arm-v7s: Extend to support PA[33:32] for MediaTek
Date: Thu, 22 Aug 2019 20:05:33 +0800 [thread overview]
Message-ID: <1566475533.11621.18.camel@mhfsdcap03> (raw)
In-Reply-To: <20190822112836.efodtwu3souq3uwa@willie-the-truck>
Thanks very much for viewing this so quickly.
On Thu, 2019-08-22 at 12:28 +0100, Will Deacon wrote:
> On Thu, Aug 22, 2019 at 11:57:11AM +0100, Robin Murphy wrote:
> > On 2019-08-22 11:17 am, Will Deacon wrote:
> > > On Thu, Aug 22, 2019 at 11:08:58AM +0100, Robin Murphy wrote:
> > > > On 2019-08-22 9:56 am, Yong Wu wrote:
> > > > > On Wed, 2019-08-21 at 16:24 +0100, Will Deacon wrote:
> > > > > > On Wed, Aug 21, 2019 at 09:53:12PM +0800, Yong Wu wrote:
> > > > > > > MediaTek extend the arm v7s descriptor to support up to 34 bits PA where
> > > > > > > the bit32 and bit33 are encoded in the bit9 and bit4 of the PTE
> > > > > > > respectively. Meanwhile the iova still is 32bits.
> > > > > > >
> > > > > > > Regarding whether the pagetable address could be over 4GB, the mt8183
> > > > > > > support it while the previous mt8173 don't, thus keep it as is.
> > > > > > >
> > > > > > > Signed-off-by: Yong Wu <yong.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> > > > > > > ---
> > > > > > > drivers/iommu/io-pgtable-arm-v7s.c | 32 +++++++++++++++++++++++++-------
> > > > > > > include/linux/io-pgtable.h | 7 +++----
> > > > > > > 2 files changed, 28 insertions(+), 11 deletions(-)
> > > > > >
> > > > > > [...]
> > > > > >
> > > > > > > @@ -731,7 +747,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)))
> > > > > >
> > > > > > Please can you instead change arm_v7s_alloc_pgtable() so that it allows an
> > > > > > ias of up to 34 when the IO_PGTABLE_QUIRK_ARM_MTK_EXT is set?
> > > > >
> > > > > Here I only simply skip the oas checking for our case. then which way do
> > > > > your prefer? something like you commented before:?
> > > > >
> > > > >
> > > > > 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;
> > > > > }
> > > >
> > > > All it should take is something like:
> > > >
> > > > if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT)
> > > > max_oas = 34;
> > > > else
> > > > max_oas = 32;
> > > > if (cfg->oas > max_oas)
> > > > return NULL;
> > > >
> > > > or even just:
> > > >
> > > > if (cfg->oas > 32 ||
> > > > (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT && cfg->oas > 34))
> > > > return NULL;
> > > >
> > > > (and if we prefer the latter style, perhaps we could introduce some kind of
> > > > "is_mtk_4gb()" helper to save on verbosity)
> > >
> > > I wondered the same thing, but another place we'd want the check is in
> > > iopte_to_paddr() which probably needs the PHYS_ADDR_T check to avoid GCC
> > > warnings, although I didn't try it.
> >
> > I'm pretty sure I confirmed that "paddr |= BIT_ULL(32)" doesn't warn when
> > phys_addt_t is 32-bit - it's well-defined unsigned integer truncation after
> > all, and if GCC starts warning about all the valid no-op code it optimises
> > away then it's going to run up against IS_ENABLED() first and foremost ;)
>
> You're quite right, although we live in a world where GCC shouts at us about
> missing comments in switch statements so I think my worry was justified!
>
> > > So if we did:
> > >
> > > static bool cfg_mtk_ext_enabled(struct io_pgtable_cfg *cfg)
> > > {
> > > return IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT) &&
> > > cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT;
> > > }
> > >
> > > Then I suppose we could do this in _alloc():
> > >
> > > if (cfg->oas > cfg_mtk_ext_enabled(cfg) ? 34 : ARM_V7S_ADDR_BITS)
> > > return NULL;
>
> ^^ Apparantly, I left the bracketting here as an exercise to the reader.
>
> > >
> > > and then this in iopte_to_paddr():
> > >
> > > [...]
> > >
> > > paddr = pte & mask;
> > > if (!cfg_mtk_ext_enabled(cfg))
> > > return paddr;
> > >
> > > if (pte & ARM_V7S_ATTR_MTK_PA_BIT32)
> > > paddr |= ...
> > >
> > > [...]
> > >
> > > What do you reckon?
> >
> > Yeah, that's the general shape of things I was picturing - I'm not that
> > fussed about the PHYS_ADDR_T_64BIT thing, especially if it's wrapped up in
> > just one place, so if you do want to keep it as belt-and-braces I'll just
> > consider it a slight code size optimisation for 32-bit builds.
>
> Ok, great. Yong Wu -- are you ok respinning with the above + missing
> brackets?
Of course I can.
NearlyAll the interface in this file is prefixed with "arm_v7s_", so
does the new interface also need it?, like arm_v7s_is_mtk_enabled. And
keep the iopte_to_paddr and paddr_to_iopte symmetrical.
Then the final patch would looks like below, is it ok?
+static bool arm_v7s_is_mtk_enabled(struct io_pgtable_cfg *cfg)
+{
+ return IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT) &&
+ (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT);
+}
+
static arm_v7s_iopte paddr_to_iopte(phys_addr_t paddr, int lvl,
struct io_pgtable_cfg *cfg)
{
- return paddr & ARM_V7S_LVL_MASK(lvl);
+ arm_v7s_iopte pte = paddr & ARM_V7S_LVL_MASK(lvl);
+
+ if (!arm_v7s_is_mtk_enabled(cfg))
+ return pte;
+
+ if (paddr & BIT_ULL(32))
+ pte |= ARM_V7S_ATTR_MTK_PA_BIT32;
+ if (paddr & BIT_ULL(33))
+ pte |= ARM_V7S_ATTR_MTK_PA_BIT33;
+ return pte;
}
static phys_addr_t iopte_to_paddr(arm_v7s_iopte pte, int lvl,
struct io_pgtable_cfg *cfg)
{
arm_v7s_iopte mask;
+ phys_addr_t paddr;
if (ARM_V7S_PTE_IS_TABLE(pte, lvl))
mask = ARM_V7S_TABLE_MASK;
@@ -194,7 +212,15 @@ 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 (!arm_v7s_is_mtk_enabled(cfg))
+ return paddr;
+
+ if (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,
@@ -315,9 +341,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;
}
@@ -731,7 +754,10 @@ 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)
+ return NULL;
+
+ if (cfg->oas > (arm_v7s_is_mtk_enabled(cfg) ? 34 : ARM_V7S_ADDR_BITS))
return NULL;
>
> Will
WARNING: multiple messages have this Message-ID (diff)
From: Yong Wu <yong.wu@mediatek.com>
To: Will Deacon <will@kernel.org>, Robin Murphy <robin.murphy@arm.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>,
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>,
ming-fan.chen@mediatek.com, anan.sun@mediatek.com,
Matthias Kaehlcke <mka@chromium.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v10 09/23] iommu/io-pgtable-arm-v7s: Extend to support PA[33:32] for MediaTek
Date: Thu, 22 Aug 2019 20:05:33 +0800 [thread overview]
Message-ID: <1566475533.11621.18.camel@mhfsdcap03> (raw)
In-Reply-To: <20190822112836.efodtwu3souq3uwa@willie-the-truck>
Thanks very much for viewing this so quickly.
On Thu, 2019-08-22 at 12:28 +0100, Will Deacon wrote:
> On Thu, Aug 22, 2019 at 11:57:11AM +0100, Robin Murphy wrote:
> > On 2019-08-22 11:17 am, Will Deacon wrote:
> > > On Thu, Aug 22, 2019 at 11:08:58AM +0100, Robin Murphy wrote:
> > > > On 2019-08-22 9:56 am, Yong Wu wrote:
> > > > > On Wed, 2019-08-21 at 16:24 +0100, Will Deacon wrote:
> > > > > > On Wed, Aug 21, 2019 at 09:53:12PM +0800, Yong Wu wrote:
> > > > > > > MediaTek extend the arm v7s descriptor to support up to 34 bits PA where
> > > > > > > the bit32 and bit33 are encoded in the bit9 and bit4 of the PTE
> > > > > > > respectively. Meanwhile the iova still is 32bits.
> > > > > > >
> > > > > > > Regarding whether the pagetable address could be over 4GB, the mt8183
> > > > > > > support it while the previous mt8173 don't, thus keep it as is.
> > > > > > >
> > > > > > > Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> > > > > > > ---
> > > > > > > drivers/iommu/io-pgtable-arm-v7s.c | 32 +++++++++++++++++++++++++-------
> > > > > > > include/linux/io-pgtable.h | 7 +++----
> > > > > > > 2 files changed, 28 insertions(+), 11 deletions(-)
> > > > > >
> > > > > > [...]
> > > > > >
> > > > > > > @@ -731,7 +747,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)))
> > > > > >
> > > > > > Please can you instead change arm_v7s_alloc_pgtable() so that it allows an
> > > > > > ias of up to 34 when the IO_PGTABLE_QUIRK_ARM_MTK_EXT is set?
> > > > >
> > > > > Here I only simply skip the oas checking for our case. then which way do
> > > > > your prefer? something like you commented before:?
> > > > >
> > > > >
> > > > > 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;
> > > > > }
> > > >
> > > > All it should take is something like:
> > > >
> > > > if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT)
> > > > max_oas = 34;
> > > > else
> > > > max_oas = 32;
> > > > if (cfg->oas > max_oas)
> > > > return NULL;
> > > >
> > > > or even just:
> > > >
> > > > if (cfg->oas > 32 ||
> > > > (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT && cfg->oas > 34))
> > > > return NULL;
> > > >
> > > > (and if we prefer the latter style, perhaps we could introduce some kind of
> > > > "is_mtk_4gb()" helper to save on verbosity)
> > >
> > > I wondered the same thing, but another place we'd want the check is in
> > > iopte_to_paddr() which probably needs the PHYS_ADDR_T check to avoid GCC
> > > warnings, although I didn't try it.
> >
> > I'm pretty sure I confirmed that "paddr |= BIT_ULL(32)" doesn't warn when
> > phys_addt_t is 32-bit - it's well-defined unsigned integer truncation after
> > all, and if GCC starts warning about all the valid no-op code it optimises
> > away then it's going to run up against IS_ENABLED() first and foremost ;)
>
> You're quite right, although we live in a world where GCC shouts at us about
> missing comments in switch statements so I think my worry was justified!
>
> > > So if we did:
> > >
> > > static bool cfg_mtk_ext_enabled(struct io_pgtable_cfg *cfg)
> > > {
> > > return IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT) &&
> > > cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT;
> > > }
> > >
> > > Then I suppose we could do this in _alloc():
> > >
> > > if (cfg->oas > cfg_mtk_ext_enabled(cfg) ? 34 : ARM_V7S_ADDR_BITS)
> > > return NULL;
>
> ^^ Apparantly, I left the bracketting here as an exercise to the reader.
>
> > >
> > > and then this in iopte_to_paddr():
> > >
> > > [...]
> > >
> > > paddr = pte & mask;
> > > if (!cfg_mtk_ext_enabled(cfg))
> > > return paddr;
> > >
> > > if (pte & ARM_V7S_ATTR_MTK_PA_BIT32)
> > > paddr |= ...
> > >
> > > [...]
> > >
> > > What do you reckon?
> >
> > Yeah, that's the general shape of things I was picturing - I'm not that
> > fussed about the PHYS_ADDR_T_64BIT thing, especially if it's wrapped up in
> > just one place, so if you do want to keep it as belt-and-braces I'll just
> > consider it a slight code size optimisation for 32-bit builds.
>
> Ok, great. Yong Wu -- are you ok respinning with the above + missing
> brackets?
Of course I can.
NearlyAll the interface in this file is prefixed with "arm_v7s_", so
does the new interface also need it?, like arm_v7s_is_mtk_enabled. And
keep the iopte_to_paddr and paddr_to_iopte symmetrical.
Then the final patch would looks like below, is it ok?
+static bool arm_v7s_is_mtk_enabled(struct io_pgtable_cfg *cfg)
+{
+ return IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT) &&
+ (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT);
+}
+
static arm_v7s_iopte paddr_to_iopte(phys_addr_t paddr, int lvl,
struct io_pgtable_cfg *cfg)
{
- return paddr & ARM_V7S_LVL_MASK(lvl);
+ arm_v7s_iopte pte = paddr & ARM_V7S_LVL_MASK(lvl);
+
+ if (!arm_v7s_is_mtk_enabled(cfg))
+ return pte;
+
+ if (paddr & BIT_ULL(32))
+ pte |= ARM_V7S_ATTR_MTK_PA_BIT32;
+ if (paddr & BIT_ULL(33))
+ pte |= ARM_V7S_ATTR_MTK_PA_BIT33;
+ return pte;
}
static phys_addr_t iopte_to_paddr(arm_v7s_iopte pte, int lvl,
struct io_pgtable_cfg *cfg)
{
arm_v7s_iopte mask;
+ phys_addr_t paddr;
if (ARM_V7S_PTE_IS_TABLE(pte, lvl))
mask = ARM_V7S_TABLE_MASK;
@@ -194,7 +212,15 @@ 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 (!arm_v7s_is_mtk_enabled(cfg))
+ return paddr;
+
+ if (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,
@@ -315,9 +341,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;
}
@@ -731,7 +754,10 @@ 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)
+ return NULL;
+
+ if (cfg->oas > (arm_v7s_is_mtk_enabled(cfg) ? 34 : ARM_V7S_ADDR_BITS))
return NULL;
>
> Will
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Yong Wu <yong.wu@mediatek.com>
To: Will Deacon <will@kernel.org>, Robin Murphy <robin.murphy@arm.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>,
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>,
ming-fan.chen@mediatek.com, anan.sun@mediatek.com,
Matthias Kaehlcke <mka@chromium.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v10 09/23] iommu/io-pgtable-arm-v7s: Extend to support PA[33:32] for MediaTek
Date: Thu, 22 Aug 2019 20:05:33 +0800 [thread overview]
Message-ID: <1566475533.11621.18.camel@mhfsdcap03> (raw)
In-Reply-To: <20190822112836.efodtwu3souq3uwa@willie-the-truck>
Thanks very much for viewing this so quickly.
On Thu, 2019-08-22 at 12:28 +0100, Will Deacon wrote:
> On Thu, Aug 22, 2019 at 11:57:11AM +0100, Robin Murphy wrote:
> > On 2019-08-22 11:17 am, Will Deacon wrote:
> > > On Thu, Aug 22, 2019 at 11:08:58AM +0100, Robin Murphy wrote:
> > > > On 2019-08-22 9:56 am, Yong Wu wrote:
> > > > > On Wed, 2019-08-21 at 16:24 +0100, Will Deacon wrote:
> > > > > > On Wed, Aug 21, 2019 at 09:53:12PM +0800, Yong Wu wrote:
> > > > > > > MediaTek extend the arm v7s descriptor to support up to 34 bits PA where
> > > > > > > the bit32 and bit33 are encoded in the bit9 and bit4 of the PTE
> > > > > > > respectively. Meanwhile the iova still is 32bits.
> > > > > > >
> > > > > > > Regarding whether the pagetable address could be over 4GB, the mt8183
> > > > > > > support it while the previous mt8173 don't, thus keep it as is.
> > > > > > >
> > > > > > > Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> > > > > > > ---
> > > > > > > drivers/iommu/io-pgtable-arm-v7s.c | 32 +++++++++++++++++++++++++-------
> > > > > > > include/linux/io-pgtable.h | 7 +++----
> > > > > > > 2 files changed, 28 insertions(+), 11 deletions(-)
> > > > > >
> > > > > > [...]
> > > > > >
> > > > > > > @@ -731,7 +747,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)))
> > > > > >
> > > > > > Please can you instead change arm_v7s_alloc_pgtable() so that it allows an
> > > > > > ias of up to 34 when the IO_PGTABLE_QUIRK_ARM_MTK_EXT is set?
> > > > >
> > > > > Here I only simply skip the oas checking for our case. then which way do
> > > > > your prefer? something like you commented before:?
> > > > >
> > > > >
> > > > > 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;
> > > > > }
> > > >
> > > > All it should take is something like:
> > > >
> > > > if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT)
> > > > max_oas = 34;
> > > > else
> > > > max_oas = 32;
> > > > if (cfg->oas > max_oas)
> > > > return NULL;
> > > >
> > > > or even just:
> > > >
> > > > if (cfg->oas > 32 ||
> > > > (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT && cfg->oas > 34))
> > > > return NULL;
> > > >
> > > > (and if we prefer the latter style, perhaps we could introduce some kind of
> > > > "is_mtk_4gb()" helper to save on verbosity)
> > >
> > > I wondered the same thing, but another place we'd want the check is in
> > > iopte_to_paddr() which probably needs the PHYS_ADDR_T check to avoid GCC
> > > warnings, although I didn't try it.
> >
> > I'm pretty sure I confirmed that "paddr |= BIT_ULL(32)" doesn't warn when
> > phys_addt_t is 32-bit - it's well-defined unsigned integer truncation after
> > all, and if GCC starts warning about all the valid no-op code it optimises
> > away then it's going to run up against IS_ENABLED() first and foremost ;)
>
> You're quite right, although we live in a world where GCC shouts at us about
> missing comments in switch statements so I think my worry was justified!
>
> > > So if we did:
> > >
> > > static bool cfg_mtk_ext_enabled(struct io_pgtable_cfg *cfg)
> > > {
> > > return IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT) &&
> > > cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT;
> > > }
> > >
> > > Then I suppose we could do this in _alloc():
> > >
> > > if (cfg->oas > cfg_mtk_ext_enabled(cfg) ? 34 : ARM_V7S_ADDR_BITS)
> > > return NULL;
>
> ^^ Apparantly, I left the bracketting here as an exercise to the reader.
>
> > >
> > > and then this in iopte_to_paddr():
> > >
> > > [...]
> > >
> > > paddr = pte & mask;
> > > if (!cfg_mtk_ext_enabled(cfg))
> > > return paddr;
> > >
> > > if (pte & ARM_V7S_ATTR_MTK_PA_BIT32)
> > > paddr |= ...
> > >
> > > [...]
> > >
> > > What do you reckon?
> >
> > Yeah, that's the general shape of things I was picturing - I'm not that
> > fussed about the PHYS_ADDR_T_64BIT thing, especially if it's wrapped up in
> > just one place, so if you do want to keep it as belt-and-braces I'll just
> > consider it a slight code size optimisation for 32-bit builds.
>
> Ok, great. Yong Wu -- are you ok respinning with the above + missing
> brackets?
Of course I can.
NearlyAll the interface in this file is prefixed with "arm_v7s_", so
does the new interface also need it?, like arm_v7s_is_mtk_enabled. And
keep the iopte_to_paddr and paddr_to_iopte symmetrical.
Then the final patch would looks like below, is it ok?
+static bool arm_v7s_is_mtk_enabled(struct io_pgtable_cfg *cfg)
+{
+ return IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT) &&
+ (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT);
+}
+
static arm_v7s_iopte paddr_to_iopte(phys_addr_t paddr, int lvl,
struct io_pgtable_cfg *cfg)
{
- return paddr & ARM_V7S_LVL_MASK(lvl);
+ arm_v7s_iopte pte = paddr & ARM_V7S_LVL_MASK(lvl);
+
+ if (!arm_v7s_is_mtk_enabled(cfg))
+ return pte;
+
+ if (paddr & BIT_ULL(32))
+ pte |= ARM_V7S_ATTR_MTK_PA_BIT32;
+ if (paddr & BIT_ULL(33))
+ pte |= ARM_V7S_ATTR_MTK_PA_BIT33;
+ return pte;
}
static phys_addr_t iopte_to_paddr(arm_v7s_iopte pte, int lvl,
struct io_pgtable_cfg *cfg)
{
arm_v7s_iopte mask;
+ phys_addr_t paddr;
if (ARM_V7S_PTE_IS_TABLE(pte, lvl))
mask = ARM_V7S_TABLE_MASK;
@@ -194,7 +212,15 @@ 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 (!arm_v7s_is_mtk_enabled(cfg))
+ return paddr;
+
+ if (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,
@@ -315,9 +341,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;
}
@@ -731,7 +754,10 @@ 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)
+ return NULL;
+
+ if (cfg->oas > (arm_v7s_is_mtk_enabled(cfg) ? 34 : ARM_V7S_ADDR_BITS))
return NULL;
>
> 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-08-22 12:05 UTC|newest]
Thread overview: 145+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-21 13:53 [PATCH v10 00/23] MT8183 IOMMU SUPPORT Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` [PATCH v10 01/23] dt-bindings: mediatek: Add binding for mt8183 IOMMU and SMI Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` [PATCH v10 02/23] iommu/mediatek: Use a struct as the platform data Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` [PATCH v10 03/23] memory: mtk-smi: Use a general config_port interface Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` [PATCH v10 04/23] memory: mtk-smi: Use a struct for the platform data for smi-common Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` [PATCH v10 05/23] iommu/mediatek: Fix iova_to_phys PA start for 4GB mode Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` [PATCH v10 06/23] iommu/io-pgtable-arm-v7s: Add paddr_to_iopte and iopte_to_paddr helpers Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` [PATCH v10 07/23] iommu/io-pgtable-arm-v7s: Use ias/oas to check the valid iova/pa Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 15:25 ` Will Deacon
2019-08-21 15:25 ` Will Deacon
2019-08-21 15:25 ` Will Deacon
2019-08-21 13:53 ` [PATCH v10 08/23] iommu/io-pgtable-arm-v7s: Rename the quirk from MTK_4GB to MTK_EXT Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 15:25 ` Will Deacon
2019-08-21 15:25 ` Will Deacon
2019-08-21 15:25 ` Will Deacon
2019-08-21 13:53 ` [PATCH v10 09/23] iommu/io-pgtable-arm-v7s: Extend to support PA[33:32] for MediaTek Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 15:24 ` Will Deacon
2019-08-21 15:24 ` Will Deacon
2019-08-21 15:24 ` Will Deacon
2019-08-21 15:34 ` Robin Murphy
2019-08-21 15:34 ` Robin Murphy
2019-08-21 15:34 ` Robin Murphy
2019-08-21 16:35 ` Will Deacon
2019-08-21 16:35 ` Will Deacon
2019-08-21 16:35 ` Will Deacon
2019-08-22 8:59 ` Yong Wu
2019-08-22 8:59 ` Yong Wu
2019-08-22 8:59 ` Yong Wu
2019-08-22 8:59 ` Yong Wu
2019-08-22 8:56 ` Yong Wu
2019-08-22 8:56 ` Yong Wu
2019-08-22 8:56 ` Yong Wu
2019-08-22 8:56 ` Yong Wu
2019-08-22 10:08 ` Will Deacon
2019-08-22 10:08 ` Will Deacon
2019-08-22 10:08 ` Will Deacon
2019-08-22 10:08 ` Robin Murphy
2019-08-22 10:08 ` Robin Murphy
2019-08-22 10:08 ` Robin Murphy
2019-08-22 10:17 ` Will Deacon
2019-08-22 10:17 ` Will Deacon
2019-08-22 10:17 ` Will Deacon
2019-08-22 10:57 ` Robin Murphy
2019-08-22 10:57 ` Robin Murphy
2019-08-22 10:57 ` Robin Murphy
2019-08-22 11:28 ` Will Deacon
2019-08-22 11:28 ` Will Deacon
2019-08-22 11:28 ` Will Deacon
2019-08-22 12:05 ` Yong Wu [this message]
2019-08-22 12:05 ` Yong Wu
2019-08-22 12:05 ` Yong Wu
2019-08-22 12:05 ` Yong Wu
2019-08-22 17:14 ` Will Deacon
2019-08-22 17:14 ` Will Deacon
2019-08-22 17:14 ` Will Deacon
2019-08-22 17:14 ` Will Deacon
2019-08-21 13:53 ` [PATCH v10 10/23] iommu/mediatek: Adjust the PA for the 4GB Mode Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` [PATCH v10 11/23] iommu/mediatek: Add bclk can be supported optionally Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` [PATCH v10 12/23] iommu/mediatek: Add larb-id remapped support Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` [PATCH v10 13/23] iommu/mediatek: Refine protect memory definition Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` [PATCH v10 14/23] iommu/mediatek: Move reset_axi into plat_data Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` [PATCH v10 15/23] iommu/mediatek: Move vld_pa_rng " Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` [PATCH v10 16/23] memory: mtk-smi: Add gals support Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` [PATCH v10 17/23] iommu/mediatek: Add mt8183 IOMMU support Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` [PATCH v10 18/23] iommu/mediatek: Add mmu1 support Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` [PATCH v10 19/23] memory: mtk-smi: Invoke pm runtime_callback to enable clocks Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` [PATCH v10 20/23] memory: mtk-smi: Add bus_sel for mt8183 Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` [PATCH v10 21/23] iommu/mediatek: Fix VLD_PA_RNG register backup when suspend Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` [PATCH v10 22/23] memory: mtk-smi: Get rid of need_larbid Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` [PATCH v10 23/23] iommu/mediatek: Clean up struct mtk_smi_iommu Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-21 13:53 ` Yong Wu
2019-08-22 14:07 ` Matthias Brugger
2019-08-22 14:07 ` Matthias Brugger
2019-08-22 14:07 ` 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=1566475533.11621.18.camel@mhfsdcap03 \
--to=yong.wu@mediatek.com \
--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=ming-fan.chen@mediatek.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@kernel.org \
--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 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.