From: "Christian König" <christian.koenig@amd.com>
To: "Jocelyn Falempe" <jfalempe@redhat.com>,
"Jani Nikula" <jani.nikula@linux.intel.com>,
"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
"Tvrtko Ursulin" <tursulin@ursulin.net>,
"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Huang Rui" <ray.huang@amd.com>,
"Matthew Auld" <matthew.auld@intel.com>,
"Matthew Brost" <matthew.brost@intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v8 4/9] drm/ttm: Add ttm_bo_kmap_try_from_panic()
Date: Fri, 6 Jun 2025 14:28:45 +0200 [thread overview]
Message-ID: <dd0532a2-4011-41ec-896d-ec066dc23cbc@amd.com> (raw)
In-Reply-To: <20250606120519.753928-5-jfalempe@redhat.com>
On 6/6/25 13:48, Jocelyn Falempe wrote:
> If the ttm bo is backed by pages, then it's possible to safely kmap
> one page at a time, using kmap_try_from_panic().
I strongly assume that we don't care about locking anything in this case, don't we?
> Unfortunately there is no way to do the same with ioremap, so it
> only supports the kmap case.
Oh, there actually is on most modern systems.
At least on 64bit systems amdgpu maps the whole VRAM BAR into kernel address space on driver load.
So as long as you have a large BAR system you can trivially have access to the MMIO memory.
> This is needed for proper drm_panic support with xe driver.
>
> Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
> ---
>
> v8:
> * Added in v8
>
> drivers/gpu/drm/ttm/ttm_bo_util.c | 27 +++++++++++++++++++++++++++
> include/drm/ttm/ttm_bo.h | 1 +
> 2 files changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index 15cab9bda17f..9c3f3b379c2a 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -377,6 +377,33 @@ static int ttm_bo_kmap_ttm(struct ttm_buffer_object *bo,
> return (!map->virtual) ? -ENOMEM : 0;
> }
>
> +/**
> + *
> + * ttm_bo_kmap_try_from_panic
> + *
> + * @bo: The buffer object
> + * @page: The page to map
> + *
> + * Sets up a kernel virtual mapping using kmap_local_page_try_from_panic().
> + * This can safely be called from the panic handler, if you make sure the bo
"This can *only* be called from the panic handler..."
Apart from those open questions, looks sane to me.
Regards,
Christian.
> + * is the one being displayed, so is properly allocated, and won't be modified.
> + *
> + * Returns the vaddr, that you can use to write to the bo, and that you should
> + * pass to kunmap_local() when you're done with this page, or NULL if the bo
> + * is in iomem.
> + */
> +void *ttm_bo_kmap_try_from_panic(struct ttm_buffer_object *bo, unsigned long page)
> +{
> + if (page + 1 > PFN_UP(bo->resource->size))
> + return NULL;
> +
> + if (!bo->resource->bus.is_iomem && bo->ttm->pages && bo->ttm->pages[page])
> + return kmap_local_page_try_from_panic(bo->ttm->pages[page]);
> +
> + return NULL;
> +}
> +EXPORT_SYMBOL(ttm_bo_kmap_try_from_panic);
> +
> /**
> * ttm_bo_kmap
> *
> diff --git a/include/drm/ttm/ttm_bo.h b/include/drm/ttm/ttm_bo.h
> index cf027558b6db..8c0ce3fa077f 100644
> --- a/include/drm/ttm/ttm_bo.h
> +++ b/include/drm/ttm/ttm_bo.h
> @@ -429,6 +429,7 @@ int ttm_bo_init_validate(struct ttm_device *bdev, struct ttm_buffer_object *bo,
> int ttm_bo_kmap(struct ttm_buffer_object *bo, unsigned long start_page,
> unsigned long num_pages, struct ttm_bo_kmap_obj *map);
> void ttm_bo_kunmap(struct ttm_bo_kmap_obj *map);
> +void *ttm_bo_kmap_try_from_panic(struct ttm_buffer_object *bo, unsigned long page);
> int ttm_bo_vmap(struct ttm_buffer_object *bo, struct iosys_map *map);
> void ttm_bo_vunmap(struct ttm_buffer_object *bo, struct iosys_map *map);
> int ttm_bo_mmap_obj(struct vm_area_struct *vma, struct ttm_buffer_object *bo);
next prev parent reply other threads:[~2025-06-06 12:29 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-06 11:48 [PATCH v8 0/9] drm/i915: Add drm_panic support Jocelyn Falempe
2025-06-06 11:48 ` [PATCH v8 1/9] drm/i915/fbdev: Add intel_fbdev_get_map() Jocelyn Falempe
2025-06-06 11:48 ` [PATCH v8 2/9] drm/i915/display/i9xx: Add a disable_tiling() for i9xx planes Jocelyn Falempe
2025-06-06 11:48 ` [PATCH v8 3/9] drm/i915/display: Add a disable_tiling() for skl planes Jocelyn Falempe
2025-06-06 11:48 ` [PATCH v8 4/9] drm/ttm: Add ttm_bo_kmap_try_from_panic() Jocelyn Falempe
2025-06-06 12:28 ` Christian König [this message]
2025-06-06 13:14 ` Jocelyn Falempe
2025-06-06 14:57 ` Christian König
2025-06-06 19:46 ` kernel test robot
2025-06-06 11:48 ` [PATCH v8 5/9] drm/i915: Add intel_bo_panic_setup and intel_bo_panic_finish Jocelyn Falempe
2025-06-06 13:24 ` Jani Nikula
2025-06-06 11:48 ` [PATCH v8 6/9] drm/i915/display: Add drm_panic support Jocelyn Falempe
2025-06-06 11:48 ` [PATCH v8 7/9] drm/i915/display: Add drm_panic support for Y-tiling with DPT Jocelyn Falempe
2025-06-06 11:48 ` [PATCH v8 8/9] drm/i915/display: Add drm_panic support for 4-tiling " Jocelyn Falempe
2025-06-06 11:48 ` [PATCH v8 9/9] drm/i915/psr: Add intel_psr2_panic_force_full_update Jocelyn Falempe
2025-06-06 13:07 ` ✓ CI.Patch_applied: success for drm/i915: Add drm_panic support (rev8) Patchwork
2025-06-06 13:08 ` ✗ CI.checkpatch: warning " Patchwork
2025-06-06 13:10 ` ✓ CI.KUnit: success " Patchwork
2025-06-06 13:22 ` ✓ CI.Build: " Patchwork
2025-06-06 13:25 ` ✓ CI.Hooks: " Patchwork
2025-06-06 13:27 ` ✗ CI.checksparse: warning " Patchwork
2025-06-06 14:12 ` ✓ Xe.CI.BAT: success " Patchwork
2025-06-08 16:36 ` ✗ Xe.CI.Full: failure " Patchwork
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=dd0532a2-4011-41ec-896d-ec066dc23cbc@amd.com \
--to=christian.koenig@amd.com \
--cc=airlied@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=jfalempe@redhat.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew.auld@intel.com \
--cc=matthew.brost@intel.com \
--cc=mripard@kernel.org \
--cc=ray.huang@amd.com \
--cc=rodrigo.vivi@intel.com \
--cc=simona@ffwll.ch \
--cc=tursulin@ursulin.net \
--cc=tzimmermann@suse.de \
--cc=ville.syrjala@linux.intel.com \
/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