From: Qiang Yu <yuq825@gmail.com>
To: Henrik Grimler <henrik.grimler@axis.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Eric Anholt <eric@anholt.net>,
Erico Nunes <nunes.erico@gmail.com>, Marek Vasut <marex@denx.de>,
Neil Armstrong <neil.armstrong@linaro.org>,
Andreas Baierl <ichgeh@imkreisrum.de>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Rob Herring <robh@kerrnel.org>,
dri-devel@lists.freedesktop.org,
linux-samsung-soc@vger.kernel.org, lima@lists.freedesktop.org,
linux-kernel@vger.kernel.org, kernel@axis.com
Subject: Re: [PATCH] drm/lima: call drm_mm_init() with a valid allocation range
Date: Tue, 2 Jun 2026 15:16:19 +0800 [thread overview]
Message-ID: <CAKGbVbt6NtBOrnE-ijV2cWLdFcHZTK7tqL6Wxoz9FTS5Sz5H2g@mail.gmail.com> (raw)
In-Reply-To: <20260601-lima-alloc-fix-v1-1-16d3f3b7b780@axis.com>
On Mon, Jun 1, 2026 at 8:04 PM Henrik Grimler <henrik.grimler@axis.com> wrote:
>
> lima_vm_create() is currently run before va_start and va_end are set up,
> meaning they are both 0. lima_vm_create() runs drm_mm_init() with them
> as arguments for the allocator, and if DRM_DEBUG_MM is enabled the
> DRM_MM_BUG_ON check in drm_mm_init then fires, as seen here on
> exynos4412-odroid-u2:
>
> [ 1.736297] ------------[ cut here ]------------
> [ 1.740370] kernel BUG at drivers/gpu/drm/drm_mm.c:931!
> [ 1.745574] Internal error: Oops - BUG: 0 [#1] SMP ARM
> [ 1.750697] Modules linked in:
> [ 1.753734] CPU: 0 UID: 0 PID: 41 Comm: kworker/u16:1 Not tainted 7.0.10-postmarketos-exynos4 #11 PREEMPT
> [ 1.763372] Hardware name: Samsung Exynos (Flattened Device Tree)
> [ 1.769446] Workqueue: events_unbound deferred_probe_work_func
> [ 1.775261] PC is at drm_mm_init+0x9c/0xa4
> [ 1.779339] LR is at lima_vm_create+0x144/0x17c
> [ ... ]
>
> Fix the issue by moving the lima_vm_create() call after va_start and
> va_end are set up.
>
> Fixes: a1d2a6339961 ("drm/lima: driver for ARM Mali4xx GPUs")
> Signed-off-by: Henrik Grimler <henrik.grimler@axis.com>
> ---
> This is a low priority fix and can wait for v7.2, it does not cause
> any real issues as far as I have seen: drm_mm_init() is re-run some
> seconds after first run with correct parameters.
Reviewed-by: Qiang Yu <yuq825@gmail.com>
drm mm in the empty_vm is not used at all, so no issue caused by it.
drm mm of a real per app vm matters but they are initialized properly
after va_start/end set. In fact only the PDE page matters in empty_vm,
I should only create it instead of the full lima_vm.
> ---
> drivers/gpu/drm/lima/lima_device.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/lima/lima_device.c b/drivers/gpu/drm/lima/lima_device.c
> index 0bf7105c8748..7c873e62c16d 100644
> --- a/drivers/gpu/drm/lima/lima_device.c
> +++ b/drivers/gpu/drm/lima/lima_device.c
> @@ -368,12 +368,6 @@ int lima_device_init(struct lima_device *ldev)
> if (err)
> goto err_out0;
>
> - ldev->empty_vm = lima_vm_create(ldev);
> - if (!ldev->empty_vm) {
> - err = -ENOMEM;
> - goto err_out1;
> - }
> -
> ldev->va_start = 0;
> if (ldev->id == lima_gpu_mali450) {
> ldev->va_end = LIMA_VA_RESERVE_START;
> @@ -387,6 +381,12 @@ int lima_device_init(struct lima_device *ldev)
> } else
> ldev->va_end = LIMA_VA_RESERVE_END;
>
> + ldev->empty_vm = lima_vm_create(ldev);
> + if (!ldev->empty_vm) {
> + err = -ENOMEM;
> + goto err_out1;
> + }
> +
> ldev->iomem = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(ldev->iomem)) {
> dev_err(ldev->dev, "fail to ioremap iomem\n");
>
> ---
> base-commit: c453c60fdba437f69209e027b418c4a24143605a
> change-id: 20260529-lima-alloc-fix-2cd5408f6493
>
> Best regards,
> --
> Henrik Grimler <henrik.grimler@axis.com>
>
next prev parent reply other threads:[~2026-06-02 7:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-01 12:03 [PATCH] drm/lima: call drm_mm_init() with a valid allocation range Henrik Grimler
2026-06-02 7:16 ` Qiang Yu [this message]
2026-06-04 4:10 ` Claude review: " Claude Code Review Bot
2026-06-04 4:10 ` Claude Code Review Bot
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=CAKGbVbt6NtBOrnE-ijV2cWLdFcHZTK7tqL6Wxoz9FTS5Sz5H2g@mail.gmail.com \
--to=yuq825@gmail.com \
--cc=airlied@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=eric@anholt.net \
--cc=henrik.grimler@axis.com \
--cc=ichgeh@imkreisrum.de \
--cc=kernel@axis.com \
--cc=lima@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=marex@denx.de \
--cc=mripard@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=nunes.erico@gmail.com \
--cc=robh@kerrnel.org \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
/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