[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241021163227.1312bbcd@collabora.com>
Date: Mon, 21 Oct 2024 16:32:27 +0200
From: Boris Brezillon <boris.brezillon@...labora.com>
To: Adrián Larumbe <adrian.larumbe@...labora.com>
Cc: Rob Herring <robh@...nel.org>, Steven Price <steven.price@....com>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard
<mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>, David Airlie
<airlied@...il.com>, Simona Vetter <simona@...ll.ch>, Philipp Zabel
<p.zabel@...gutronix.de>, kernel@...labora.com,
dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/9] drm/panfrost: Handle page mapping failure
On Tue, 15 Oct 2024 00:31:40 +0100
Adrián Larumbe <adrian.larumbe@...labora.com> wrote:
> - ops->map_pages(ops, iova, paddr, pgsize, pgcount, prot,
> + ret = ops->map_pages(ops, iova, paddr, pgsize, pgcount, prot,
> GFP_KERNEL, &mapped);
> + if (ret) {
> + /* Unmap everything we mapped and bail out */
> + mmu_unmap_range(mapped, start_iova, is_heap, ops);
> + return ret;
> + }
I'm pretty sure you don't need to know whether this is a heap BO or not
in that path. All you need to do is unmap what you've already mapped,
which gives you some guarantees:
- the pages you unmap must be present (no need to iova_to_phys())
- unmapping one 2M page at a time is not needed, because you know where
the mapped region starts/ends, so you don't need this
"is-this-the-end-of-the-heap-buffer" check that forces us to scan 2M
at a time
Powered by blists - more mailing lists