On Wed, Nov 11, 2020 at 8:40 PM Yong Wu wrote:
>
> In the lastest SoC, M4U has its special power domain. thus, If the engine
> begin to work, it should help enable the power for M4U firstly.
> Currently if the engine work, it always enable the power/clocks for
> smi-larbs/smi-common. This patch
On Sat, Jul 11, 2020 at 2:50 PM Yong Wu wrote:
>
> As title.
>
> Signed-off-by: Yong Wu
> ---
> drivers/iommu/io-pgtable-arm-v7s.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/io-pgtable-arm-v7s.c
> b/drivers/iommu/io-pgtable-arm-v7s.c
> index
On Tue, Sep 3, 2019 at 5:38 PM Yong Wu wrote:
>
> MediaTek IOMMU don't have its power-domain. all the consumer connect
> with smi-larb, then connect with smi-common.
>
> M4U
> |
> smi-common
> |
> -
> | |...
> | |
> larb1
On Fri, Sep 6, 2019 at 12:05 AM Sakari Ailus
wrote:
>
> On Thu, Sep 05, 2019 at 07:53:37PM +0900, Tomasz Figa wrote:
> > On Thu, Sep 5, 2019 at 7:45 PM Sakari Ailus
> > wrote:
> > >
> > > Hi Dongchun,
> > >
> > > On Thu, Sep 05, 2019 at 05:41:05PM +0800, Dongchun Zhu wrote:
> > >
> > > ...
> > >
On Wed, Mar 20, 2019 at 1:56 AM Andrew Morton wrote:
>
> On Tue, 19 Mar 2019 15:41:43 +0800 Nicolas Boichat
> wrote:
>
> > On Mon, Feb 25, 2019 at 8:23 AM Nicolas Boichat
> > wrote:
> > >
> > > On Thu, Feb 14, 2019 at 1:12 AM Vlastimil Babka
On Mon, Feb 25, 2019 at 8:23 AM Nicolas Boichat wrote:
>
> On Thu, Feb 14, 2019 at 1:12 AM Vlastimil Babka wrote:
> >
> > On 1/22/19 11:51 PM, Nicolas Boichat wrote:
> > > Hi Andrew,
> > >
> > > On Fri, Jan 11, 2019 at 6:21 PM Joerg Roedel wrote:
>
On Thu, Feb 14, 2019 at 1:12 AM Vlastimil Babka wrote:
>
> On 1/22/19 11:51 PM, Nicolas Boichat wrote:
> > Hi Andrew,
> >
> > On Fri, Jan 11, 2019 at 6:21 PM Joerg Roedel wrote:
> >>
> >> On Wed, Jan 02, 2019 at 01:51:45PM +0800, Nicolas Boichat wrote:
&
Joerg: Just to make sure, is this patch in your queue? Thanks.
On Thu, Jan 31, 2019 at 2:21 AM Will Deacon wrote:
>
> On Mon, Jan 28, 2019 at 05:43:01PM +0800, Nicolas Boichat wrote:
> > L1 tables are allocated with __get_dma_pages, and therefore already
> > ignored by kmemlea
[2.863922] arm_v7s_alloc_pgtable+0x114/0x17c
[2.868354] alloc_io_pgtable_ops+0x3c/0x78
...
Fixes: e5fc9753b1a8314 ("iommu/io-pgtable: Add ARMv7 short descriptor support")
Signed-off-by: Nicolas Boichat
---
I only tested this on top of my other series
(https://patchwork.kernel.org/patc
Hi Andrew,
On Fri, Jan 11, 2019 at 6:21 PM Joerg Roedel wrote:
>
> On Wed, Jan 02, 2019 at 01:51:45PM +0800, Nicolas Boichat wrote:
> > Does anyone have any further comment on this series? If not, which
> > maintainer is going to pick this up? I assume Andrew Morton?
>
>
On Tue, Jan 1, 2019 at 11:59 AM Yong Wu wrote:
>
> The register VLD_PA_RNG(0x118) was forgot to backup while adding 4GB
> mode support for mt2712. this patch add it.
>
> Fixes: 30e2fccf9512 ("iommu/mediatek: Enlarge the validate PA range
> for 4GB mode")
> Signed-off-by: Yong Wu
> ---
>
On Tue, Jan 1, 2019 at 11:58 AM Yong Wu wrote:
>
> Both mt8173 and mt8183 don't have this vld_pa_rng(valid physical address
> range) register while mt2712 have. Move it into the plat_data.
>
> Signed-off-by: Yong Wu
> ---
> drivers/iommu/mtk_iommu.c | 3 ++-
> drivers/iommu/mtk_iommu.h | 1 +
>
e this property.
>
> It is a preparing patch for mt8183.
>
> Signed-off-by: Yong Wu
Reviewed-by: Nicolas Boichat
> ---
> drivers/iommu/mtk_iommu.c | 4 ++--
> drivers/iommu/mtk_iommu.h | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/mt
On Tue, Jan 1, 2019 at 11:58 AM Yong Wu wrote:
>
> The protect memory setting is a little different in the different SoCs.
> In the register REG_MMU_CTRL_REG(0x110), the TF_PROT(translation fault
> protect) shift bit is normally 4 while it shift 5 bits only in the
> mt8173. This patch delete the
, we add a larb-id
> remapping relationship in this patch.
>
> If there is no this larb-id remapping in some SoCs, use the linear
> mapping array instead.
>
> This also is a preparing patch for mt8183.
>
> Signed-off-by: Yong Wu
I think it's a little cleaner this way, thanks.
Reviewed-by: Nicolas B
On Fri, Dec 21, 2018 at 4:02 PM Yong Wu wrote:
>
> On Fri, 2018-12-21 at 12:43 +0800, Nicolas Boichat wrote:
> > On Sat, Dec 8, 2018 at 4:42 PM Yong Wu wrote:
> > >
> > > The M4U IP blocks in mt8183 is MediaTek's generation2 M4U which use
> > > the ARM
On Sat, Dec 8, 2018 at 4:43 PM Yong Wu wrote:
>
> There are 2 mmu cells in a M4U HW. we could adjust some larbs entering
> mmu0 or mmu1 to balance the bandwidth via the smi-common register
> SMI_BUS_SEL(0x220)(Each larb occupy 2 bits).
>
> In mt8183, For better performance, we switch larb1/2/5/7
On Sat, Dec 8, 2018 at 4:42 PM Yong Wu wrote:
>
> The M4U IP blocks in mt8183 is MediaTek's generation2 M4U which use
> the ARM Short-descriptor like mt8173, and most of the HW registers
> are the same.
>
> Here list main differences between mt8183 and mt8173/mt2712:
> 1) mt8183 has only one M4U
On Sat, Dec 8, 2018 at 4:42 PM Yong Wu wrote:
>
> The larb-id may be remapped in the smi-common, this means the
> larb-id reported in the mtk_iommu_isr isn't the real larb-id,
>
> Take mt8183 as a example:
>M4U
> |
>
in the future.
Cc: sta...@vger.kernel.org
Fixes: ad67f5a6545f ("arm64: replace ZONE_DMA with ZONE_DMA32")
Signed-off-by: Nicolas Boichat
---
Changes since v2:
- Commit message
(v3 used the page_frag approach)
Changes since v4:
- Do not pass ARM_V7S_TABLE_GFP_DMA to kmem_ca
). These calls will continue to
trigger a warning, as we keep GFP_DMA32 in GFP_SLAB_BUG_MASK.
This implies that calls to kmem_cache_*alloc on a SLAB_CACHE_DMA32
kmem_cache must _not_ use GFP_DMA32 (it is anyway redundant and
unnecessary).
Cc: sta...@vger.kernel.org
Signed-off-by: Nicolas Boichat
Acked
A previous patch in this series adds support for SLAB_CACHE_DMA32
kmem caches. This adds the corresponding
/sys/kernel/slab/cache/cache_dma32 entries, and fixes slabinfo
tool.
Cc: sta...@vger.kernel.org
Signed-off-by: Nicolas Boichat
---
There were different opinions on whether this sysfs entry
pped hunks that added cache_dma32 sysfs file, and moved
the hunks to PATCH v5 3/3, so that maintainer can decide whether
to pick the change independently.
Changes since v5:
- Rename ARM_V7S_TABLE_SLAB_CACHE to ARM_V7S_TABLE_SLAB_FLAGS.
- Add stable@ to cc.
Nicolas Boichat (3):
mm: Add suppor
On Fri, Dec 7, 2018 at 4:05 PM Matthew Wilcox wrote:
>
> On Fri, Dec 07, 2018 at 02:16:19PM +0800, Nicolas Boichat wrote:
> > +#ifdef CONFIG_ZONE_DMA32
> > +#define ARM_V7S_TABLE_GFP_DMA GFP_DMA32
> > +#define ARM_V7S_TABLE_SLAB_CACHE SLAB_CACHE_DMA32
>
> This nam
the hunks to PATCH v5 3/3, so that maintainer can decide whether
to pick the change independently.
Nicolas Boichat (3):
mm: Add support for kmem caches in DMA32 zone
iommu/io-pgtable-arm-v7s: Request DMA32 memory, and improve debugging
mm: Add /sys/kernel/slab/cache/cache_dma32
in the future.
Fixes: ad67f5a6545f ("arm64: replace ZONE_DMA with ZONE_DMA32")
Signed-off-by: Nicolas Boichat
---
Changes since v2:
- Commit message
(v3 used the page_frag approach)
Changes since v4:
- Do not pass ARM_V7S_TABLE_GFP_DMA to kmem_cache_zalloc, as this
is u
). These calls will continue to
trigger a warning, as we keep GFP_DMA32 in GFP_SLAB_BUG_MASK.
This implies that calls to kmem_cache_*alloc on a SLAB_CACHE_DMA32
kmem_cache must _not_ use GFP_DMA32 (it is anyway redundant and
unnecessary).
Signed-off-by: Nicolas Boichat
---
Changes since v2:
- Clarified
A previous patch in this series adds support for SLAB_CACHE_DMA32
kmem caches. This adds the corresponding
/sys/kernel/slab/cache/cache_dma32 entries, and fixes slabinfo
tool.
Signed-off-by: Nicolas Boichat
---
There were different opinions on whether this sysfs entry should
be added, so I'll
On Thu, Dec 6, 2018 at 5:37 PM Vlastimil Babka wrote:
>
> On 12/6/18 4:49 AM, Nicolas Boichat wrote:
> >> So it would be fine even unchanged. The check would anyway need some
> >> more love to catch the same with __GFP_DMA to be consistent and cover
> >> al
On Thu, Dec 6, 2018 at 11:32 AM Wei Yang wrote:
>
> On Thu, Dec 06, 2018 at 08:41:36AM +0800, Nicolas Boichat wrote:
> >On Wed, Dec 5, 2018 at 8:18 PM Wei Yang wrote:
> >>
> >> On Wed, Dec 05, 2018 at 03:39:51PM +0800, Nicolas Boichat wrote:
> >> >On W
On Wed, Dec 5, 2018 at 10:02 PM Vlastimil Babka wrote:
>
> On 12/5/18 6:48 AM, Nicolas Boichat wrote:
> > In some cases (e.g. IOMMU ARMv7s page allocator), we need to allocate
> > data structures smaller than a page with GFP_DMA32 flag.
> >
> > This change makes
On Wed, Dec 5, 2018 at 8:18 PM Wei Yang wrote:
>
> On Wed, Dec 05, 2018 at 03:39:51PM +0800, Nicolas Boichat wrote:
> >On Wed, Dec 5, 2018 at 3:25 PM Wei Yang wrote:
> >>
> >> On Wed, Dec 05, 2018 at 01:48:27PM +0800, Nicolas Boichat wrote:
> >> >In so
On Wed, Dec 5, 2018 at 5:56 PM Michal Hocko wrote:
>
> On Wed 05-12-18 13:48:27, Nicolas Boichat wrote:
> > In some cases (e.g. IOMMU ARMv7s page allocator), we need to allocate
> > data structures smaller than a page with GFP_DMA32 flag.
> >
> > This change makes
On Wed, Dec 5, 2018 at 3:25 PM Wei Yang wrote:
>
> On Wed, Dec 05, 2018 at 01:48:27PM +0800, Nicolas Boichat wrote:
> >In some cases (e.g. IOMMU ARMv7s page allocator), we need to allocate
> >data structures smaller than a page with GFP_DMA32 flag.
> >
> >This chan
On Wed, Dec 5, 2018 at 10:04 AM Nicolas Boichat wrote:
>
> On Tue, Dec 4, 2018 at 10:35 PM Vlastimil Babka wrote:
> >
> > On 12/4/18 10:37 AM, Nicolas Boichat wrote:
> > > On Sun, Nov 11, 2018 at 5:04 PM Nicolas Boichat
> > > wrote:
> > >>
&g
in SLAB_CACHE_DMA32.
Also, print an error when the physical address does not fit in
32-bit, to make debugging easier in the future.
Fixes: ad67f5a6545f ("arm64: replace ZONE_DMA with ZONE_DMA32")
Signed-off-by: Nicolas Boichat
---
Changes since v2:
- Commit message
(v3 used the
Remove duplicated code between slab and slub, and will make it
easier to make the test more complicated in the next commits.
Fixes: ad67f5a6545f ("arm64: replace ZONE_DMA with ZONE_DMA32")
Signed-off-by: Nicolas Boichat
---
mm/internal.h | 18 --
mm/slab.c | 8 +-
kmalloc cache array, as there are currently
no users of kmalloc(..., GFP_DMA32). The new test in check_slab_flags
ensures that such calls still fail (as they do before this change).
Fixes: ad67f5a6545f ("arm64: replace ZONE_DMA with ZONE_DMA32")
Signed-off-by: Nicolas Boichat
---
Change
by the previous
commit.
- Use DMA or DMA32 depending on the architecture (DMA for arm,
DMA32 for arm64).
Changes since v2:
- Reworded and expanded commit messages
- Added cache_dma32 documentation in PATCH 2/3.
v3 used the page_frag approach, see [3].
Nicolas Boichat (3):
mm
On Tue, Dec 4, 2018 at 10:35 PM Vlastimil Babka wrote:
>
> On 12/4/18 10:37 AM, Nicolas Boichat wrote:
> > On Sun, Nov 11, 2018 at 5:04 PM Nicolas Boichat
> > wrote:
> >>
> >> This is a follow-up to the discussion in [1], to make sure that the page
> >
On Sun, Nov 11, 2018 at 5:04 PM Nicolas Boichat wrote:
>
> This is a follow-up to the discussion in [1], to make sure that the page
> tables allocated by iommu/io-pgtable-arm-v7s are contained within 32-bit
> physical address space.
>
> [1]
> https://lists.linuxfoundatio
debugging easier in the future.
Fixes: ad67f5a6545f ("arm64: replace ZONE_DMA with ZONE_DMA32")
Signed-off-by: Nicolas Boichat
---
As an alternative to the series [1], which adds support for GFP_DMA32
to kmem_cache in mm/. IMHO the solution in [1] is cleaner and more
efficient, as it al
On Mon, Nov 26, 2018 at 4:02 PM Christoph Hellwig wrote:
>
> On Fri, Nov 23, 2018 at 01:23:41PM +0100, Vlastimil Babka wrote:
> > Is this also true for caches created by kmem_cache_create(), that
> > debugging options can result in not respecting the alignment passed to
> > kmem_cache_create()?
On Fri, Nov 23, 2018 at 11:04 AM Nicolas Boichat wrote:
>
> On Thu, Nov 22, 2018 at 4:23 PM Christoph Hellwig wrote:
> >
> > On Wed, Nov 21, 2018 at 10:26:26PM +, Robin Murphy wrote:
> > > TBH, if this DMA32 stuff is going to be contentious we could possibly just
On Thu, Nov 22, 2018 at 4:23 PM Christoph Hellwig wrote:
>
> On Wed, Nov 21, 2018 at 10:26:26PM +, Robin Murphy wrote:
> > TBH, if this DMA32 stuff is going to be contentious we could possibly just
> > rip out the offending kmem_cache - it seemed like good practice for the
> > use-case, but
On Thu, Nov 22, 2018 at 10:36 AM Matthew Wilcox wrote:
>
> On Wed, Nov 21, 2018 at 10:26:26PM +, Robin Murphy wrote:
> > These are IOMMU page tables, rather than CPU ones, so we're already well
> > outside arch code - indeed the original motivation of io-pgtable was to be
> > entirely
On Thu, Nov 22, 2018 at 2:02 AM Michal Hocko wrote:
>
> On Wed 21-11-18 16:46:38, Will Deacon wrote:
> > On Sun, Nov 11, 2018 at 05:03:41PM +0800, Nicolas Boichat wrote:
> > > For level 1/2 pages, ensure GFP_DMA32 is used if CONFIG_ZONE_DMA32
> > > is de
On Thu, Nov 22, 2018 at 6:27 AM Robin Murphy wrote:
>
> On 2018-11-21 9:38 pm, Matthew Wilcox wrote:
> > On Wed, Nov 21, 2018 at 06:20:02PM +, Christopher Lameter wrote:
> >> On Sun, 11 Nov 2018, Nicolas Boichat wrote:
> >>
> >>> This is a follow
On Thu, Nov 22, 2018 at 2:32 AM Christopher Lameter wrote:
>
> On Sun, 11 Nov 2018, Nicolas Boichat wrote:
>
> > SLAB_CACHE_DMA32 is only available after explicit kmem_cache_create calls,
> > no default cache is created for kmalloc. Add a test in check_slab_flags
> &
SLAB_CACHE_DMA32 is only available after explicit kmem_cache_create calls,
no default cache is created for kmalloc. Add a test in check_slab_flags
for this.
Fixes: ad67f5a6545f ("arm64: replace ZONE_DMA with ZONE_DMA32")
Signed-off-by: Nicolas Boichat
---
include/linux/slab.h |
: ad67f5a6545f ("arm64: replace ZONE_DMA with ZONE_DMA32")
Signed-off-by: Nicolas Boichat
---
Changes since v1:
- Changed approach to use SLAB_CACHE_DMA32 added by the previous
commit.
- Use DMA or DMA32 depending on the architecture (DMA for arm,
DMA32 for arm64).
drivers/iommu/io-pgtable
Remove duplicated code between slab and slub, and will make it
easier to make the test more complicated in the next commits.
Fixes: ad67f5a6545f ("arm64: replace ZONE_DMA with ZONE_DMA32")
Signed-off-by: Nicolas Boichat
---
mm/internal.h | 17 +++--
mm/slab.c | 8 +-
for SLAB_CACHE_DMA32 in slab and slub (patches 1/2)
- iommu/io-pgtable-arm-v7s (patch 3):
- Changed approach to use SLAB_CACHE_DMA32 added by the previous
commit.
- Use DMA or DMA32 depending on the architecture (DMA for arm,
DMA32 for arm64).
Nicolas Boichat (3):
mm: slab/slub: Add
On Fri, Nov 9, 2018 at 6:43 PM Vlastimil Babka wrote:
>
> On 11/9/18 9:24 AM, Nicolas Boichat wrote:
> > Some callers, namely iommu/io-pgtable-arm-v7s, expect the physical
> > address returned by kmem_cache_alloc with GFP_DMA parameter to be
> > a 32-bit address.
&
er/1009116/ .
I'm still a bit uncomfortable with GFP_DMA passed to kmem_cache_alloc
suddenly becoming GFP_DMA32 in the underlying call, but I'm not sure
if there is a better way (apart from duplicating the caches, and a lot
of ifdefs in callers).
Thanks,
> >
> > Robin.
> >
> > &g
allocate SLAB_CACHE_DMA cache in DMA32 region,
if CONFIG_ZONE_DMA32 is set.
Fixes: ad67f5a6545f ("arm64: replace ZONE_DMA with ZONE_DMA32")
Signed-off-by: Nicolas Boichat
---
include/linux/slab.h | 13 -
mm/slab.c| 2 +-
mm/slub.c| 2 +-
3 files c
easier in the future.
Fixes: ad67f5a6545f ("arm64: replace ZONE_DMA with ZONE_DMA32")
Signed-off-by: Nicolas Boichat
---
drivers/iommu/io-pgtable-arm-v7s.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c
b/drivers/iommu/io-p
Some callers (e.g. iommu/io-pgtable-arm-v7s) require DMA32 memory
when calling __get_dma_pages. Add a new macro for that purpose.
Fixes: ad67f5a6545f ("arm64: replace ZONE_DMA with ZONE_DMA32")
Signed-off-by: Nicolas Boichat
---
include/linux/gfp.h | 2 ++
1 file changed, 2 insertion
This is a follow-up to the discussion in [1], to make sure that the page tables
allocated by iommu/io-pgtable-arm-v7s are contained within 32-bit physical
address space.
[1] https://lists.linuxfoundation.org/pipermail/iommu/2018-November/030876.html
Nicolas Boichat (3):
mm: When
59 matches
Mail list logo
