[PATCH v7 5/9] drm/fb_dma: Add generic get_scanout_buffer() for drm_panic

Maxime Ripard mripard at kernel.org
Fri Jan 12 13:56:17 UTC 2024


On Fri, Jan 12, 2024 at 02:41:53PM +0100, Daniel Vetter wrote:
> > +		fb = plane->state->fb;
> > +		/* Only support linear modifier */
> > +		if (fb->modifier != DRM_FORMAT_MOD_LINEAR)
> > +			continue;
> > +
> > +		/* Check if color format is supported */
> > +		if (!drm_panic_is_format_supported(fb->format->format))
> > +			continue;
> > +
> > +		dma_obj = drm_fb_dma_get_gem_obj(fb, 0);
> > +
> > +		/* Buffer should be accessible from the CPU */
> > +		if (dma_obj->base.import_attach)
> 
> This might be a bit too restrictive, since some drivers import dma-buf
> including a vmap. So just checking for ->vaddr might be better. But can be
> changed later on.
> 
> > +			continue;
> > +
> > +		/* Buffer should be already mapped to CPU */
> 
> I'd clarify this comment to state that vaddr is invariant over the
> lifetime of the buffer and therefore needs no locking. Correct locking
> that a) takes all the locks b) never ever stalls for one is absolutely
> crucial for a panic handler that won't make the situation worse.

I think this comment was made to address buffers that are accessible to
the CPU but don't have a CPU mapping (ie, created with
DMA_ATTR_NO_KERNEL_MAPPING for example).

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20240112/5dfd7308/attachment.sig>


More information about the dri-devel mailing list