> Single memory zone feature will remove ZONE_DMA32 and ZONE_DMA. So add
> the quirk IO_PGTABLE_QUIRK_ARM_MTK_TTBR_EXT to let level 1 and level 2
> pgtable support at most 35bit PA.
>
> Signed-off-by: Ning Li
> Signed-off-by: Yunfei Wang
Reviewed-by: Miles Chen
>
> Rename MTK_IOMMU_TLB_ADDR to MTK_IOMMU_ADDR, and update MTK_IOMMU_ADDR
> definition for better generality.
>
> Signed-off-by: Ning Li
> Signed-off-by: Yunfei Wang
Reviewed-by: Miles Chen
___
iommu mailing list
iommu@lists.linux
;
> For this reason, assign the right phandle to mediatek,infracfg in
> the iommu node.
>
> Signed-off-by: AngeloGioacchino Del Regno
>
Reviewed-by: Miles Chen
> ---
> arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff -
;
> For this reason, assign the right phandle to mediatek,infracfg in
> the iommu node.
>
> Signed-off-by: AngeloGioacchino Del Regno
>
Reviewed-by: Miles Chen
> ---
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
ot;mediatek,infracfg" phandle.
I also like the idea of using mediatek,infracfg instead of a list of
platform compatible strings.
Reviewed-by: Miles Chen
>
> In order to keep retrocompatibility with older devicetrees, the old
> way is kept in place.
>
> S
}
init_iova_domain()init_iova_domain()
init_iova_domain() is called at the same time.
>Fix this by protecting init_iova_domain() with iommu_dma_cookie->mutex.
Reviewed-by: Miles Chen
>Exception backtrace:
>rb_insert_color(param1=0xFF80CD2BDB40, p
Hi Yunfei,
> The calling to kmem_cache_alloc for level 2 pgtable allocation may run
> in atomic context, and it fails sometimes when DMA32 zone runs out of
> memory.
>
> Since Mediatek IOMMU hardware support at most 35bit PA in pgtable,
> so add a quirk to allow the PA of pgtables support up to
fore, we need to check the return value of iommu_map_sg_atomic
> in two cases according to whether it is less than 0.
>
> Fixes: ad8f36e4b6b1 ("iommu: return full error code from
> iommu_map_sg[_atomic]()")
> Signed-off-by: Yunfei Wang
Yes, we have to make sure ssize_t &g
Fixes: 635319a4a744 ("media: iommu/mediatek: Add device_link between the
consumer and the larb devices")
Signed-off-by: Miles Chen
---
Change since v2
probe fail if larbdev is NULL so we do not have to worry about release logic
Change since v1
fix a build warning reported by kernel t
Hi YF,
> The calling to kmem_cache_alloc for level 2 page table allocation may
> run in atomic context, and it fails sometimes when DMA32 zone runs out
> of memory.
>
> Since Mediatek IOMMU hardware support at most 35bit PA in page table,
s/Mediatek/MediaTek/
s/support/supports/
> so add a
Hi Yong,
>On Mon, 2022-04-25 at 11:03 +0100, Robin Murphy wrote:
>> On 2022-04-25 09:24, Miles Chen via iommu wrote:
>> > When larbdev is NULL (in the case I hit, the node is incorrectly
>> > set
>> > iommus = < NUM>), it will cause device_link_add()
hi Robin,
>> -link = device_link_add(dev, larbdev,
>> - DL_FLAG_PM_RUNTIME | DL_FLAG_STATELESS);
>> -if (!link)
>> -dev_err(dev, "Unable to link %s\n", dev_name(larbdev));
>> +if (larbdev) {
>
>Until the MT8195 infra MMU support lands, is there
e
consumer and the larb devices")
Signed-off-by: Miles Chen
---
Change since v1
fix a build warning reported by kernel test robot
https://lore.kernel.org/lkml/202204231446.iykdz674-...@intel.com/
---
drivers/iommu/mtk_iommu.c| 13 -
drivers/iommu/mtk_iommu_v1.c | 13 ++
e suggest to use '--base' as documented in
>https://git-scm.com/docs/git-format-patch]
>
>url:
>https://github.com/intel-lab-lkp/linux/commits/Miles-Chen/iommu-mediatek-fix-NULL-pointer-dereference-when-printing-dev_name/20220423-070605
>base: https://git.kernel.org/pub/scm/linux
arb devices")
Signed-off-by: Miles Chen
---
drivers/iommu/mtk_iommu.c| 16 ++--
drivers/iommu/mtk_iommu_v1.c | 16 ++--
2 files changed, 20 insertions(+), 12 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 6fd75a60abd6..140
Hi Joerg, Robin,
> Applied without stable tag for now. If needed, please consider
> re-sending it for stable when this patch is merged upstream.
> Yeah, having figured out the history, I ended up with the opinion that
> it was a missed corner-case optimisation opportunity, rather than an
>
Hi Robin,
> For various reasons based on the allocator behaviour and typical
> use-cases at the time, when the max32_alloc_size optimisation was
> introduced it seemed reasonable to couple the reset of the tracked
> size to the update of cached32_node upon freeing a relevant IOVA.
> However,
ould reset the allocation size if *any* 32-bit space
> has become available.
>
> Reported-by: Yunfei Wang
> Signed-off-by: Robin Murphy
Reviewed-by: Miles Chen
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
>> If no cached iova is freed, resetting max32_alloc_size before
>> the retry allocation only give us a retry. Is it possible that
>> other users free their iovas during the additional retry?
>
> No, it's not possible, since everyone's serialised by iova_rbtree_lock.
> If the caches were already
Hi Yunfei,
>> Since __alloc_and_insert_iova_range fail will set the current alloc
>> iova size to max32_alloc_size (iovad->max32_alloc_size = size),
>> when the retry is executed into the __alloc_and_insert_iova_range
>> function, the retry action will be blocked by the check condition
>> (size
: Christoph Hellwig
Cc: Rob Herring
Cc: Matthias Brugger
Cc: Joerg Roedel
Reviewed-by: Matthias Brugger
Signed-off-by: Miles Chen
---
Change since v4
- remove unnecessary data->enable_4GB = false, since it is kzalloc()ed.
Change since v3
- use lore.kernel.org links
- move "change since..
On Fri, 2020-09-04 at 11:42 +0200, Joerg Roedel wrote:
> On Mon, Aug 31, 2020 at 06:56:39PM +0800, Miles Chen wrote:
> > In previous discussion [1] and [2], we found that it is risky to
> > use max_pfn or totalram_pages to tell if 4GB mode is enabled.
> >
> > Check 4
: Christoph Hellwig
Cc: Rob Herring
Cc: Matthias Brugger
Signed-off-by: Miles Chen
---
Change since v4
- remove unnecessary data->enable_4GB = false, since it is kzalloc()ed.
Change since v3
- use lore.kernel.org links
- move "change since..." after "---"
Change since v2:
On Thu, 2020-08-27 at 20:27 +0100, Robin Murphy wrote:
> On 2020-08-27 06:31, Yong Wu wrote:
> > On Wed, 2020-08-26 at 16:56 +0800, Miles Chen wrote:
> >> In previous discussion [1] and [2], we found that it is risky to
> >> use max_pfn or totalram_pages to
: Christoph Hellwig
Cc: Rob Herring
Cc: Matthias Brugger
Signed-off-by: Miles Chen
---
Change since v3
- use lore.kernel.org links
- move "change since..." after "---"
Change since v2:
- determine compatible string by m4u_plat
- rebase to next-20200720
- add "---&qu
: Christoph Hellwig
Cc: Rob Herring
Cc: Matthias Brugger
Signed-off-by: Miles Chen
---
Change since v3
- use lore.kernel.org links
- move "change since..." after "---"
Change since v2:
- determine compatible string by m4u_plat
- rebase to next-20200720
- add "---&qu
On Wed, 2020-07-22 at 17:19 +0200, Matthias Brugger wrote:
>
> On 22/07/2020 16:19, Miles Chen wrote:
> > In previous discussion [1] and [2], we found that it is risky to
> > use max_pfn or totalram_pages to tell if 4GB mode is enabled.
> >
> > Check 4GB mode by rea
e_4GB only when has_4gb_mode
[1] https://lkml.org/lkml/2020/6/3/733
[2] https://lkml.org/lkml/2020/6/4/136
[3] https://lkml.org/lkml/2020/7/15/1147
Cc: Mike Rapoport
Cc: David Hildenbrand
Cc: Yong Wu
Cc: Yingjoe Chen
Cc: Christoph Hellwig
Cc: Rob Herring
Cc: Matthias Brugger
Signed-off-by:
On Wed, 2020-07-22 at 15:17 +0800, Miles Chen wrote:
> On Tue, 2020-07-21 at 23:19 +0200, Matthias Brugger wrote:
> >
> > On 21/07/2020 13:24, Yong Wu wrote:
> > > On Tue, 2020-07-21 at 11:40 +0200, Matthias Brugger wrote:
> > >>
> > >> On 21/07/2
On Tue, 2020-07-21 at 23:19 +0200, Matthias Brugger wrote:
>
> On 21/07/2020 13:24, Yong Wu wrote:
> > On Tue, 2020-07-21 at 11:40 +0200, Matthias Brugger wrote:
> >>
> >> On 21/07/2020 04:16, Miles Chen wrote:
> >>> In previous discussion [1] and [
On Tue, 2020-07-21 at 11:10 +0200, David Hildenbrand wrote:
> On 21.07.20 04:16, Miles Chen wrote:
> > In previous discussion [1] and [2], we found that it is risky to
> > use max_pfn or totalram_pages to tell if 4GB mode is enabled.
> >
> > Check 4GB mode by readin
] https://lkml.org/lkml/2020/7/15/1147
Cc: Mike Rapoport
Cc: David Hildenbrand
Cc: Yong Wu
Cc: Yingjoe Chen
Cc: Christoph Hellwig
Cc: Yong Wu
Cc: Chao Hao
Cc: Rob Herring
Cc: Matthias Brugger
Signed-off-by: Miles Chen
---
drivers/iommu/mtk_iommu.c | 26
On Wed, 2020-07-15 at 23:05 +0200, Matthias Brugger wrote:
>
> On 02/07/2020 11:37, Miles Chen wrote:
> > In previous disscusion [1] and [2], we found that it is risky to
> > use max_pfn or totalram_pages to tell if 4GB mode is enabled.
> >
> > Check 4GB mode by rea
On Wed, 2020-07-15 at 14:51 -0600, Rob Herring wrote:
> On Thu, Jul 02, 2020 at 05:37:17PM +0800, Miles Chen wrote:
> > Add a description for mediatek,infracfg. We can check if 4GB mode
> > is enable by reading it instead of checking the unexported
> > symbol "max_pfn
Add mediatek,infracfg to iommu node.
Signed-off-by: Miles Chen
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 70b1ffcab7f0..a6f14f68ef7e 100644
--- a/arch
/136
Cc: Mike Rapoport
Cc: David Hildenbrand
Cc: Yong Wu
Cc: Yingjoe Chen
Cc: Christoph Hellwig
Signed-off-by: Miles Chen
---
drivers/iommu/mtk_iommu.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu
Add mediatek,infracfg to iommu node.
Signed-off-by: Miles Chen
---
arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
index db17d0a4ed57..0749b0f4834c 100644
Add a description for mediatek,infracfg. We can check if 4GB mode
is enable by reading it instead of checking the unexported
symbol "max_pfn".
This is a step towards building mtk_iommu as a kernel module.
Cc: Yong Wu
Signed-off-by: Miles Chen
---
Documentation/devicetree/bind
On Thu, 2020-06-04 at 10:25 +0200, David Hildenbrand wrote:
> On 04.06.20 10:01, Miles Chen wrote:
> > To build this driver as a kernel module, we cannot use
> > the unexported symbol "max_pfn" to setup enable_4GB.
> >
> > Use totalram_pages() instead to
To build this driver as a kernel module, we cannot use
the unexported symbol "max_pfn" to setup enable_4GB.
Use totalram_pages() instead to setup enable_4GB.
Suggested-by: Mike Rapoport
Signed-off-by: Miles Chen
Cc: David Hildenbrand
Cc: Yong Wu
Cc: Chao Hao
---
drivers/iommu/m
On Thu, 2019-07-11 at 09:50 +0100, Robin Murphy wrote:
> On 11/07/2019 06:33, miles.c...@mediatek.com wrote:
> > From: Miles Chen
> >
> > This change exports dma_alloc_from_contiguous and
> > dma_release_from_contiguous to modules.
> >
> > Currently, we
On Thu, 2017-11-23 at 09:58 +0100, Christoph Hellwig wrote:
> Can you just resend the original patch with the fixes?
>
No problem. I'll resend the original patch with this fix.
___
iommu mailing list
iommu@lists.linux-foundation.org
On Thu, 2017-11-16 at 16:13 -0800, Andrew Morton wrote:
> On Fri, 17 Nov 2017 06:56:12 +0800 <miles.c...@mediatek.com> wrote:
>
> > From: Miles Chen <miles.c...@mediatek.com>
> >
> > dma-debug reports the following warning:
> >
> > [name:panic
On Sun, 2017-10-01 at 10:04 +0200, Christoph Hellwig wrote:
> On Wed, Sep 27, 2017 at 11:23:52AM +0100, Robin Murphy wrote:
> > > I found that debug_dma_alloc_coherent() and debug_dma_free_coherent()
> > > assume that dma_alloc_coherent() always returns a linear address.
> > > However it's
On Tue, 2017-09-26 at 15:53 +0100, Robin Murphy wrote:
> On 26/09/17 14:24, miles.c...@mediatek.com wrote:
> > From: Miles Chen <miles.c...@mediatek.com>
> >
> > dma-debug report the following warning:
> >
> > [name:panic&]WARNING: CPU: 3 PID: 298
45 matches
Mail list logo
