Linux IOMMU Development
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Kaustabh Chakraborty <kauschluss@disroot.org>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
	Inki Dae <inki.dae@samsung.com>,
	Seung-Woo Kim <sw0312.kim@samsung.com>,
	Kyungmin Park <kyungmin.park@samsung.com>
Cc: iommu@lists.linux.dev, dri-devel@lists.freedesktop.org
Subject: Re: Help: Samsung Exynos 7870 DECON SYSMMU panic
Date: Tue, 24 Jun 2025 18:12:43 +0100	[thread overview]
Message-ID: <0bc60699-eeaa-4121-8d93-0274862f5aed@arm.com> (raw)
In-Reply-To: <544ad69cba52a9b87447e3ac1c7fa8c3@disroot.org>

On 2025-06-18 3:02 pm, Kaustabh Chakraborty wrote:
> Since bcb81ac6ae3c (iommu: Get DT/ACPI parsing into the proper probe path),
> The Samsung Exynos 7870 DECON device (with patches [1], [2], and [3]) seems
> to not work anymore. Upon closer inspection, I observe that there is an
> IOMMU crash.
> 
> [    2.918189] exynos-sysmmu 14860000.sysmmu: 14830000.decon: [READ] PAGE FAULT occurred at 0x6715b3e0
> [    2.918199] exynos-sysmmu 14860000.sysmmu: Page table base: 0x0000000044a14000
> [    2.918243] exynos-drm exynos-drm: bound 14830000.decon (ops decon_component_ops)
> [    2.922868] exynos-sysmmu 14860000.sysmmu:   Lv1 entry: 0x4205001
> [    2.922877] Kernel panic - not syncing: Unrecoverable System MMU Fault!
> [    2.922885] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.16.0-rc2-exynos7870 #722 PREEMPT
> [    2.995312] Hardware name: Samsung Galaxy J7 Prime (DT)
> [    3.000509] Call trace:
> [    3.002938]  show_stack+0x18/0x24 (C)
> [    3.006582]  dump_stack_lvl+0x60/0x80
> [    3.010224]  dump_stack+0x18/0x24
> [    3.013521]  panic+0x168/0x360
> [    3.016558]  exynos_sysmmu_irq+0x224/0x2ac
> [         ...]
> [    3.108786] ---[ end Kernel panic - not syncing: Unrecoverable System MMU Fault! ]---

For starters, what if you just remove this panic() from the IOMMU 
driver? Frankly it seems a bit excessive anyway...

 From the logs below it seems there is apparently unexpected traffic 
already going through the IOMMU when it wakes up. Is this the DRM 
drivers doing something sketchy, or has the bootloader left the display 
running for a splash screen? However in the latter case I don't 
obviously see why delaying the IOMMU probe should make much difference, 
given that the decon driver should still be waiting for it either way.

Thanks,
Robin.

> The commit has been introduced in mainline v6.15-rc1. I've also tested in
> v6.15, v6.15.2, and v6.16-rc2, and there have been no apparent changes.
> 
> I've tried to revert the commit, and it does work that way. But on reading
> the commit message I understand that I need to find a proper solution here.
> I've tried to skim down the revert, and this is what I get - if i change
> line [4] as follows:
> 
> -		dev->bus->dma_configure(dev);
> +		if (!strcmp(dev_name(dev), "14830000.decon"))
> +			dev->bus->dma_configure(dev);
> 
> It really doesn't like dma_configure for some reason. It works, but:
> 
> [    2.779291] exynos-decon 14830000.decon: late IOMMU probe at driver bind, something fishy here!
> 
> I believe the IOMMU hardware doesn't like the fact that it is being
> initialized/resumed too early. I formed this conclusion by comparing the
> logs:
> 
> mainline:
> [    1.274575] I_HAVE_ADDED_THESE: SYSMMU: exynos_sysmmu_resume enter
> [    2.859656] I_HAVE_ADDED_THESE: SYSMMU: __sysmmu_enable enter
> [    2.864192] I_HAVE_ADDED_THESE: SYSMMU: __sysmmu_enable_clocks enter
> [    2.869299] I_HAVE_ADDED_THESE: SYSMMU: write: reg 0x00000000 val 0x00000007
> [    2.875062] I_HAVE_ADDED_THESE: SYSMMU: __sysmmu_init_config enter
> [    2.880006] I_HAVE_ADDED_THESE: SYSMMU: write: reg 0x00000004 val 0x01100784
> [    2.885819] I_HAVE_ADDED_THESE: SYSMMU: __sysmmu_set_ptbase enter
> [    2.890677] I_HAVE_ADDED_THESE: SYSMMU: write: reg 0x0000000c val 0x00044a14
> [    2.896490] I_HAVE_ADDED_THESE: SYSMMU: __sysmmu_tlb_invalidate enter
> [    2.901695] I_HAVE_ADDED_THESE: SYSMMU: write: reg 0x00000010 val 0x00000001
> [    2.907507] I_HAVE_ADDED_THESE: SYSMMU: __sysmmu_enable_vid enter
> [    2.912366] I_HAVE_ADDED_THESE: SYSMMU: write: reg 0x00000000 val 0x00000005
> [    2.912371] I_HAVE_ADDED_THESE: SYSMMU: exynos_sysmmu_irq enter
> [    2.912836] [drm] Exynos DRM: using 14830000.decon device for DMA mapping operations
> [    2.918175] I_HAVE_ADDED_THESE: SYSMMU: exynos_sysmmu_v5_get_fault_info enter
> [    2.918182] I_HAVE_ADDED_THESE: SYSMMU: show_fault_information enter
> [    2.918189] exynos-sysmmu 14860000.sysmmu: 14830000.decon: [READ] PAGE FAULT occurred at 0x6715b3e0
> [    2.918199] exynos-sysmmu 14860000.sysmmu: Page table base: 0x0000000044a14000
> [    2.918243] exynos-drm exynos-drm: bound 14830000.decon (ops decon_component_ops)
> [    2.922859] I_HAVE_ADDED_THESE: SYSMMU: section_entry enter
> [    2.922864] I_HAVE_ADDED_THESE: SYSMMU: lv1ent_offset enter
> [    2.922868] exynos-sysmmu 14860000.sysmmu:   Lv1 entry: 0x4205001
> [    2.922877] Kernel panic - not syncing: Unrecoverable System MMU Fault!
> 
> and with the patch above applied:
> [    3.018478] [drm] Exynos DRM: using 14830000.decon device for DMA mapping operations
> [    3.025794] exynos-drm exynos-drm: bound 14830000.decon (ops decon_component_ops)
> [    3.058655] exynos-dsi 14800000.dsi: [drm:samsung_dsim_host_attach] Attached td4300-panel device (lanes:4 bpp:24 mode-flags:0x23)
> [    3.070189] exynos-drm exynos-drm: bound 14800000.dsi (ops exynos_dsi_component_ops)
> [    3.078506] [drm] Initialized exynos 1.1.0 for exynos-drm on minor 1
> [    3.090747] I_HAVE_ADDED_THESE: SYSMMU: exynos_iommu_map enter
> [    3.090845] I_HAVE_ADDED_THESE: SYSMMU: to_exynos_domain enter
> [    3.093325] I_HAVE_ADDED_THESE: SYSMMU: section_entry enter
> [    3.097662] I_HAVE_ADDED_THESE: SYSMMU: lv1ent_offset enter
> [    3.102000] I_HAVE_ADDED_THESE: SYSMMU: lv1ent_offset enter
> [    3.106337] I_HAVE_ADDED_THESE: SYSMMU: lv1set_section enter
> [    3.110762] I_HAVE_ADDED_THESE: SYSMMU: exynos_iommu_set_pte enter
> [    3.115726] I_HAVE_ADDED_THESE: SYSMMU: exynos_iommu_map enter
> [    3.120317] I_HAVE_ADDED_THESE: SYSMMU: to_exynos_domain enter
> [    3.124914] I_HAVE_ADDED_THESE: SYSMMU: section_entry enter
> [    3.129240] I_HAVE_ADDED_THESE: SYSMMU: lv1ent_offset enter
> [    3.133578] I_HAVE_ADDED_THESE: SYSMMU: lv1ent_offset enter
> [    3.137916] I_HAVE_ADDED_THESE: SYSMMU: lv1set_section enter
> [    3.142340] I_HAVE_ADDED_THESE: SYSMMU: exynos_iommu_set_pte enter
> [         ...] (a lot of repetitions later)
> [    4.322904] I_HAVE_ADDED_THESE: SYSMMU: section_entry enter
> [    4.327230] I_HAVE_ADDED_THESE: SYSMMU: lv1ent_offset enter
> [    4.331567] I_HAVE_ADDED_THESE: SYSMMU: lv1ent_offset enter
> [    4.335905] I_HAVE_ADDED_THESE: SYSMMU: alloc_lv2entry enter
> [    4.340329] I_HAVE_ADDED_THESE: SYSMMU: page_entry enter
> [    4.344407] I_HAVE_ADDED_THESE: SYSMMU: lv2ent_offset enter
> [    4.348744] I_HAVE_ADDED_THESE: SYSMMU: lv1ent_offset enter
> [    4.353082] I_HAVE_ADDED_THESE: SYSMMU: lv2set_page enter
> [    4.357246] I_HAVE_ADDED_THESE: SYSMMU: exynos_iommu_set_pte enter
> [    4.362751] I_HAVE_ADDED_THESE: SYSMMU: exynos_sysmmu_resume enter
> [    4.362767] I_HAVE_ADDED_THESE: SYSMMU: __sysmmu_enable enter
> [    4.362771] I_HAVE_ADDED_THESE: SYSMMU: __sysmmu_enable_clocks enter
> [    4.362777] I_HAVE_ADDED_THESE: SYSMMU: write: reg 0x00000000 val 0x00000007
> [    4.362782] I_HAVE_ADDED_THESE: SYSMMU: __sysmmu_init_config enter
> [    4.362786] I_HAVE_ADDED_THESE: SYSMMU: write: reg 0x00000004 val 0x01100784
> [    4.362791] I_HAVE_ADDED_THESE: SYSMMU: __sysmmu_set_ptbase enter
> [    4.362795] I_HAVE_ADDED_THESE: SYSMMU: write: reg 0x0000000c val 0x00042a64
> [    4.362799] I_HAVE_ADDED_THESE: SYSMMU: __sysmmu_tlb_invalidate enter
> [    4.362803] I_HAVE_ADDED_THESE: SYSMMU: write: reg 0x00000010 val 0x00000001
> [    4.362808] I_HAVE_ADDED_THESE: SYSMMU: __sysmmu_enable_vid enter
> [    4.362811] I_HAVE_ADDED_THESE: SYSMMU: write: reg 0x00000000 val 0x00000005
> 
> Then it continues booting as usual.
> 
> My lack of understanding of the IOMMU and DRM subsystems are really
> limiting my triaging capabilities here, therefore I ask for any form
> guidance or assistance with this.
> 
> Thank you.
> 
> [1] https://lore.kernel.org/r/20250612-exynosdrm-decon-v2-0-d6c1d21c8057@disroot.org
> [2] https://lore.kernel.org/all/20250612-exynos7870-drm-dts-v1-2-88c0779af6cb@disroot.org
> [3] https://lore.kernel.org/all/20250612-exynos7870-drm-dts-v1-3-88c0779af6cb@disroot.org
> [4] https://elixir.bootlin.com/linux/v6.16-rc2/source/drivers/iommu/iommu.c#L431


  parent reply	other threads:[~2025-06-24 17:12 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-18 14:02 Help: Samsung Exynos 7870 DECON SYSMMU panic Kaustabh Chakraborty
2025-06-18 14:06 ` Kaustabh Chakraborty
2025-06-24 17:12 ` Robin Murphy [this message]
2025-06-25  7:39   ` Kaustabh Chakraborty
2025-06-25  8:42     ` Marek Szyprowski
2025-06-25 10:12       ` Kaustabh Chakraborty
2025-06-25 11:34       ` Robin Murphy
2025-06-28 15:39         ` Kaustabh Chakraborty
2025-06-30 12:09           ` Robin Murphy

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=0bc60699-eeaa-4121-8d93-0274862f5aed@arm.com \
    --to=robin.murphy@arm.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=inki.dae@samsung.com \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=kauschluss@disroot.org \
    --cc=kyungmin.park@samsung.com \
    --cc=m.szyprowski@samsung.com \
    --cc=sw0312.kim@samsung.com \
    --cc=will@kernel.org \
    /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