Re: [PATCH] drm/fbdev-dma: fix getting smem_start

From: Thomas Zimmermann
Date: Wed Jun 12 2024 - 09:03:53 EST


Hi

Am 12.06.24 um 10:45 schrieb Daniel Vetter:
On Tue, Jun 11, 2024 at 11:29:58AM +0200, Thomas Zimmermann wrote:
Hi

Am 11.06.24 um 10:23 schrieb Peng Fan:
Subject: Re: [PATCH] drm/fbdev-dma: fix getting smem_start

Hi

Am 11.06.24 um 03:00 schrieb Peng Fan:
Subject: Re: [PATCH] drm/fbdev-dma: fix getting smem_start

Hi

Am 04.06.24 um 10:03 schrieb Peng Fan (OSS):
From: Peng Fan <peng.fan@xxxxxxx>

If 'info->screen_buffer' locates in vmalloc address space,
virt_to_page will not be able to get correct results. With
CONFIG_DEBUG_VM and CONFIG_DEBUG_VIRTUAL enabled on ARM64,
there is dump below:

Which graphics driver triggers this bug?
It is NXP i.MX95 DPU driver which is still in NXP downstream repo.
Which DRM memory manager does that driver use?
DRM_GEM_DMA_DRIVER_OPS
So fbdev-dma would be correct. But with the gem-dma allocator, wouldn't you
allocate from one of these dma_alloc_() calls at [1] ? How does the drivers
end up with vmalloc'd fbdev memory? Specifically in the light of the docs at
[2].
I think when you have an iommu dma_alloc just allocates pages, and uses
the iommu to make it all contiguous for the device, and vmalloc for the
kernel. So it's not allocated with vmalloc(), just ends up getting mapped
into the vmalloc range.

Thanks, that makes sense. As I mentioned in another reply, it might make sense to protect smem_start with an opt-in flag for only that single driver that needs it.

Best regards
Thomas

-Sima


[1] https://elixir.bootlin.com/linux/v6.9/source/drivers/gpu/drm/drm_gem_dma_helper.c#L146
[2] https://elixir.bootlin.com/linux/v6.9/source/Documentation/core-api/dma-api-howto.rst#L124

Best regards
Thomas

I'm asking because if the driver allocates BOs via vmalloc(), should it really
use fbdev-dma?
We use it for fbdev emulation. If drm_kms_helper.fbdev_emulation is 0,
fbdev emulation could be disabled.

Thanks
Peng
Best regards
Thomas

Thanks,
Peng.
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB
36809 (AG Nuernberg)
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)


--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)